Most engineering teams I talk to went through the same curve with AI.
They rolled out an assistant in the editor. The first weeks felt like a real change: faster boilerplate, quicker answers, less time in the docs. Then the gains stopped growing. People kept using it every day, but the team didn’t ship much faster than a few months earlier.
The usual explanation is the model. It isn’t smart enough yet, the next one will fix it. I don’t think that’s it. The ceiling is the setup, not the model. I call it a false plateau because it looks like the limit of the technology, and it’s really the limit of how we’re using it.
Why it flattens
Think about where the assistant actually lives. It runs next to you, inside your editor, on your laptop.
That has consequences:
- It shares your machine. Builds, tests and the agent all compete for the same resources.
- It usually can’t run the full environment, so it can’t check its own work. It proposes, and you verify.
- It only moves when you prompt it. Every step starts with a person typing.
So the work is still shaped around one engineer, one task, one session at a time. The assistant makes each step faster, but the number of steps and the person doing them stay the same. That’s autocomplete with extra steps, not a different way of working.
A talk from Cursor and Amplitude on engineering teams in the agentic era gave me the vocabulary for this, and it matched what I was seeing.
What changes past it
The teams that get past the plateau are doing three things.
They move agents off the laptop. An agent in the cloud gets an isolated machine with the full dev environment. It can install, build, run the tests and look at the result. Several can run in parallel without fighting over your RAM. You stop babysitting and start reviewing finished work.
They trigger agents on events, not prompts. A pull request is opened. A customer reports a bug. A ticket changes status. An alert fires. Those are moments where a system already knows something needs to happen, so the agent can start there instead of waiting for someone to type.
They give agents bigger jobs. Not a single completion, but a task with a beginning and an end: investigate, change, test, open the PR, respond to review. Longer tasks are where the time savings actually compound.
None of this is about using AI more. It’s about changing what an engineer spends the day doing.
What we’re doing at COR
We’re in the middle of this at COR, and the first lesson was that agents are only as good as the context they get.
In March I built an MCP server that connects our platform to tools like Claude and Cursor. Before that, every person used AI on their own, against no real data. With it, an agent can read the actual ticket, the actual project, the actual state of things. That turned out to matter more than any model upgrade.
In April we ran a full planning cycle with an agentic dev workflow and measured it conservatively. The cycle went from 44 hours of effort to 16.5, a 63% reduction. Debugging in staging and PR review each took about 75% less time. The next cycle, with a written playbook, had zero reworks.
The part that surprised me wasn’t the speed. It was where the bottleneck moved. Once writing code got cheap, the slow part became deciding what to build, giving the agent the right context, and reviewing what came back. Those are engineering skills, but they’re not the ones most of us trained for.
The job is changing
The way I think about it: less typing, less line by line reviewing, more orchestrating. Defining the task well, choosing what runs in parallel, setting the checks that decide what is safe to merge, and spending human attention where it matters.
That’s a team design problem as much as a tooling one. It touches how you write tickets, how you review, what you measure, and who owns what. It’s also the most interesting workflow problem I’ve worked on in years.
If your team is sitting on the same plateau, I’d like to compare notes. Write me at hi@dguzman.me.
Update, October 2026: since writing this we built TARS, an agent our team uses to investigate production incidents, and the event-driven part stopped being a plan. I’ll write about it soon.