软件还有手艺吗：Bun 迁 Rust、AI 代工与工业化的未来

Over the last few months, there has been a good ol’ fashioned flamewar over the migration of Bun from Zig to Rust via extremely heavy usage of Claude Code. Last month, Jarred Sumner, creator of Bun, published an in-depth explanation of how and why Bun was migrated to Rust, akin to something you would find on any corporate blog from any tech company with a big engineering department. Shortly thereafter, Andrew Kelley, creator of the Zig programming language, published a screed for the ages, venting about the apparently long dysfunctional relationship between Zig and Bun as well as his and others’ terrible experience working with Jarred. Andrew referred to Jarred as a “stinky manager” and said that “Jarred was already writing slop well before he had access to LLMs”. Both posts are worth reading, the first for a genuinely new and daring approach to software engineering and the latter as an example of a letter that would have been better off burnt than sent. I am grateful for this fiasco, as it gave me a reason to revisit a question that has been bothering me for most of my software engineering career.

To start with, I believe that the production of most software is an industrial process, not a craft process. We work in large, many-thousand-person organizations, on commodity hardware and systems, our roles largely standardized across departments, companies and even countries. Even before the advent of generative AI, we imposed best practices on the production of software, stripping away much of the discretion the individual might have over the fundamentals of how the software was produced. Many decades ago, it was likely true that the production of software was a craft process, done by hand by a skilled individual punching holes in a card, working late into the night, but it’s abundantly clear to me that now, as it is practiced, the production of software is an industrial process by and large. To me, this is not up for debate, it’s self-evident.

What I have wondered for a long time now is whether the production of software should be a craft process. Does better software come from developers and engineers imagining themselves as craftsmen, whittling away at their masterworks year after year? Or does better software come from the imposition of industrial, repeatable, automated processes, with developers and engineers as nothing more than skilled but replaceable workers in the code factory? Is it better to develop and pursue your own personal standard of craftsmanship when coding, or to seek out and embrace industrial best practices wholeheartedly and produce code dispassionately and impersonally?

If you are involved in software development, I would ask that you sit with this a minute and ask your heart how you really feel about the question. Do you want to be creating masterworks or are you fine doing your small part to create commodities? Done? Good. Now, with your newfound perspective, go out and terrorize everyone you meet about it. Anyone who disagrees with you is Wrong and a Bad Person and you are justified in using any and all means necessary to correct their behavior and prevent it from spreading further. Get out there and have some fun!

In the meantime, for those not sufficiently moved to immediately proselytize their new, deeply held and eminently correct opinion, allow me to introduce the tabs vs spaces debate as a path into understanding exactly why the Great Bun Migration of 2026 portends so much about the future of craftsmanship in software development.

Wrong. Tabs are inherently evil.

— Dennis Draheim, “Tabs vs. Spaces”, comp.lang.c, Dec 29, 1988

If I had thought this through, I would have known the answer already, but as I sat down to research and write this post, I was genuinely shocked to learn that people have been arguing about tabs vs spaces for longer than I have been alive. I am firmly in my mid-thirties now and I’ve been told that I need to maintain a rigorous exercise regime lest I want problems later on in life, so it’s good to get the heart pumping every once in a while with surprises like this one.

Death to tabs!

Regards,

Dan, who will always use 3-space, er, tabs.

— Daniel Berger, “Using TABs vs. spaces II. (the Philosophy flamewar reloaded ;-))”, RubyTalk, Jul 2007

For those who have only joined the software industry in the last few years, we used to argue often and loudly about whether code should be indented with spaces or tabs. Nowadays, there are formatters that take care of such things for you automatically, to the point that I couldn’t tell you whether I use tabs or spaces anymore in any of the code I write. There were a couple solid decades where that was definitely not the case though.

I said that braces are redundant information. In other words, if you indent the code correctly, the braces don’t add additional information. In fact, that is tautological: if the braces do add additional information, you’ve indented the program incorrectly. Braces are not Compiler-Fluff.

— T. William Wells, “Braces are not Compiler-Fluff.”, comp.lang.c, Jan 4, 1989

When I first joined the industry over a decade ago, I remember being enthralled with discussions of the merits of tabs/spaces over the perceived sins of spaces/tabs. My seniors would sit around during lunch and opine at length about their preferred way of indenting code. And not just tabs or spaces, but where the newlines should go and why. Should a single-line while loop all go on one line if it can? Or should it go across 3 (or, if you had the luxury, 4) lines, making it clear what was going on and allowing easy modification later? Each language had a dozen little places where you could have your opinion about how it should look, and people certainly did!

C code layout is a classic example of rule-governed behavior in which the rules are inexplicit and often less than half-conscious, but evidently very strong.

— Eric S. Raymond, comp.lang.c, Dec 23, 1988

I remember caring about tabs vs spaces, and formatting more broadly, in a profound way. I had long conversations about the merits of my preferred whitespace, and why it mattered deeply and always would. I couldn’t for the life of me tell you which one I thought was better now, and I can’t be bothered to dig up my old code to know for sure.

in the tabs-vs-spaces debate, i see people saying “tabs lets us customize our tab-width”, as though we do this “for fun” — but this is about meeting the real needs of real people who have real impairments — how is this not seen as a simple cut-and-dry accessibility issue?

— ChaseMoskal, “Nobody talks about the real reason to use Tabs over Spaces”, /r/javascript, 2019

It wasn’t just a preference, people imbued real meaning to tabs vs spaces! You could be wrong and it would affect people’s opinions of you, as irrational as that may sound today. To put a finer point on the depth of the issue culturally, this entire debate was immortalized in a scene in the Silicon Valley TV show, when Richard, the main character, ends things with a woman he would otherwise want to sleep with because she kept using spaces to indent her code.

Richard and Winnie sitting on a couch mid-argument in Silicon Valley; she looks at him with narrowed eyes as he talks.

The tabs-versus-spaces argument, from “Tabs versus Spaces (From Silicon Valley)”, aksonai.

I don’t want to hear any more people’s opinions. I think that has been made clear by locking the topic, even though I have been baited into the discussion yet again. I have all the information, every point that can possibly been made has been made. This topic is the bikeshed of all bikesheds, and as the BDFN I get to choose the color.

— Andrew Kelley, Zig GitHub Issues, Oct 28, 2023

No less than Andrew Kelley has made his position quite clear about how Zig code should be formatted. A Zig program will simply fail to compile if it includes tabs or uses the wrong kind of newline at the end of a line, and zig fmt will not let you use 2 spaces for indentation instead of 4. If you have a problem with this, then you should configure your code editor to handle it for you automatically or use a different language. This has been, apparently, controversial and it takes only half a minute to find long, heated discussion of this all over the place. This was another thing I did not know before I sat down to write this essay, but serendipity provides when one sets out to finally put the Truth to print.

A few years into my career, around 2014, I remember some coworkers arguing about whether we should introduce flake8 into the Python codebase at the place I worked. flake8 checked the Python Enhancement Proposal 8 which detailed how Python code should be formatted. PEP8 was an old proposal, from 2001, and while linters had been around for a while, it was only roughly in the early 2010s that automatic formatters appeared that would tell you where parts of your codebase weren’t formatted “correctly” and then fix it for you. You could use tabs or spaces, it supported both, but I think it would whine if the codebase mixed styles, though it’s been long enough that, again, I cannot exactly recall.

