Some thoughts on AI, mainly the coding agent side of things

Agentic coding, in essence#

I have been using code agents for all my side projects for roughly the past 18 months and it has completely changed the way I think about programming. Granted, my setup is elaborate and far from just running a prompt in something like Claude or ChatGPT online. And it evolved at incredible speed, roughly 6 completely different approaches, with some side quests. Agentic coding is NOT getting a subscription, downloading a CLI tool and off you go. The output will not be what you want it to be. I tuned my entire workflow to accommodate agentic coding, from eslint rules to symbol mappers to wiki-like knowledge bases with pitfalls and patterns.

I have to admit, I always liked programming for the sake of fleshing out a vision or a requirement. To me, it is a tool, a way to manifest my own or a clients requirements in a software tool. I never liked programming for the sake of the programming itself, needlessly complex toolchains or other distractions. Frontend development especially is and has been a mess for as long as I can remember, that doesn’t help.. And there have been evangelists for one or the other way of doing something for as long as programming has existed. So nothing has changed and probably never will on that front.

Right now I notice a lot of collective amnesia. I have to chuckle when I read that people blame LLM output for being wrong or introducing bugs. Like nobody ever introduced bugs? Like every piece of software written in the last 45 years is perfect? How threatened do we need to feel to completely block that out? The iterative process remains. We stand at the beginning of a new era. All previous attempts that tried to abstract the act of coding away from feature development pale in comparison to what is currently going on. And as a single person working on something, I can have 3 agents develop individual features or let them orchestrate to work on a fullstack feature. It is so much more efficient. Even if I have to nudge every single task to get it right to where I want it, it is still more efficient, because not only can I work on 3 tracks at the same time, but I also have the capacity on top of that to think about the big picture of whatever I want to achieve, without getting lost in technical details.

I am not sure how to express this, but I think either you really try to get used to the workflow - find that flow, work with it and not against it, find your individual way for your individual requirements - or agentic coding is not your cup of tea and you go on doing it the way you are used to. To reach flow state, problem-solving remains the most prominent trigger for me. And that is still my job to a large extent. It just shifts a little bit.

I do not see anything wrong with either agentic coding or sticking to the path. If you are the kind of programmer who can reminisce for hours on the beauty of algorithms, I am the last person who wants to take that away from you. I completely get it. I feel the same when I see my ideas coming together.

• Yes, there is always a way to not do it, with every tool. That includes LLMs for coding.
• Yes, your architecture will suck after running 24 agents for a week without a single review.
• Yes, vague instructions don’t just confuse juniors or your coworkers, they also confuse agents.

The harness is the work#

Let me get more specific about the setup:

• Rules and patterns are not just there for style. They encode decisions. If there is exactly one way to fetch data in this codebase, then that is a rule.
• The symbol mapper/language server allows an agent to more efficiently find its way around the entire codebase.
• The knowledge base is a wiki of pitfalls, library specific instructions and patterns. Some is curated by me, pitfalls are automatically added using its own standardised way.
• The entire engineering, development, testing and verification process is rule based and enforced throughout.
• An issue tracker records work done, refereced in code as well as in the local knowledge base

None of this is free. The harness extension is real work, it has to be maintained, and it is specific to me and my stack. But that is the trade: you pay once, in a form that keeps paying, instead of paying again in every single prompt.

Unfortunately there is no standardised featureset that is available in all code agents. I am sure we will get there eventually.

Reviewing code#

The reasonable objection to all of this.. If three agents produce code in parallel, somebody has to read it, and that somebody is me. So what stops the review from becoming the new bottleneck? I do not read most of it line by line. That sentence makes people uncomfortable, so let me explain what happens instead.

There are two gates. The first one is mechanical and it is the whole point of the harness. Types, lint, the rules, code statistics, the tests. If it does not pass, it never reaches my eyes at all. The second gate is me, and I start at the feature level, not at the diff. Does it do the thing? Does it do it user friendly? Is it shaped like the rest of the codebase? That is a fairly fast judgement.

This only scales because of the first gate. If your harness is weak, everything lands on the second gate, you are back to reading every line, and the parallelism buys you exactly nothing.

A manifestation of this issue is currently visible in almost all large open source projects. Or to be more precise, how hard it can be to integrate this new workflow into existing, manual processes.

On attribution#

In terms of code attribution, well, I guess that is a grey zone that people will have to figure out on a legal level. For myself, if I define the architecture, the feature, the way it should be done and the refinement until completion, and I use an agentic tool to get what I want while I would be perfectly capable of typing the code myself, I attribute the end result to myself. It is a tool, I tell it what to do, I use it to achieve an output that I desire, I tell it when we are done.

Whether or not some intellectual property is violated in the process is my job to figure out. I might as well be copying and pasting from Stack Overflow, like we all did (and somehow everybody also forgot…).

