We gave our team Copilot. I'm working 12-hour days. They stopped using it after a month. What went wrong?

[eng_director_luis]

Six months ago, I walked into our quarterly planning meeting with a grin. “We’re rolling out GitHub Copilot to the entire engineering org,” I announced. “Leadership thinks we can increase velocity by 30%. This is going to be transformative.”

Today, I’m writing this at 9 PM on a Thursday. I’ve been working 12-hour days for three months straight. And when I checked our internal analytics last week? Developer utilization of AI tools: 22%. Down from 78% in week one.

The Promise vs. The Reality

Here’s what leadership expected:

• 30% faster feature delivery
• Same team size handling more scope
• “AI does the boring stuff, engineers focus on creative work”

Here’s what actually happened:

• My workload exploded managing the rollout, training, and constantly adjusting processes
• Sprint velocity initially jumped 15%, then fell back to baseline by month two
• PR review time increased by 91% because PR sizes ballooned
• Developers quietly stopped using the tools, but nobody wanted to admit it

The 30-Day Cliff

I dug into the data because something felt off. The pattern was eerily consistent across teams:

• Week 1-2: 75-80% adoption. Excitement, experimentation, Slack channels buzzing with “look what Copilot just generated!”
• Week 3-4: 50-60% usage. Novelty wearing off, friction points emerging
• Week 5+: 20-25% sustained usage. Only a handful of engineers still using it regularly

I interviewed my team leads. Here’s what killed adoption:

1. The “almost right” problem — AI-generated code required careful review and debugging. For complex business logic, it often took longer to fix than to write from scratch.

2. Workflow mismatch — Our codebase has specific patterns, internal libraries, and compliance requirements. Copilot suggestions often violated our standards.

3. Review bottleneck — Junior engineers used AI more enthusiastically, but their PRs grew massive (average PR lines: +154%). Senior engineers spent hours in review, creating a backlog.

4. Training gap — We gave people access but no structured onboarding on how to use these tools effectively. They learned by trial and error, got frustrated, and gave up.

The Manager Burnout Nobody Talks About

Meanwhile, I’m drowning:

• Fielding questions about tool usage and best practices
• Attending vendor training sessions and executive briefings
• Explaining to leadership why we’re not seeing the promised ROI
• Mediating disputes about whether AI-generated code meets our standards
• Revising coding guidelines, PR templates, and review processes
• Managing the morale hit when engineers feel pressured to use tools that don’t help them

The irony? Leadership sees our AI investment as “solved” because we deployed the tools. They’ve already inflated sprint expectations by 35% for next quarter. But I’m the one working 12-hour days while my engineers are back to their old workflows.

The Hard Questions I’m Asking

I feel like I’m missing something fundamental. Research says developers using AI are 19% slower but believe they’re 20% faster. Harvard Business Review reports that 83% of workers say AI increased their workload. We’re not alone in this paradox.

But here’s what I need help with:

1. How do you bridge the expectation gap with leadership? They read generic ROI articles and assume our team has infinite capacity now. How do I show them the reality without sounding like I’m making excuses?

2. What does structured AI adoption actually look like? I feel like we failed because I just turned on the tools and hoped for the best. What’s a realistic rollout plan?

3. Are we measuring the wrong things? Maybe individual code velocity isn’t the metric. Should we be looking at different KPIs?

4. Who’s actually benefiting from these tools? Because right now it feels like managers are working harder, developers stopped using them, and leadership is living in a fantasy world.

I love my team. I believe in using the right tools for the job. But I’m burning out trying to make this work while watching utilization plummet.

For those who’ve rolled out AI coding tools successfully — what am I missing? And for those who’ve failed like me — how did you recover?

---

PS: If one more executive sends me an article about how “Copilot will 10x your team,” I might lose it. Show me the internal data, not the vendor marketing.

[vp_eng_keisha]

Luis, this hits home hard. I’ve lived this exact nightmare from the VP seat, and I want to validate something important: you’re not failing. The rollout process failed you.

Last year, our CEO came back from a conference fired up about AI coding tools. Within a week, we had enterprise licenses for our entire 85-person engineering org. Within a month, I was in the same place you are — working until 10 PM, fielding complaints, watching adoption crater, and trying to explain to the C-suite why we weren’t shipping 50% faster like the vendor promised.

The “Infinite Capacity” Fallacy

Here’s the mental model shift that finally helped me push back on leadership:

AI tools don’t give your team infinite capacity. They potentially shift where capacity is spent.

When our CFO said “we’re giving engineers Copilot, so we can take on 40% more features next quarter,” I had to sit him down with actual data:

