How to build an AI-native engineering team: what to change in reviews, specs, tooling and hiring

Founders expect AI to make their teams ship faster. Most engineering teams I talk to already use it every day, and in many of them delivery hasn’t changed.

Delivery speed is where AI-native and AI-assisted teams differ:

• An AI-native engineering team builds its whole workflow around AI doing the first draft of most tasks. People there own the judgment around it: they decide what to pass to the agent, and fully own the result.
• An AI-assisted team gives everyone a coding assistant and keeps the old workflow.

The main difference is how you manage the team.

I'm the CTO at On The Spot Development. We build offshore development centers in Poland for product companies, and as a fractional CTO I help engineering teams with AI adoption. This article covers what I’ve tried with customer teams and what other tech leads shared with our Team Lead Club. For the broader shift in roles, see our piece on AI's impact on engineering roles and hiring.

Define what "10x" means before you start

The founders of a US company that runs compliance checks asked me how to get a 10x boost from AI. But what should the 10x measure? Revenue, productivity, or cutting the team to a tenth? I always suggest defining the goal first, because each goal leads to a different plan. For example:

• faster feature delivery,
• fewer defects,
• lower cost per change,
• capacity for a new product line.

I made the same point back in 2025, in 10 mistakes startups make when building with GenAI: teams invest in AI before they define what success looks like.

Automate the whole workflow

With that company I ran about five sessions. Every engineer already used AI, but delivery still hadn't sped up, and PRs waited for review as long as before.

I started with basic hygiene. We set up agents for the developers and automated part of the testing. Review was where work got stuck, and they had no automated review at all, so we added an AI review agent to their Atlassian stack. It catches typos and simple inconsistencies, but it still needs a human in the loop. Design went through three handoffs: a manager's clickable mockups, then Figma, then code. I suggested a design system in code, so the mockups go straight to the developers.

I wouldn't call the result dramatic. We fixed the basics, and most of my time went into getting developers, QA, designers and managers to agree on one workflow.

The main lesson: automate the whole delivery flow in parallel. When development speeds up while review, testing, design and product stay manual, the bottleneck moves downstream and overall speed stays flat. Roman Voronin made the same point at our TechSpot Core conference: coding was never the main bottleneck, so the priority is to cut the time from a new idea to its release.

A Harvard study, reported in October 2026, shows the same pattern: coding agents added 30% more code and review-to-merge time grew by 49%. The amount of finished software didn't measurably change. The 2025 DORA report puts it in one line: "AI doesn't fix a team; it amplifies what's already there."

[callout]Key takeaway: speeding up coding alone moves the queue to review. Plan changes to review, testing and design at the same time as you add agents.[/callout]

What to change in practice

Here's the setup I'd put in place. Some of it comes from my own projects, some from tech leaders who showed our Team Lead Club what works in their teams.

Pull requests: small and explained

• A diagram in every pull request. On one of my projects, the PR template asks for a before-and-after diagram in Mermaid. Don't check it by hand: add an automated check to the pipeline. The diagram lets engineers and agents see how the system changes, even when agents write most of the code.
• Small tasks for agents. My colleague's team gives its coding agent only tasks of up to two story points, so it never produces thousand-line pull requests. In each domain team, a developer is responsible for driving agent PRs through review and keeping the queue moving.

Specs and decisions live in the repository

• Short specs next to the code. On another project we use OpenSpec: an open-source framework for spec-driven development. Before the agent writes code, the team writes a short proposal, specs, a design and a task list for each change, keeps them in the repository and agrees on them. The specs stay in git as Markdown, and the team updates them after each release, so the agent and every new engineer always work from an up-to-date description of the system. An engineer from one of our customer teams showed our Team Lead Club how his team goes a step further: it links each test to the spec it protects, so when a test fails, the agent reads the spec, and only then fixes the code.
• Architecture Decision Records that record the reason. Write "moved off RPC because of this constraint". With that approach, future engineers and AI agents understand why the code was built this way.

One agent setup for the whole team