All my coworkers and I had one last discussion about tabs vs spaces, picked one after a perhaps overlong discussion, and that was that, and our codebase started to trend towards one static style. We all installed flake8 and mostly stuck by its formatting suggestions, and later embraced autopep8 as well to make it happen automatically. That last debate wasn’t that fun though, not the way all the other ones were. I can’t recall that we ever really talked about tabs vs spaces again, moving on to other well-worn topics of discussion.

Looking back on it, I remember codebases having so much more personality before automatic formatting. I remember opening up a file and, without having to use git blame or the like, knowing who was the last person to touch this file because who else would do something so weird with all those and’s! I would spend an extra 30 minutes making sure I got all the formatting right, because the senior engineer on the team would reject the changes outright if they didn’t match his standards for how things should look. Found some good bugs that way too, making sure the code looked right. Half the effort of learning a new codebase was learning how to read the idiosyncratic style the team had developed to format the code, let alone how to write it. I wrote lots of little scripts to make sure I was doing it right, and I remember getting better at writing shell scripts because the fear of being called a noob by my older, more experienced peers for not doing things the Right way kept me up at night.

What I think we lost when we adopted formatters was everyone having an obvious and personal sense of connection to the code and the other people who wrote it. Maybe you didn’t have control over what the code did, but, hey, at least, you and your team had some say over how it looked. Now, any sense of personality, of whimsy, of experimenting with the syntax of the language itself, gets sanded away and buffed out and only the impersonal functionality of it all gets left behind.

As a senior engineer who is responsible for implementing best practices and what not for my team, the two paragraphs above are juvenile and dumb and if a junior engineer sent them to me justifying why they turned the formatter off, I would give them help channel duty for a month. Off the clock though, I have to ask myself, don’t you ever want to just let it rip?

Someone asked about the code base. “Currently it’s 247 lines of C.” Some expressions of incredulity. Whitney displayed the source, divided between five text files so each would fit entirely on his monitor. “Hate scrolling,” he mumbled.

— Stephen Taylor, “Impending kOS”, Vector, Sep 1, 2014

typedef char C;typedef long I;
typedef struct a{I t,r,d[3],p[2];}*A;
#define P printf
#define R return
#define V1(f) A f(w)A w;
#define V2(f) A f(a,w)A a,w;
#define DO(n,x) {I i=0,_n=(n);for(;i<_n;++i){x;}}
I *ma(n){R(I*)malloc(n*4);}mv(d,s,n)I *d,*s;{DO(n,d[i]=s[i]);}
tr(r,d)I *d;{I z=1;DO(r,z=z*d[i]);R z;}
A ga(t,r,d)I *d;{A z=(A)ma(5+tr(r,d));z->t=t,z->r=r,mv(z->d,d,r);
R z;}
V1(iota){I n=*w->p;A z=ga(0,1,&n);DO(n,z->p[i]=i);R z;}
V2(plus){I r=w->r,*d=w->d,n=tr(r,d);A z=ga(0,r,d);
DO(n,z->p[i]=a->p[i]+w->p[i]);R z;}
V2(from){I r=w->r-1,*d=w->d+1,n=tr(r,d);
A z=ga(w->t,r,d);mv(z->p,w->p+(n**a->p),n);R z;}
V1(box){A z=ga(1,0,0);*z->p=(I)w;R z;}
V2(cat){I an=tr(a->r,a->d),wn=tr(w->r,w->d),n=an+wn;
A z=ga(w->t,1,&n);mv(z->p,a->p,an);mv(z->p+an,w->p,wn);R z;}
V2(find){}
V2(rsh){I r=a->r?*a->d:1,n=tr(r,a->p),wn=tr(w->r,w->d);
A z=ga(w->t,r,a->p);mv(z->p,w->p,wn=n>wn?wn:n);
if(n-=wn)mv(z->p+wn,z->p,n);R z;}
V1(sha){A z=ga(0,1,&w->r);mv(z->p,w->d,w->r);R z;}
V1(id){R w;}V1(size){A z=ga(0,0,0);*z->p=w->r?*w->d:1;R z;}
pi(i){P("%d ",i);}nl(){P("\n");}
pr(w)A w;{I r=w->r,*d=w->d,n=tr(r,d);DO(r,pi(d[i]));nl();
if(w->t)DO(n,P("< ");pr(w->p[i]))else DO(n,pi(w->p[i]));nl();}

C vt[]="+{~<#,";
A(*vd[])()={0,plus,from,find,0,rsh,cat},
(*vm[])()={0,id,size,iota,box,sha,0};
I st[26]; qp(a){R a>='a'&&a<='z';}qv(a){R a<'a';}
A ex(e)I *e;{I a=*e;
if(qp(a)){if(e[1]=='=')R st[a-'a']=ex(e+2);a= st[ a-'a'];}
R qv(a)?(*vm[a])(ex(e+1)):e[1]?(*vd[e[1]])(a,ex(e+2)):(A)a;}
noun(c){A z;if(c<'0'||c>'9')R 0;z=ga(0,0,0);*z->p=c-'0';R z;}
verb(c){I i=0;for(;vt[i];)if(vt[i++]==c)R i;R 0;}
I *wd(s)C *s;{I a,n=strlen(s),*e=ma(n+1);C c;
DO(n,e[i]=(a=noun(c=s[i]))?a:(a=verb(c))?a:c);e[n]=0;R e;}

main(){C s[99];while(gets(s))pr(ex(wd(s)));}

— Arthur Whitney, “An Implementation of J” (Incunabulum), jsoftware.com, summer 1989

The Go programming language was announced by Google in November 2009, after having been worked on internally since 2007. It was designed by Unix and C pioneers and legends like Ken Thompson and Rob Pike. The day after its release, someone posted the following about Go’s gofmt formatting tool that came along with the language.

I think it’s pretty neat that a source code formatting tool is provided along. It’s also a nice thing that the parser/ast/pretty printer are available as mods.

However, I’m not sure that trying to enforce a formatting style by denying the ability to configure the formatter (as the FAQ mentions) is a good idea. It could be good that at least the go/printer package allows more flexible configuration even if the command-line gofmt tool doesn’t.

I don’t think it’s so bad that different C/C++ project use different set of conventions and I doubt that the plans of encouraging everyone to use the same style by making go/printer non-configurable will really work. Instead, I expect that many people will do what I intend to and customize it, even at the cost of pulling go/printer out and including a tweaked version of it in the formatting tool source tree (opening braces at end of if/else/etc. instead of on their own lines drastically reduce readability for me)

— Antoine Chavasse, golang-nuts, Nov 11, 2009

Russ Cox, an early member of the Go team, had this to say in direct response:

We hope that people will accept the output of gofmt precisely because it puts an end to these kinds of style debates. How many different brace styles are there in C? Too many.

Personally I find it liberating to let gofmt format for me, because it means I have more neurons available for attacking interesting programming problems. There are things I don’t like about gofmt’s output, but I love not worrying about them anymore.

— Russ Cox, golang-nuts, Nov 11, 2009

In a follow-up post about gofmt a month later, Cox had this to say:

The most obvious benefit of using gofmt is that when you open an unfamiliar Go program, your brain doesn’t get distracted, even subconsciously, about why that brace is in the wrong place; you can focus on the code, not the formatting.

— Russ Cox, “Gofmt”, swtch.com, Dec 15, 2009

That post is a worthwhile read; it gets into the benefits of what happens when your programming language has one canonical format for all programs and why that’s worth all the difficulties of making that possible in your programming language compiler. We’ll return to that subject of linting and types later on, don’t you worry. For now, though, here are some more thoughts from the Go team.

