Same tools, 10x the results

Most of my work these days is with engineering teams that already have the AI tools. Everyone has a license, access to the same models and a comparable budget. What I keep noticing is how differently people use them, and how much the return depends on that use.

The range is wide. Inside one company, an engineer uses the agent for autocomplete and the occasional question, while the person next to them runs three agents overnight and reviews the results in the morning. One team estimates a rebuild at thirty people for eighteen months; a team of six with the same tools ships it in a quarter. Yet after a company rolls the tools out to everyone, only a small share of the engineers say they feel a real change.

So when someone tells me, “We have all the AI tools, everyone has a license, and I don’t feel the 10x,” I understand it. I’ve said a version of it myself. For a while I blamed the tools, the codebase or the need for one more model generation. I no longer think that explains the gap. The difference I keep seeing is whether the team changed how it works when it got the tools. A lot of teams added an agent and kept working the same way, so the gains were small.

Here is what I am observing, and the habits I would build to get closer to that 10x.

What I think is happening

The tool is not the variable. Across teams using the same agents and models, the differences show up in everyday decisions: what gets written down, what the agent can do on its own, and what has to be true before a human looks at the output. Those decisions determine how much work can move without someone supervising each step. I would measure the improvement by how quickly changes reach customers. That is what I mean by getting closer to 10x.

The gains come after a dip, and most organizations are not funding the dip. Every team I have seen make the shift got slower first. There is real engineering to do before agents can work well: useful error messages, tools for the systems they need to reach, and code they can navigate. Sometimes that includes a move to a typed language, because compiler errors give the model feedback it can act on before the code runs. I have seen teams move to TypeScript for that reason alone, and Rust keeps coming up for the same reason. That work takes time away from features before it starts paying back.

When the code gets fast, decisions become the bottleneck. When a product took the better part of a year to build, two months deciding to build it and another two approving the launch were easier to overlook. Now the code takes a month or two, and those decisions take longer than the build. The teams I know that are furthest along spend more time deciding than coding. I wrote in Making Software in 2026 that building faster is only valuable if you are building the right thing. I am seeing that happen sooner than I expected.

The playbook

These observations lead me to seven habits, starting with the engineer’s daily work and extending to the organization around it. Developing new habits is hard. The return comes from repeating them until they become how the team works.

One. Write down what is in your heads, then keep pruning it.

Most of what a team knows lives in people and travels through Slack, onboarding, code review and stand-ups. An agent does not have that context by default. Put the knowledge it needs in the steering files: the instructions and references it reads when it starts work.

Then keep pruning. The do-nots you wrote for last year’s model can bloat the context of this year’s. In the last few months alone, I have removed most of the skills I used daily as the models improved. Ask whether each rule is still earning its place. I called context the moat earlier this year. This is the daily work of keeping it useful.

Good looks like: When an engineer catches an agent mistake, they check whether it lacked context and commit the missing information that afternoon. When the team adopts a new model, someone reviews the old do-not rules and deletes the ones it no longer needs.

Bad looks like: The steering file is a tone instruction and three bullets, or forty pages of do-nots accumulated against old model quirks. Nobody rereads it. The knowledge the agent needs still lives in Slack threads and people’s heads, so it keeps making the same mistake.

What really good looks like: The company has a shared brain where decisions, customer feedback and lessons from engineering, product and sales flow in automatically. Someone owns keeping each source current and pruning what has gone stale. I have built several versions of this. My favorite keeps documentation close to the code, adds an embedding layer to make related knowledge easy to find, and exposes it through a simple API for people and agents to read and update the knowledge. You can use what the company already knows to develop new ideas, with the sources there to check.

Two. Budget the slowdown, out loud.

Keeping context useful takes time, and so does making the codebase workable for agents. Put that work on the roadmap and tell the team and leadership that features will slow down while it happens. For a team with substantial work to do, that might mean the next two months. If that time has to be found between features, the shift will keep getting postponed.

Good looks like: Two months on the roadmap, named and defended. The team improves tool errors, builds an MCP server for an internal system the agent kept getting wrong, and adds types where they would catch repeated mistakes. Leadership knows why features slowed and what improvement to look for.

Bad looks like: The tools fail silently, and the model guesses and hands the guess back. Making the codebase work for agents is what an engineer does on Friday afternoons between features. The first question at every review is still why the team is not faster.

What really good looks like: The team tracks where agents get stuck and uses that evidence to decide what to fix next. If five tasks need a human to explain the same internal system, making that system usable becomes planned work. Leadership can see whether the investment reduces interruptions, rework and the time it takes to ship. There is room on the roadmap to keep doing this as the codebase and models change.

Three. Give the agent a bar it can check itself against, then get out of the loop.

The point of that investment is to let work move without your attention at every step. If you have to read each response before the agent can continue, your day fills with waiting and switching tasks. Give it a way to check its own work and a clear point at which to come back to you. Of everything on this list, I think this one explains most of the gap.

Good looks like: The code has to compile, the tests have to pass, and the acceptance checks have to show the requested behavior. The agent comes back when it clears that bar or when it is stuck and needs a decision. Three or four independent tasks can run at once. The shared checks live in the steering file so nobody has to type them again.

