Posted on Leave a comment

I came back to coding after 20 years, and the fault line on my team was nothing like I expected

A moment from last quarter that I keep coming back to.

I had given an AI coding agent a non-trivial brief — a real production change to a payments edge case in a client system. I let it plan, execute, run its own tests, and submit the pull request. I reviewed at the seams: architectural fit, the spec contract, the risk surface. Merged. Shipped. It held.

The same week, one of my senior engineers — a brilliant builder with fifteen years of production code behind him, who is literally helping me build an AI-native software factory — handed an agent a smaller task, watched it produce one buggy commit, and turned the autonomy down to “auto-complete in my IDE only” for the next fortnight.

Same company. Same tools. Same agents. Completely different operating posture.

I stopped writing production code in 2005. I came back to it eighteen months ago, because AI made it possible — and interesting — again. The engineer who throttled the agent is a far better builder than I will ever be.

The variance between us is not about skill. And it has reshaped how I think about team design.

The fault line isn’t where the org chart says it is

When my team and I started this transition, I assumed the readiness curve would track seniority. Senior engineers, having seen more, would steady the ship. Junior engineers, less invested in old habits, would adapt faster.

The reality is almost the opposite — and the data backs the experience.

The 2025 Stack Overflow Developer Survey of more than 49,000 developers found AI adoption now sits at 84 per cent, while trust in AI accuracy has dropped to 29 per cent — down from 40 per cent a year earlier. The breakdown is the part that matters. Experienced developers with 10+ years of record have the lowest “highly trust” rate at 2.6 per cent, and the highest “highly distrust” rate at 20 per cent. 66 per cent of all developers say they are now spending more time fixing “almost-right” AI-generated code.

Use is up. Trust is down. And the people building the most are trusting the least.

This shows up inside an AI-native team in the same shape. The variance I see between my engineers is not their ability to use the tools. It is the autonomy budget they are willing to grant the machine. Some give an agent the same trust I do — let it plan, let it act, intervene at the seams. Others, after a single error, clamp it to “auto-complete only, do not commit anything I haven’t typed.”

The thing nobody is naming out loud: a quiet part of every experienced engineer would prefer this technology not to fully work. If it does, twenty years of craft is being commoditised in front of them. One almost-right bug becomes proof. The mind looks for the confirming signal.

I felt it too, briefly, in 2024 — and let it go, because the alternative was to be the bottleneck in my own company.

Also Read: Singapore’s AI infrastructure gap is trapping businesses in pilot purgatory

The half-baked trap

You cannot run an AI-augmented team on a traditional review discipline. The maths breaks.

If agents generate code at machine speed and every line, then routes through human eyeballs, you have not built leverage. You have built a faster typewriter feeding a slower bottleneck. The human reviewer becomes the constraint, burns out, and starts shallow-reviewing, which is worse than not reviewing at all, because everyone now thinks the code has been checked.

The teams that get traction are the ones that go fully through the shift, not halfway. They build a machine-to-check-the-machine layer underneath the human. AI code review against architectural and security policies. AI test generation against the spec. Agents enforcing the same disciplines that made junior engineers safe a decade ago — structured commits, contract tests, observability, and rollback. Human review concentrates at the seams: spec quality, architectural fit, risk surface, customer-visible behaviour.

This is not less rigour. It is rigour relocated. And the team needed to run it, which looks nothing like the one we had two years ago.

The team that has emerged

A few things I did not expect when this was still theoretical, and now take for granted.

  • The shape is flatter, but the apex is more concentrated. The middle layer of execution-only roles has thinned. The judgment layer — small, senior, opinionated — has not. You do not need more people. You need more clarity at the top of the funnel.
  • The highest-leverage skill is now specification. Agents execute against precise specs. They flail against vague ones. The bottleneck on an AI-native team is not coding capacity. It is the specification capacity. The colleague who can turn a customer ask into a clean, testable spec produces more output today than three engineers used to.
  • “Senior” means something different. It used to mean “writes the most production code.” It now means “decides what the agents should do, sees the failure modes earliest, and owns the seams.” Tenure is no longer a reliable proxy for either.
  • Culture has to actively reward the new posture. In the old culture, a senior engineer earned respect by producing tight, well-crafted code. In the new culture, the same engineer earns respect by orchestrating five agents producing a hundred times the code, without losing the architectural plot. If your reward signals still point at the old behaviour, your best people will quietly resist the shift — and they will be right to, given what you are rewarding them for.

Also Read: Can Thailand close the gap between US$1B in waiting capital and US$120M in actual investment?

What I would tell anyone reshaping a team right now

One thing, if I had to pick one.

Decide deliberately what level of agent autonomy you are running at, and align the whole team to it. Not implicitly. Not “we use AI.” Explicitly — at the level of “agents may plan, execute, run their own reviews and tests, and merge with a senior signing the seams.” Or whatever level you choose. Then build the machine-to-check-the-machine layer that lets you actually operate at that level safely.

The teams that drift into AI use without that decision land in the worst of both worlds. Fast code generation feeding slow human review. The bottleneck human is getting blamed for being slow. The agent is getting blamed for being unreliable. Neither is the real problem. The real problem is a team operating at two cadences, with two trust postures, hoping nobody notices the gap.

Customers notice. So do the engineers who have already made up their minds — in both directions.

For a deeper exploration of how AI is reshaping mid-market operating models, including team design, the five-layer always-on architecture, and a 90-day playbook, see The Always-On Enterprise: Why AI Is the Operating System Your Business Is Missing (Amazon, 2026). 

Editor’s note: e27 aims to foster thought leadership by publishing views from the community. You can also share your perspective by submitting an article, video, podcast, or infographic.

The views expressed in this article are those of the author and do not necessarily reflect the official policy or position of e27.

Join us on WhatsAppInstagramFacebookX, and LinkedIn to stay connected.

The post I came back to coding after 20 years, and the fault line on my team was nothing like I expected appeared first on e27.

Leave a Reply

Your email address will not be published. Required fields are marked *