Go is efficient, scalable, and productive. Some programmers find it fun to work in; others find it unimaginative, even boring. In this article we will explain why those are not contradictory positions. Go was designed to address the problems faced in software development at Google, which led to a language that is not a breakthrough research language but is nonetheless an excellent tool for engineering large software projects.

— Rob Pike, “Go at Google: Language Design in the Service of Software Engineering”, 2012

Software engineering A personal definition: To maximize the quality of software a given group of programmers can create. Our programmers are Googlers, not researchers. For a new language, practicality and ease of adoption are critical.

The key point here is that our programmers are Googlers, not researchers. Typically fairly young, fresh out of school, probably learned Java, maybe learned C or C++, probably learned Python. They are not capable of understanding a brilliant language, but we want to be able to use them to build good software. And so the language that we give them has to be easy for them to understand and easy for them to adopt.

— Rob Pike, “From Parallel to Concurrent”, Lang.NEXT, 2014, 20:40

An explicit design goal of Go was that any Joe Schmo from a second-tier university like Cornell or Columbia could come in and write performant code at Google scale, obviating the need for a PhD in C++ Template Studies that was theretofore required. As well, in reading up on the design documents and listening to these presentations, I found that the Go team placed a large emphasis on huge programs written in Go compiling fast. In point of fact, Go was initially conceived while waiting for a large C++ codebase to compile.

I started another compilation, turned my chair around to face Robert, and started asking pointed questions. Before the compilation was done, we’d roped Ken in and had decided to do something. We did not want to be writing in C++ forever, and we—me especially—wanted to have concurrency at my fingertips when writing Google code. We also wanted to address the problem of “programming in the large” head on, about which more later.

— Rob Pike, “Less is exponentially more”, 2012

I focus on these two things, making it easier to write performant code and speed up the compilation process, because both of them map neatly onto economic terms, specifically deskilling and work intensification. Google spent untold millions to create a programming language that made it possible for them to hire less skilled, cheaper labor while also getting more work out of them in less time.

In economics, deskilling is the process by which skilled labor within an industry or economy is eliminated by the introduction of technologies operated by semi-skilled or unskilled workers. This results in cost savings due to lower investment in human capital, and reduces barriers to entry, weakening the bargaining power of the human capital. Deskilling is the decline in working positions through the machinery or technology introduced to separate workers from the production process.

— Wikipedia, “Deskilling”, Jul 2026

Work intensification has been defined as “the rate of physical and/or mental input to work tasks performed during the working day”. Work intensity comprises several elements, including the rate of task performance; the intensity of those tasks in terms of physical, cognitive, and emotional demands; the extent to which they are performed simultaneously or in sequence, continuously, or with interruptions; and the gaps between tasks.

— Trades Union Congress, “Work intensification”, Jul 2023

I remember the one and only job I had where I worked daily with a C++ codebase. It sucked. I would hit compile and walk away from the computer for a half hour and go watch the senior developer drive Emacs with a keyboard and a joystick he had jury-rigged with elisp to be hooked up to etags. I still feel my face get red when I recall being that intern and telling him I was pretty good with Emacs and then asking him why he had a joystick on his desk and slowly losing my mind as he flew through the Mathematica kernel like a fucking fighter pilot. Cameron, I hope you are doing well, you are a legend, I learned so much from you, thank you!

Two stick figures sword-fight in office chairs while their code compiles; caption: “The #1 programmer excuse for legitimately slacking off: ‘My code’s compiling.’”

— Randall Munroe, “Compiling”, xkcd, Aug 15, 2007.

Let me be clear, I don’t think it was wrong or anything for Google to make Go. It wasn’t obviously the right choice at the time for Google to invest into building Go, but it is obviously the right choice now after more than fifteen years of success after success with Go. It’s a long-term investment that has enabled Google to grow and grow and grow into one of the most valuable companies in the history of the world. And a big part of that growth strategy was them being able to hire less skilled labor to do more of the work than before, and also being able to extract more work out of them because Go compiled so much faster than C++ by design.

I was asked a few weeks ago, “What was the biggest surprise you encountered rolling out Go?” I knew the answer instantly: Although we expected C++ programmers to see Go as an alternative, instead most Go programmers come from languages like Python and Ruby. Very few come from C++.

— Rob Pike, “Less is exponentially more”, 2012

But I also understand why the C++ people didn’t flock to Go. Why would they? It cut their bargaining power in the labor market and workplace! If they used Go, they would have fewer excuses to slack off some during the day, and all that knowledge about C++ performance wouldn’t be so useful to them or their employers anymore, they wouldn’t be as special. Likewise, for the less skilled programmer previously unable to perform a lucrative task like code at Google scale, a technology that deskills a particular economic activity is incredibly empowering. Oh, I never took a proper programming language course and don’t know nothing about the sharp edges of concurrency, but I can write a web server in Go that gets sick performance and maybe gets me a promotion? Sign me up!

For my part, I never liked Go that much. I could tell that Go was an attack on the humble artisanal C++ templatesmiths, and therefore should be rejected out of hand, out of solidarity, from the start! No, not so much, I tried to love it for a week and just never found anything I liked that much about it. It never made my heart sing.

Not like Clojure did at least.

[Development Speed slide on screen] So what kind of runner can run as fast as they possibly can from the very start of a race, right? Only somebody who runs really short races.

But of course we are programmers and we’re smarter than runners apparently because we know how to fix that problem. We just fire the starting pistol, every hundred yards and call it a new sprint.

— Rich Hickey, “Simple Made Easy”, 2011, 17:10

If you’ve read enough forums about programming and software in the last decade or so, I’m sorry for making you flinch like that, thinking this was going to turn into another Clojure evangelism essay. For everyone else, Clojure is a powerful programming language created by Rich Hickey that turns impressionable minds, young and old, into raving artisans, seekers of simplicity, walking down the path of Decomplection, while never leaving the comfort of your hammock.

I was one such mind, and I’m grateful for it. Though it’s rare now, when I do write code by hand, no matter what language, I’m secretly writing Clojure, with lots of functions and clean data structures and maps. I’ve been that guy who snuck Clojure into workplaces by way of a microservice here and another over there, justifying it because Clojure has that one special library that makes this one really important thing we really care about so much easier, I promise!

There’s hundreds of essays across the internet about why you should learn Clojure, even if you never get a job writing it. Broadly, I agree: broadening your horizons is a good thing, and Clojure has some real good stuff in it that most would benefit from encountering and incorporating into their thinking about how to develop software. What you should be careful with though is the ideology that comes along with it.

Rich Hickey has, bucket for bucket, one of the most impressive records for giving talks that make you want to walk into your company’s codebase and light it on fire. Any senior developer watching “Simple Made Easy” on the company VPN should set off those Kill Bill sirens in the CTO’s office and a katana should drop down from the drop ceiling panels, because that CTO is about to have to defend themselves and their timelines for the next quarter from a dozen meetings about how they need to urgently address the creeping horror that is Mutable State. They should have after school programs like D.A.R.E. for project managers that teach them how to watch out for developers showing signs of enjoying “Hammock Driven Development”.

A round kids’ sticker: a cartoon cat and dog in rainbow shirts give a thumbs up under the word “FRIENDS”, ringed by the text “DON’T LET FRIENDS TRY IMMUTABLE STATE”.

