DEV Community: Timon Krebs

AI Gives Individuals Rockets. Teams Need Air Traffic Control.

Timon Krebs — Tue, 14 Jul 2026 19:38:07 +0000

AI made writing software cheap. That is the obvious story. More code, more prototypes, more pull requests, more “I built this in one afternoon” moments. Very impressive. Very dangerous. Very LinkedIn.

Because the interesting story starts one step later: once quantity becomes cheap, quality becomes the bottleneck.

And by quality I do not mean “does it compile?” or “did the model also generate tests that heroically confirm its own assumptions?” Those things still matter, obviously. But they are not the scarce thing anymore. The scarce thing is confidence: confidence that the change is right, that the team understands it, that the product still makes sense, and that the system will not turn into archaeological material for future developers.

It was never easier to build software. It was never harder to build good software.

Code review is where the bill arrives

AI increases output faster than teams can increase understanding. That is why code review is becoming the new bottleneck. O’Reilly’s article on agentic code review makes this visible with some wonderfully numbers: code churn up 861%, incidents-to-PR up 242.7%, defect rates rising from 9% to 54%, median review duration up 441.5%, and more PRs merged with zero review.

That is not a productivity graph. That is a smoke alarm with axis labels.

Traditional review was designed for a world where humans produced code at human speed. A developer wrote a change, another developer reviewed it, and the system was slow but at least somewhat balanced. AI breaks that balance. Now code can arrive faster than humans can deeply review it, and the bottleneck moves from “can we produce a solution?” to “can someone competent become confident this solution is right?”

Reviewing everything line by line is not the answer. That does not scale. But reviewing less while pretending nothing changed is worse. That is how you get a codebase that technically works, spiritually screams, and requires a priest before every refactor.

The one-person AI rocket hits the team wall

A lot of current AI best practices work extremely well for experienced, skilled one-person shows. And that makes sense. If you know the domain, know the architecture, understand the tradeoffs, and can smell nonsense through three layers of confident autocomplete, AI is incredible. It is like having a very fast junior developer who never sleeps, never complains, and occasionally invents a database migration because it felt emotionally right.

For a strong individual, this can be a genuine superpower. The human keeps the system model in their head. The AI produces options, drafts, tests, refactorings, explanations, and glue code. The expert filters. The loop is tight. The context is local. The quality gate is one brain.

Teams are harder.

In a team, the bottleneck is not only implementation. It is shared understanding. Who knows why we chose this architecture? Who remembers the product constraint from three weeks ago? Who understands which stakeholder request was intentionally not implemented? Who can tell whether this new feature fits the domain model or just sounds plausible in a PR description?

AI makes the individual loop faster, but teams do not scale by making everyone individually faster. They scale by making understanding transferable.

That is where many current practices hit a wall. Prompting harder does not solve it. More agents do not solve it. A bigger context window helps, but it does not magically create agreement. Team-level AI needs shared context infrastructure: explicit decisions, visible assumptions, domain language, product principles, review criteria, and a way to surface misunderstandings before they become architecture.

This is why quality practices are not bureaucracy anymore. They are the scaling layer.

ADRs and Open Knowledge Format are not “nice documentation.” They are how AI usage becomes team-compatible. They turn private reasoning into shared artifacts. They let humans and agents argue over the same object. They make it possible to review not only the code, but the intent behind the code.

The one-person AI rocket is impressive. But if you want a team to fly, you need more than rockets. You need air traffic control.

Review has to move up a level

We still need to look for bugs, security issues, test gaps, and architecture drift. But we also need to review product quality: is this intuitive, is it consistent, does it solve the actual user problem, does it add clarity or complexity, does it reflect taste?

This matters because AI makes stakeholder wishes dangerously affordable. In the past, some bad ideas died peacefully because they were too expensive to implement. A beautiful natural selection mechanism. Now AI can build them all. The backlog no longer has brakes; it has a rocket engine and a questionable sense of direction.

So restraint becomes a technical skill. Taste becomes part of engineering. Saying “no” becomes architecture.

