Coding with AI Agents: the 20% nobody talks about

At LayerX, every engineer codes with AI assistants. Not as an experiment, not on the side, not only for the easy tasks. Coding, reviewing, planning. All of it runs through Claude Code and Cursor, every day, across the whole team.

This is not a pilot we are still evaluating. It is part of our engineering process now, the same way version control and code review are. And at this moment, I will say it plainly: it is non-negotiable. For how we build software, this is the way to go. I am not hedging on that.

Almost every feature the LayerX team ships now passes through a coding agent before it reaches a human reviewer. The leverage is real, the speed is real, and on a good day it feels like three extra senior engineers joined the team overnight. Honestly, I don't want to go back.

But there is a catch 🤔

I have also spent a lot of time cleaning up after these tools. So when I read another thread claiming someone rebuilt years of engineering with a single prompt, or that "nobody reads the code anymore," I feel the need to say the quiet part out loud. 😱

That is not what production software looks like. Not even close.

The catch is not that the tools are bad. It is that they only pay off when real engineering sits behind them. Here is what building this way has actually taught me. Eleven lessons. No code. Just the things I wish someone had told me before I started trusting the ai models that we can use today.

Lesson 1: The first 80% is the cheap 80%

A coding agent will get you to eighty percent of a feature fast. It scaffolds, wires, names things reasonably, and produces something that runs. The first time you see it, it feels like cheating.

The trap is believing the remaining twenty percent is also nearly done. It isn't. That twenty percent is the edge cases, the failure modes, the concurrency, the security boundary, the thing that breaks at 3 a.m. under load you didn't simulate.

That twenty percent is engineering. It is also the part that separates the crowd from the people who actually ship reliable software. The agent hands everyone the same eighty percent. What you do with the last twenty is the entire game.

Lesson 2: The "one prompt rebuilt years of work" story is a magic trick

I've grown tired of the stories. One prompt, and years of someone's engineering supposedly reproduced in an afternoon.

It's not true, and the reason is simple. What you're looking at is a prototype, not a product. It demos well. It has no real users, no concurrency, no abuse, no compliance, no data migrations, no on-call history baked into its design.

Years of engineering are not years of typing. They are years of decisions. Every awkward branch in a mature codebase is usually a scar from a real incident. An agent can reproduce the surface in an afternoon. It cannot reproduce the judgment, and the judgment is the product.

Lesson 3: You never stop reading the code

The other claim I don't believe: "I don't read the code anymore."

Over time you do develop a sensibility. You learn to smell when something is off, where the agent tends to cut corners, which kinds of prompts produce fragile output. That sensibility is valuable and it's worth building.

But sensibility tells you where to look. It does not look for you. Every meaningful change still gets a proper review, the same review I'd give a junior engineer who is fast, confident, and occasionally very wrong. Skipping that step isn't a productivity gain. It's a deferred incident.

Lesson 4: Without a design, the agent will invent one for you

This is the failure mode that costs the most, and it's quiet.

Ask an agent for a feature with no design and no constraints, and it will happily deliver. It will also write a second version of a helper that already exists, introduce logic nobody asked for, and solve the same problem three different ways in three different files. None of it is wrong on its own. Together, it's entropy.

The agent optimizes for "make this prompt pass," not "fit this cleanly into a coherent system." If you don't bring the architecture, it will improvise one, and improvised architecture is how you end up with a codebase nobody can maintain. Give it the design, the constraints, the existing patterns. Tell it explicitly what not to do. Guidance is not optional. It's the job.

Lesson 5: A prototype is a promise, not a product

Vibe coding is fantastic for the first mile. You can stand up something real in a day, put it in front of people, and learn fast. The LayerX team does this constantly, and it's one of the best uses of the tools.

Then the hard part starts.

Polishing is the hard part. Making it shine under stress is the hard part. The prototype is a promise that the thing can work. Turning that promise into software that holds up in production is slow, unglamorous, deeply technical work. The agent helps, but it doesn't shorten the distance the way the demo made you believe it would.

Lesson 6: Production is earned with tests and performance, not prompts

The moment you want thousands of users, the rules change. The moment you want to sell to other companies, they change again.

At that point, proper unit testing stops being a nice-to-have. Rigorous performance work stops being a later problem. How the system behaves under load, what happens when a dependency is slow, where it degrades and how it recovers, these are the questions that decide whether you have a business or a liability.

An agent will write tests for you. It will not decide what is worth testing, what your performance budget is, or what "good enough to charge for" means. Those are engineering decisions, and they're the ones customers are actually paying for.

Lesson 7: Every model release rewrites your assistant's personality

This is the most underrated frustration of working with these tools.