Do not get me wrong, Rich Hickey, and the Clojure community by extension, give great talks about compelling ideas, that’s exactly my point. What I am warning about is that they embody deeply and argue convincingly the idea that the production of software should be a craft process. That you, as an individual, should deeply think about the program you are going to write before writing it, that you should prefer simple, well-understood tools applied in masterful ways rather than complex, magical ones that invite too much complexity and therefore, sadly but obviously, disaster. That an individual armed with a powerful language and honed skills can go so much further, so much faster than a whole team of people who aren’t thinking so deeply, working with tools that aren’t so sharp.

A cartoon in the style of Gary Larson’s “Cow tools”: a cow stands behind a table of crude implements — a lambda, a cube marked with a list and a tree, a magnifying glass reading “a b c” — with a barn slung in a hammock behind it. Caption: “Functional tools”.

As someone who has at earlier times in my life struggled to fit into society, there is an underlying appeal to Clojure and other Lisps, and to the idea of software as craftsmanship as a whole, that I wouldn’t have to deal with other people if I could just find the right set of tools and train myself to use them well enough to produce code good enough that nothing else really mattered. If I could just have gotten the parentheses to balance out right then I could have had my solitude and taken on life at my own pace, in my own way.

Those feelings went away as I got older, got a social life, integrated better into society and generally chilled out as a person. The question that remains though to me, again, is whether we should aspire to be craftsmen and craftswomen of software. Is the Hickeyian mode of production best for software? I urge you to ask yourself this question, and accost friends, family, coworkers, and strangers with your answer.

— Tim Ewald, “Clojure: Programming with Hand Tools”, ClojureTV, Jan 8, 2014

All work which would be irksome to do by hand is done by immensely improved machinery; and in all work which it is a pleasure to do by hand machinery is done without.

— William Morris, News from Nowhere, 1890

A desire to return to working with one’s own hands with simple tools making perfect things of their own design is not unique to the Clojure community. Over the years, I have worked with a surprising number of people who enjoyed doing woodworking in their spare time.

The Machine may be against Life, but it certainly saves one a lot of work.

— Janet Malcolm, “About the House”, The New Yorker, May 13, 1967

While listening to my coworkers talk about their latest project in the lull before stand-up meetings, I once detected a debate and pushed on it, and I was surprised to learn that there was a good amount of civil discussion about the use of power tools within the hobby woodworking community. The matter has more or less been settled in industry: they have work to do and money to make, and of course they are using the power tools as much as makes sense.

Norm! Norm! Norm! Norm! (crowd goes crazy) Four more years, four more years…

Some of you might have guessed that I’m a bit infatuated with power tools. I’m an engineer (at least the degree says so…), so I see a peculiar beauty in any machine that works well, be it a tool or a camera or an airplane. I just like good tools, and for me that’s a significant part of my enjoyment of this hobby.

That said, I’ve begun to appreciate how people can enjoy using a well-tuned handplane. It’s true what they say, there really is nothing like the sound & feel of a good plane doing it’s job… Not to worry though…I won’t give up my power tools, NEVER!

— Just_George, “Neander or Normite?”, Southeast Michigan Woodworkers Forum, Mar 29, 2004

For the hobbyists though, a line separates the lovers of power tools from those of hand tools, with perhaps a silent majority of hybridists in between, buying maybe, just one or two power tools to cut down on the stuff they really don’t like doing, but never giving fully into the devil’s juice that is electricity.

I came to the realization that working with wood is a fundamental human experience. […] Classical woodworking is not the kind of technology that comes and goes; it never becomes dated, or changes and becomes obsolete. It will always be there as long as there are trees and metal and muscles. […] Using a hand tool, you can often accomplish a task in one-tenth the time it would take using a seemingly superior modern tool or technique. Consider the ax. It’s phenomenal, just amazing, what you can do with an ax.

— Roy Underhill, “An Interview With Roy Underhill, Host of The Woodwright’s Shop”, Mother Earth News, Nov 1, 1985

The hobbyists gave themselves and each other names even. The hand tool lovers called themselves “Galoot”, “Neanderthal”, their hero Roy Underhill became “St. Roy”, their best vintage and well-cared-for tools were “Crispy”, and power tools were dismissed as “Tailed Apprentices”. “Normites” of course had their own jargon. It was all pretty copacetic as far as my cursory investigation has revealed. The hobbyists drew their own lines around what they thought was good and fun, while the industry pumped out ever more powerful tools that could take in a raw tree and shit out a whole cabinet.

Woodworking professionals and hobbyists, after many centuries and rapid, shocking technological advancements, seem to have mostly figured out their stances broadly speaking and exist in a nice harmony. Surely, a young and upcoming field full of bright young minds like the software industry would learn from this history and have peaceful and productive discussions about the state of their industry and the proper use of automated tools.

Right?

What klutz had the idea of high level languages. Should be retroactively killed. Anyone got an time machine? :-)

— Neil Franklin, alt.folklore.computers, Nov 29, 1998

BBTW, the ‘C’ compiler is a complete piece of shit. It produces some of the worst code I have ever seen (trying to do a matrix multiply in 3210 ‘C’ ran 5 times slower than the host 68k on a Quadra 700 - rewriting the same in assembler ran 7-8 times faster). If you do any serious 3210 programming, you will need to learn 3210 assembler.

— Walter Horat, comp.sys.mac.hardware, Dec 4, 1993

Clearly because the problem this “useless program” so clearly demonstrates is found in virtually every other function that C is used to compile. It is clear evidence that C optimizes like shit.

It is clear that C pushers wish to ignore this fact.

— Scott Nudds, comp.arch.embedded, Dec 29, 1996

However once the specs are out there (or once the chips become well understood) hand coded assembly will beat compilers hands down.

— Paul Hsieh, comp.os.linux.development.apps, Mar 18, 1996

Correct, unless the assembler sees a segment override or a base or index register, it won’t know it’s a memory reference even if there are brackets. This fact is documented somewhere and is an artifact of the fact that the mental incompetants who designed MASM were C geeks and designed the whole assembler ass-backwards with typed data and untyped operations, whereas in fact things are the other way around in assembly language. The fact that it screws up forward references is inexcusable, this is exactly what an assembler is FOR!

— John Wilson, alt.lang.asm, Mar 22, 1994

Btw, the term that “todays compilers beat human assembly code” applies mainly to bloody beginners and people concentrating on pure theory.

— TS, comp.lang.asm.x86, Oct 1, 2000

I prefer avoiding bastard languages like C.

— Scott Nudds, comp.lang.asm.x86, Apr 24, 1997

I think the key here is NEVER trust a compiler when you have time critical code to write. I have written many real time drivers and since I switched to ‘c’ instead of assembly a few years back, I have noticed that compiler technology leaves a lot to be desired.

— rogerc, comp.lang.c.moderated, Apr 11, 1995

I also do assembly language on the 8051 because I’m not convinced that a HLL can do a good job. Flame me if you like.

— Roger Ivie, alt.folklore.computers, Jan 16, 1991

Allowing a hotshot who doesn’t understand how the compiler works to try to hand-optimize is insane.

— Mark C. Carroll, comp.arch, May 13, 1992

Ah, the good ol’ days. The above is a mix of genuine bile that users of Usenet liked to spit at each other, as well as some slightly more substantive discussion of the use of automated tools like compilers. Compilers weren’t new in Usenet’s day, but they also weren’t so good yet, nothing compared to the likes of GCC and LLVM today. So users had legitimate complaints about them, that have largely been resolved with time and much development effort on the behalf of the compiler makers. I would understandably be pissed too if I was trying to use a nail gun and even once the nail shot out the wrong end!