Only because we can build everything users and stakeholders say they want does not mean we should. That sentence sounds obvious until every request comes with a working prototype by lunch.

For teams, this is even more important. A single expert can silently apply taste while coding. A team cannot rely on silent taste. Taste has to become discussable. Product judgment has to become reviewable. Architecture has to become visible. Otherwise every developer and every agent optimizes locally, and the product slowly becomes a collection of individually reasonable decisions that collectively require an apology.

AI is amazing at quality — if we aim it there

Clean Code (or even better Vertical Slices), Domain-Driven Design, Behavior-Driven Development, better tests, clearer naming, useful documentation, Architecture Decision Records (and for the js/python devs even type-systems are not a given) — all the things teams used to call important right before saying “but we do not have time” suddenly become much easier. AI can extract domain language from tickets, draft BDD scenarios, compare code against product intent, find inconsistencies, propose refactorings, summarize tradeoffs, and generate documentation that is at least good enough to start a fight.

Starting the right fight is underrated.

Used badly, AI creates more code than understanding. Used well, AI creates more understanding than code. That is the difference between acceleration and acceleration directly into a wall.

And this is where the team-scaling benefit appears. AI can help turn tacit knowledge into shared knowledge. It can turn vague intent into examples. It can turn a messy discussion into a decision record. It can turn a PR into a reviewable explanation of tradeoffs. It can turn “I thought we agreed on this” into “here is the artifact where we can see that we absolutely did not.”

That is not just documentation. That is organizational debugging.

The surprising value of imperfect ADRs

One of the best examples is Architecture Decision Records. I used to think of ADRs mainly as documentation: useful, responsible, slightly boring, and therefore doomed to be written “later,” which in software means sometime after the heat death of the universe.

AI changes the economics. You can generate ADRs after the fact. That sounds suspicious, and yes, ideally decisions are documented when they are made. But even after-the-fact ADRs can be incredibly useful because they expose what the system appears to believe.

The generated ADR says: “We chose this architecture because…” and someone on the team immediately says: “Wait, no we didn’t.”

Perfect.

That is not a documentation failure. That is a misunderstanding becoming visible. A slightly wrong ADR can be better than no ADR because it creates a concrete object for discussion. It gives the team something to correct, challenge, refine, and align around.

Software engineering is a specification gathering exercise.

The same applies to Open Knowledge Format (OKF): decision logs, domain concepts, assumptions, risks, examples, open questions, product principles. The first version does not have to be perfect. In fact, if it is slightly imperfect, it may be better. Perfect documentation can create silence. Imperfect documentation creates useful friction, and useful friction is where shared understanding is built.

This is especially powerful in teams because the artifact becomes a meeting point between people, code, and agents. The developer can challenge it. The reviewer can use it. The product person can correct the intent. The next AI run can use it as context. The new team member can understand not only what exists, but why it exists.

That is how quality scales. Not by making every individual remember more, but by making the important things harder to lose.

The trap is cognitive debt

The danger is not simply that AI writes bad code. Humans have been writing bad code for decades with far less impressive hardware. The real danger is that AI writes plausible code faster than teams can understand it.

That creates cognitive debt: more features than product coherence, more tests than confidence, more documentation than agreement, more code than ownership. At that point AI has not made the team faster. It has made confusion scalable.

We fell into this trap too. AI made progress feel effortless, so we produced more. Then review became heavier, assumptions became harder to track, and misunderstandings appeared in places where the code looked perfectly fine. The important part was noticing early.

The countermeasure was not to use less AI. It was to use AI differently. Not only for implementation, but for review surfaces: ADRs, explanations, domain notes, product questions, test scenarios, risk summaries, alternative interpretations. AI became less of a code generator and more of a misunderstanding detector.

A surfaced misunderstanding is a gift. A hidden misunderstanding is an incident wearing fake glasses and a mustache.

This is the team version of the AI sweet spot. Do not only ask AI to produce the next change. Ask it to make the reasoning behind the change inspectable. Ask it to expose assumptions. Ask it to compare the change against ADRs, OKF, product principles, and domain language. Ask it to help the team disagree earlier and more precisely.