• Code generation is only 20-30% of software delivery
• The other 70-80% is requirements, design, review, testing, deployment, and maintenance
• Speeding up 30% of 20% = 6% theoretical max gain, not 40%
• AND only if we don’t hit bottlenecks elsewhere (we did)

I showed him our metrics: PR review time had spiked 91% (just like yours). Our bottleneck wasn’t code writing — it was code review and validation. Generating code faster just moved the constraint.

How I Recovered (and What I Wish I’d Done First)

Step 1: Reset expectations with leadership

I scheduled a working session with our exec team and walked them through:

• Current utilization data (not adoption, utilization)
• Where bottlenecks actually were in our delivery process
• Realistic ROI timeline: 6-12 months to see measurable impact, not 30 days

The key was framing it as “we need to invest in making this work” vs “this isn’t working.” Leadership wants success, but they need to understand what success actually requires.

Step 2: Pilot teams, not org-wide rollout

We hit pause on the org-wide deployment and went back to basics:

• Selected 2 teams (one product team, one platform team)
• Gave them structured training (not just tool access)
• Measured real impact over 8 weeks: velocity, quality, developer satisfaction
• Documented what worked and what didn’t

The platform team saw genuine productivity gains (lots of boilerplate, clear patterns). The product team saw minimal impact (complex business logic, frequent context switching). Different workflows, different results.

Step 3: Address the process bottlenecks

AI tools don’t work in isolation. We had to evolve our processes:

• Rewrote PR guidelines for AI-assisted code (required tests, smaller PRs)
• Trained senior engineers on efficient review of AI-generated code
• Created internal docs on when to use AI tools vs when not to
• Set up office hours for engineers to learn effective prompting

Step 4: Measure what matters

We stopped tracking “lines of code per day” and started tracking:

• Time from feature request to production
• Defect rate in production
• Developer satisfaction scores
• Actual sustained tool utilization (not just adoption)

Spoiler: Our delivery time improved 8% over 6 months. Not 30%, but real and sustained. Developer satisfaction went up because we removed the pressure to use tools that didn’t help them.

Your Questions, My Answers

How do you bridge the expectation gap with leadership?

Show them the data. Not vendor data — your data. Utilization dropping to 22% is a feature, not a bug. It means engineers are using the tool only when it actually helps. That’s good judgment, not failure.

Frame it as: “We learned what works and what doesn’t. Now we can scale what works.”

What does structured adoption actually look like?

Start with volunteers, not mandates. Find your champions — the engineers who genuinely benefit from these tools. Learn from them. Then expand gradually with proven patterns.

Are we measuring the wrong things?

Yes. Individual developer velocity is a local optimization. Measure team throughput, delivery stability, and customer value. That’s what the business actually cares about.

Who’s actually benefiting?

In our experience:

• Junior engineers benefit (learning patterns, boilerplate)
• Platform teams benefit (repetitive patterns, high volume)
• Senior engineers in complex domains benefit least (context matters more than code)

You’re Not Alone

A recent survey found that managers work 12-15 hour days after AI adoption, while utilization drops to 22% within 30 days. This is a pattern, not your failure.

The tools are evolving. Our processes are evolving. But the human and organizational factors matter more than the technology.

Take care of yourself, Luis. Burning out won’t help your team. Push back on those inflated sprint commitments. Use your data to reset expectations. And remember: your job is to deliver value, not to justify a vendor’s marketing claims.

[product_david]

Luis, Keisha’s breakdown is excellent from the engineering leadership perspective. Let me add the product angle — because I think part of what’s happening here is a fundamental misalignment about what problem we’re trying to solve.

The Question Nobody Asked

When your leadership said “30% faster delivery,” did anyone ask: 30% faster at doing what?

Because here’s what I’ve seen happen (including on my own teams):

• Engineers write code 20% faster
• Product still takes 2 weeks to define requirements
• Design still needs a week for mockups
• QA still needs 3 days to validate
• We still ship every 2 weeks regardless of when code is “done”

Net customer impact: 0%

The AI tools optimized a local maximum (developer coding time) while the actual constraint was somewhere else entirely. It’s like upgrading the engine on a car stuck in traffic.

The Code Velocity Trap

I’m going to say something that might be unpopular: faster code writing can make products worse.

Three months ago, one of my PMs came to me excited. “The engineering team is moving so fast with Copilot! They implemented all five features I spec’d out!”

Great, right? Except:

1. Two of those features were wrong — we’d misunderstood the customer need
2. One feature introduced technical debt we’re still paying down
3. Users adopted only one of the five features
4. We now have four features to maintain, document, and support

