What Evidence 18 Months Of AI Assisted Coding Created

In the spring of 2025, I started coding seriously with AI for the first time after multiple trials letting AI do code during the advent of LLMs. Looking back, what I did then was still far away from anything we would call agentic coding today. It was a cautious first approach, driven by a handful of questions: What can this fast growing technology really do? Where can it actually help? Where does it fail? And how does it change my own work as a developer?

My first task for an AI was deliberately small. I asked it to build a simple video game, I loved to play on my Commodore C64 more than 40 years ago.

The result was sobering. It did not really work. The AI misinterpreted requirements, left out important details, made assumptions I had never stated, and delivered code whose quality was well below any reasonable standard. What I got was not a usable little piece of software but a first lesson: AI does not automatically understand what I mean or want. It needs context, and it needs a lot of it.

I learned very quickly that it is not enough to tell an AI “write me some software” or “build me a product with these features”. That sounds tempting, but in practice it does not work, at least not if you are serious about building good software. The AI needs a clear description of what it is supposed to build. It needs constraints, quality criteria, and architectural context.

It needs to understand what is wanted, and even more importantly, what is not wanted.

I never left software development

Perhaps my own background is relevant here. I have worked in software development my whole life - 43 years particularly. I built my first software product at the age of fourteen and sold my first one at sixteen. My path led me from BASIC and Assembler through C, C++ and Java, and eventually to Ruby and Python. Ruby is still my favorite language, because its syntax is elegant and expressive and you write less boilerplate code.

Professionally, I see myself today more as a manager, consultant and Product Leader, but I never stopped developing. I still work on an open-source product, I have started in 2009 and I keep writing code myself in multiple products. So I am not writing this report as an observer who knows AI coding only from demos, keynotes and LinkedIn posts. I am writing it as an active developer who has been building software for decades and who spent the past years finding out, very concretely, what AI can actually deliver in real-world, professional software development.

From better code completion to real curiosity

After those first sobering experiments, I began working with classic copilots like many others. At the time, these tools were essentially not much more than better code completion. And yet, after a while, I was surprised. The AI could predict remarkably well what I wanted to write next.

I was excited, how well it recognized patterns, suggested fitting lines of code, and accelerated the small, repetitive tasks that could easily fill hours of a developer’s day.

The effect was strongest in the areas that tend to annoy me personally: frontend polishing, pixel-perfect CSS and HTML, responsive design and accessibility. In exactly these areas, the AI made me dramatically faster. Not because these things are unimportant, quite the opposite, but because they demand a lot of detail work that costs time, binds concentration and I am usually not good in it - despite I demand great design, even from myself. The AI took much of that tedious work off my hands and quickly produced usable suggestions that I only had to review and adjust.

That made me curious. What is behind this? How far can I push that? What happens if I give the AI not just individual lines of code but larger tasks?

One central lesson from this phase was that context is decisive: the less context the AI has, the worse the results become. So I started improving my prompts. I gave the AI more constraints: what code quality I expect, which coding guidelines I use, which architectural principles matter to me, and how certain things should be implemented in my project. And indeed, the results got better - partly.

Stepping into vibe coding

In the summer of 2025, I attempted for the first time what became known as “vibe coding”. I started to give the AI larger tasks, no longer small, simple and isolated coding tasks but coherent changes to the code base, requiring it to touch multiple files and understand the architecture.

I was (and still am) working on a full business application that covers the entire offer to cash (O2C) workflow for our business and on our website backend taking in training registrations and handling operations. A real production software with real customers and real money flowing through it, not a playground. Breaking it would mean potentially stopping the flow of cash. To give you a sense of the scale, around 1,400 fully automated tests run permanently against the codebase and now, I started to give it into the hands of an AI agent. My safety net was only one thought: “worst case, I revert to last known good state…”

I worked mostly with GitHub Copilot at that time and experimented with different LLMs in it. For an extended period, I had a single agent running in the background to which I assigned tasks. The routine was usually similar: precisely formulate the task, set the constraints, let it generate the result, review the code. Prompt after prompt, me monitoring it executing every single sequence of coding, having it ask for permission for every micro step.