The goal is not fewer conversations. The goal is better conversations with less fog.

Quality work feels slower first

Here is the uncomfortable part: using AI for quality often slows you down at the beginning (at least when compared to turning the slop to 11). It adds review work. It creates more discussion. It surfaces disagreements. It asks the team to think before merging. Very rude.

This can feel frustrating when AI has made implementation feel instant. But the slower feeling is not necessarily waste. Often it is the system learning. Better decisions reduce rework. Better ADRs reduce confusion. Better domain language reduces translation errors. Better product review reduces feature bloat. Better tests reduce fear.

In the long run, quality becomes productivity. Maybe even in the not-so-long run.

The trick is surviving the awkward middle, where the team is doing more thinking but has not yet received the compound interest. This is where culture matters. If the culture worships output, quality work will look like delay. If the culture values understanding, quality work looks like investment.

This is also where scaling starts to work. At first, ADRs, OKF, and richer reviews feel like extra weight. Later, they become rails. New people onboard faster. Agents produce more relevant drafts. Reviews become less repetitive. Decisions stop being rediscovered every sprint. Product discussions become less emotional because the assumptions are visible on the table instead of hiding inside everyone’s head wearing camouflage.

The early cost is real. But the alternative is paying interest on cognitive debt forever, which is less fun than it sounds, and it already sounds terrible.

Quality is the new Quantity

AI is a multiplier, but multipliers do not care what they multiply. If your process rewards output over understanding, AI multiplies output over understanding. If your team says yes to every stakeholder request, AI multiplies product complexity. If your review process is already overloaded, AI does not magically fix it; it delivers more boxes to the burning warehouse.

But if your culture rewards clarity, taste, review, architecture, shared understanding, and useful disagreement, AI multiplies those too. That is the opportunity.

The first wave of AI software development was about producing more. The next wave is about understanding better. The winning teams will not be the ones with the most generated code. They will be the ones with the best filters: the best review systems, the clearest product judgment, the strongest shared understanding, and the discipline to say no when building would be easy but wrong.

For individuals, AI can be a rocket. For teams, quality is the guidance system. Without it, everyone moves faster in slightly different directions, which is a very efficient way to create a distributed mess.

The Codebase Is the Prompt

Timon Krebs — Sat, 27 Jun 2026 23:52:13 +0000

The database analogy is usually wrong when people use it to explain AI.

A language model is not a database full of facts, documents, or answers. When you ask it a question, it is not looking up a record and returning the matching row. There is no table called “JavaScript bugs” or “how to design an API” hidden inside the model.

But the analogy is not useless. It is just usually applied at the wrong level.

The prompt is not a key that retrieves a stored answer. It is more like a fuzzy query into a compressed space of learned patterns. The model does not fetch the answer. It reconstructs a plausible continuation from the patterns that the prompt makes relevant.

This matters because people often mentally separate the prompt from the data.

“My instruction is the prompt. The codebase is the material the model works on.”

But the model has no such separation.

In a codebase task, the codebase is the prompt.

The surrounding code conditions the output just as much as the typed request does. The naming, the architecture, the hidden assumptions, the tests, the missing tests, the file layout, the comments, the abstractions, and the inconsistencies all become part of the query.

This became obvious to me after using Fable 5.

I was blown away. I blasted through two Claude Code subscriptions, one personal and one from work, and upgraded to the Max plan almost entirely because of Fable. I had personal projects lying dormant for years, not because I did not care about them, but because I could not find the time and energy to get back into the complexity they required. I had tried earlier models every now and then, asking them to add features or move these projects forward, and every time they failed hard.

With Fable 5, that changed.

It solved multiple problems that I had personally sat with for hours without success. More importantly, it solved them in a way I could understand. It did not just dump code on me. It helped me see the shape of the solution. For a while, it felt almost godlike. I was in heaven. The only thing keeping me from going completely crazy from lack of sleep were the token limits.