The problem? We optimized for output (features shipped) instead of outcome (customer value delivered). Faster code meant we built the wrong things quicker.

Before AI tools, the friction of implementation forced us to prioritize ruthlessly. “We can only build 2 of these 5 features this quarter, so which ones actually matter?” Now that friction is lower, we’re building more… but not necessarily building better.

The Disconnect Between Individual and Team Performance

Keisha mentioned this, but it’s worth emphasizing from a product perspective:

Your developers might be individually more productive (writing code faster, generating boilerplate quicker), but if team throughput doesn’t increase, your customers see zero benefit.

I track:

• Time from customer problem identification to solution in production
• Feature adoption rates (are we building things people use?)
• Customer satisfaction with releases
• Technical debt accumulation

On my teams with high AI tool usage:

• Individual developer metrics: up 15%
• Team delivery metrics: flat or down
• Feature adoption: down 12% (we’re shipping more, users care less)
• Tech debt: up significantly

The Faros AI productivity research found the same pattern: individual task completion up 21%, but no measurable improvement at the company level.

Are We Solving the Right Problem?

Your question “who’s actually benefiting from these tools?” cuts deep.

I’d add: what problem were we trying to solve in the first place?

• If the problem was “engineers spend too much time on boilerplate” → AI tools might help
• If the problem was “we’re building the wrong features” → AI tools make it worse
• If the problem was “we can’t validate assumptions quickly enough” → AI tools are neutral
• If the problem was “our delivery process has too many handoffs” → AI tools don’t help

In our sprint retros, I started asking: “What would have helped us deliver more customer value this sprint?”

The answers were never “faster code writing.” They were:

• “Clearer requirements upfront”
• “Better collaboration between product and engineering during design”
• “Less context switching between projects”
• “Faster feedback from customers on prototypes”
• “Not being pressured to commit to scope we knew was unrealistic”

A Framework That Helped Me

When leadership started asking “why aren’t we faster with AI tools?”, I reframed the conversation:

Speed at what stage of the customer value chain?

Stage	AI Tool Impact	Actual Bottleneck
Problem discovery	None	Customer access, research time
Requirements definition	Minimal	Alignment, clarity, prioritization
Design & prototyping	Some (for mockups)	Iteration cycles, feedback loops
Code implementation	Moderate-High	Complex business logic, review
Testing & QA	Some (test generation)	Edge cases, integration testing
Deployment	None	Process, approvals, risk management
Adoption & feedback	None	User education, measurement

If your bottleneck is in stages where AI doesn’t help, speeding up code writing just creates inventory that sits waiting.

What I’m Doing Instead

Rather than pushing for AI tool adoption, I’m focusing on:

1. Shipping smaller, learning faster — If we can write code faster, use that to test assumptions with smaller MVPs, not build more features

2. Product-engineering pairing — More time upfront defining the problem means less rework later, regardless of coding speed

3. Outcome metrics over output metrics — I don’t care if we shipped 10 features or 3. Which ones are customers actually using and loving?

4. Ruthless prioritization — Lower implementation friction means we need better filters on what to build, not weaker ones

My Advice

When you talk to leadership, reframe the conversation from “why aren’t we 30% faster?” to “what outcome were we trying to achieve, and is faster code writing the right lever?”

Maybe the answer is yes! If your bottleneck genuinely is code implementation, AI tools can help (with the right process changes Keisha described).

But if the bottleneck is requirements clarity, design iteration, testing, deployment process, or customer feedback cycles… well, faster code writing might make things worse by flooding the bottleneck with more work-in-progress.

Your 22% utilization might be a sign of good engineering judgment: the team is using the tools when they help and ignoring them when they don’t.

That’s not a failure. That’s engineers optimizing for the right outcome instead of blindly using tools because leadership bought them.

[maya_builds]

Oh Luis, I felt this post in my bones. We went through almost the exact same thing with Figma’s AI features last year — leadership was like “AI will revolutionize design!” and then… crickets after month two.

Reading Keisha and David’s responses, I keep thinking about something nobody’s really saying directly: Did anyone actually ask the developers what they needed before dropping these tools on them?

The Design Tool Parallel

When Figma rolled out AI features (auto-layout suggestions, content generation, design-to-code), our design team had the same adoption curve you’re seeing:

• Week 1-2: “Wow this is cool! Look at this mockup it generated!”
• Week 3-4: “Okay but I have to fix everything it suggests”
• Week 5+: Most people stopped using it entirely

The difference between the designers who kept using AI features and those who didn’t came down to one thing: workflow fit.