After some weeks of handholding my coding agent I became more courageous and continuously allowed it to do more tasks autonomous without asking for permission. I even walked away while it was coding. The pace of new LLMs arriving with significant improvements in code quality accelerated that and I ended up having it code 30 minutes to hours fully alone.

Very quickly, one thing became clear: my role was changing.

I was programming less in the classic sense. Instead, I spent more and more time reviewing the code the AI produced, understanding it, correcting it, and fitting it into the existing application.

My main activity shifted from programming to code review.

That was not a small difference. Code review is not simply hunting for bugs. It means examining architectural decisions, ensuring consistency with existing patterns, upholding framework conventions, and recognizing technical debt early.

At first, I was still considerably faster overall. The AI took over a great deal of the writing work. I also began delegating test automation to it. Initially I formulated the test cases myself and let the AI write the actual tests, which worked well and again noticeably increased my productivity. But that productivity had a price.

The price of speed: technical debt

Approaching winter of 2025, I noticed technical debt accumulating. Lots of small issues, many developers would not consider als serious, but 40 years of professional software development left a mark with me when it comes to technical debt. It has accumulated to an extent, I felt considerably uncomfortable with.

In the short term I was faster, but in the long term I had to spend more and more time cleaning up the inconsistencies that had crept in. Part of my productivity gain evaporated again, because I was paying back debt that had been created by too much freedom, too little context, and too few consistent guardrails.

In the end, I spent almost two weeks, spread over several working phases, cleaning up the mess the LLMs left in my code base (yes, I did that with the help of AI).

