Moving fast in the wrong direction
LLM-enhanced programming is here to stay. Arguments against it are dead, especially in the professional world, and the only reason it would shift “backwards” is because running the models is currently subsidised to the extreme. This isn’t going to be a piece about how it’s “bad”, nor how we should all abandon the tools - might as well try and pick a fight with a rhino, ultimately it’s still going to run you over.
No, this is about trying to encourage you to step left, when the whole world is pretending to sprint to the right.
Hacking software out was always the fun bit…
Opening up any social news feed - especially LinkedIn - is an adventure in insanity now. Eight out of ten (no citation, but come on) posts are an LLM/Transformer generated pile of slop. Patterns without unique voice everywhere as you scroll. In my world of software development, it’s always the same story - someone picks up a Claude subscription, feeds it a prompt about some “app” they want built, and shares the same tired screenshots of a material/tailwind UI alongside how they predict development is dead inside six months.
Ignoring that this is the longest six months ever (this rhetoric was around way before LLMs, basically since getting into programming its been a trope), it misses the point of the job. Truthfully creating software from scratch has always been an absolutely wild and fast riot of fun. That initial rush of dopamine from spending a few hours locked in smashing out a prototype is delicious.
Anyone who thinks that pumping out a functioning bit of software inside an afternoon is some radical jump in speed clearly hasn’t ever participated in a hackathon. Even speaking personally as a not particularly fast programmer, I’ve smashed out projects in a weekend - or even a day - plenty of times, especially when the idea just wants to get out. Difference being now you can get that without having to actually open up an editor or read/write the code, and the UI that gets smeared over the top of it is slicker. Advantages to training models on good looking interfaces.
…but never the satisfying or important bit
Normally this is where this kind of thinkpiece veers into talking about deployment/production, but the truth is (as much as I care about that whole process), if you wanted to get a hobby project out into the world easily, services like Vercel have existed in some form or another forever. Hell, go back to the 00’s of the web and it was just a case of dragging some PHP files around in Filezilla.
No, instead the satisfying part of good work is bringing a team together to share the problem space you’re solving. The best teams (and you know who you are if you’re reading this) would sit in rooms together, or on calls, and hash out a problem space for a good chunk of time before anyone touched an editor. It isn’t just about scope and process either - it’s about making sure everyone understands the direction you’re pulling in.
In fact I’d go as far as arguing that bringing solutions to problems instead of the problem itself is actively caustic to shared reasoning and collaboration. Getting buy-in on directions of travel can’t be done with a shiny presentation about how good your solution is at the end of the process. Don’t get me wrong - I’ve done it myself, made a mad dash in a direction and then come back at the end and gone “right we’re going this way”, but the key is that in doing that, don’t pretend you’re getting buy-in - lay out the actual tradeoffs you’ve decided on and get it into everyone’s hands as fast as possible, completion be damned.
Doing it solo is the hallmark of hobby project development
If you’ve got a career that’s over the 5 year mark, you’ve been there in your junior days. Diligently working on that bug to change the colour of a button, then the button doesn’t exist anymore because someone with more autonomy than you has decided it doesn’t need to exist. Suddenly you’re helping with a giant feature release that has everyone running around like rats on a hot tin roof, because the wrong screen got shown in the wrong meeting, and someone gave a timeline without discussion.
It’s a disenfranchising, painful experience and in my mind, speaks to a style of software development that should remain firmly in the hobby project. This is something that its important to be really, really explicit about - it has nothing at all to do with LLMs. This is a style of coworker who has existed in the industry for a really long time. Haven’t ever worked with someone who behaves that way? Might be worth examining, that.
To continue to be really clear - this kind of software development isn’t evil or wrong, it just can’t pretend to be collaborative. It works incredibly well for prototypes, demos, one-shot tools, bespoke software and contract work. You fundamentally cannot build a business around it though - because businesses succeed on shared connection, tribal domain knowledge and empassioned, empowered people pulling in the same direction.
The splintering of ID around Quake - just faster
There’s a really good example of this from ID Software. If you’re not a gamer, you might not know them, but they’re the company responsible for the original (and current!) Doom games. Back in their inception in the 90s they were spearheaded by two Johns - Carmack and Romero. Wolfenstein and Doom were mega hits for them, and to follow that, they needed something even bigger/badder. Carmack is probably one of the best programmers to ever grace us (Doom’s source code still stands as a pinnacle to port onto any device). The decision with Quake was to go full 3D, and build a true engine under the game, complete with scripting language. So Carmack essentially went into the hole. Except he went in basically alone. In his absence the rest of the team continued to do their jobs - they built assets and resources, designed levels and themes. But there was no shared core to build things around. So when Carmack came back with the engine, and there was no time left, the vision of a sprawling RPG proto-metaverse was gone - and instead all the assets were thrown together into a big grab bag and some kind of game was birthed.
Quake isn’t exactly bad, but it lacks the focus of truly classic games, especially of the era. Going back to play Doom (1993) even now feels tight and fun, whereas Quake doesn’t have quite the same level of polish, just a bit of nostalgia. Romero abandoned the studio and went on to essentially self-immolate his career trying to birth Daikatana. Carmack stayed at ID and refined his work (now back in the mix of an actual team) and the studio continues to be a real pillar of gaming excellence.
Bringing this back to LLMs - my argument is that this splintering and friction just happens way, way faster now, and more often, because people can go “further”, quicker.
The hard work is bringing people with you
Convincing someone to change their mind when they think they’re right is basically impossible. This isn’t about trying and win over people who think that solving all the problems for the team is the solution. But if you’re earlier in your career or you are finding this article so far is resonating with you, the thing to learn is how to present. I’ve given a few talks, walked people through processes, problems and ideas. It’s tough. You won’t win everyone over. People will nod and agree and then go right back to doing what they did before.
But when you can connect, when you can build that bond with someone over the work? The power of it is insane. If hacking out a prototype is a quick cheap hit of speed, working together as part of a team pulling together is like being hopelessly deep in the opiate hole. Even years later I get wistful about the teams I’ve worked in which had these attributes, the individuals I paired and crafted with, the software we produced and maintained. The highlights of my career aren’t software crafted as an individual - because those have existed, and some are even cool - but rather the solutions built as part of a collective.
So how do you not go insane
Because insane is the right word for it. (Currently at least) For the princely sum of $20 a month you can get a sycophantic junior who types at a few hundred lines a minute and tells you every idea you have is a good one. Even when you prompt the infinite typing monkeys to be adversarial it’ll drop the challenges the second you “correct” it - and the challenges are never backed by deep belief.
Make no mistake - LLMs are powerful, but they’re not intelligent. They don’t care. They don’t have learned, earned experience and scars. They’ve not been awake at 2am patching a database that went pop. They’ve never had an argument over what logging library to use. They’ve never had to tell someone to shove SOLID where the sun doesn’t shine because right now Steve, production is on fire so you will just approve the damn PR with the tested fix in it.
Reports of “AI-induced psychosis” (Sorry, I’ve got to put anything with “AI” in quotes because I refuse to bend to the marketing that this is what these tools are) get louder every day and our working lives aren’t immune from this.
Craft by hand - even if it’s just quietly
Get LLMs out of your pet projects. I’m a massive proponent for building near-useless software and tools, bespoke to just you as an individual or just as a joke. The process and feedback loop of gently layering code together - feeling the repetition in your fingers as you build out a functioning system - is its own form of dopamine. If nothing else, if you’ve fully abandoned this, you’re missing out on another form of satisfaction. Just the feeling of hooking up one handler, building that one migration, putting together that one test suite - it feels good.
The ability to parse and develop a taste of your own for what you see as “good code” is invaluable. Even if it’s not the same as the person next to you, at least if you’ve got an opinion you can have a reasoned discussion about the software you build. How can you know the pitfalls with architectural decisions being made in the code you push, if you’ve not personally committed to those consequences with a bit of sweat? When the code is “free”, the investment is zero, so why would you worry about the future?
Lay keystones together, and use the tools to iterate out from that
Sometimes you might not be able to take another person with you, and that’s okay - especially in smaller companies. But I have found one thing that LLMs are exceptional at is taking prior art, and building from that.
A practical example from recently - I had to migrate a codebase from one database to another. I did a few hours of mostly manual work breaking apart, wrapping the storage interfaces and putting tests over the top that hit both interfaces. When I was happy that it was all working correctly, I threw together an initial version of the code for a new database, then just started guiding the LLM through per-interface getting it to build underlying implementations that passed the test suites, and finally some very simple (with tests) startup scripts that moved the data from one implementation to the other.
The end result was one of the most uneventful and highest confidence migrations I’ve ever pushed - and it even let me do following database change (code structure, rather than data) a week later with impunity.
Prioritise it’s use for undifferentiated heavy lifting, not thinking
I do sometimes drive with the classic “create me a plan I can review for X” to then use as jumping off point for the agent, but really only ever for tasks that hit a lot of files. It’s important when producing software that you’re aware of what the intent of the code is, even if you’re not keeping every single line in your head. Truthfully, that’s pretty much always been the case, even pre-LLM. It’s why there’s a long history of developers wearing headphones and trying to maintain a flow state - you can keep the context of a string of functions in your head easily enough, but god help you if you lose the thread.
This is the real understated skill of the developer - in picking up existing software and figuring out not just explicitly what it does, but why it does it. This can include driving to the house of the person on the git blame and asking them why the insanity that is breaking your system exists - and what you’ll often find is someone who can explain to you why something that would offend even the most lax developer was written.
When you take your hands off the wheel and start letting these agents drive to that degree, that context disappears. It becomes a twisted version of that old programming joke:
Once the agent context and God knew why this function was created, and now only God knows.
You are the agent’s context
This in my opinion is the big one. People seem to advocate for just fully stepping away from the agent - setting it off on some mad autopilot, maybe with some degree of harness, and just letting it rip.
If you actually watch what the agent is “thinking”, you’ll just see how mad it goes, how often. Constant loops of the same words over and over. Insane discussions with itself. It saying it categorically shouldn’t do something then just turning around and doing it anyway.
When this happens I realise I’ve asked the infinite monkey cage to do too much, I swiftly take the thread behind the chemical shed and revert its changes, then break the problem down to a smaller chunk. Code is much like dog muck left in the rain - it rarely gets better with time, and expecting the stochastic parrot to be able to “realise” it should clear up its own mess is asking quite a lot.
Conclusion
Anyone that’s worked with me knows my disdain for heavy handed process. Design by committee is a joke and you can’t get anywhere if everyone just stands around waiting for someone else to make a decision. But there’s a gaping, yawning difference between the world of SAFe and just yolo vibecoding your way through the job.
That’s the heart of this. It’s a job, a profession. It demands working with others and being vulnerable in the moments before you’re sure of your solution - because if you’re so sure of it, you’ve taken all the decisions away anyway. No one is going to convince you to change your mind, nor are they going to be particularly driven to share in implementing it.
The best seniors and mentors I’ve had (maybe some of them are reading this) were actually incredibly hands off when it came to the code itself. They’d pull me to whiteboards and miro diagrams. Hop into calls to help shape what I was typing. Reassure me when it all went bang that no one was dying and that they’d help me fix it, not just take the problem off me. They listened to my viewpoints and genuinely had a talent for making sure they didn’t dismiss or disregard concerns even when telling me to do literally anything else please god don’t use that pattern.
Close the infinite chatbot. Pick a fight. Make friends again. Touch grass.
Because as painful as it can be to deal with humans, the alternative is worse, even for the bottom line.
Relevant from me
- AI Code tools are a Tarpit
- You’re awesome. Your code is probably worthless though.
- Doors and Corners
- Pretending I Have Production
- Not My Job