So I expanded the experiment. I used it on more personal projects, including multi-year-old projects I had not touched because of time constraints, life, and having small kids. Again, the same thing happened. Old projects started moving. Problems that had felt too expensive to re-enter suddenly became solvable.

But at work, I could not get the same fable boost.

At first, the obvious explanation was process. Maybe I was not committing to the tool in the same way. Maybe strict acceptance criteria, guardrails, review requirements, and company constraints prevented the same flow.

Then came the ban.

That pause gave me time to review what had actually happened. I looked back at code Fable had written for me. I also reviewed code from other developers that had been generated with Fable. The picture became more complicated.

Sometimes Fable had produced excellent code. Sometimes it had solved genuinely difficult problems. But sometimes it had produced bad code with obvious issues.

Eventually, something clicked.

The quality of the output was closely linked to the quality of the codebase it was working with.

That sounds obvious. But the solution is not obvious.

The simple reflex is to say: if the model performs worse in a bad codebase, give it more good code. Give it best practices. Give it clean examples. Give it architecture guidelines. Add counterweights to the prompt so the messy codebase does not dominate the answer.

But this does not help as much as one would hope.

The reason is that good code is local.

In a good codebase, encapsulation and clear interfaces let you understand a function from its signature and a small neighborhood around it. You do not need to read the entire system to safely change one piece. The relevant information is close by. The code compresses well because the same patterns repeat. The model can see the local shape and infer the missing parts.

Bad code is non-local.

A function depends on hidden global state. Behavior changes because of something in a distant file. A method only works if someone remembered to call init() first. A harmless-looking change breaks an unrelated feature because the real dependency is implicit. The important information is not near the code being changed.

This is where LLMs struggle.

The information the model needs to be correct may simply not be in its context window. Worse, neither the user nor the model necessarily knows which distant code is the relevant context to supply. So the model reasons from what it can see, fills the gaps with priors, and produces something confident and wrong.

This is why “just add best practices” often fails.

Best practices are not neutral. They also become part of the query. If you give the model a messy codebase and then add a clean example, you may think you are saying: “Fix this bad code using this good principle.”

But the prompt is saying: “Continue with this pattern.”

Those are different tasks.

The model can get pulled away from the actual problem. It may produce code that looks better in isolation but does not fit the hidden constraints of the system. It may follow the best practice while missing the reason the code became ugly in the first place.

A bad codebase is therefore not merely a hard query against a good prompt.

It is a bad prompt.

You are handing the model a worse input and asking for a better output than the input supports.

This closes the loop back to compression. The very property that makes code bad for humans — irregularity, inconsistency, special cases, high entropy — is the same property that makes it hard for a predictive model to work with. Good code compresses well because it is regular. A language model is, at bottom, a compressor of regularities. So regular code is its home turf, and irregular code is where it is weakest.

The thing that frustrates the human and the thing that defeats the model are one thing.

That is also why in-context learning is often misunderstood. The model is not learning your codebase in the way a developer does. It is not building a durable mental model. It is being temporarily conditioned by whatever fits into the prompt. If the relevant invariants are missing, implicit, or spread across the system, the model cannot reliably infer them just because you gave it more text.

And this also explains context rot.

Context rot is not merely what happens when the context window gets long. It is what happens when the query decays. Old assumptions, abandoned solutions, stale files, half-correct explanations, and irrelevant examples remain in the conversation. The model keeps trying to satisfy all of them because, from its perspective, they are still part of the prompt.

The practical conclusion is not that LLMs are useless on bad codebases.

It is that the fix is usually not a cleverer prompt.

The fix is to supply the non-local context the model cannot see, and to shrink the task until locality holds again. Instead of asking the model to fix the system, ask it to inspect one boundary. Instead of asking it to refactor a tangled module, first ask it to identify the hidden invariants. Instead of giving it generic best practices, give it the specific constraints that make this codebase weird.

The people who get real value from LLMs on bad codebases are often the people who already understand the code well enough to compress the chaos for the model.

The model rewards whoever can make the query sharp.

Do not just prompt the model to solve the problem. First use the model, and your own system knowledge, to find the smallest slice of reality where the problem becomes locally understandable.