For a while, I had a strange feeling at work: I was moving much faster than the system around me.

On my own, AI had changed the way I built software. I was spending less time grinding through boilerplate and more time shaping the solution, reviewing output, and testing whether it actually held up. The work felt lighter, but the results were better. I could get through a task in a day that used to drag across most of a week.

Then I would zoom back out and see that, at the team level, not much had really changed. People had access to the same tools I did, but mostly used them as better autocomplete. Helpful, sure, but not enough to change the pace of delivery.

That gap bothered me. It felt like we had adopted the tooling without adopting the workflow.

The real difference

The biggest change for me was not that AI wrote some code here and there. It was that I had stopped treating coding as the main event.

Instead of writing everything myself and occasionally asking for help, I was doing something closer to this:

  • Define the problem clearly
  • Give the model the right context
  • Review the output with skepticism
  • Run the code, test it, and fix what matters

That sounds subtle, but it is a different job. The value shifts away from typing and toward judgment.

Once I saw that clearly, it became hard to ignore what it meant for the broader team. If one engineer changes their workflow and gets dramatically faster, that is interesting. If the rest of the org is still working the old way, then the constraint is no longer individual output. The constraint is the operating model.

At that point I had two options: keep the advantage as a personal productivity hack, or try to make the case that we should work differently as a group.

Making the case internally

I put together a presentation for leadership. The point was not that AI was exciting or inevitable. Everyone had already heard that pitch. The point was simpler: we were leaving a measurable amount of engineering capacity on the table, and we already had enough tooling to do something about it.

I framed it in three parts.

First, I showed where we already were. GitHub Copilot and Copilot CLI were available. The barrier was not access. The barrier was depth of adoption. Most engineers were still using AI as a convenience feature instead of changing how they approached implementation.

Second, I argued that the mental model had to change. If AI can reliably handle a large share of routine implementation work, then the engineer’s role shifts toward design, guidance, validation, and quality control. That is where leverage comes from.

Third, I covered the objections, because any serious argument for AI-first has to make room for them.

  • You still need review, tests, and verification. Faster output is only useful if the code is sound.
  • You need some cost discipline. Not every task deserves the biggest model.
  • Engineers still own the code. AI can help produce it, but responsibility does not move.
  • Security and compliance rules do not relax just because a model was involved.

Those caveats were not there to soften the pitch. They were part of the pitch. An AI-first workflow only works if people trust that quality standards are still intact.

I also proposed concrete next steps instead of leaving it at principle:

  • Set clearer expectations for where AI should be part of the workflow
  • Improve testing so faster implementation does not create downstream risk
  • Revisit capacity planning with AI-assisted delivery in mind
  • Publish simple guidance on model choice and usage patterns
  • Run a small pilot and measure the result

The pilot mattered most. Without a real result, this would stay in the category of interesting opinion.

From presentation to pilot

I first presented the idea to my manager and her manager. The discussion went well enough that they asked me to take it to a broader group. Once that happened, the conversation changed. It was no longer just about how I liked to work. It became a legitimate question about whether the organization should formalize a new default.

Eventually a frontend team was chosen for the pilot.

The team lead and I put together a practical guide for how to work this way day to day. That document was important because vague advice like “use AI more” is not operational. People need to know what good usage looks like.

We spelled out things like:

  • what context to provide before asking for code
  • how to break work into prompts the model could actually handle well
  • what parts of the response needed close review
  • when to trust the output and when to throw it away
  • how verification and testing fit into the loop

In other words, we were not trying to encourage more AI usage in the abstract. We were trying to define a repeatable workflow.

The result

We ran the pilot for a few sprints and tracked story point velocity.

Within a couple of months, that team showed a 300% increase in velocity.

Same team. Same general planning cadence. Same headcount. Far more throughput.

That number got attention for obvious reasons, but the more useful point is what it did and did not mean.

It did not mean engineers were suddenly working three times harder. It did not mean every task became trivial. It meant a lot of the low-leverage implementation work got cheaper, so more of the team’s time could go into judgment, iteration, and finishing the work cleanly.

The workflow was especially strong at things like:

  • turning a clear ticket into working code
  • generating tests around a known interface
  • refactoring repetitive patterns
  • scaffolding components and boilerplate

The engineers still had to do the parts that matter most:

  • decide whether the approach made sense
  • catch logic mistakes and missing edge cases
  • review for security, performance, and maintainability
  • make tradeoffs the model could not make responsibly on its own

That, to me, is the real story behind the velocity gain. The work did not disappear. The work shifted.

What changed my mind about rolling this out

Before the pilot, I was confident AI-first could work because I had seen it in my own output. After the pilot, I was confident it could scale because we had evidence from a real team operating under normal conditions.

That changed the conversation with leadership. You no longer have to argue from hype or intuition when you can point to a team that shipped materially faster with the same people.

It also clarified where the hard part is. The hard part is not picking a model or installing tooling. Most organizations already have more than enough capability on that front. The hard part is helping people change how they work.

Good engineers have spent years building fluency around manual implementation. Asking them to move up a level, to spend less time writing every line and more time directing and validating, is a real shift in identity. That is why this is as much a culture problem as a tooling problem.

Where I think this goes

I do not think every team will look identical, and I do not think “AI-first” means humans stop doing deep technical work. It means the default changes. Instead of assuming every task begins with a blank file and hand-written implementation, you assume AI is part of the path unless there is a good reason otherwise.

That sounds like a small wording change, but it has pretty big implications for planning, code review, testing, and expectations around individual output.

The broader lesson for me is that most companies are not blocked on access to AI tools. They are blocked on the gap between having the tool and reorganizing the work around it.

That gap is not glamorous. It involves presentations, internal buy-in, pilot design, usage guidelines, and metrics. But that is what turns a personal productivity win into an organizational one.

That was the point of this effort, and it is still the part I find most interesting: not whether AI can help an engineer move faster, but how you prove it well enough that a whole organization is willing to change.