AI took my job as a coder. Then it made me a better software engineer.

I’ve been doing agent-supported coding for a few weeks now, and it definitely has changed the way I work. It’s not worse, just different. Which is remarkable, given that many programmers are having a disturbingly different experience: LLMs generating bad code, introducing bugs, even destroying data. I also read accounts from people lamenting skill atrophy, loss of job satisfaction, and a feeling of disconnection from their own codebase. It sounds like for these developers, the LLM became the mythical Monkey’s Paw that gives you what you want, and then takes away something dear to your heart.

I don’t want to find myself in this dark place eventually. I also don’t want to find myself stuck when LLM prices skyrocket, or the whole AI bubble bursts. The reason why I don’t think I will end up stranded is my attitude towards coding, or rather, to software engineering.

Passive and active guidance

Working with an agent is when good coding standards pay off. I got to enjoy that satisfaction before. It was when we introduced linting, unit and integration tests to our infra code a few years into our operation. We quickly realized how our confidence in the code we deployed was growing, while the amount of nightly emergency fixes was going down. Now, tests and linting rules are the guardrails that prevent agents from introducing regressions and becoming too creative with their new code.

Even with these guardrails in place, I don’t rely on the agent to find its way alone. My agent sessions look like pair programming, with the agent as the driver and me as the observer. I see other developers switch their attention to other things while the agent does its thing. I follow every step it takes. Not just because I don’t fully trust it. I also keep asking questions about its approach, and intervene to help it find the best solution. Every task results in a merge request that we review thoroughly before we integrate the changes into our codebase. (I just found a neat way to do these reviews in the terminal, about which I’ll write soon.)

Many years of experience have taught me that this kind of investment into “boring” engineering practices pays dividends. I don’t see why that should change with LLMs.

From programming to engineering

I don’t care how software is made, I care about what it does in the end. Loris Cro put it well in his article “My Software North Star:

• Software should be useful to the end user
• Software should be correct
• Software should be maintainable and efficient

But how do you achieve that?

Before I started to use coding agents regularly, my many responsibilities at work left me little time to practice what I’d call “engineering discipline”. My process was: do a bit of thinking in advance, start coding, review, deploy. It did the job, but there wasn’t much “engineering” to it, and it always felt a bit shallow.

The software engineering methods I read about in the 80s — SA/SD, Jackson SD, SADT — are long dead, and deservedly so. But their intent didn’t die. Today’s methods have different names, and they tend to be leaner: discovery instead of requirements analysis, TDD instead of formal verification, ADRs instead of binders full of design docs. The problem is, they’re only “light” relative to 1985, but still not at all light for a team of two. Learning these engineering methods, let alone practising them regularly, always felt like a luxury we couldn’t afford. AI agents changed these economics.

Get it in writing

Like everyone, I started out by asking the LLM to implement small new features. (I found it hilarious how much better it was at Rails coding than me.) Soon, I picked up other people’s practice of ending prompts with the question of what else it needed to know. This alone eliminated a lot of backtracking and do-overs, and evolved naturally into having the agent generate a comprehensive plan first, and implement that plan in a second phase.

Plans require decisions, during both their inception and their implementation. Realizing the advantage of documenting our technological direction, I started dabbling with Architecture Decision Records a few years ago. ADRs are documents that preserve the thoughts behind decisions with significance for the shape of a software. Usually, those are also the kind of decisions that are difficult to revert later. In 16 years at the same company, I learned to appreciate the value of organizational memory. If only writing those documents wouldn’t take so much effort, especially if you’re not writing in your native language! I don’t think I ever wrote more than a handful. Thanks to a coding partner that takes great care of that, I now have a dedicated repository just for ADRs.

Once I got more proficient at guiding that coding partner, my next step was to break out of the feature-building box. I started involving the agent even before launching new projects. An extensive back-and-forth that I call “crucible sessions” results in clear documentation of a project’s motivations, goals, and most importantly, its scope. Staying focused has always been a struggle for our team. There’s always the temptation of tackling random issues we discover during project work. It’s easy to rationalize the distraction as “a good opportunity”. Starting with a clear definition of a feature and its scope helps us tremendously with shipping it without detours. In the process of refining this workflow, I learned that this kind of document is called a PRD. The agent saves them on Linear as project documents.

You might notice a pattern: all these improvements preserve knowledge and create transparency. This pattern now repeats like a fractal on all levels of my work. I’m writing less code, but I’m creating more value.

There’s more than just code

Like Mark Betz, “I don’t miss writing code“. I don’t feel disenfranchised by the agent that does it for me.

It’s probably an identity thing. My job has never been to deliver code, or to provision servers, or to type words into a blog editor. My job is to keep our business on a healthy trajectory, technologically and otherwise. I’m enjoying being able to do that job more effectively than before.

Did it turn me into an AI Booster? Hell no. I struggle to reconcile the many quandaries around AI usage with my family’s addiction to food and shelter. My message is not “Use AI, it’s great!” It’s: “When you have good software engineering practices, everything works better.” With or without LLMs.

I don’t believe this new era is “Game Over” for developers. It’s a forcing function to get clear about what we’re building, and to communicate well how we’re doing it. If that resonates with your situation, The Server Room is where we can figure it out together.