My impression is that woodworkers and software developers are alike in that people engaged in both industries often enjoy doing more of that kind of thing as a hobby in their free time. They were likely good at working with wood/code in the first place and maybe that’s why they pursued a career in doing it full time and professionally. Where I think they differ is that a woodworker would not argue often and perhaps even loudly that they should be allowed to use the hand tools they use as part of their hobby in order to accomplish their professional tasks at work.

And, yet, many software developers who aspire to create high quality code with good craftsmanship want to bring the tools they use as part of their hobbies, like Clojure, Haskell, Elixir, and other functional and/or esoteric languages, to the workplace and use them instead of the more, shall we say, industrial languages already in use there, like TypeScript, Python, Java, and Ruby.

Why is that? As I’ve said, I’ve felt the impulse myself and so I will only comment on what I was doing and why. Sometimes the work was not inspiring, and I felt that it was perhaps beneath a coder of my caliber. I knew several functional languages! I had read a bunch of books about them! I had a hammock that I sat in sometimes! Why was I having to use Python to write CRUD apps? Sneaking Clojure in was a pressure release valve, one that let me take down the dissonance between my self-image as a craftsman and the fact that the work I was doing did not require high quality code in that way. It was important that the work was done, but how “well” it was done, not so much.

I didn’t like what I was doing at times, so I tried to at least be pleased with how I was doing it. It’s embarrassing to admit all this, and I wish I had realized the dynamic in myself earlier on.

At some point though, I lost that drive up the mountain towards quality. It was a gradual process, starting before I even knew about Clojure or much about software development in general. In college, I installed Emacs and Linux on my laptop as my operating system and dove into learning how it all really worked. I had to install so many packages, and do so much just to be able to do everything else all my peers were doing on their MacBooks and Windows machines. I learned so many macros and key bindings and was flying around my file system looking at everything. I knew I was learning more about how computers really worked and those others were just, I don’t know, learning the things we were supposed to be learning.

At least once a semester I did something that turned my computer into a complete tire fire. I think I uninstalled Python one time because I was trying to install a new version and everything just broke on the spot, couldn’t tell you why. I spent a day or two fixing it, and I learned a lot about Python versions and backups. But I didn’t really do much else for a while and that started to annoy me quite a bit. I had other things I wanted to do besides maintaining my laptop. So I sold out.

I remember loving my MacBook Air when I first got it. It was so easy to do stuff! I would update the versions of things and nothing would break. I couldn’t look at the source code for the operating system and I found myself not caring in the slightest. I was on to bigger and better things, like learning Clojure!

Looking back on it, that was probably the first sign that I was perhaps not a craftsman at heart. How could a craftsman abandon such fine tools just because they don’t know how to use them properly? I had that same feeling of relief later on when I switched from Emacs to VS Code. It was my third job out of college and VS Code was getting really popular and everybody on my team was using it. I wanted to do some pair programming with them, and the VS Code session sharing plugin was a siren call to my ears as a remote worker. Maybe, I could just use VS Code for pair programming and then Emacs for the real serious work I had to get done? Yeah that could work.

Anyway, I just use VS Code now and I haven’t done anything serious in Emacs in years. Likewise, I couldn’t tell you the last time I used Clojure, as I am now a surprisingly content user of Rust, Python, and TypeScript, as well as a disgruntled combatant of Terraform. As I worked more in the industry, on teams and across departments, I came to think of myself as less of a craftsman and more of a better worker.

I caught myself thinking less and less about how to achieve code with the highest quality and more and more about just writing some code to unblock the next person down the line. If I spent too long digging in, chasing perfection, the assembly line and Jira board might get backed up behind me, and we can’t have that now, can we.

As I worked more, I fell ass backwards into being a DBA and then a DBRE and it took me further and further away from software development. My thoughts shifted over to reliability, on call schedules, and making sure that the changes we made were safe and wouldn’t crash the system.

I started to learn Rust in my free time, as it seemed interesting, and I found that as I was on call for systems that were impacted by systems other people wrote, I cared more about the reliability of everything as a whole. The systems not crashing and not waking me up in the night mattered way more to me than how good the architecture diagrams looked. Code quality and reliability often go hand in hand, but they are not the same thing at the end of the day.

Pardon me this digression, but did you know that people used to protest the laws that required you to wear your seat belt? No, really!

Automobiles were invented in 1886 by Carl Benz. Mass production of the automobile began in 1901 by Ransom Olds (apparently the namesake of the Oldsmobile, who knew) and really kicked off with the Ford Model T in 1908. And as cars became more widespread, so did accidents and deaths. Roughly speaking as a nonhistorian not aiming for rigor, with the increased usage of automobiles by the American populace as well as many roadways funded by Congress in 1916, 1921 and 1926, traffic deaths reached their peak in 1937, with about 30 deaths for every 100,000 people in the United States. The subsequent war and ongoing Great Depression seem to have caused per capita deaths to drop sharply, and after climbing back through the 1950s the rate was around 20 deaths per 100,000 by about 1960. However, the passing of the Federal-Aid Highway Act of 1956, along with the buildout of the highway, caused deaths to spike up again to ~26 per 100,000 people in the late 1960s. And then deaths began a slow, gentle glide down towards today’s rate of about 12 per 100,000 people. What happened?

There are many reasons why people stopped dying so often in car crashes, it’s a long, complicated history. So, by your leave, I’ll just be focusing on one part of it, namely the invention and diffusion of the miracle that is the three-point seat belt, and the American government’s various interventions to compel its usage onto the unwilling and rebellious general public.

The modern three-point seat belt was invented in 1959 by Volvo engineer Nils Bohlin. Volvo believed so strongly that they had a responsibility to save human lives that they made the patent free for their competitors to use. A decade or so on, with people still needlessly dying in car crashes around the country every day, the U.S. federal government mandated in 1968 that all cars must have seat belts installed by the manufacturers.

Even though all new cars had them, people still weren’t wearing them in 1973 and 1974. So the Nixon administration looked at the car fatality statistics and mandated that, starting with the 1974 model year, every new car be fitted with a seat belt ignition interlock: a device that would not let the engine start unless the driver’s seat belt was buckled.

A still from a 1974 GM dealership training film showing a driver buckling a seat belt in a Chevrolet.

Buckling up in a 1974 Chevrolet, from “1974 Chevrolet / GM Safety Belt System Dealership Promotional Sales Training Film”, The Emulsion Alchemist.

Within a year, Congress had passed a law rolling back this mandate by the administration and also forbidding any future presidential administrations from ever trying something like that again. Drivers hated the interlock system so much that they overwhelmed congressional offices with complaints. Oftentimes, the interlock systems were faulty and cars would simply not start despite drivers buckling their seat belts. People hated the ignition interlock system, and the US government backed off, scared.

But, people were still dying every day from car accidents, deaths that could have been prevented by seat belts. By the early 1980s, seat belt usage was still pretty low, with only about 11 percent of front-seat occupants actually wearing them. So the Reagan administration launched a campaign to get state legislatures to mandate seat belt usage, enforced by local law enforcement, and over the next few years several states did.

That’s when the protests began again. Radio hosts began decrying the mandatory seat belt laws as overreach by distant, authoritarian Big Brother. Many argued that it was safer to be “thrown clear” through the windshield or out the window, than it was being held back by the seat belt during an accident. Incredible, but hey, they didn’t have the internet back then. Some of these movements even won: Massachusetts voters repealed their brand new seat belt law by referendum in November 1986, and the state didn’t get another one until 1994. But mostly, people actually started wearing them and finally people stopped needlessly dying so much. Nowadays, culturally, the only people I would expect to not regularly wear seat belts are stupid teenagers who are reinventing time honored ways to rebel against society.

