While I have been following the developments since the LLM revolution with interest, until about a month ago I hadn’t found many use cases for AI that made much sense to me, other than using DeepL for translation.
I have tried ChatGPT with both text and speech, and was always put off by how shallow the responses were. I think text summarisation is generally a helpful feature of LLMs. Other than that, the killer use case for my writing, as a non-native English speaker, was as follows: Write a sentence in English, translate it into German and then back into English, or some variation of this process (nowadays DeepL also has a Write assistant feature). Initially, doing this helped me to write more idiomatically. However, over time, I found myself resorting to this trick less and less, as it can subtly change the meaning of a sentence, which is important.
I used AI for coding, but only a little here and there. I only used it to generate small code snippets or bash scripts. This worked fine. However, when I started working with Claude Code for the first time, my perspective changed.
When I tried it on one of my own private projects, I quickly started seeing results. So I leaned more into it and found it increasingly useful. I became invested in it because it allowed me to do things that I hadn’t been able to do in a reasonable amount of time on my own. I tackled features and changes that I had wanted to implement for quite some time, but couldn’t find the time for. I began to feel intrigued.
What really sold it to me in the end was observing the behaviour of the coding agent. When it worked with unit tests or just with the program’s responses on stdout, it would often examine the output and try again with slightly different approaches when it failed to get something right immediately. I also often observed it inserting print statements to obtain additional data, as programmers would do. It looped and iterated for a while, which I could observe hands-off provided I gave it sufficient permissions to use various tools without prompting.
Now I’m sure everyone by now has heard the term vibe coding. Any engineer worth their salt will react to that with … let’s find the right word … caution; maybe you have seen the meme about vibe coding and vibe debugging.
Similarly to how I mentioned above that I want to maintain control over my own translations, engineers want to maintain control over whatever code changes come out of an LLM agent. But of course you also want to offload some cognitive load to the agent. After all, that’s the whole point!
In my opinion, a good way to think about this is to compare it to how we reason about which changes and refactorings are covered by large-scope or end-to-end tests, or how we reason when reviewing pull requests. Based on our experience with code in general over the years and the structure of a particular test suite, we can judge which changes and refactorings are covered by the tests and won’t cause breakage. In the case of PR reviews, we need to judge the risk of unfamiliar code from clues such as which artefacts are touched and what that means.
As an experienced developer, you definitely want to (at least initially) keep the thing on a tight leash and grow things in a controlled and sustainable manner. The supposedly impressive one-shotted video game that comes with physics engine and all is—we can guess that much—a recipe for frustration and disappointment as soon as the vibecoder wants to do that one change which would make his vibe-coded videogame truly unique. The goal will seem so close but yet so far.
The awesome platform or website for his business will become quickly a liability. He won’t be able to fix things without hiring someone who truly know what they are doing, even if that person only gives the AI the crucial hint which takes it out of its doomloop. A doomloop describes the state where one can’t make the AI fix an issue, and where the AI tries it over and over again, based on the outputs it sees or the prompts one gives it; the latter because one are insufficiently capable of giving it the right clues because the programmer is not able to make sense of the problem. This is basically the vicious cycle dual to the virtuos cycle I was so impressed by, where the agent was able to beautifully converge on a solution after a couple of iterations of taking in feedback and improving the solution based on it.
Where it goes wrong we are basically dealing with variants of so-called ‘leaky abstractions,’[1] which simply mean that at some point expertise counts. The famous old Pirelli ad still says it best: “Power is nothing without control.”
And this applies in every field of generative AI. Those who use it as the proper tool that it is will be the people we will judge successful later on. They will produce movies that don’t look like bland generic slop, but are fictions transporting a message, fictions that make you forget the medium.
What generative AI in generally can do, if employed judiciously, is increase ‘territory covered.’ At some point in the very near future, I guess we’ll see one-man businesses doing impressive things, or breath-taking movies produced by teams of very few people.[2] Cases in which that power is channeled properly.
And thusly, agentic programming fundamentally expands an engineer’s reach and capacity. Much like GPS navigation enables you to confidently navigate unfamilar territory, agentic programming allows you to tackle larger, more complex challenges. This naturally applies to proof-of-concept projects or getting things started, especially in programming languages or contexts where it would be impossible to get started that quickly without it. But it does not stop there at all.
A colleague of mine today put it concisely that AI is good a finding the needle in a haystack, which exactly matches my experience. And I just watched a YouTube video in which someone made the point that he learned to “let go,”[3] in the sense that at some point he wouldn’t insist anymore to know the complete territory of the codebase, for AI would be able to find the problematic spot anyways, should a problem arise.
In any case, you retain full discretion over which AI-generated changes to accept or reject, but the tool amplifies your capabilities significantly. And also which capability of yours to “supercharge,” or which to “power up,” if videogame lingo suits you more, fellow kids.
You might want to use it to create larger territory, or to make surgical edits. It’s entirely up to you on how tight a leash you want to keep the thing on, actually.
Anticipating some lamentation here, let me say that, yes, some traditional coding skills may atrophy—just as our navigation instincts have weakened since GPS became ubiquitous. But few would choose to return to paper maps, except perhaps to prove a point. We don’t insist on writing assembly language to preserve those skills either. Every programmer needs to go through a learning phase in which he achieves some mastery of algorithms and computer science. I don’t see how anything would change this. Just like any ‘normal’ engineer needs to master calculus, but won’t later on solve or build anything by writing equations.
Coming towards some sort of a conclusion, let me state that automation has always been central to the programmer’s mindset, and AI agents represent a particularly elegant evolution of this principle. They excel at bridging the gap between human intent and automated execution, allowing developers to express requirements in natural language. This declarative approach—where you describe what you want rather than exactly how to achieve it—lets the AI handle implementation details while you maintain control through carefully crafted constraints and context. Behaviour-driven-development, if anyone remembers, that beautiful idea of writing almost computer-readable, really precise requirements,[4] currently has its rebirth as spec-driven engineering with the help of LLMs,[5] and I think this is awesome. Btw., that means that articulation skills—always having been important—will become even more relevant.
So, don’t let the overhyping of agentic AI distract you in the slightest from the fact that with agents we have an absolutely powerful tool in our hands. Sure, the providers of the models have every interest in making he hype machine go full-steam. I don’t fault them for that. Reminds me of the advertising slogan of Oil of Olay back in the day that promised to unlock the “Secret of Beauty.” The point I’m making: Don’t mistake OpenAI showcase videos for the real thing. In that light, I really don’t have much patience for Gary Marcus’s takes at the moment (for example the one where he declares that “AI Agents have, so far, mostly been a dud“),[6] although I’m usually very much theoretically inclined. But I’m just thinking, ok, we don’t get AGI, and LLMs may have reached a plateau for a while. So what?
We haven’t even begun to exploit the full potential of the technical power available to us right now. So I for one rather like to direct my attention toward actually productive ways of looking at things, like this wonderfully pragmatic piece of writing: It’s a “you” problem, not a Claude Code problem,[7] where the author shows us ways of getting the most out of what’s available to us right now. What I loved most about that post is where he pointed out that architecture (modularity) is still a thing, and your responsibility.
All in all, you get the drift. It’s not about these agents ordering and paying for our pizza, making calls, and so on. It’s not about vibecoded video games. Focus on the simple principle and recognise its power: you have an LLM, and this LLM has tools.[8] You can write specifications and the agent will execute them with however little or however much power you want to entrust it with (somewhat more on private projects or proofs of concept, for example). That’s it. The idea of agentic coding is here to stay.
Remember way back when we figured out how to put just the right words in the Google search field, such that what we were searching for would appear right on page 1? This is very similar to what I think is today’s imperative: learning to harness AI’s power and become skilled in using it. Image source: commons.
Footnotes
Joel Spolsky: The Law of Leaky Abstractions; joelonsoftware.com.
Not saying this here is non slop-y, but, imagine some of those tricks getting deployed by someone with very good taste, where it’s not in your face but more Alien 1-like (very sparsely, leaving much to the imagination). Thanks to a friend for sending me this!
“I tried vibe coding for 30 days. Here’s what I learnt…” YouTube; the link transports you straight to the “let go” phrase at the 10:03 minute mark.
It never really took off, which one in hindsight can see why. The extra glue-step where the natural language statements (that were hoped to come directly from PMs, similarly to how we typically want to hand off html and css to designers or frontend specialists) needed to get mapped to underlying API calls etc. was just too cumbersome (pun intended, see Cucumber). Natural language processing was the missing technology here, really.
A colleague brought kiro.dev to my attention. From a quick read, it seems that it aims to automate some good practises of cleanly structured planning phases, thereby distinguishing them from execution phases.
Can be found here on his Substack.
https://www.reddit.com/r/ClaudeCode/comments/1mlqs4n/its_a_you_problem_not_a_claude_code_problem/
Just how big of a deal this really is, is pointed out in the video “10 Things GPT-5 Changes“ at the 2:37 minute mark (which this YouTube link brings you right to) with the discussion of a tweet and article of some Ben Hylak, who draws a comparison to human intelligence and how tightly it is linked to tool-use.