Every new release, every new model, the behavior shifts. A prompt pattern that worked beautifully last month now produces something subtly different. The defaults move. The way it interprets ambiguity moves. You spend real effort relearning how to make the assistant do the right thing.

I've learned to treat every major release as a new hire. Talented, probably an upgrade, but unproven on our codebase. So I stay conservative. For a while after an update, generated code gets extra scrutiny, not less. The upgrade is usually worth it. The blind trust during the transition is not.

Lesson 8: The agent amplifies the engineer you already are

A coding agent is a multiplier, and multipliers work in both directions.

Give it to a strong engineer with clear standards and it makes them dramatically faster at producing good code. Give it to someone who skips design and avoids review, and it makes them dramatically faster at producing bad code. Same tool, opposite outcomes.

This is why I'm not worried that agents make engineers irrelevant. They do the reverse. They raise the value of judgment, taste, and discipline, because those are now the scarce inputs. The typing was never the bottleneck. The thinking always was.

Lesson 9: I write in languages I never sat down to learn

I did not expect this one when we started. I now move between Python, Swift, and Zig without ever having paid the full price of learning any of them the traditional way.

There used to be a tax on every new language. Weeks of syntax, idioms, tooling, standard libraries, and the conventions that only make sense once they have burned you. That tax kept a lot of good engineers locked inside one or two languages for an entire career.

The agent collapsed that tax. I can start in an unfamiliar language and ask the code questions as I go. Why is it written this way. What does this idiom actually do. Is this the idiomatic choice here, or just one that happens to compile. I am learning the language while I ship in it, not for months before I am allowed to start.

This is one of the parts I love most, and it has changed what I am willing to take on. But it works for one reason. I already know how to engineer. I am not learning to program, I am mapping ideas I already understand onto new syntax, and the judgment about whether the result is sound comes from experience that has nothing to do with the language. The agent translates. The engineering is still mine.

Lesson 10: Engineering process is the moat now

When code becomes cheap to generate, the thing that's still expensive is keeping a system coherent.

That means process. Code review that actually reviews. Conventions the agent is told to follow. Architecture decisions written down. CI that fails loudly. A real definition of done. None of this is new. What's new is that it's no longer the boring overhead around the real work. It is the work.

The engineering process is what separates software that scales from software that quietly rots while shipping fast. At LayerX, that discipline is not negotiable. Our shared conventions, our reviews, and our written architecture decisions are what let a small team move quickly without the codebase coming apart underneath us. The teams that win with these tools will be the ones with the strongest discipline, not the ones with the cleverest prompts.

Lesson 11: We can't work without it, and that's exactly why discipline matters

I'll be honest about where the LayerX team lands on all of this. We rely on coding agents heavily, across every part of how we build, and none of us would seriously argue for going back. They've changed how fast we move and how small a team can stay while doing it.

But it is not only roses 🌷

Used without guidance, these tools will quietly work against you. They'll fill your codebase with duplication, drift from your design, and hand you a prototype dressed up as a product. Used with strong engineering around them, they're the best leverage I've seen in my career.

The technology is not the differentiator anymore. Everyone has the same agents. The differentiator is the engineer steering them, and the process holding it all together. The other twenty percent. That's still us, and it matters more than ever.

Where we actually stand

Everything above is the de facto state of building software today. Not a prediction. The current reality, lived day to day by our team.

And it's moving fast. Each model release pushes hard, and the improvements are not cosmetic. I can already see models getting better at following our guidelines, respecting our conventions, and applying standard software practices without being told twice. That trajectory is real, and I expect it to hold.

But here is my honest read for the months ahead. The model will still need proper guidance, and it will still need rigorous software engineers behind the scenes steering it toward the right things. Better does not mean autonomous. A sharper tool still needs a hand that knows where to cut, and on the LayerX team that hand is always a real engineer.

The productivity gain itself is not up for debate. A coding assistant augments what you can do and lifts your output by an order of magnitude. That is undeniable, and anyone who has used these tools seriously already knows it.

What it does not do is replace years of engineering decisions, or let you replicate them quickly. Those decisions are accumulated judgment, and judgment does not compress into a prompt.

So I don't think AI is eating software's lunch. I think it's doing something more interesting. It is turning the engineer into a kind of superhero, proficient at a scale and in situations the engineer alone would never have reached, fluent in corners of the system they wouldn't have thought to explore. The engineer doesn't disappear in that story. The engineer gets amplified.

That's the future I'm betting on. Better models, every month. And right behind them, more engineering than ever.

Engineering is the new Moat 🏰

We build AI-native software at LayerX, and we ship it with agents every day. If you're wrestling with the same questions about getting from prototype to production, I'd genuinely like to hear how your team is handling it.