The designers who benefited had workflows where the AI actually solved a problem they cared about. The ones who abandoned it felt like the AI was solving problems they didn’t have.

Sound familiar?

The Onboarding Gap

You mentioned this: “We gave people access but no structured onboarding.” This is huge.

When we roll out design tools, we don’t just give people a license and say “good luck!” We:

• Run hands-on workshops showing real use cases
• Pair junior designers with experienced users
• Create internal docs with examples from our actual work
• Have regular “tips and tricks” sessions
• Build a community where people share what works

But for AI coding tools, I see companies just… turn them on and expect magic.

It’s like giving someone a professional camera and expecting great photos without teaching them composition, lighting, or how their specific camera works. The tool is powerful, but only if you know how to use it in your context.

The “AI Brain Fry” Problem

There’s new research about something called “AI brain fry” — basically, cognitive overload from constantly evaluating AI suggestions.

Here’s what I’ve seen:

Every AI suggestion requires a decision:

• Is this suggestion correct?
• Does it match our patterns?
• Is it better than what I would write?
• Should I modify it or start over?

That’s exhausting. After a while, your brain is just… fried.

One developer told me: “It’s like having an over-eager junior engineer constantly tapping my shoulder with suggestions. Even when they’re good suggestions, the interruption kills my flow.”

When we design tools, we think a lot about cognitive load. How many decisions does the user have to make? How much context switching? AI tools often increase both, even when they’re saving typing time.

The User-Centered Question

Here’s what I wish more engineering leaders would do (and what we finally did with design tools):

Talk to your users (the developers) like you’d talk to customers.

What if you ran a user research session?

• “When you tried using Copilot, what were you trying to accomplish?”
• “What friction did you hit?”
• “In what situations did it actually help?”
• “What would make you want to use it more?”

I’d bet you’d discover things like:

• “I use it for writing tests because that’s genuinely helpful”
• “I don’t use it for our core business logic because it doesn’t understand our domain”
• “I’d use it more if the suggestions matched our code style”
• “I turned it off because the constant suggestions were distracting”

That’s design research 101: observe actual behavior, understand the context, identify real needs.

Adoption vs. Value

David’s point about output vs. outcome really resonates from a design perspective.

In design, we learned that “number of mockups created” is a terrible metric. What matters is “did we solve the user’s problem?”

Similarly, “lines of code generated by AI” means nothing if it doesn’t help your team deliver better software.

Your 22% sustained utilization might actually be the right number. It means people are being selective, using the tool for the 22% of work where it genuinely helps.

We aim for the same thing with design tools — use the right tool for the job, not every tool for every job.

The Pressure to Use Tools “Because We Paid For Them”

This drives me crazy.

Sunk cost fallacy is real, but it’s especially toxic with tools. Just because your company spent money on licenses doesn’t mean engineers should use tools that make their work harder.

I’ve seen this with design tools too. Leadership buys enterprise licenses, then pressures teams to “get value from the investment” even when the tool doesn’t fit the workflow.

The result? People use the tool badly, create worse work, and burn out trying to force-fit a tool into a process where it doesn’t belong.

Better approach: Acknowledge that not every tool works for every team. Measure value delivered, not tool usage.

What Actually Worked for Our Design Team

After our initial failed rollout, we hit reset:

1. Made it optional — Removed pressure to use AI features. Let people opt in when they wanted.

2. Found the champions — Identified the 3-4 designers who genuinely loved the AI features. Asked them to document what worked.

3. Created use case guides — Not generic tutorials, but specific examples: “Use AI for this type of work, not that type.”

4. Built feedback loops — Monthly sessions where people shared tips and frustrations. Turned qualitative feedback into process improvements.

5. Measured what mattered — Stopped tracking “AI feature usage” and started tracking “design quality” and “designer satisfaction.”

Within 6 months, utilization stabilized around 30-35% — but those were high-value uses, not people forcing it.

My Questions for You

Since you mentioned your team stopped using it — have you asked them:

• What would make them want to use it again?
• What specific tasks would AI tools actually help with?
• What got in the way of using it effectively?

Their answers might surprise you. And they might give you the data you need to either:

• Fix the rollout process and try again with better support
• Or acknowledge that these tools don’t fit your team’s workflow right now, and that’s okay

Either way, you’d be making a decision based on user needs, not vendor promises.

Final Thought

Luis, you’re burning out trying to make a tool work that your team isn’t finding valuable. That’s backwards.

Your job is to help your team deliver great software, not to justify a licensing spend.

If the tool helps: great, invest in making it work.
If it doesn’t: cut your losses and focus on what actually moves the needle.

Either way, talk to your team. They’ll tell you what they need.