In short, though many, many other factors were at play, seat belts have saved hundreds of thousands of lives in America thanks to waves of concerted, paternalistic effort by the public and private sectors explicitly against the will of the American people at times. Seat belt usage is now so common as to be thoroughly unremarkable, somehow surprisingly absent from the raging culture wars in America and abroad.

A line chart of the vehicular fatality-risk index for car and LTV occupants from 1960 to 2012, indexed to 100 in 1960, declining steeply and ending far below the comparison index for dying of disease.

Vehicular fatality-risk index for car and LTV occupants, 1960–2012 (1960 = 100), plotted against the risk of dying from disease. Source: NHTSA, “Lives Saved by Vehicle Safety Technologies… 1960 to 2012” (DOT HS 812 069).

Safety glasses are my bane. In sixteen years I’ve yet to find a comfortable pair…..almost tolerable maybe but certainly not comfortable.

— sii, “comfortable hard hat”, Mike Holt Forums, May 31, 2012

My apologies for the digression. Back to my main point: did you know that some programmers actively don’t use programming languages with strong type systems and other safety features? No, really! Like a moth to the flame, some people bitterly cling to dynamic types and other features of unsafe languages like manual memory management, finding comfort in the familiar warmth of getting regularly burnt by race conditions, buffer overflows and null pointer exceptions.

I’ve been complaining about of years and I won’t wear them useless I need to or am forced too. When I put some glasses and all of a sudden I can’t cut grade there is a problem.

— Dozerboy, “Improvements in Safety Glasses…”, Heavy Equipment Forums, Jun 16, 2012

How many massive security incidents — Heartbleed, Cloudbleed, Stagefright, EternalBlue — will it take per year before we learn our lesson? How many bugs must we squash that are simply not possible in safe languages, available today and for no cost? Do not mistake me for a Rust supremacist here either. If you want to use any other language like C or Python or whatever, be my guest, I use whatever is best suited for a task too, but why not turn on all the safety features you can!

Of course it takes longer to put it on and off the beam than the work I do.

— iwire, “OSHA Policy on Subcontractors”, Mike Holt Forums, Nov 15, 2006

What I hear when I listen to fundamental arguments against type systems and the other safety features designed into programming languages is the cry of a child with scorched and scarred hands begging to be allowed to lick the stove this time. Where’s the thrill of it, if the computer makes sure that you don’t step on well known, well marked and clearly understood landmines, when you are just trying to go about your everyday business? How dare those authoritarians impose any sort of restriction on my ability to lay traps for myself, my coworkers, and my employer? Types and memory management are pure paternalism, forced on the working man by ivory tower academics who have never done a real day’s work in their lives. Some might say! Not me, though. I like not getting thrown clear of my car and my software when things crash.

So safety glasses are not all that great, ANSI or not. I doubt the ability of the wussy clip-on side shields to do much other than delaying a malnourished mosquito for a half second.

— JST, “eye protection for eyeglass wearers”, Practical Machinist, Aug 23, 2006

Not wanting to use a safety system because it’s slow, buggy, or hard to use, well, I wouldn’t want to use one of those either! I find myself of two minds. I remember the resentment and exasperation I felt when I tried to get lifetimes to work in Rust for the first, fifth, and hundredth time. If you see lifetimes actually working in my code, you got three guesses about who wrote that code, me or the agents, and the first two guesses don’t count. I don’t like writing code that passes the borrow checker in Rust, but I love having code that passes the borrow checker. To put a finer point on it, I believe that everyone should already always be wearing their metaphorical seat belts when programming and I myself would have ripped out the ignition interlock system and its software analogues with my bare teeth if I was forced to use something so faulty and annoying.

You see a guy complain about hard hats and safety glasses on the job site, and watch them drive home in a ball cap and sunglasses. To a large extent the problem is phsycological. I suffer from it right along with everyone else.

— Strathead, “comfortable hard hat”, Mike Holt Forums, Jun 1, 2012

For Bun, correctly handling the lifetimes of garbage-collected values and manually-managed values has been a major source of stability issues - most often small memory leaks and occasionally, crashes. Every memory allocation has to be meticulously reviewed. Where do these bytes get freed? How do we ensure it only gets freed once? Did we check for JavaScript exceptions properly? Is this garbage-collected pointer visible to the conservative stack scanner? Is this garbage collected memory or manually managed memory?

— Jarred Sumner, “Rewriting Bun in Rust”, bun.com, 2026

A major reason that Jarred Sumner pulled the trigger on the rewrite was that Bun was suffering from a swath of bugs that were common in Zig and categorically impossible in Rust. Zig gives you more than enough rope to hang yourself with when you manage memory by hand. Rust was explicitly designed with a borrow checker built in, a central authority figure in your compiler that wags its finger at you whenever you do anything that might cause a race condition or memory mismanagement. You do have to change how you write your software, it’s true, and I say good! I’ve been on call for software written by rugged individualists who argued against safety features, I’ve been woken up because the software they wrote was never quite as high quality as they thought it was, and the post mortems where they meekly fought against the suffocating safety blankets we had to impose on their software to keep them from crashing the business into a wall were immensely satisfying.

Andrew Kelley @ 11:30: You can’t handle memory allocation failure in this language and I picked on JavaScript but this is a problem with Python, Ruby, Perl, PHP, Haskell, Lisp, Swift, NIM, and Go, they’re all hopeless. They all have hidden memory allocations, you can’t write perfect software in any of these languages, like you’re done, like hello world, done.

Questioner during Q&A @ 43:23: I may not have been paying attention but it seems like Rust was conspicuously absent from all of your language comparisons and I was wondering why.

Andrew Kelley: That oh that’s a great question yeah okay so the scoop on rust as far as memory allocation goes. It used to be that the standard library would panic on allocation failure, I don’t know where this is in the nightly releases or stable, but they added some functions to all the containers to try and mitigate this. So you can kind of like reserve memory and the next, if you have a list, reserve twenty spaces and now the next twenty appends won’t fail. So, two answers, one it used to be that the standard library disqualified itself from being used, the core stuff is fine the language is fine. Now they’ve added stuff the standard library that’s kind of like an afterthought, it’s kind of like bike lanes in New York City, but it does the job you know like you can write perfect software in Rust. Rust is a great competitor to Zig. I think Rust is like the main competitor to Zig. That’s all I am going to say about that. Shout out to Steve Klabnik.

— Andrew Kelley, “Zig: A programming language designed for robustness, optimality, and clarity”, Recurse Center, Mar 20, 2018

What surprised me about the migration of Bun from Zig to Rust, was not that they wanted to do it, but that they were able to do it so fast, and for such low cost. We will see if it’s ultimately successful, time will tell, yet so far, Bun seems to keep Bunning on without too many hiccups.

To round it out, I also am not claiming that Rust is categorically better than Zig in every way, or that a language like Haskell with its strong safety systems is better than any other language. Speaking without much experience with Zig, if you actually need that much fine-grained memory control, Zig seems like it would be the better experience. What I do have a problem with is when people who don’t actually need the unsafe features of a language keep getting predictably burnt by those same unsafe features, yet insist that they can write safe code by themselves every time and don’t need to wear their seat belts. Simply put, that is a recipe for you and your program landing face down on the pavement time and again.