Bad looks like: An engineer uses a single agent in one terminal or an IDE, waits thirty seconds to a minute for each response, reads the code, corrects it, and waits again.

What really good looks like: Each completed task gives the next agent a working change, a record of the checks that passed and the assumptions behind it. One agent builds an interface; another builds a feature on top of it. The combined work has its own checks before review. As those foundations grow, an engineer can hand over larger pieces of work. Humans review the result and make the decisions that still need judgment; the work keeps moving between those decisions.

Four. Iterate on the spec, not the code.

To define that bar, you need to know what the software should do. For ambiguous work, settling the requirements in a document is faster than working them out across a codebase. Teams that already practice behavior-driven development have a head start here, because the habit is familiar.

Good looks like: The model drafts a specification, and the engineer works through the requirements and open questions with it before implementation starts. The code arrives close to right, and review can focus on how it works.

Bad looks like: A vague prompt, a mountain of generated code, then an afternoon of “that is not what I meant,” correcting intent one diff at a time.

What really good looks like: Product and engineering agree on examples of what should happen, including the awkward cases. Those examples become acceptance tests the agent can run. When a requirement changes, the spec and tests change together. A month later, someone can still tell why the feature behaves the way it does and whether a proposed change preserves what customers rely on.

Five. Shift testing left, all the way to the laptop.

Those checks need to be fast enough to run repeatedly. Quick feedback is what lets an agent work for hours and correct its own mistakes. That feedback loop is also what interests me about AlphaProof’s work with the Lean proof assistant: the system can check its attempts as it goes.

We have been talking about fast, reliable tests for years. Agents make the return on that work much larger. The everyday feedback loop needs to run on a laptop or devbox, with predictable local substitutes for the services it depends on. Every cloud round trip between attempts slows that loop down.

If you cannot run enough of your system to check a change because “it was not designed that way,” this is part of the slowdown you need to budget.

Good looks like: Linters, unit and integration tests, and focused performance and security checks run locally in minutes. The agent can make a change, see exactly what failed and try again without waiting for a shared environment or asking someone to set it up.

Bad looks like: Integration tests mean the full system end to end against live services, so they need a shared environment, a VPN and someone’s patience. The agent either skips them or waits, and the break is found in production.

What really good looks like: One documented command starts the local environment and runs the relevant checks from a fresh checkout. Failures are repeatable. Contract checks keep the local substitutes aligned with the real services. When a bug escapes, the team turns it into a reproducible case and adds it to the local loop. Each mistake improves the feedback available for the next task.

Six. Start with a few teams, not all of them.

The habits above take practice, and every codebase needs a different mix of work. Give a few teams room to find that mix before asking the whole organization to change. The next team should have something proven to start from.

Good looks like: A handful of teams go first with cover from leadership. They document the context, tooling and routines that helped them ship, including what failed. The next wave starts with working examples.

Bad looks like: Every team gets a license on the same Monday and attends the same training. Nobody has found the practices yet, so there is nothing to copy. Six months later most teams are working the same way they did before.

What really good looks like: An engineer from a pilot team joins the next team for its first few tasks, bringing the working setup and lessons from the pilot. That team adapts the practices to its codebase and sends improvements back. Each wave starts further ahead. The organization tracks whether changes reach customers sooner without increasing defects or exhausting people.

Seven. Speed up decisions, especially the reversible ones.

As those teams get faster, the waiting around them becomes more visible. Look at every approval on the path to production and ask whether it was designed for a world where the build took a year. Changing those approvals often needs people outside engineering involved from the start.

Good looks like: Approvals that used to hide inside a long build have been removed or shortened to a day’s work. Reversible decisions within the team’s remit can be made on the spot.

Bad looks like: The code is done in six weeks and then sits for two months waiting on the same launch review that was designed for a twelve-month build.

What really good looks like: The team knows in advance which decisions it can make, what evidence it needs and when someone else must be involved. It can release a small change, see how customers respond and roll it back without assembling a new approval chain each time. Bigger decisions have a named owner and a deadline. The organization measures time spent waiting alongside time spent building, so the next bottleneck is visible.

What this does not fix

There is a cost to this way of working that the playbook alone does not resolve. Engineers are staying up late trying to craft the prompt that keeps an agent working overnight, so there is a change waiting in the morning. Running several agents in parallel raises cognitive load, and switching between terminal tabs all day is tiring. More work moving at once can still mean more work for the person reviewing it.

Reviewing AI output is harder than writing code for a lot of people, especially early in their careers. Senior engineers have spent years reviewing other people’s code. Engineers still building that skill need time and support to develop it. I have written before that judgment is the scarce resource. The review queue is where that shows up first.

Where to start

Whether you lead an engineering group, contribute to a squad or build on your own, start with one task you still have to supervise response by response. Work out what keeps bringing it back to you: missing context, unclear requirements, checks the agent cannot run, or a decision nobody has made.

Fix that, then try again. Notice how far the work gets before it needs you, and whether the result takes less effort to review. Keep what helped, write it down and use it on the next task. That is how the change becomes a habit.

Made with BlueTip 🦋 (https://www.bluetip.ai)