"Why does your engineer say three weeks when you got it done in two hours?"

I've heard this question from 7 CTOs in the last month alone.

And this morning I got another call: an engineering manager who sent his first PR after two years of not writing code, excited like a kid on Christmas morning, only to run into a wall of code review comments from his team. "Code doesn't meet standards," "Needs refactoring," "This won't go to production as is."

This isn't a bug. It's the symptom.

Over the past year, having built 10+ agents in production at Flare and now consulting with dozens of teams on AI-first coding adoption, I've watched the same movie play out in every company. Initial excitement, enthusiastic adoption announcements, productivity promises of 10x gains, and then... the crash into reality.

Let's talk about what's actually happening on the ground, without the bullshit.

Something fascinating started emerging about six months into this work. I kept seeing the same pattern: managers - VPs of R&D, CTOs, Group Managers - would start coding with Cursor, Claude Code, or whatever tool caught their attention, and suddenly they're submitting PRs. And they're genuinely having fun. The joy of creation returning after years of meetings and spreadsheets.

At first, I thought it was just the buzz of new technology, the dopamine hit of a shiny new toy. But then I started noticing something deeper.

Why are managers succeeding with agents when experienced engineers are struggling?

There are two reasons nobody's really talking about, and they cut to the heart of what makes this transition so difficult.

Managers are used to delegating responsibility. It's literally part of the job description. You take a problem, break it down, assign it to people, and trust them to execute. Transferring that mental model to an AI agent is a natural extension of what they already do every day.

Engineers? They've built their entire careers on having complete control over their code. Every line, every function, every architectural decision flows through their fingers and their minds. Asking them to hand that control over to an agent is like asking someone to let a stranger drive their car - technically possible, psychologically difficult.

It's not about trust in the technology; it's about identity and craft.

Managers and product people live in a world of explanations, iterations, and communication. They spend their days translating between business requirements and technical implementation, between stakeholder needs and engineering reality. This is exactly what agents need - clear, iterative, verbal communication about what needs to happen.

Engineers are used to expressing themselves in code, not in words about code. Ask an experienced engineer to explain what they're about to build, and you'll often get "just let me code it, it'll be faster than explaining." But agents need the explanation first.

This fundamental mismatch is exploding in ways nobody anticipated when they announced their AI-first initiatives.

A manager writes some code using Claude Code, genuinely proud of getting back into coding after years away. Submits a PR. Gets blocked by the engineering team.

• "Doesn't follow our patterns"
• "Missing error handling"
• "This won't scale"
• "Need to refactor before merging"

The manager is confused - the feature works, the tests pass, why the resistance? The engineers are frustrated - why is management now adding to their code review burden with substandard code?

An engineer who's been coding with AI for months submits a substantial PR. Another engineer, who doesn't use AI tools, looks at it and immediately flags it:

• "This is too much code to review properly"
• "Why are there five different approaches to the same problem?"
• "This looks like it was written by different people"

The AI-using engineer is frustrated - they delivered the feature in a quarter of the time. The reviewing engineer is overwhelmed - they're being asked to review and take responsibility for code they can barely follow.

An entire team goes AI-first. Suddenly, they're producing in one week what used to take two months. Product is thrilled.

Then the tech debt explosion hits.

Code that was hastily accepted because "it works and we're moving fast" starts creating problems. Architectural decisions made quickly without full consideration come back to haunt them.

The question nobody prepared for: Should we be refactoring within the same sprint where the code was just written? Is it reasonable to iterate that fast? Should we slow down even though everything technically works?

In every team I work with, I see the exact same distribution emerge, and it's remarkably consistent across companies, regardless of size or culture.

These people write exclusively with AI. Not a single line of manual code. They've fully internalized the new paradigm.

But here's what's critical: they're not all equal.

An engineer who's been writing code with AI for six months can accomplish in an hour what someone who started two weeks ago accomplishes in a day. There's a seniority hierarchy within AI-first coding itself that we haven't even begun to formalize or recognize.

What does a "senior AI-first engineer" even mean? We don't have vocabulary for it yet, but the skill gap is massive and obvious.

They use AI partially. Mostly for tab completion, occasionally for generating boilerplate, sometimes for debugging. They dip their toes in but haven't made the full mental shift. They're hedging their bets, and honestly, that's probably rational given the current state of uncertainty.

They don't touch the AI tools at all. And before we dismiss them as dinosaurs or Luddites, let me tell you: they often have legitimate reasons.

• Some have tried it and found it slows them down because they spend more time correcting the AI than they would writing it themselves
• Some work in domains where the code is so specialized that current AI models don't help much
• Some are concerned about IP and security
• Some just really love the craft of coding and don't want to give it up

These aren't invalid positions.

"I have no idea how to plan sprints anymore." - Team Lead, Series B Startup

When you have all three tribes in a single team, everything breaks:

Estimation becomes meaningless. One engineer finishes a feature in a day. Another takes two weeks on something comparable. Both are good engineers. Both are delivering quality work. But the variance is so high that traditional estimation models are completely broken.

Story points become meaningless when the same "5-point story" takes one person 4 hours and another person 3 days, depending on how they're using AI.

Code reviews become battlegrounds. The Power User submits a 2,000-line PR that they generated in a few hours. The Denier is assigned to review it and immediately pushes back - this isn't reviewable, it's too much, they can't take responsibility for code they don't understand.

The Power User is frustrated - why are we slowing down progress for outdated review practices?

The Denier is equally frustrated - why am I being asked to rubber-stamp code I haven't validated?

Both have valid points. There's no clear right answer.

Standards become contested territory. The code that AI generates often works but doesn't match the team's existing patterns. Do you enforce the old patterns, even though they were designed for human-written code? Do you evolve new patterns that work better with AI-generated code? Do you have different standards for AI-generated versus human-written code? How do you even tell the difference?

