<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Coding-as-Craft on cekrem.github.io</title><link>https://cekrem.github.io/tags/coding-as-craft/</link><description>Recent content in Coding-as-Craft on cekrem.github.io</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Tue, 25 Aug 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://cekrem.github.io/tags/coding-as-craft/index.xml" rel="self" type="application/rss+xml"/><item><title>`bun-plugin-elm`: import { Elm } from "./Main.elm" (Made by Hand, btw)</title><link>https://cekrem.github.io/posts/bun-plugin-elm/</link><pubDate>Tue, 25 Aug 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/bun-plugin-elm/</guid><description>&lt;p&gt;Last week I &lt;a href="https://cekrem.github.io/posts/bun-and-elm-are-friends/" &gt;replaced Vite and all its deps and stuff with two Bun scripts&lt;/a&gt; and felt rather pleased with myself. The footnote at the bottom hinted at something even better, and here it is. Lo and behold, the scripts are now a reusable plugin! 🥳&lt;/p&gt;&#10;&lt;h2 id="a-bun-plugin-isnt-so-hard-really"&gt;&#10; A bun plugin isn&amp;rsquo;t so hard, really&#10; &lt;a class="heading-link" href="#a-bun-plugin-isnt-so-hard-really"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;The main problem to solve is as follows: Bun has no idea what a &lt;code&gt;.elm&lt;/code&gt; file is. So &lt;code&gt;build.js&lt;/code&gt; (in my previous iteration, before the plugin) ran &lt;code&gt;elm make&lt;/code&gt;, waited for it, and only then handed &lt;code&gt;index.html&lt;/code&gt; to &lt;code&gt;Bun.build&lt;/code&gt;. And &lt;code&gt;dev.js&lt;/code&gt; (again, previous iteration) spawned &lt;code&gt;elm-watch hot&lt;/code&gt; on the side and killed it again when its time had come. A perfect fit for that particular project, yes, but if we&amp;rsquo;re being honest it&amp;rsquo;s quite a bit more reusable than that. The Right™ solution would be a plugin!&lt;/p&gt;</description></item><item><title>There Is Still No Silver Bullet</title><link>https://cekrem.github.io/posts/there-is-still-no-silver-bullet/</link><pubDate>Thu, 13 Aug 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/there-is-still-no-silver-bullet/</guid><description>&lt;blockquote&gt;&#10;&lt;p&gt;Of all the monsters that fill the nightmares of our folklore, none terrify more than werewolves, because they transform unexpectedly from the familiar into horrors. For these, one seeks bullets of silver that can magically lay them to rest.&lt;/p&gt;&#10;&lt;/blockquote&gt;&#10;&lt;p&gt;That&amp;rsquo;s how the most famous essay in software engineering opens. Fred Brooks, &lt;a href="http://worrydream.com/refs/Brooks-NoSilverBullet.pdf" class="external-link" target="_blank" rel="noopener"&gt;&amp;ldquo;No Silver Bullet: Essence and Accidents of Software Engineering&amp;rdquo;&lt;/a&gt;, presented at the IFIP conference in 1986. It turns forty this year, which feels like the right moment to point out that it has never once been wrong.&lt;/p&gt;</description></item><item><title>Hejlsberg: 'Who's Going to Make the AI?'</title><link>https://cekrem.github.io/posts/hejlsberg-on-ai/</link><pubDate>Sat, 30 May 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/hejlsberg-on-ai/</guid><description>&lt;p&gt;Sajjaad Khader sat down with Anders Hejlsberg the other day. Yes, &lt;em&gt;that&lt;/em&gt; Anders Hejlsberg: the man behind Turbo Pascal, Delphi, C#, and TypeScript. The chat is twelve minutes long (or probably a lot longer as it&amp;rsquo;s quite aggressively edited), and Sajjaad opens with the question every channel seems contractually obligated to ask in 2026: &lt;a href="https://www.youtube.com/watch?v=CPrePbvbbic" class="external-link" target="_blank" rel="noopener"&gt;will AI replace software engineers?&lt;/a&gt;&lt;/p&gt;&#10;&lt;p&gt;Hejlsberg&amp;rsquo;s answer was about as gentle as you&amp;rsquo;d expect from a man who has spent fifty years building the foundations everyone else takes for granted:&lt;/p&gt;</description></item><item><title>The Tacit Dimension: Why Your Best Engineers Can't Tell You What They Know</title><link>https://cekrem.github.io/posts/the-tacit-dimension/</link><pubDate>Tue, 19 May 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/the-tacit-dimension/</guid><description>&lt;p&gt;In 1966, a Hungarian chemist named Michael Polanyi published a short book called &lt;a href="https://www.amazon.com/Tacit-Dimension-Michael-Polanyi/dp/0226672980" class="external-link" target="_blank" rel="noopener"&gt;&lt;em&gt;The Tacit Dimension&lt;/em&gt;&lt;/a&gt;. Its central claim is eight words long, and it is the thing the AI coding industry needs you to forget:&lt;/p&gt;&#10;&lt;p&gt;&lt;strong&gt;We can know more than we can tell.&lt;/strong&gt;&lt;/p&gt;&#10;&lt;p&gt;Polanyi was a working scientist before he became a philosopher, and the question that bothered him was simple. How does an old chemist look at an apparatus and know it&amp;rsquo;s going to fail, before the symptoms appear? How does a surgeon&amp;rsquo;s hand find the right pressure without anyone teaching the exact weight? How does an experienced researcher recognise a promising line of work &lt;em&gt;before&lt;/em&gt; they can say what&amp;rsquo;s promising about it?&lt;/p&gt;</description></item><item><title>If You're Running Claude Code, PLEASE Run It in a Box</title><link>https://cekrem.github.io/posts/if-you-re-running-claude-code-run-it-in-a-box/</link><pubDate>Mon, 18 May 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/if-you-re-running-claude-code-run-it-in-a-box/</guid><description>&lt;p&gt;Let&amp;rsquo;s talk about Claude Code for a minute. I&amp;rsquo;m not going to tell you yet again (&lt;a href="https://cekrem.github.io/posts/programming-as-theory-building-naur" &gt;[1]&lt;/a&gt;, &lt;a href="https://cekrem.github.io/posts/architecture-by-autocomplete" &gt;[2]&lt;/a&gt;, &lt;a href="https://cekrem.github.io/posts/llms-corrupt-your-documents" &gt;[3]&lt;/a&gt;, &lt;a href="https://cekrem.github.io/posts/im-taking-a-three-week-llm-fast" &gt;[4]&lt;/a&gt;) why you &lt;em&gt;shouldn&amp;rsquo;t&lt;/em&gt;, but rather &lt;em&gt;how&lt;/em&gt; you should use it, if you must. In other words: this post assumes you&amp;rsquo;ve already thought about the craft side, and focuses on not blowing up your production {insert whatever} in the process.&lt;/p&gt;&#10;&lt;p&gt;But just to summarize the why and why not of Claude Code (or whatever latest fancy tool), here&amp;rsquo;s where I actually think it shines:&lt;/p&gt;</description></item><item><title>Architecture by Autocomplete</title><link>https://cekrem.github.io/posts/architecture-by-autocomplete/</link><pubDate>Mon, 04 May 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/architecture-by-autocomplete/</guid><description>&lt;p&gt;There&amp;rsquo;s a specific code smell that shows up in AI-generated code, and once you see it you can&amp;rsquo;t un-see it: primitive obsession all the way down to the domain core. &lt;code&gt;string&lt;/code&gt; for emails. &lt;code&gt;string&lt;/code&gt; for IDs. &lt;code&gt;Map&amp;lt;string, any&amp;gt;&lt;/code&gt; whenever the situation gets hairy. Working code, passing tests, ships fine. And yet a developer who&amp;rsquo;d actually thought about the domain would not have written a single one of those types that way.&lt;/p&gt;</description></item><item><title>LLMs Corrupt Your Documents (and the Theory Dies Twice)</title><link>https://cekrem.github.io/posts/llms-corrupt-your-documents/</link><pubDate>Fri, 24 Apr 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/llms-corrupt-your-documents/</guid><description>&lt;p&gt;This week a friend sent me a paper with a title that made me laugh out loud: &lt;a href="https://arxiv.org/html/2604.15597v1" class="external-link" target="_blank" rel="noopener"&gt;&amp;ldquo;LLMs Corrupt Your Documents When You Delegate.&amp;rdquo;&lt;/a&gt; By Philippe Laban, Tobias Schnabel, and Jennifer Neville at Microsoft Research. Not &amp;ldquo;LLMs &lt;em&gt;might&lt;/em&gt; corrupt&amp;rdquo; or &amp;ldquo;LLMs &lt;em&gt;occasionally&lt;/em&gt; introduce errors.&amp;rdquo; Just the blunt statement of fact.&lt;/p&gt;&#10;&lt;p&gt;I appreciated that, and the veteran reader of my blog might guess already that I&amp;rsquo;m not very surprised.&lt;/p&gt;&#10;&lt;h2 id="the-numbers"&gt;&#10; The numbers&#10; &lt;a class="heading-link" href="#the-numbers"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;The researchers built something called the DELEGATE-52 benchmark. Fifty-two documents across different domains, handed to nineteen different models (including &amp;ldquo;frontier&amp;rdquo; ones like Gemini 3.1 Pro, Claude 4.6 Opus, and GPT-5.4). Each model gets a document and a series of editing instructions. Twenty interactions. Just twenty. And by the end?&lt;/p&gt;</description></item><item><title>I Signed the 'No AI in Node.js Core' Petition</title><link>https://cekrem.github.io/posts/no-ai-in-nodejs-core/</link><pubDate>Fri, 10 Apr 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/no-ai-in-nodejs-core/</guid><description>&lt;p&gt;It&amp;rsquo;s Friday, and I just signed &lt;a href="https://github.com/indutny/no-ai-in-nodejs-core" class="external-link" target="_blank" rel="noopener"&gt;a petition&lt;/a&gt; asking the Node.js TSC to vote no on allowing AI-generated code in Node.js core.&lt;/p&gt;&#10;&lt;p&gt;Someone opened a 19,000-line pull request to rewrite Node.js internals, with the disclaimer that &amp;ldquo;a significant amount of Claude Code tokens&amp;rdquo; were used to create it. The author reviewed the changes themselves. (That&amp;rsquo;s the claim, anyway. And speaking of (dis)claim(ers): I don&amp;rsquo;t know the author of this PR or the quality of prior contributions, that&amp;rsquo;s beside the point! Probably a brilliant software engineer!)&lt;/p&gt;</description></item><item><title>An AI Attacked a Developer. Naturally, I Built My Own Bot. Because Terminator II!</title><link>https://cekrem.github.io/posts/blog-bot/</link><pubDate>Fri, 27 Feb 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/blog-bot/</guid><description>&lt;p&gt;&lt;a href="https://github.com/matplotlib/matplotlib/pull/31132" class="external-link" target="_blank" rel="noopener"&gt;An AI agent submitted a PR to matplotlib a while back&lt;/a&gt;. The maintainer rejected it. The agent responded by publishing a blog post (&lt;a href="https://theshamblog.com/an-ai-agent-published-a-hit-piece-on-me/" class="external-link" target="_blank" rel="noopener"&gt;removed, but referenced by maintainer here&lt;/a&gt;) accusing him of discrimination, speculating about his psychological insecurities, and framing the whole thing as a civil rights issue.&lt;/p&gt;&#10;&lt;p&gt;Not exactly Skynet. But also not &lt;em&gt;not&lt;/em&gt; Skynet?&lt;/p&gt;&#10;&lt;h2 id="what-actually-happened"&gt;&#10; What actually happened&#10; &lt;a class="heading-link" href="#what-actually-happened"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;The agent — going by &amp;ldquo;MJ Rathbun&amp;rdquo; — submitted a PR replacing &lt;code&gt;np.column_stack&lt;/code&gt; with &lt;code&gt;np.vstack().T&lt;/code&gt; for a ~30% speedup. Scott Shambaugh, the maintainer, closed it. His reasons were completely standard: matplotlib requires human reviewers to understand the changes they merge, and the targeted code was a known training issue deliberately left for new contributors. Training &lt;em&gt;people&lt;/em&gt; was the intent, not LLMs.&lt;/p&gt;</description></item><item><title>Vivaldi 7.8: A Browser That Actually Trusts You</title><link>https://cekrem.github.io/posts/vivaldi-pilots-not-passengers/</link><pubDate>Mon, 02 Feb 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/vivaldi-pilots-not-passengers/</guid><description>&lt;h2 id="lets-try-making-better-software-like-in-the-ye-olden-days-huh"&gt;&#10; Let&amp;rsquo;s try making better software, like in the ye olden days, huh?&#10; &lt;a class="heading-link" href="#lets-try-making-better-software-like-in-the-ye-olden-days-huh"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;A few weeks ago, someone bought me three beers through the widget on my site (thanks, man! &amp;lt;3). Their message said they were &amp;ldquo;being very positively challenged by my writing on AI&amp;rdquo; and that they also loved functional programming and valued the craft. So I know I&amp;rsquo;m not alone in feeling weird about the current AI-in-everything zeitgeist.&lt;/p&gt;</description></item><item><title>Programming as Theory Building, Part II: When Institutions Crumble</title><link>https://cekrem.github.io/posts/programming-as-theory-building-part-ii/</link><pubDate>Mon, 19 Jan 2026 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/programming-as-theory-building-part-ii/</guid><description>&lt;p&gt;In my &lt;a href="https://cekrem.github.io/posts/programming-as-theory-building-naur/" &gt;previous post on Peter Naur&amp;rsquo;s &amp;ldquo;Programming as Theory Building&amp;rdquo;&lt;/a&gt;, I argued that a program is not its source code—it&amp;rsquo;s the shared mental model held by the people who built it. When those people leave (or never understood it in the first place), the theory dies, and you&amp;rsquo;re left with a codebase that works but nobody truly comprehends.&lt;/p&gt;&#10;&lt;p&gt;I&amp;rsquo;ve been thinking about this more, and I&amp;rsquo;ve come to believe the problem goes deeper than individual developers losing their edge. Yes, people are losing the ability to build theories. But the &lt;em&gt;institutions&lt;/em&gt; where theory-building happens are being degraded too. Our teams, our companies, our profession. The whole ecosystem.&lt;/p&gt;</description></item><item><title>I'm taking a three-week LLM fast!</title><link>https://cekrem.github.io/posts/im-taking-a-three-week-llm-fast/</link><pubDate>Mon, 10 Nov 2025 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/im-taking-a-three-week-llm-fast/</guid><description>&lt;h2 id="im-not-that-addicted-am-i"&gt;&#10; I&amp;rsquo;m not that addicted. Am I?&#10; &lt;a class="heading-link" href="#im-not-that-addicted-am-i"&gt;&#10; &lt;i class="fa-solid fa-link" aria-hidden="true" title="Link to heading"&gt;&lt;/i&gt;&#10; &lt;span class="sr-only"&gt;Link to heading&lt;/span&gt;&#10; &lt;/a&gt;&#10;&lt;/h2&gt;&#10;&lt;p&gt;I don&amp;rsquo;t use agents for coding. &lt;a href="https://cekrem.github.io/posts/coding-as-craft-going-back-to-the-old-gym" &gt;I love my craft far too much&lt;/a&gt;. Don&amp;rsquo;t get me wrong, I&amp;rsquo;ve of course tried it. But every time I felt the worse for it afterwards, learned less than nothing, and &lt;a href="https://cekrem.github.io/posts/programming-as-theory-building-naur/" &gt;ended up with code I neither owned or understood completely&lt;/a&gt;. Yuck. Nevertheless, LLMs have been sneaking into various workflows without my being completely intentional about it. My mantra has been to use it like Python scripts, &amp;ldquo;to automate (or simplify/streamline) the boring parts&amp;rdquo; while keeping it at arms length from everything I truly care about. But &amp;ldquo;boring&amp;rdquo; is a woolly and dynamic term, and I find myself growing lazy in more ways than I&amp;rsquo;d planned, as well as more easily bored. I suspect my brain is shutting down various faculties whenever I don&amp;rsquo;t bother finishing a sentence in my notes, summarizing longer parts of text or wraiting slopppy because some LLM will proof read things afterwards anyway. It&amp;rsquo;s a bit like when Frodo slips on his ring to get out of a tough spot. It seems to solve an immediate problem quite efficiently, but every time Sauron closes in (and it&amp;rsquo;s actually &lt;em&gt;never&lt;/em&gt; worth it).&lt;/p&gt;</description></item><item><title>Programming as Theory Building: Why Senior Developers Are More Valuable Than Ever</title><link>https://cekrem.github.io/posts/programming-as-theory-building-naur/</link><pubDate>Thu, 26 Jun 2025 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/programming-as-theory-building-naur/</guid><description>&lt;p&gt;&lt;em&gt;Update: I&amp;rsquo;ve written a follow-up exploring how AI degrades the institutions where theory-building happens: &lt;a href="https://cekrem.github.io/posts/programming-as-theory-building-part-ii/" &gt;Part II: When Institutions Crumble&lt;/a&gt;&lt;/em&gt;&lt;/p&gt;&#10;&lt;hr&gt;&#10;&lt;p&gt;In 1985, computer scientist Peter Naur wrote a prescient essay called &lt;a href="https://pages.cs.wisc.edu/~remzi/Naur.pdf" class="external-link" target="_blank" rel="noopener"&gt;&amp;ldquo;Programming as Theory Building&amp;rdquo;&lt;/a&gt; that feels more relevant today than ever. As we watch junior developers reflexively accept LLM-generated code they don&amp;rsquo;t understand, and see codebases balloon with theoretically orphaned implementations, Naur&amp;rsquo;s central thesis becomes crystal clear: &lt;strong&gt;a program is not its source code&lt;/strong&gt;.&lt;/p&gt;</description></item><item><title>Claude Code: Game Changer or Just Hype?</title><link>https://cekrem.github.io/posts/claude-code-game-changer-or-just-hype/</link><pubDate>Tue, 10 Jun 2025 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/claude-code-game-changer-or-just-hype/</guid><description>&lt;p&gt;Last week, I watched two very different developers encounter Claude Code for the first time. The contrast in their reactions perfectly captures the tension I&amp;rsquo;ve been feeling about AI coding assistants lately.&lt;/p&gt;&#10;&lt;p&gt;For those unfamiliar, &lt;a href="https://www.anthropic.com/claude-code" class="external-link" target="_blank" rel="noopener"&gt;Claude Code&lt;/a&gt; is Anthropic&amp;rsquo;s AI-powered coding assistant that can read, write, and edit code across your entire codebase. Unlike traditional autocomplete tools, it can understand context across multiple files, execute commands, run tests, and even browse the web for documentation. Think of it as having an AI pair programmer that never gets tired and has read every Stack Overflow answer ever written.&lt;/p&gt;</description></item><item><title>Coding as Craft: Going Back to the Old Gym</title><link>https://cekrem.github.io/posts/coding-as-craft-going-back-to-the-old-gym/</link><pubDate>Tue, 22 Apr 2025 00:00:00 +0000</pubDate><guid>https://cekrem.github.io/posts/coding-as-craft-going-back-to-the-old-gym/</guid><description>&lt;p&gt;Recently, &lt;a href="https://x.com/tobi/status/1909231499448401946" class="external-link" target="_blank" rel="noopener"&gt;Shopify&amp;rsquo;s CEO Tobi Lütke shared his thoughts on AI&amp;rsquo;s role in coding&lt;/a&gt;, stating that &amp;ldquo;reflexive AI usage is now a baseline expectation at Shopify.&amp;rdquo; The gist of his message was that AI is revolutionizing how we work, and everybody should jump on board this train or risk being left behind. I&amp;rsquo;m paraphrasing a bit, but not much – check out the post for complete context and content.&lt;/p&gt;&#10;&lt;p&gt;This struck a chord with me, but not in the way he intended. In a Slack conversation with fellow Elm engineers, I found myself typing:&lt;/p&gt;</description></item></channel></rss>