What 6 Months of AI Coding Did to My Dev Team

If your business builds software - even a little - your dev team is changing faster than you realise. Not the people. The work itself.

I'm running a 20-person team building We UC, our unified communications platform. And over the last six months, I've watched something strange happen. The bottleneck in software development isn't where it used to be. It's moved.

And if you're hiring developers right now - or trying to figure out why your team isn't shipping faster despite using AI tools - you need to understand this shift.

This is not just for tech CEOs. If you have two developers and a Claude Code subscription, this applies to you. If you run a services business that hired a dev to build an internal tool, this applies to you. If you are a founder vibe-coding your own MVP in Replit, Lovable or Cursor, this applies to you. Anywhere software is being built, the shape of the work has moved.

How Software Development Used to Work

Here's how it worked when I started building We UC.

You hired developers to write code. You measured their output in lines committed, features shipped, story points closed. Code review was the quality gate. If it passed review, it shipped.

The craft was the code itself.

But now with We UC, something fundamental shifted. We started using AI coding tools - Claude Code primarily, with some of the team using Cursor. And the entire rhythm broke.

The code started arriving faster than we could process it. Therefore the job changed.

The Question That Started Everything

Three months ago, one of my senior engineers came to me visibly frustrated. He'd spent two days reviewing pull requests from a junior developer using Claude Code. Thousands of lines. Feature worked perfectly. Tests passed.

But he looked at me and said: "I didn't actually read the code. I couldn't. There was too much of it. What's my job now?"

That question landed. Because I'd been feeling the same thing but couldn't name it.

Around the same time, I came across findings from a Thoughtworks retreat - senior engineering leaders from the biggest tech companies, brought together to figure out what happens when AI writes the code. They didn't leave with answers. They left with a map of fault lines. Places where traditional software development is cracking right now.

And reading through it felt like reading my own notes from building We UC.

Where the Work Migrated

Here's what nobody tells you about AI writing code: the engineering quality doesn't vanish. It just moves upstream.

Think about a normal user story: "As a user, I want to upload a photo."

Your developers know what that means. JPEG, PNG, reasonable file size, progress bar. Cultural context fills in the gaps automatically.

But an AI doesn't have that context.

The 50,000 Email Problem

We learned this at We UC the hard way. One of our developers asked an agent to build a notification system. Simple request. The agent built it. Worked beautifully in testing.

Went to production. Started sending 50,000 emails in three minutes.

Because there was no rate limit in the specification.

The engineering rigour we used to apply after the code was written now has to happen before a single line exists.

We've gone back to techniques that felt dead - structured requirements, state machines, decision tables. The kind of formal documentation agile was supposed to kill.

But here's the thing - that rigour makes the AI incredibly effective. When we feed an agent a state machine showing exactly what states are allowed and what transitions can happen, the code it generates is almost always correct.

The specification became the product. The code? Disposable.

The code died. The spec won.

That is the shift. Everything else is a consequence of it.

If we have a perfect test suite and decide to rewrite our backend from Python to Rust, we just feed the tests to an agent and say: make these pass.

This is a complete inversion of how software used to be built.

The Layer Nobody Named Yet

There's a layer of work emerging in my team that doesn't have a name yet. It sits between writing code and shipping to production.

I call it supervisory work.

Breaking problems into agent-sized chunks. Knowing when to let the agent run and when to step in. Fixing output not by rewriting code but by adjusting the prompt or the constraints.

And here's what surprised me. My team split into two groups.

Group one: the seniors who understand the whole system. They're drowning. The juniors and agents generate code at 10x speed, but code doesn't ship itself. It needs architectural review. It needs to fit legacy systems. It needs to be unblocked. My senior engineers became traffic controllers, too busy reviewing AI output to actually build anything themselves.

Group two: the juniors who just started. They're thriving. No muscle memory telling them to write code a certain way. They treat the AI as a teammate, not a threat to their identity.

And the net-negative phase is gone. We used to hire a junior and they'd drain productivity for six months whilst learning where everything is. Now? A junior with Claude Code ships useful code in week one.

The Danger Zone: Mid-Level Engineers

But there's a danger zone nobody's talking about. The mid-level engineers. Three to five years of experience. Just enough skill to be set in their ways. Not enough to be true architects.