It sounds like a small thing, but I see it on most teams: work slows down when every engineer has a different environment. One has the agent plugins configured, another doesn't. Each developer’s laptop has its own setup, so the same agent gives different results.

Fix it once, at the infrastructure level. The tech leader keeps these in sync for everyone:

• agent setup and plugins,
• rules and skills in the repository,
• debugging tools,
• telemetry and dashboards.

[callout]Key takeaway: set up agents, rules and observability once, at the infrastructure level, and make the tech lead responsible for keeping them in sync.[/callout]

An engineer from one of our customer teams showed our Team Lead Club how his team sets up its agents:

• Instructions only. The agent's instruction file in each repository contains only rules that change its behavior. To keep session sizes small, architectural history and long explanations belong in separate docs.
• Rules on three levels. First, an organization policy nobody can override, then rules per repository, then each engineer's own settings.
• An allow-list of commands. The agent runs routine commands on its own and asks before anything risky. Without it, engineers who have to approve every command start clicking "apply" on autopilot. With fewer requests, they read each one carefully.
• A plan before code. For anything complex, the agent works in plan mode first. The team reviews the plan with an architect, and then the agent can start writing code.

Decide what to automate next

Rufat's team runs every automation idea through three checks: how often the task repeats, how much it costs to verify the result, and how easily you can undo a wrong result.

Ownership: who answers for agent code

I’ve seen teams with dozens of unmerged PRs. In my experience, the reasons are almost always management problems, and fixing them is the tech leader’s job.

Agents bring up a question I think about a lot: who answers for code that the team hasn’t read line by line? I’ve settled on the engineer who started the agent. But that only works if agent PRs are small enough to read, which is why the two-story-point limit matters. And every team needs one review process, set by their tech leader.

[callout]Rule of thumb: every agent PR needs one engineer who owns it, from review to merge.[/callout]

“Sometimes you just need good people. Show them the pickup time is longer than they expect, shift reviews and reviewers, and you’ll see your velocity go up 20%, just because PRs aren’t lying around.”

That’s why we invest in tech leaders. At On The Spot Development we run Team Lead Club, a regular meeting of our engineering leaders. They share their experience with AI adoption: what they tried, what worked, what didn’t, and how to bring AI into the work of the whole team. Customers get tech leads who learn beyond the context of their own product.

Hire for fundamentals, breadth and ownership

What I look for in engineers has shifted. On one recent project I interviewed almost every engineer myself. Knowledge of a specific framework or library matters less every month, because an agent handles those details quickly and well. My criteria:

• Fundamentals. An engineer who works with infrastructure needs to know how access works in the cloud. An engineer who works with data needs to understand transactions, SQL, relations and constraints. How transactions work in one specific database matters less. Knowing the basics lets the engineer plan the work and direct the agent with the right questions and prompts.
• Breadth of knowledge. The more domains an engineer has worked in, with interest and with results, the better. Scars from past mistakes count too. Broad experience helps with decisions where agents don't have enough context, such as planning testing and releases or designing an architecture that is simple now but scalable in the future.
• Ownership and curiosity. With agents in the loop, the gap in delivery between developers grows, and output can be out of proportion to title and salary. An engineer with a strong background who is lazy and sloppy delivers less than a responsible, curious junior. For me, ownership and genuine interest now weigh more than past experience.

There's no single hiring process to copy. Every customer adapts the stages and test tasks to its product. In our model, On The Spot Development's in-house recruiters run the search and the first screen. The customer's team runs the technical interviews, adds a test task if it wants one, and makes the final decision. If you hire on your own payroll, our tech recruitment works the same way.

When I join technical rounds, candidates can use AI. I watch how they explore the problem and whether they can explain and defend what the AI wrote.

Remote hiring brings two problems we now screen for:

• Hidden AI on calls. More and more candidates read answers from an AI tool on another screen. Our recruiters have seen it often enough to spot it quickly. I once had a candidate pretend to think deeply while reading live AI answers. If you interview remotely, watch for this.
• Fake profiles for AI roles. Lately, we've seen CVs that look solid until you check them: the companies don't exist, and the GitHub account was created last month. So for AI roles, screening starts with a reality check: a quick video call about the candidate's projects and a cross-check of their LinkedIn profile and past employers.

