AI Agents and the Rockstar Developer Problem
Generated code arrives fast, but teams still need shared design, local conventions, change budgets, and review gates before output becomes software they can own.
Every software team eventually meets some version of this old failure mode: one very capable developer builds a system that only they can really explain.
The details change from company to company. Sometimes it is a custom framework that exists because one person got bored with the boring one. Sometimes it is a build system with three hidden assumptions and one person who knows the ritual. Sometimes it is a beautiful abstraction that looks like serious engineering until the first bug report arrives and nobody can explain how data moves through it.
Smart was fine. Smart helped.
The failure was unshared design.
The architecture lived in one head. The code fit the person writing it, not the people who had to change it later. Code review stopped helping because nobody wanted to say they did not understand the impressive part. Eventually the person left, changed teams, lost interest, or became too busy to explain the system they had created.
Then the team discovered the actual architecture document: production.
AI agents are making that old problem cheap, fast, and repeatable.
As I have written in AI Coding in Real Systems: Code Is Cheap. Software Isn’t, the code arrives faster now. The ownership, verification, and integration costs still arrive on the team’s side of the ledger.
The New Rockstar Forgets Yesterday
A human rockstar, for all the damage one can do, at least has continuity. They remember the argument that produced the abstraction. They remember why the service boundary landed there. They remember which bug made them add the defensive layer everyone else now has to step around.
A continuous mind sat behind the mess. That did not make the code maintainable, but it at least gave the team one place to ask why the system looked like that.
An agent session has no durable ownership unless the team builds it. It can generate a clever solution in the morning, generate a different style of clever solution in the afternoon, and then confidently refactor both tomorrow from a partial view of the repository.
The old rockstar developer created a private architecture.
The AI version creates a series of private architectures, one chat at a time.
Each individual change can look reasonable. The tests pass. The code compiles. The explanation sounds calm. The agent used a known pattern, maybe even a good one. But the system slowly collects incompatible ideas:
two ways to model errors
three ways to configure clients
a new helper layer around a framework that already had the helper
a validation style from one tutorial
a reactive pattern in one endpoint because the model saw it somewhere
a security check that is correct locally and meaningless in the real request path
None of those has to be catastrophic alone. That is why the failure mode is hard to see early. The cost shows up when the next developer has to change the system and finds five small architectures pretending to be one application.
This is not a model-quality complaint per se. Better models will reduce some of the local mistakes. They will not remove the need for a coherent engineering style.
That is also why broad “language support” claims are not the solution here. What Code LLM Vendors Usually Mean by “Language Support” splits that into a ladder: syntax is one thing, framework fit is another, and workflow support is where serious teams start caring.
Consistency Is Operational Memory
Developers like to talk about consistency as if it were polish. Naming, layout, dependency choices, exception patterns, logging, tests, configuration, HTTP client usage. These sound like small matters until a team is under pressure.
Under pressure, consistency becomes operational memory.
If every Quarkus resource handles failures the same way, you know where to look. If every service uses typed configuration the same way, you know how a setting reaches runtime. If tests follow a predictable shape, you can add one without rediscovering the local habits. If logging uses one library and one style, incident review is less annoying than it already has to be.
The boring shape of a codebase is part of how a team thinks together.
AI agents do not naturally respect that shape. They respect the context they see, the instructions they receive, the examples closest to the current task, and the statistical gravity of all the code they were trained on. That means they can be fast, helpful, and slightly too willing to solve the problem they inferred instead of the problem this system has.
If the repo has no visible rules, the agent invents a style.
If the prompt has no boundaries, the agent expands the task.
If the review only checks whether the output works, the architecture drifts.
That is not the agent being malicious or stupid. It is doing what we asked badly enough.
The Agent Is Not a Teammate
I use agents. I like them. Hand-written code has no moral purity here. Plenty of terrible code was typed by humans with full confidence and a mechanical keyboard.
But teams get into trouble when they treat the agent like a teammate and then forget the parts of teamwork that make software survivable.
A teammate carries memory. A teammate can be responsible for a design after the merge. A teammate can sit in the incident review and explain the trade-off. A teammate can learn the local codebase over years and internalize what the team does not want repeated.
An agent can help with all of that, but it does not own any of it.
Ownership still lands on the humans.
That changes how I want teams to use these tools. The agent should not act like a replacement senior engineer with unlimited permission to reshape the codebase. It should work inside clear boundaries:
clear task scope
visible local conventions
small changes
tests that describe the expected behavior
review that checks integration, not only syntax
a human who can explain why the final version belongs in this system
That slows the tool down enough for the team to stay with it. Some slowness is not waste. Some slowness is the part where understanding catches up with output.
The Senior Job Moves Toward Taste and Control
Senior engineering judgment moves upstream and sideways in the agent era.
Less time typing boilerplate can be good. I am happy to spend less of my life writing the tenth shape of the same DTO mapping. But if implementation gets cheaper, the important question changes from “can we build it?” to “what shape should it have, and how do we keep that shape over time?”
That is architecture. Not the slide-deck version. The daily version.
Which framework feature should we use before adding our own layer?
Which abstraction is too clever for this problem?
Which generated test proves behavior, and which one only proves that the mock was configured?
Which local convention should be written down because the agent keeps missing it?
Which change should be split because the diff is now too large for meaningful review?
That last question has its own version in Give Coding Agents a Change Budget. A change can be technically valid and still too large for a human reviewer to own in one pass.
That work can feel less glamorous than watching a tool generate a full feature in one pass. It is also the work that keeps a team from drowning in plausible code.
AI raises the value of taste because it lowers the cost of producing tasteless volume.
Taste here does not mean personal preference with seniority attached to it. It means choosing the plain thing that fits the system, rejecting the impressive thing that does not, and explaining the difference without turning review into a debate club.
Code Nobody Understands Is Still Debt
One of the more dangerous habits in agent-assisted development is accepting code because the agent can explain it.
That is a low bar.
The agent can explain almost anything after the fact. The explanation may even be accurate. But a generated explanation is not the same as team understanding. If the humans cannot maintain the code without reopening the chat and asking the same system to interpret itself, the team has taken on a new dependency.
Sometimes that dependency is fine. We already depend on tools. We depend on compilers, IDEs, search, docs, static analysis, and people with better memory than ours. But depending on an agent to make sense of architecture the team never understood is a bad trade.
It creates a codebase that can only be maintained through the same mechanism that made it confusing. A team can live there for a while, but it is an expensive place to maintain software.
This is also where The Spec Trap comes back in. If the intent never became concrete enough for a human or a test to check, the implementation can pass the written prompt and still miss the system.
The healthier pattern is simple: use the agent to accelerate work the team can still own.
Let it draft the boring parts. Let it find similar code. Let it write the first test. Let it propose a refactor. Let it explain an unfamiliar dependency. Let it handle mechanical edits where the rules are clear. You can even brainstorm implementation ideas and evaluate their pros- and cons.
Then slow down at the boundary where the code changes the architecture, the runtime behavior, the security model, or the team’s future review burden.
That boundary is where the rockstar problem starts.
Write Down the Local Rules
Banning agents would age badly and waste a lot of useful leverage.
The practical answer is to make the team’s engineering taste visible enough that an agent can work inside it.
That means plain files with plain names. AGENTS.md. CONTRIBUTING.md. Local coding rules. Architecture decision records when the decision matters. Examples of the pattern you want copied. Tests that fail when the agent improvises in the wrong place. Small prompts that tell the agent the shape of the task before it starts inventing a better world.
This can look like process until it saves a review. It is context engineering for codebases. The more operational version of that idea is AGENTS.md: Give Your Coding Agent an Operating Manual.
If you do not give the agent a local operating model, it will bring one from somewhere else. Usually several. Usually with unjustified confidence.
The same applies to review. Generated code needs a fit check before it gets a cleverness check. The first question is whether the change belongs.
Does it follow the framework’s standard path?
Does it use the same configuration model as the rest of the service?
Does it add an abstraction because the system needs one, or because the model has seen that shape often?
Can the next developer change this without asking an LLM to narrate the maze?
If the answer is no, the code still needs work, even if every test is green.
For the repository side of this, I would pair that operating manual with Coding Agent Guardrails: Treat Every Commit as Untrusted. Prompt discipline helps, but the repo still needs hooks, CI, protected paths, and merge boundaries that can say no.
Keep the Code Boring Enough to Survive
The old rockstar developer left behind code that made the rest of the team feel slower and less informed.
The AI version can do the same thing at a much larger scale. It can make everyone feel productive while the codebase becomes harder to reason about. It can make architecture drift look like velocity. It can make review feel unnecessary because the output is clean, formatted, and accompanied by a confident explanation.
That is the trap.
Generated code should still be team code. It should follow the same conventions, carry the same tests, fit the same architecture, and be understood by the people who will wake up when it breaks.
Agents are useful. Speed is useful. Fast drafts are useful.
But the work is not finished when the agent stops editing files. The work is finished when the team can own what changed.
That is the part the rockstar developer never optimized for.
It is the part we cannot outsource now.