To accelerate down the slippery slope towards programming as one would in 1984, in 2021 I told myself I was going to do every day of Advent of Code in Rust. Advent of Code is an online puzzle platform, where every day from December 1st to December 25th, increasingly harder puzzles are posted and people can submit their solutions and compete with each other to see how fast they can solve it. I am not and never have been a competition programmer, I just wanted to see if I could do it and learn some Rust along the way.

— Day 22: Reactor Reboot —

Operating at these extreme ocean depths has overloaded the submarine’s reactor; it needs to be rebooted.

The reactor core is made up of a large 3-dimensional grid made up entirely of cubes, one cube per integer 3-dimensional coordinate (x,y,z). Each cube can be either on or off; at the start of the reboot process, they are all off. (Could it be an old model of a reactor you’ve seen before?)

To reboot the reactor, you just need to set all of the cubes to either on or off by following a list of reboot steps (your puzzle input). Each step specifies a cuboid (the set of all cubes that have coordinates which fall within ranges for x, y, and z) and whether to turn all of the cubes in that cuboid on or off.

— Advent of Code, “Day 22: Reactor Reboot”, 2021

One of my fondest memories in my programming life was spending an entire Saturday cooped up in my room solving the problem for Day 22. It involved calculating things about shapes in space, and I remember having to do some tricky spatial decompression thing or something. The feeling though was incredible, spending many, many hours thinking and bashing my head against the keyboard, trying to figure out the trick. Finally getting the idea for the solution and then spending a half hour coding it up in Rust was such a rush, I was ecstatic when I wobbled out of my apartment to go find a late dinner.

I couldn’t have known at the time that 2021 was the last possible chance to really do Advent of Code before the coding machines arrived in force and the entire tech industry got swept along and away. So I’m quite grateful I got to do Advent of Code as it was intended to be experienced before ChatGPT showed up and shot all of us into the future.

My position on LLMs is that I would prefer that somehow the math would not work out, that multiplying the right matrices together enough times would not give a machine the semblance of intelligence. I think we are in for a rough decade or two politically and socially because of the economic changes that generative AI will bring about in the world economy.

If the models never got any smarter than they are now, it would still herald a major white collar worker extinction event. If we locked down all the models and never trained another one, and let the current level of intelligence provided by the models diffuse through society, you cannot tell me that society wouldn’t still be ripped up at a foundational level. I know they hallucinate, I know they make mistakes, and I know that businesses simply do not care and want to use AIs for as much as they can get away with in order to replace costly human labor. In this way LLMs have been a big downer for me.

On the flip side, I’ve never been more excited about working with computers though. I can take a walk, mess around with Claude on my phone a bit, and come back to 20 different PRs ready to review that are at least a good start if not full completion of the tasks I was interested in. Sure, there are Big Implications to me and everybody having access to this technology, but I got a thousand ideas and a billion tokens to burn chasing them down, and who has time to be depressed, I got slop to sling.

Part of the reason I learned Clojure was the promise that working in a higher-level language allowed one to move further faster than in a lower-level one. If you keep true to that spirit and that desire, if that is really your main goal, why wouldn’t you leave manually writing the code behind as well? I want to move fast and make things, me writing the code was incidental to that.

The phrase that made me sit down and write this essay, that really crystallized so many things for me, was when Andrew Kelley said that Jarred Sumner was “writing slop well before he had access to LLMs.” The deeper I thought about it, the juicier it felt. Slop has taken on such a big and new meaning ever since generative AI got on the scene, that I had almost forgotten what it meant before we got thrust wildly into the future. Andrew Kelley said it in a fit of pique but I really believe that sometimes our hearts sing loudest in anger.

Cmd+s, plus an editor = format on save. You can write slop, never use the tab key to indent, etc, and you hit Cmd+s and things magically snap into place. It saves an enormous amount of energy. And the amount of energy saved, across a given work week, is very significant.

— damassi, “Feature Request: breakBeforeElse”, prettier GitHub repo, 2020

SLOP (slop) n. 1. A one-sided fudge factor (q.v.). Often introduced to avoid the possibility of a fencepost error (q.v.). 2. (used by compiler freaks) The ratio of code generated by a compiler to hand-compiled code, minus 1; i.e., the space (or maybe time) you lose because you didn’t do it yourself.

— “Jargon File”, v2.1.1, eds. Guy L. Steele and Eric S. Raymond, 1990

At least in common parlance, slop had a meaning prior to its modern LLM-inspired one. And it was low quality output, written by either a machine or a human being. We see in that first quote damassi talking about how one is able to focus on just writing the code instead of focusing on syntax, producing slop that then gets cleaned up in the formatter. And the Jargon File is pointing at the output of the compiler: all that extra assembly code produced by a compiler, that’s the slop; if the hacker had written it himself, it would have been trimmed away.

I’ll offer my definition of slop: a pejorative term for something, created by man or machine, lacking quality. A natural follow-up, what qualities matter? And I’ll offer that what constitutes slop is subjective, depending on the observer.

I noticed a phenomenon when ChatGPT first came out. Everybody I talked to thought it was pretty good at everything besides their particular job, which it obviously lacked the expertise to be able to handle well. Oh, yeah, of course I use it to explore some medical thing for me, or to double-check a contract just in case, or write a poem about Shakespeare if he were a dog. But I would never trust the code it writes, that has to be triple checked before it even gets within a mile of production! My friends all had the same reaction, that yes it has its uses, and they used it every day by then, but the lawyers said I shouldn’t be letting it read contracts, the doctors said I shouldn’t be trusting its medical advice, and the poets all said it was obvious that the poem was written by someone that didn’t understand poetry.

I don’t get that reaction as much anymore, the models have advanced sufficiently that people are more accepting that it maybe, might know what it is talking about when it comes to their field. If you know what to look for, then you can tell that something is low quality, but if you don’t know the signs, you won’t see it.

Now! To address a counterargument right off the bat, aren’t there objective standards that can be used to solely determine whether something has a particular quality? And there are! However, I’ll caution you, that if you walk down that road, quality as a solely objective property of something that you can measure and quantify, then you risk straying into the realm of the coding machines again.

High quality code is well formatted! Great, the agent runs the formatter automatically. High quality code has low cyclomatic complexity! Great, the agent knows to refactor if the scanner flags it. High quality code has comments! Great, the agent writes comments, in fact it loves to write comments. High quality code has “good” comments! Remember, we are being objective and avoiding subjectivity, so tell me in an objective way what constitutes “good”.

We can play this game, and it’s fun, for me at least, because I’ll have a good time boxing you into a corner real quick if you try to define quality in an objective way such that a coding agent could not produce it, without trying to bail out to a subjective measure like “good” comments or the like. I’m not saying something with high quality can’t exist. I’m saying that the perception of that quality is at least in part subjective to each person and cannot be explained in purely objective ways, otherwise, you open the door to the coding agents and computers running those objective functions at each turn.

In short, slop is in the eye of the beholder. It’s a label someone can apply that is completely colored by their preferences and experience. Everybody wants to think they’re objectively calling something slop, but if we could objectify the identification of slop, then we could tell the agents how to detect and avoid it, and we are left with only the subjective parts of what was once considered slop, if there’s anything left at all besides begrudgingly good output.