After a year of working with teams of every size, from 3-person startups to 200-person engineering organizations, there are a few things I know with certainty. And not all of them are pleasant truths that people want to hear.

Anyone who promises you that your entire team will go AI-first and suddenly you'll have 10x output is selling you an illusion. They're either naive, lying, or trying to sell you something. The reality is far more complex and messy.

Yes, you read that right. I've seen it happen in almost every team. The first month after serious AI adoption, velocity actually decreases.

Why? Because people are learning to work differently, communicate differently, and think differently. They're fighting their muscle memory. They're making mistakes they wouldn't have made before. They're spending time in tool-switching overhead. They're dealing with the cognitive load of a new workflow.

This is normal, expected, and temporary - but only if you plan for it.

Everyone focuses on this - "Oh, our engineers use IntelliJ, how will they switch to Cursor?"

That's the easy part.

The hard part is getting engineers to hand over control of their code to an external agent. To trust a process they don't fully understand. To accept that they might not know exactly how every line of code works.

This is a psychological and identity shift, not a technical one.

This is huge and almost every company underestimates it.

Your senior engineers carry enormous amounts of architectural knowledge, design decisions, gotchas, and conventions in their heads. They know why things are the way they are. They know what was tried and didn't work. They know the edge cases and the technical debt and the future plans.

None of this is accessible to AI agents.

For AI-first coding to work, this tacit knowledge needs to become explicit. It needs to be in:

• Documentation
• Architecture decision records
• Well-commented code
• Explicit style guides
• Context files that agents can consume

But here's the problem: nobody wants to do this work. It feels like documentation, and everyone hates documentation. It's not on the roadmap. It doesn't deliver features. So it doesn't get done, and the agents work blind.

Not all tools are created equal. And more importantly, not every engineer needs the same tool.

I see companies trying to standardize on one AI coding tool, and it creates as many problems as it solves. Some engineers thrive with agentic tools like Claude Code that take control. Others prefer copilot-style autocomplete. Others want something in between.

The variance in individual needs is high, and trying to force uniformity often backfires.

When a team can build in a week what used to take two months, how do you roadmap? How do you prioritize? How do you say no?

Product managers used to have the natural constraint of engineering capacity to help them make trade-offs. Now that constraint is loosening - but unevenly. So they're getting whiplash. Some features come incredibly fast. Others still take forever. There's no predictability.

There's a darker side that people aren't talking about openly: the anxiety and identity crisis that many engineers are experiencing.

If an agent can write the code, what's my value? If a manager with no context can ship a feature using Claude Code, why do we need me?

These aren't irrational fears - they're existential questions that deserve serious consideration and honest conversation. The answer isn't "you'll be fine, you'll just work at a higher level" - that's dismissive and unhelpful.

The real answer is that the role is changing, the skills required are changing, and we need to help people navigate that transition with dignity and support.

The Power Users often become isolated. They're moving so fast that they're hard to collaborate with. They submit PRs that others can't review. They make architectural decisions that others don't understand. They're productive as individuals but can create friction in the team system.

Some companies are responding by creating "AI-first" teams separate from "traditional" teams, but that creates its own problems - knowledge silos, resentment, and the question of which team gets which work.

I've met several team leads who can now personally out-produce their entire previous team. They're writing full features themselves using agents instead of managing people.

It's a weird liminal space - are they individual contributors? Are they still managers? What's their role?

Some companies are creating new positions for these people, like "AI-Augmented Tech Lead" or "Autonomous Feature Owner." We're inventing new org structures in real-time.

I haven't even touched on agents in production yet - that's a completely different conversation with its own complexity. Production agents that serve users directly, not just agents that help developers write code. The reliability requirements, the safety concerns, the monitoring challenges, the user experience questions. It's an entirely separate mountain to climb, and most companies are still at base camp on this one.

And I haven't talked about the specific methodologies that are working. The practices that successful teams are converging on:

• Agent-first documentation - writing docs specifically for AI consumption
• Dual-track review - one reviewer looks at functionality, another at AI-generated code quality
• Velocity calibration periods - consciously slowing down commitments while people learn
• Agent context management - maintaining specific context files that agents can consume
• Progressive delegation - gradually increasing agent autonomy over time

These are emerging practices that will become standard, but they're not codified yet.

Here's what you need to understand: these problems are manageable.

I'm not painting this picture to scare you or to suggest that AI-first coding isn't worth it. It absolutely is. The productivity gains are real. The transformation is inevitable. The competitive advantage is significant.

But - and this is critical - the solutions need to be tailor-made to your company.

What works for a 10-person startup won't work for a 500-person enterprise. What works for a team building a consumer app won't work for a team building mission-critical infrastructure. What works for a company with a strong documentation culture won't work for one that's always been code-first.

The patterns I've described are universal. The distribution of Power Users, Middle, and Deniers? That's consistent everywhere. The initial productivity dip? Happens to almost everyone. The knowledge gap problem? Every company faces it.

But the solutions are deeply contextual:

• Your team's existing culture and practices
• Your technical domain and constraints
• Your product maturity and velocity needs
• Your organizational structure and decision-making processes
• Your tolerance for risk and experimentation
• Your timeline and business pressures

There is no off-the-shelf playbook. No one-size-fits-all framework. No consultant (including me) who can hand you a 10-step plan that will just work.

What I can do - what anyone helping with this transition should do - is help you understand the landscape, identify the patterns in your specific situation, and design solutions that fit your context. Solutions that account for your team's unique dynamics, your company's specific constraints, and your organization's particular goals.

Every company is navigating this transition differently. And that's not a bug - it's a feature. The companies that succeed will be the ones that resist the urge to copy someone else's approach and instead do the hard work of figuring out what works for them.