The effect of existing experience#

This is where it gets interesting, in my opinion. I have been doing this, or some iteration of it, for the last 25 years. I kinda know what I am doing and I also know when I don’t. Still, it probably lets me describe more precisely what I want an agent to do, how, and why. And I can judge the output fairly quickly, and I know the entire stack, from the top down, and many, many different concepts. This is not vibe coding. It is an accelerator.

If you don’t know what you are doing, then… well, you don’t know, and the result will show that.

Which leads to the uncomfortable follow-up question: if the experience is what makes this work, where does the next person get theirs? I climbed a ladder whose lower rungs are exactly the work that is being automated now. The knowledge and experience needs to be somehow gained. How this is supposed to be achieved is currently beyond me.

What happens to a shared codebase#

Everything above is me, usually alone. If I produce three times as much in a team setting, somebody has to review three times as much. On a team, my efficiency gain is somebody else’s reading load, unless everybody is on board with an approach like the above. That is not a tooling problem.

Then there is the harness itself. Everything I described above is a personal artifact. On a team it stops being personal: the rules, the knowledge base, the conventions become shared infrastructure, and shared infrastructure needs an owner, a review process and a way to settle disagreements. Your harness becomes a codebase in its own right.

And there is the question of why. Code tells you what happens, never why it happens that way. We used to smuggle some of the why into commit messages and into the heads of the people who were there. Now the commit messages are generated too. Either the reasoning lands somewhere durable, or it evaporates, and in two years nobody on the team can tell you why the thing is built like that. The knowledge base that also records decisions and business requirements as a way to look up later is the closest thing I have to an answer.

So where do we stand?#

Is the (TypeScript/React-) code as good as I would have written it myself? Sometimes even better, rarely worse. Would I do something differently? Probably yes. Would it matter? Probably not. Would I expect myself to hit the nail on the first try for a complex task? Never happened. Did an agent ever fuck up something? Absolutely. Did I fuck up something? No, I blamed the tooling ;-)

Right now the whole technology is at a stage where harnesses need to be groomed, hooks implemented, rules defined and a lot of different ways tried to find something that works for the broad task at hand. This will only get easier and less bespoke over time. I generally like to think of things like that in a broader timeframe and with some distance. It is clear that the whole Cambrian explosion that happened in the last couple of years is just the beginning. The thing is here to stay.

LLMs will get more specialised, there will be alternatives to frontier LLMs, and at some point we will be able to detach from the big corpos. This will take time, but it will happen eventually. Things will cool down eventually; the atoms will vibrate a bit more slowly. You will see. The thing I am not so sure about is whether we will have affordable local compute anytime soon. That’s its own entire topic.

I know the expected move here is to offer a tidy caveat so I look balanced. I do not have one. I am not claiming that any particular model, company or tool will still matter in five years, and I would happily bet against most of them. What I do not see reversing is the direction. A capability like this, once it exists and once it is this cheap to reproduce, does not go back in the box. You can regulate how it is used, you can price it differently, you can dislike it on principle. The ability does not un-exist. My confidence is not about the products, it is structural.

Yes, there are many unanswered questions. Yes, that includes environmental issues. This has happened before in human history. We will sort things out, we will have legal solutions to these issues, societal rules and environmental and efficiency breakthroughs, probably faster than anything that happened during the entire first industrial revolution. We will also figure this one out. The pendulum swings and will ever keep swinging.

I am not a ruthless technocrat. I am also not in a cult, of whatever colour. I just see what is there and I am reasonably good at recognising a pattern, despite all the noise. Years ago I told my colleagues that even though the output of the LLMs we had back then was mediocre at best that we will see huge improvements and that this will come back to bite us. Looks like it did. At least for some of us.

Frontend works fairly good with LLMs today because - I assume - the corpus of knowledge available is vast. Niches are hit and miss. Skilled developers will still be needed in decades to come. Today, it is impossible to reasonablu automate the entirety of the software process. The responsability of the person checking code in also stays the same and I think personal accountability still is important.

I don’t believe the people that claim this will go nowhere. I also don’t believe people that proclamate the immediate obsolescence of software devs. I believe that experienced devs will always be required to create and keep software running. The roles will shift slightly. And some niches might not change at all. The reality will be, as it is so often, somewhere in the middle.

In the end, I am a hundred percent certain that agentic coding will prevail in one form or another, especially for tasks that can be done rather quickly and with low risk attached. Testing will have to be improved and certainly QA as well. The good thing is that most of this can also be automated to a certain extent.

Things we should be aware of#

• Corporations are not your friends (still)
• People creating content to farm rage are not trustworthy
• Not sure how knowledge and experience are accumulated through delegation alone
• CEOs are not mythical demigods and AI CEOs are borderline psychotic
• Things are going to be figured out eventually
• Try to see beyond the hype and IPOs
• Don’t panic