"Make us AI-native": a 30-day plan for engineering leaders

How to turn a vague AI mandate into a baseline, a few changed workflows, clear team norms and honest results in one month.

Keel team · 15 October 2026 · 7 min read

The short version

"Make us AI-native" is usually a goal without a definition. Your first job is to turn it into something you can show progress on in 30 days.
Week 1: take a baseline of how work flows today. Week 2: pick two or three workflows and change them on purpose. Week 3: write team norms, especially for reviewing AI-written code. Week 4: measure and report back.
Measure outcomes at team level (cycle time, incidents, what shipped), not tokens, lines of code or individual usage.
Agree with founders up front what "done" looks like at day 30, and what it does not mean: it does not mean half the team is gone.

A lot of engineering leaders are being handed the same mandate this year. In The Pragmatic Engineer article "Headed for the Exit: the Great Engineering Leader Career Break" (August 2026), Gergely Orosz describes CTOs expected to "magically transform the company to be AI-native", often alongside pressure to cut engineering costs and ship more with fewer people, while AI coding bills climb. If that sounds familiar, this guide is for you.

The mandate is rarely defined. That is your opening. If you define it well, with a plan that has something to show at the end of each week, you get to shape what "AI-native" means for your team instead of having it defined for you by whichever founder last read a thread about agents.

First, define the goal in one paragraph

Before week 1, write down what you think "AI-native" should mean for your company, and get your CEO or founders to react to it. Keep it concrete. Here is a version we would start from:

"Within a quarter, AI tools are a normal part of how we plan, build, review and operate software. We can point to specific workflows where they have made us faster or better, we have clear rules for how AI-written code is reviewed and owned, and we can show the effect on what we ship without measuring people by how much AI they use."

Notice what is missing: headcount, token targets, and percentage-of-code-written-by-AI. Those may come up. They should not be the definition.

Week 1: baseline how work actually flows

You cannot show improvement without a "before". Spend the first week understanding the current state, the way a good fractional CTO does in their first month: read the git history, look at deploy frequency and incidents, and talk to the people doing the work.

Delivery. Rough cycle time from first commit to production, deploy frequency, and the size of a typical pull request. Approximate numbers are fine.
Quality. Incidents and rollbacks over the last quarter, and where bugs tend to come from.
Where time goes. Ask each engineer: what took the most time last sprint that you wish it hadn't? You will hear about flaky tests, slow reviews, unclear tickets and boilerplate.
Current AI use. Who already uses what, for what, and what they have stopped using. Usage is usually more uneven than leadership thinks.
Cost. What you currently spend on AI tools, and who pays for what.

End the week with a one-page summary. It is your baseline and the first thing you show founders.

Week 2: pick two or three workflows and change them

"Use AI more" changes nothing. Changing a specific workflow does. From the week 1 conversations, pick two or three places where AI tools are likely to help and where you can see the result within a few weeks. Good candidates:

Test writing and fixing flaky tests, where the work is well bounded and easy to check.
First-pass code review, an agent leaving comments before a human reviews, so human reviewers spend time on design and risk.
Small, well-specified tickets (bug fixes, internal tools, migrations) handed to an agent end to end, with a human owning the result.
Incident and on-call support: summarising logs, drafting postmortems, finding related past incidents.

For each workflow, name an owner on the team, write down what "better" would look like, and agree how you will know. Avoid starting with your riskiest code (payments, auth, data deletion) until the review norms in week 3 exist.

Week 3: write the team norms

This is the week that matters most and gets skipped most often. AI tools change who writes code, but not who is responsible for it. Founders shipping very large AI-written pull requests is a recurring theme in the Pragmatic Engineer piece, including one CTO whose founder shipped a 60,000-line pull request, and the questions it raises are the ones your norms need to answer: who reviews it, and who is on call for it?

Team norms for AI-assisted work (starting point)

The author owns it. Whoever opens the pull request is accountable for every line, however it was produced. "The agent wrote it" is never an answer in review or in an incident.
Keep pull requests reviewable. Set a soft size limit. Large AI-generated changes get split, or come with a written explanation of the approach and what was checked.
Say what the tool did. A line in the PR description: what was generated, what was changed by hand, how it was tested.
Human review is about design and risk. Let tools catch style and obvious bugs. Reviewers focus on whether this is the right change and what could break.
Sensitive areas get a second reviewer. List them: payments, auth, permissions, data migrations, anything customer-facing that is hard to roll back.
Same rules for everyone. Founders and leaders included. Agree the on-call owner before anything merges.
No surveillance. We do not track individual token usage or rank people by AI use.

Write these with the team, not for them. Engineers who helped draft the rules follow them.

Week 4: measure, then report back

Go back to your baseline and compare, for the workflows you changed. Keep it honest and at team level. DX notes that research shows developers don't like metrics aimed at measuring individual engineers, so keep the numbers at team level and out of individual reviews. Measuring people by AI usage is a fast way to get gamed numbers and unhappy engineers.

What to look at:

Cycle time and review time on the workflows you changed
Incidents, rollbacks and bugs traced back to changed code
What shipped that would not have shipped otherwise
What the team says: which changes they would keep, and which they would drop
Spend on AI tools against what you got for it

Some results will be mixed after only a few weeks. Say so. A report that says "test generation worked, agent-written migrations did not, here is why" is more credible than one where everything went up.

Your 30-day plan on a page

Before day 1: one-paragraph definition of "AI-native", agreed with founders.
Week 1, baseline: delivery, quality, where time goes, current AI use, current cost. Output: one-page summary.
Week 2, workflows: two or three workflows, each with an owner and a definition of "better".
Week 3, norms: ownership, PR size, disclosure, review focus, sensitive areas, on-call. Written with the team.
Week 4, measure and report: before and after at team level, what to keep, what to stop, the plan for the next 60 days.

Setting expectations with founders

The hardest part of this mandate is often not the engineering. It is that "AI-native" can mean very different things to you and to your CEO. Have that conversation in the first week, not the last.

Agree on what day 30 shows. A baseline, a few changed workflows, written norms, and early results. Not a transformed company.
Separate the cost question. If the real goal is cutting engineering spend, ask for that to be said directly. It needs a different plan, and mixing it into an AI rollout makes engineers suspicious of every tool you introduce.
Agree that founders follow the norms. If a founder can merge a huge unreviewed change, nobody else will take the rules seriously.
Agree how progress is reported. Outcomes and shipped work, not token counts or lines of code.

A short script for the opening conversation:

"I want this to work, so I want us to agree what success looks like. In 30 days I'll bring back where we started, the workflows we changed, the rules we set for AI-written code, and what changed as a result. I'd rather show you real results on three things than vague progress on everything. Can we agree that's the bar?"

After day 30

Keep the changes that worked, drop the ones that did not, and pick the next two or three workflows. Report back on the same team-level measures every month so the story stays consistent. If you need help structuring that report, see our guide on showing leadership what AI is doing for your team, and for the harder question of how this changes individual reviews, read performance reviews when your engineers use AI agents.