Keep the team's AI knowledge inside your company

A speaker at our April TechSpot Core conference described skills as "accumulated operational experience embedded into reusable systems": engineering patterns that agents can run and the team keeps improving.

That memory needs a long-lived home, and the way you build the team decides where it ends up. In an offshore development center, engineers work full-time for one customer and follow its processes. On The Spot Development handles employment, payroll, equipment, office and HR, with an account manager as the contact. Every engineer signs an NDA and an IP assignment before getting access to the customer's systems, and the customer keeps control over device management and access to its infrastructure.

"The most impressive thing is no doubt the quality of the whole process, starting from the hiring stages and all the way up to providing the employees with all they need to carry out day-to-day responsibilities. We often hear that [On The Spot Development] is one of the best companies our team members have dealt with."

For AI know-how, an offshore development center works like an in-house team: the setups and skills stay in your repositories. The difference is where you hire and who handles employment.

Measure the flow

How fast engineers feel with AI and how fast the team delivers are two different numbers. In METR's 2025 trial, experienced open-source developers expected AI to cut their task time by about 24%, and took 19% longer instead. In a February 2026 update, METR says developers are probably faster with today's tools, but it can't say by how much. Many developers now refuse to work without AI, so there's no baseline to compare against. Self-reported speed-ups stay unreliable.

Expect things to get slower before they get faster. DORA's 2026 report on the ROI of AI-assisted development calls this a J-curve: at first, teams lose time learning the tools and checking AI-written code.

Track the whole flow, and track speed and stability together. Take a baseline before you change anything. I track:

• time from ready to merged,
• review wait time,
• change failure rate,
• the cost of a change, including tokens.

[callout]Key takeaway: measure the whole flow, from ready to merged, and look at speed and stability together. How fast engineers feel is a different number.[/callout]

What other engineering leaders told us

On the 137 podcast, Boaz Adato, Head of Engineering Guild at HoneyBook, talked about their AI journey. One point stayed with me: AI's impact is different between new and legacy systems. A brand-new service and a ten-year-old codebase need different expectations and checks. You can watch the full episode.

FAQ

[faq] What is an AI-native engineering team?

A team that builds its whole workflow around AI doing the first pass on much of the work. Engineers decide what to hand to the agent and own every change it makes. [/faq]

[faq] What's the difference between AI-native and AI-assisted teams?

An AI-assisted team gives everyone a coding assistant and keeps the old workflow. An AI-native team changes reviews, specs, tooling, ownership and hiring around the agents. [/faq]

[faq] Why hasn't AI made our engineering team ship faster?

Usually because only coding got faster. Review, testing, design and product stayed manual, so work now waits in those stages. Find the step where work waits longest and automate around it. [/faq]

[faq] How do you measure the impact of AI on an engineering team?

Take a baseline first, then track time from ready to merged, review wait time, change failure rate and the cost of a change, including tokens. Self-reported speed-ups are unreliable. [/faq]

[faq] Should we build an AI-native team in-house or with a partner?

In-house works when you can hire in your market at the pace you need. An offshore development center fits when you want a long-lived team that follows your processes and keeps its know-how in your repositories. [/faq]

Where to start

Name the outcome you want from AI and how you'll measure it. Find the step in your flow where work waits longest, and automate around it before you add more speed upstream. Keep pull requests small and explained, and put specs and decisions in the repository. Give the team one shared setup. Make sure every change has an engineer who owns it. Hire for fundamentals, breadth of knowledge and ownership.

If you're building an AI-native team and want to talk about hiring or an offshore development center in Poland, get in touch.

***

About the author

Anton Vasiljev is the CTO at On The Spot Development. He works with product companies as a fractional CTO and helps engineering teams adopt AI in their delivery process.

Feel free to contact him via LinkedIn.