A lot of less experienced and mediocre engineers likely think these tools are brilliant. They’re producing more code, feeling productive. The problem is they don’t see the quality problems they’re creating.
This is compared to the experienced coder.
They’ve lived with the consequences of bad code and learnt what good code looks like. When they look at AI-generated code, they see technical debt being created at scale. Without proper guidance, AI-generated code is pretty terrible. Their scepticism is rational.
Then, this paragraph really caught my eye:
I’ve regularly seen sceptical experienced engineers change their view once they’ve been shown how you can blend modern/XP practices with AI assisted coding.
I got caught up in this "modern/XP practices" phrase. I was like, "are we talking about Extreme Programming here?" I hadn't really thought about that in a while, or considered it "modern." So I went and looked it up to remind myself and found this Martin Fowler post on extreme programming from a decade ago.
XP was one of the first agile methods, indeed XP was the dominant agile method in the late 90s and early 00s before Scrum became dominant as the noughties passed.
For a lot of folks today, "scrum" is synonymous with "agile," for better and for worse. But there's a whole world of agile techniques out there. Falling down this XP rabbit hole was a good reminder of this for me.
So what, exactly, is XP? According to Fowler:
It popularized many practices that have since been widely used in software development, including: continuous integration, refactoring, TestDrivenDevelopment, and agile planning.
I would add "small, frequent changes" to that list too, and then other than TDD, just call this "good engineering" today.
To bring it back to AI, where we started above: AI will change how we write software. It's already doing that, but then, good engineering practices endure. Those good engineering practices can serve as a framework for understanding how best to use LLMs and other AI-based tools.
Here’s the crux of the programmer identity crisis, according to its author Simon Højberg:
The ghosts of ancient Hackers past still roam the machines and—through the culture they established—our minds. Their legacy of the forging of craft lingers. A deep and kinetic craft we’ve extended and built a passionate industry on.
I find craft arguments compelling. I am a craft-focused coder first and foremost. By craft, I mostly just mean care and attention to detail, a love for the language and style of a program. Programming for the sake of other programmers, not just for the computer executing the code.
It’s this craft that Simon feels is in jeopardy with AI-assisted coding. About LLM coding, he writes:
It reeks of a devaluation of craft, skill, and labor. A new identity where our unique set of abstract thinking skills isn’t really required; moving us into a realm already occupied by product managers and designers.
The thing I want to talk about is the difference in craft and its alternative, what I’ll call the just-ship-it coder. I’ve jokingly referred to this as the coder who goes, “Did it work? Great, ship it!” It’s a low bar, and maybe you get a sense of my feelings about the pure just-ship-it coder.
Now realistically, a pure craft coder or a pure ship-it coder don’t exist. We’re all somewhere along that spectrum. I love craft, but I’m pragmatic. I work with folks who are more inclined to ship than worry about craft, but even they don’t want to produce slop no one can maintain. I do, however, think there’s a pretty sharp divide between craft and ship-it coders in the circles I work in.
My open source colleagues care deeply about craft. My professional colleagues care deeply about shipping code. I find adoption of AI-assisted tools much higher in my work colleagues than in my open source colleagues. I think there’s a corollary here to this idea that Simon writes about, that AI tools are going to ruin the craft of what we do.
I’m not sure it is. I think you could be a craft-loving coder and still use an AI assistant. See Mitchell Hashimoto’s post on Vibing a Non-Trivial Ghostty Feature. You can read his process there and see plenty of care and craft involved. As I said, I consider myself a craft coder, and I find it fun to use AI tools in my coding. I totally agree that there’s a risk that we don’t focus enough on craft with these tools, but that risk exists even without using AI. The trick for us who care about craft is to keep arguing for it, regardless of any specific tooling we use.
I saw that it's Django's 20 year birthday today (via Simon Willison). Wow, that's hard to believe, but also, I know it all too well. My own career parallels Django's history.
Back in 2005, I was about a year into my first real professional career. I was what we called at the time a "webmaster." I ran the web site for the library systems of Auburn University. I had been programming in Python for a little over a year and had fallen in love with the language. Then I found Django as it was open sourced. It so immediately matched my mental model of programming for the web in Python that I started using it everywhere I could - small sites at the library and my own personal sites.
That work lead me to a deeper connection in the Python and Django communities, which lead me to meet Rob Curley, which lead me to the Washington Post, which ultimately really started my love of working in the publishing and media industries. Now here I am 20 years later, still doing web development, still loving Python, and still working in media, entertainment, and publishing. I don't use Django as much anymore, as my work these days is focused more on AWS and infrastructure, but it's influence on me cannot be overstated.
Cheers, Django! Here's to 20 years more. Carry on!