Retraining them - teaching them to supervise agents instead of writing syntax - that's the hardest organisational challenge we're facing as a company.

So here's what I'm learning as a CEO hiring developers. The job description just changed. If you're looking for people who write code fast, you're hiring for the wrong skill.

You need people who can architect systems, write unambiguous specifications, and supervise non-deterministic agents. That's a completely different person.

What Breaks: The Tribal Knowledge Problem

Last month, our server went down at 2am. Error code 503: Service unavailable.

On-call engineer - sharp, capable - asked an AI assistant for help. AI read the documentation. Said: restart the server.

He did. Crashed again five minutes later. Restarted. Crashed. Restarted. Crashed.

By the time he escalated to me, we'd restarted the server six times.

I looked at the logs for 30 seconds and knew exactly what it was. Database connection pool was full because a marketing batch job was running.

That's not documented anywhere. It's tribal knowledge. Lived experience.

An AI doesn't have that. It sees 503, reads the manual, restarts the server. Over and over.

This is why all the hype about "self-healing systems" is rubbish right now. To make an agent effective during an outage, you need to build what the Thoughtworks retreat called an "agent subconscious" - a knowledge graph of every incident, every weird edge case, every bit of undocumented institutional knowledge that lives in your senior engineers' heads.

We're starting to build that at We UC. Every time something breaks, we document not just what happened but why someone with experience would know what to do.

The Yes-Man Problem

But there's another problem. AI agents are trained to be helpful. They're yes-men.

During an incident, you don't want a yes-man. You want someone to challenge your assumptions. One engineer at the Thoughtworks retreat suggested we need "angry agents" - specifically prompted to poke holes in your theory. Because otherwise the human and the agent will just agree with each other whilst the server burns.

Here's the point. If your business is betting on AI to make your software team faster, you need the prerequisites first.

Documentation that actually captures how things work. Seniors who can architect, not just code. And a system for preserving institutional knowledge before the AI makes everyone forget how things actually work.

The Graphics Card Analogy

So here's what I've learned running a dev team in the age of AI agents. The work isn't disappearing. It's moving from execution to supervision.

Think about graphics programming in 1992. Engineers hand-coded the maths to draw a single polygon on the screen. Calculating exact pixel positions. By 1994, the GPU arrived. Hardware did the polygons.

If you insisted on hand-coding polygons in 1995, you weren't a specialist. You were obsolete.

The engineers who survived became lighting engineers, animators, physics programmers. They weren't telling the computer how to draw a triangle. They were telling it how light reflects off a wet street.

Nobody hand-codes polygons anymore. We all work in game engines.

Software engineering is hitting that exact moment right now.

What to Look for When Hiring

So if you're hiring developers, here's what to look for. Not coding skills. Architectural thinking. Judgement under uncertainty.

Can they write a specification tight enough that an AI can't misinterpret it?

Can they design a test suite that catches hallucinations before production?

Can they debug a system they didn't personally write?

At We UC, that's what we hire for now.

The Cognitive Debt Problem

And here's what keeps me up at night. For decades, code review wasn't just about catching bugs. It was how developers learned the system. If agents write all the code and your team stops reading it, they become strangers in their own codebase.

When something breaks at 3am, they're staring at code written by a machine, trying to reverse-engineer the logic whilst your customers are screaming.

We're building tools for what we call continuous comprehension. AI that summarises architectural changes. Weekly sessions where the team architects together even though agents write the code.

Because you have to schedule time to understand your own software now. It won't happen naturally anymore. The speed of AI demands it.

What This Means If Software Is Built Anywhere in Your Business

So look, if software is being built anywhere in your business - or you are thinking about starting - the ground is shifting.

Your seniors are drowning in review. Your juniors are thriving with AI. Your mid-levels don't know which way to jump.

The companies that win will be the ones that see this shift coming and retrain before it's too late.

I'm not pretending I have all the answers. We're figuring this out in real time at We UC. Making mistakes. Adjusting. Learning what works and what doesn't when you're leading a dev team through this transition.

But one thing is clear: the best founders I know aren't panicking. They're adapting.

Be one of them.

If running a business through the AI transition is on your plate, I wrote The CEO Operating System - the framework I use to run multiple companies without burning out. It is free. axelmolist.com/ceo-os