Have you ever been in a meeting with two people who consider themselves craftsmen, typically with titles like senior architect or lead engineer, who have two very different and opposing ideas of what high quality code means? I’ve been in the industry long enough now that I’ve sat through a few of these and it’s always fun. And I’m not saying oh one wants to ship high quality code no matter how long it takes, and the other person just wants to get stuff done. No, I’m saying they both want to focus on producing high quality code and they fundamentally disagree about what that looks like. If you ever want to understand why there are various microservice fiefdoms in your company’s systems, look at the various lords and ladies and their respective domains and try to find the transcript for the Zoom meeting where they almost came to blows over whether protobuffers or JSON with schemas would produce the best outcome.

I won’t go so far as to say that there is no true craftsman when it comes to software development. But beyond the situation described above, I noticed something about the idea that software should be a craft process done by hand that has started to bother me more and more. I felt it as I watched software craftsmen online try and argue that computers could only ever make low quality slop code, and that coding agents will never work.

I’ll state without evidence, that to be among the best software developers in the world, to pursue and hone your craft, you have to believe that you can write a computer program that can do anything a human can do. Maybe it would take a decade, and a dedicated team working under you, and more resources than it deserves, but you have to believe you could do it. I’ll water it down even, and just say much of the work done by software developers is making computers do tasks that were once done by human beings, and that often the software we write prevents human beings from being hired in the first place. Now, I’ll admit I’ve built up a strawman here, but wrestling is fake too, and it’s still fun to watch, so, now, watch this next move.

I believe it is an act of supreme hubris for software craftsmen to believe that the only job that cannot and should not be automated is their own. You want me to take at face value the idea that you can write software that takes us to the moon, trades a billion stocks a second, coordinates globe-spanning corporate enterprises, and yet the second it crosses into your area of expertise, it’s obviously impossible and can only invite disaster. What makes programmers so special? Why are we the only ones who should be insulated from automation?

This is where I broke hard with the software craftsmen and the idea that software should be a craft process entirely done by hand. I don’t have the arrogance anymore to believe that what I do is so special that it cannot be done by a machine. Why should we be allowed to point the threat of automation at everyone but ourselves?

“Go away or I will replace you with a very small shell script.” — a ThinkGeek t-shirt, circa 2008.

Why must code be the only thing done by hand?

Moving beyond the past and present, I do have some predictions about what will happen next with this whole AI thing. Let’s start with Bun, Zig, and Rust.

I’ll bravely stand on the side of soon to be billionaire Jarred Sumner and say that people will keep happily using Bun. It’ll have some weird new bugs, probably because of the rewrite, but they’ll get fixed amid much discussion that goes nowhere.

New projects in Zig are functionally dead at the enterprise level. Any business minded person who is even mildly clued in will look at how Andrew Kelley acted and will think twice before greenlighting a major project or partnership with Zig again. Hobbyists will continue to use it right up until another language comes along that catches their eye in the right way, doesn’t have the baggage Zig does, and has even the slightest chance of crossing the gap into the enterprise.

TigerBeetle and Ghostty are going to be targeted for rewrites in Rust by people trying to gain attention for themselves and/or people who hate Andrew Kelley because of the mean things he said about Jarred Sumner. If they are particularly spiteful, they’ll try and do the Zig compiler itself. (I would be shocked if TigerBeetle and Ghostty did a Rust migration themselves though, feels like it would take another couple major missteps in Zigland before that would happen, they seem pretty bought in, in ways that Bun obviously never was).

An open source tool that makes it easy, fast and cheap to coordinate a billion agents to rewrite any project in Rust while still passing all the original tests will be released by the end of 2026. Nothing Jarred mentioned in his blog post made me think, barring API costs, that somebody couldn’t implement a tool that would make that easy for anybody to pull off. If they really want to show off, they’ll keep the code up to date in real time as pull requests get merged on the original project on an ongoing basis.

Now, let’s talk about the future of craftsmanship in software.

The models will keep getting smarter, faster and cheaper.

The coding agents will keep getting better.

The AI financing bubble might pop, loudly and with much chaos even, but for our purposes, the coding agents are here to stay. They’re not going to go away, they’re part of the software development process, in some form or another, permanently now.

There will continue to be large pressure from the markets and executives on software developers to use coding agents as much as possible, with the explicit goal of deskilling and intensifying the work being done by those developers. Why shouldn’t Marketing be able to open pull requests? Why do engineers get to have all the fun with code changes?

Language and framework lock-in for small to medium sized projects is evaporating and will be dead by end of 2027.

A “good” Linux kernel entirely rewritten in Rust won’t exist until 2028 though.

The wary acceptance of using hobbyist hand tools in the workplace born during ZIRP in order to keep programmers around and happy will be wiped away. Professional projects written in hobby languages like Zig, Clojure, Elixir and Haskell that don’t have a really, really good reason to be written in those languages, those will be swept out and automatically rewritten into something that is more in distribution for the models, like Python, Ruby, TypeScript and Rust.

The code produced by coding agents, and software developers still working by hand, will be put further and further into straitjackets. I have my own ideas about what that looks like as well, and I think generally there will be concentrated effort across the industry to quantify what quality looks like and automate the production of it as much as possible.

I’m split about the proliferation of type systems. I think TypeScript is winning out over JavaScript, but I think that’s because people hated writing JavaScript mostly. I am not sure if agents and people will actually benefit from turning type systems on for Ruby, Python and the like yet. We’ll see if we can get past the ignition interlock stage of stronger safety system rollouts and have usage of them be as common as seat belts today.

All in all, what I see happening is a further continuation of software becoming an industrial process, the same way it has been for decades now. People who want to solve tricky programming problems by hand can do so on their own time, at home outside working hours, as a hobby. But at work, the expectation will increasingly be to let the coding agents do as much as possible as often as possible.

My last prediction, and the answer to my original question, is that the further industrialization of software development via coding agents will increase the “quality” of code far beyond what any one craftsperson could produce. The models will keep getting smarter, and the automated tools we use to ensure quality in code will continue to get cheaper and better. Most software should not be created via a craft process, by hand or by individuals, and it’ll be increasingly less economically viable to do so in a competitive, global marketplace.

Software engineering, software development, programming, whatever you want to call it, has been constantly eating itself for as long as the field has existed. To expect that it would settle into a staid industry that never threw everyone for a total loop again is to deny the nature of this beast. Every 10 years or so, the industry gets turned upside down and there’s not anything anybody can do about it. Why should we expect the cycle to stop now? We keep thinking we have hit the End of History when it comes to working with computers, that a new tool or hardware or new something won’t ever happen again and upend everything all at once. Hell, we are still inventing new ways of working with wood after several millennia of working with it! We’re not even done with figuring out how to produce wood, how could we have already found the exact right way to produce code?

To finish this overly long essay up, the other day I merged a PR I didn’t even try to read. It was a tiny one, just one file changed, a little configuration setting, I knew exactly what should have been in there, and I was in the middle of doing a million other things. Claude knew what she was doing, we had talked through the change, it was to unblock something important, I’m sure she did it right, it’s pretty hard to mess up. All the tests passed, the linter was happy, everything looked the way it was supposed to look in CI. So why should I have looked at the code? And I went back and checked just now and it was fine, really, nothing to worry about. It’s just one little change in one little file. What’s the worst that could happen? I still read the important stuff, I promise!

We live in interesting times, and all I can do is suggest you find your joy in that, wherever it might lie. For me, I smell a new type of craft in the promise of ensuring and imbuing quality in the output of coding agents, and I am very curious to see how deep it goes.

At least my hands don’t hurt anymore, not the way they used to. That’s been nice.