The most striking issue was the inconsistent use of the framework. I use Ruby on Rails for good reason: Rails not only ships with a wealth of good framework elements to use, it also enforces a principle that contributes enormously to productivity: “Convention over Configuration”. It not only helps do avoid making the same decisions in multiple places, it also significantly reduces the amount of code that gets written (think of principle #10 of the agile manifesto: Simplicity). The framework offers sensible paths, reduces unnecessary complexity, and keeps code consistent across different areas of an application.

And yet the AI kept reinventing things that Rails already covers cleanly. Sometimes it used framework features, sometimes it did not. Sometimes it applied Ruby’s standard library properly, sometimes it built its own detours. A problem solved one way in one place was solved a different way in another. The agent simply did not work in a consistently algorithmic manner. It did not consistently follow architectural principles and standards and also kept forgetting what already existed in other parts of the application. It did not reliably recognize which patterns were established or how similar problems had already been solved.

I had to feed it context again and again.

From this came another important lesson: I was far better off giving the AI very small, precisely specified steps than large, diffuse tasks. The bigger the task, the bigger the room for interpretation. And the bigger the room for interpretation, the more likely the AI was to make assumptions, invent solutions, or drift away from established patterns.

Which brought me to one of the biggest practical problems of this way of working: the context window. The longer the tasks became, the larger the code base or radius of work, the more input and output accumulated, the fuller the context window got, and the worse the results were. Quality degraded noticeably. The agent lost the overview, repeated old mistakes, or abandoned patterns it had already followed previously.

For me, this was a key insight: AI coding does not automatically scale with the size of the task. On the contrary. The larger and more diffuse a task becomes, the more it needs structure, context management and clear boundaries.

Guardrails instead of hope

The next stage of my journey was therefore explicit rules. I began working with a central file (claude.md) in which I recorded guidelines, guardrails and coding principles: how I define code quality, how tests should be written, which reviews to perform, which architectural principles apply, and which framework conventions must be respected. The agent will read it before and follow through when acting on any task.

By the first quarter of 2026, this file had grown to more than 200 lines of rules. That sounds like a lot, but it made a real difference. Quality improved again. The AI had more orientation, worked more consistently, made fewer wild assumptions and did not run into “nirvana” anymore. At the same time, the models themselves improved substantially. There was a tangible leap in quality during this period. Models like Claude Opus 4.7 and ChatGPT 5.4 COdex marked a milestone for me: I was impressed how much more usable the output has become, especially in combination with my own guardrails.

There was, however, another side effect: token consumption rose considerably. More context, more rules, better specifications and longer interactions all increase cost. One hour of agent work is still far cheaper than human development work, of course. But it would be wrong to believe that AI coding is simply free, endlessly scaling productivity. It takes time, experience and money to master this way of working productively. So I added more guardrails to keep token consumption considerably low.

Discovering Spec-Driven Development

In the spring of 2026, I came across “Spec-Driven Development” in earnest for the first time, and I was immediately enthusiastic.

That has a lot to do with my own history. In the early years of Test-Driven Development, I worked in a very similar way. With Ruby on Rails I adopted RSpec early on, and with it Behavior-Driven Development. I have always been a great believer in describing behavior precisely and deriving good tests from that description.

Spec-Driven Development felt like a renaissance of those techniques and ideas, but with one significant difference. With BDD we had to express wanted behavior in semi-formal languages and structures.

Today we can write specifications in natural language, in plain English.

That is an enormous advantage, because these specifications are now understandable for humans and machines alike.

So I looked at various SDD frameworks, but was not particularly taken with any of them. Some seemed to create more process weight than I wanted. So I started pragmatically: I wrote and dictated my first specs myself, then used Claude to improve them, formulate acceptance criteria, uncover ambiguities and avoid typical misunderstandings.

In doing so, one thing became clear to me: the new bottleneck is the specification.

If the specification is weak, it leaves too much room for interpretation. And when the AI has to interpret too much, it makes assumptions. Those assumptions can be wrong. Sometimes they are even plausibly wrong, meaning they look reasonable at first glance but are still incorrect in the concrete context. That is why it is not enough to tell the AI what to do. You also have to tell it what not to do.

AIs like to please us humans. They over-deliver. They try to be helpful and in doing so, sometimes build more than you actually wanted. This problem is not entirely new. Human developers have always made assumptions and occasionally built things nobody ordered. The difference is that with AI it happens faster, more often, and at greater scale.

Why product people need to write better specs again

Anyone who knows me from my Product Owner trainings knows that I have always been pragmatic about User Stories. I never bought into forcing everything into the “As a user, I want…” format. What always mattered more to me was that the desired behavior is clearly told or described. Good acceptance criteria were often more valuable than “format-compliant” user stories.

With AI, exactly this becomes even more important. Spec-Driven Development brings us back to an old but often neglected truth:

Good software begins with good understanding, and good understanding needs good specification.

This does not mean we should write enormous requirement documents, and it does not mean falling back into old waterfall patterns. Quite the opposite. Spec-Driven Development is anything but waterfall: Specs are not written months in advance for all the features of a product. They emerge just in time, when a feature actually becomes the next relevant piece of work. The specification is not bureaucracy created up front but an immediate working instrument for implementation, review and learning.

Good specs for AI-integrated development have to be precise, testable, alive and easy to change.

They have to provide enough context for an agent to work sensibly. They have to contain acceptance criteria. They have to set boundaries. They have to respect the existing architecture and the existing patterns. And they have to be short enough not to become a burden themselves.

Spec drift and software archaeology

Another great advantage of Spec-Driven Development lies in a problem I see in many organizations: specification drift: After five or ten years, often nobody knows anymore whether a particular behavior in a piece of software is intended or whether it is a bug. Just because someone says today that something should behave differently does not mean the current behavior is wrong. Perhaps exactly this behavior was deliberately requested at some point.

Then something begins, what I call ”software archaeology”

You spend hours searching in the code. You search old tickets. You search wiki pages written so many years back. You search unit tests. You try to reconstruct why something was built the way it was. Maybe you find the answer… maybe you do not.

Many organizations have dead documentation. It sits in Jira, Confluence or many other systems, but it is not maintained, not in sync with the code. Over time it loses value, and at some point nobody trusts it anymore.

Spec-Driven Development can address this when the specification becomes living documentation. The spec does not only describe what should be built. It stays connected to tests, code and behavior, and over the long term it can help reduce drift.

To me, this is one of the most exciting long-term effects of this way of working.

It is not just about writing code faster today. It is about being able to understand, years from now, why the software behaves the way it does.

From one agent to many agents

In recent months, I have started working with several agents at the same time. The workflow today looks roughly like this: first, a complete specification is created. Then I let agents analyze and plan against this specification, which produces a task list. After that, several agents work in parallel on different parts: generating code, writing tests, reviewing the specification, adding acceptance tests, and in some cases preparing deployment steps.

This is a fundamentally different way of working than classic programming. There is less typing and more orchestrating.

The developer does not become less important because of this. On the contrary, the responsibility grows. You have to be able to judge the quality of a specification You have to make architectural decisions. You have to recognize when an agent is running in the wrong direction. You have to review results, spot technical debt, and integrate the work of several agents into a consistent whole.

To me, this is the real change: AI does not simply replace developers. It transforms the work of developers.

What will development teams look like in the future?

As a Certified Scrum Trainer, I have understood and taught Scrum as a team sport for the past twenty years. I do not expect that to change fundamentally. Software development remains a team sport. What will change is the size of teams and the way work flows through them.

I expect that a Product Leader or Product Owner will in future work with a significant smaller team of developers, each of whom orchestrates several AI agents. The whole product team remains self-organized but will be considerably smaller than many of today’s Scrum teams of (recommended) up to eight developers, or the even larger teams you sometimes find in organizations.

A plausible target picture would be one Product Owner or Product Leader, roughly three experienced developers, and several AI agents per developer. Together they form a human-AI integrated development workflow, including DevOps or even DevSecOps. Such teams will be smaller but more capable than what we used to see from a classical Scrum Team of less than 10. The cadences of such a team will certainly change, too.

I believe that classic sprints will lose relevance in many contexts.

Work will attach itself more strongly to specs: a feature will be understood as a spec, and such a feature can typically be implemented in one to two days typically, in the worst case three days. Review activities will therefore be timed much more tightly. I tend toward working cycles of three days at most.

The question then becomes whether classic sprints are needed at all, or whether Kanban-like cadences fit better: regular reviews, separate retrospective candences, and a continuous flow from specification to implementation to feedback.

Upstream work will change as well: Developers who orchestrate agents need to be much more involved in discovery, refinement and specification. When the spec becomes the central bottleneck, product work can no longer be cleanly separated from development.

For me, this is an evolution of what Agile brought us 25 or 30 years ago: shorter cycles, closer collaboration, faster feedback.

With AI and agentic coding, these cycles become even shorter, and the activities blend even more strongly into one another.

My interim conclusion after more than a year

After way more than a year of AI-assisted, professional software development, my most important insight is this:

Spec-Driven Development is the future of AI-integrated development workflows.

Not because specifications are new, but because AI gives them a new significance. In the past, poor specifications were already expensive, but conversations, experience and implicit team knowledge could often absorb the damage. With AI agents, poor specifications are translated into poor code faster than ever.

Conversely, good specifications can unlock enormous productivity.

AI does not automatically make us better. It amplifies what is already there. Good architecture, good tests, good product understanding and clear acceptance criteria become more valuable, not less.

All the principles we developed in 20-30 years of agile software development become even more important.

The bottleneck shifts from writing the code to formulating the right problem, setting good guardrails, and reviewing the results.

I do not believe AI developers will simply replace humans. I do believe teams will change massively. The future, as I see it, belongs to small, experienced human-AI teams:

Product Leaders who can prepare good specs, developers who orchestrate several agents, and a development process that connects specification, code, tests, review and deployment far more tightly than before.

The uncomfortable part of this conclusion is the timing. This shift is not waiting for anyone. The developers and product people who learn to write AI-ready specifications now will define how their teams work. Those who wait will inherit workflows designed by others, and they will spend the coming years paying back the debt of every vague requirement an agent turned into code.

To me, this does not feel like the end of Agile. It feels like the next stage of its evolution. And the craft at the center of that stage is specification - still some sort of technical excellence.

If you want to build that craft deliberately rather than through a year of trial and error like mine, we have distilled these lessons into a six-week bootcamp:

Spec-Driven Development for Product Leaders

You bring a real feature case, work hands-on with agents like Claude Code, and leave with a working specification practice, turning great specs into production ready code.