The plan from the inside: how we're running the AI-first shift

I’ve already given the polished talk about this. I told the unease that brought me here, then what a harness is, and last the new role of every profession in tech. Stage, slides, a story that lands. What doesn’t fit in a presentation is what comes after you step off it: the real plan, with half-built deliverables and a to-do list that never ends.

That’s what I came to open up here. Not the why, which is already told, nor the concept, which is too. The inside: the target we wrote for the end of the year, the big blocks of work we carved out to get there, how it gets run day to day without turning into status theater, and the ritual that keeps it standing. With what’s already done and, above all, with how much is still missing.

The target we wrote for the end of the year

We set a final state so we wouldn’t row in every direction, and the center of it isn’t “use more AI”: it’s the AI doing the heavy lifting end to end, with a human deciding what becomes true at each gate. That distinction is the whole article. Anyone can wire up a flow that runs on its own with a CI script; what we want is the agent writing the code, the tests and opening the PR, and us stepping in to steer and approve, not to type.

It fits in two sentences. By the end of the year, the path from discovering a product to the pull request runs local, end to end, with the agent doing the work and a person kicking it off and reviewing. And fixing a bug that comes in from a customer happens with the agent alone in the queue: it reproduces, investigates, fixes and opens the PR, and we only step in when the risk calls for it.

Here’s the whole design. Click each step to see what it does, and notice whose hand is on each one:

If that alphabet soup lost you, one second to translate. PDY is our Product Discovery in Jira, the board where every idea lands and gets prioritized before it becomes a problem. Problem Statement is the problem written as a hypothesis, not as a given, framed by two methods: JTBD (jobs to be done, the job the customer wants done) and HMW (how might we, the “how could we…” question that opens room for a solution instead of nailing one down). PRD is the document that locks down what will be delivered. And the handoff is the package (problem, PRD and test scenarios) that passes from product and design to engineering without anyone rewriting a thing.

Look at what changes. In almost every step the one doing the work is the AI: the skill prioritizes the demand, generates a prototype, breaks down the epic, codes, writes the test, opens the PR. The human steps in between one step and the next, reviewing and clearing the next one, and the diamonds mark the handoff when the work crosses areas. That’s what separates AI-first from “I automated a piece”: the machine isn’t following a fixed script, it’s doing the work that used to be ours, and we became the critic who approves. We stop being the glue between steps and become the judgment at the end.

And there’s a principle underneath it that I dug in hard on: one system, not ten loose initiatives. Every task goes through the same path, and what changes from one to the next is how much human it asks for. A complex feature, like the tire inventory or the lift-axle setup, each one full of business rules with exceptions, pulls a lot more people into the middle than a dumb tweak that can run almost entirely on its own. Same track, different brakes. It’s more annoying to build this way, because you itch to go solve each case your own way, but that was the call: start local, with a half-baked version zero, and let it learn on top of real tasks, instead of scattering loose experiments everywhere and stitching nothing together afterward.

And why local, and not some fancy remote machine firing everything off on its own from day one? Because the goal right now is to learn the loop, not to impress anyone. Running local, with a human hitting play, is the cheap way to see where the flow jams, where the agent goes off the rails and where context is missing, before trusting it to run with nobody watching. We’ll decide on the remote execution tool later, once the local flow is standing, and whichever one we pick has one rule that doesn’t change: Jira stays the source of truth for tasks, so whatever we plug in has to update it, not compete with it. Swapping the source of truth in the middle of a shift like this is pulling the floor out from under the whole team at once.

How we trust the automatic merge

If the agent codes and opens the PR on its own, the obvious question is: how do you let that into production without a human reading every line? The answer is two automatic gates that every PR crosses, in both modes.

The first gate is the tests: they block the merge, and in a bugfix the test has to fail without the fix, to prove it catches the bug and doesn’t just cover the line. The second is the AI code review, which comments on every PR. But there’s one decision the machine doesn’t make on its own: what’s critical. Did it touch money, data you can’t rebuild, access and security, hardware integration or a dependency? Then it’s critical, and a human approves before it goes in. The rest goes in on its own, with both gates green.

This holds in both ways engineering works. In autonomous maintenance, the agent sits alone in the queue, triaging and fixing bugs with no dev steering; in directed delivery, the dev steers the agent from the handoff to the merge. In each one, notice where a human still puts a hand:

Eight fronts, not a pile of tasks

To get from the target down to the day-to-day, we split the work into eight fronts, which add up to 236 tasks and subtasks in our ClickUp. Dumping that mountain of little tasks here in the middle of the text turns into noise, so I left the raw backlog in an appendix at the end, for whoever wants to dig into it. In the body, what matters is the big deliverable of each front and where it stands. It didn’t come from a pretty org chart: it came from how the work grouped itself when we wrote down everything that had to change at the same time for tech to go AI-first without creating a new bottleneck further down.

I'll email you whenever there's new writing. No spam.

Notify me

I’ll go through them, and I’ll be honest about where each one is.

1. The base on Claude Code. The first deliverable was the most concrete: getting everyone working in the same AI tool, and not just engineering, also product, design and operations. That part is already running. What’s left is the more tedious and less visible part, which is having real shared context between people and being able to see how much each team consumes, so we don’t find out too late that someone blew past the limit in the middle of a delivery.

2. Review, QA and testing. It’s the front that hurts most, because it’s the one that holds quality when code starts coming out too fast. The first AI review tool we put in couldn’t handle our volume, so we’re swapping tools mid-way. Along with that comes setting up mandatory human review for the sensitive spots, opening a QA role (which we never had dedicated) and measuring test coverage product by product. None of it is glamorous, and it’s what keeps us from shipping fast and wrong.

3. The Design System. It’s the most mature front by far, and it became our best example of how the thing should go. We’ve already closed the diagnosis and the foundation, with hundreds of tokens organized in a way the AI can read and use on its own. Now it’s in the middle of applying that to real components, with two platforms migrating at the same time. It’s the piece where the machine already looks like what we promised on paper, and that’s why it pulls the rest.

4. The upstream flow. This is where the start of that path from the target lives: discovery, the problem statement, the PRD, the repository that becomes the source of truth for a product. The big deliverable is making this piece run with the AI in the middle, and not just engineering at the far end. It’s one of the fronts with the most work still ahead, and that makes sense, because redesigning how we discover and spec product touches a lot of people.

5. Data as the owner of the truth. This is the quietest shift of all. The data team stops just delivering reports on demand and becomes the curator of our single source, which makes sure the AI sees the right data and doesn’t go hallucinating on top of old or contradictory stuff. It’s still more on paper than on the ground, but without it the rest jams, because no agent performs well on top of messy context.

6. The team’s operation. It’s the people front, and the slowest on purpose. This is where the first pods built to run an end-to-end delivery with AI come in (the tire inventory one and the lift-axle one were the first two), the pairing for folks to learn hands-on, the onboarding course I’m recording myself and the design of how careers change from here. The pairs aren’t fixed, they rotate, so what one person learned doesn’t stay locked inside a single duo. Changing how the team works is what generates the most discomfort, so we go slow and listening.

7. Governance and security. The part nobody wants to do and the one that can blow up the most. An agent with admin access in the wrong place is damage with no undo, so there’s a dedicated front just to review database permissions, sensitive-data policy and the governance of who can create and run what. This also includes the communication to the whole company, because this shift can’t stay only in the head of whoever started it.

8. The infra underneath. It’s the foundation almost nobody sees: a single repository to give the AI more context, our own data backend in place of the old tool, the environments to stage safely. The big deliverable of this front has already come a long way, and it’s what makes everything else possible. Without a foundation, the building doesn’t go up.

Where we actually are

If you put the eight fronts together and look with no filter, this is the picture: a few blocks are already closed, some are halfway, and most haven’t even really started. Closed: the diagnosis, the base on Claude Code, the Design System foundation, the indicators with the panel and a good chunk of the data infra. Halfway: AI review, the Design System on components, upstream and the first pods. And still a promise: the redesigned test pipeline, governance, the company-wide communication and the data team’s shift.

In other words: most of the plan hasn’t happened yet. And I wrote this text right now, with the plan at this point, on purpose. I could have waited for everything to look nicer, with more green blocks, to tell the story with a happy ending. But then it wouldn’t be the real thing anymore, it’d be marketing. We’re at the very start of a shift that will take the whole year, with the team building while the structure is still being assembled, and showing it half-done is the point. Whoever only tells the finished part is selling.

And there’s a part of this harder to swallow than the list of red blocks: the piece that moves slowest is the people, not the technology. Getting everyone onto Claude Code was fast. Getting a team that spent ten years proud of writing every line by hand to accept steering an agent instead of typing, that’s what takes time, and it’s what I solve least with milestones and a panel. It’s where I’m having to learn patience the most.

How we manage this without turning it into theater

A plan this size dies easily in two ways: it either becomes a list nobody opens, or a status meeting where everyone pretends it’s all green. We tried to dodge both with four simple things.

One is working with milestones, not loose tasks. The Design System is the best example: it’s sliced into numbered milestones, from the diagnosis to full application, and you can honestly say which one we’re on. A closed milestone is a closed milestone, no “almost”.

Another was putting a real owner on the big AI deliverables, instead of spreading everything across the squads and no one pulling. When something is everyone’s, it usually ends up being no one’s.

The third I’d sum up as measure little, but measure. We threw everything into a single panel, seven indicators, each answering a dumb, hard question, because the temptation to track twenty numbers and look at none is enormous. How much we deliver per week in PRs and tasks, how much of the review is already the AI and not us, how much bug escapes to production, how much of the code has tests to hold the AI shipping fast, how much of the code already comes from the AI itself, how the team feels using it, and how long we take to validate and put it live. If one of them gets worse while the others improve, it’s a sign we just pushed the bottleneck sideways.

And the fourth is more surrender than tactic: accepting that the bottleneck now is us, not the machine. The AI already builds fast; what jams is redesigning the work, training, reviewing and deciding, and that’s why half of these fronts are about people and process, not about tools. A tool we swap in a week. A decade-old habit takes a lot longer.

The ritual: a follow-up every two weeks

What holds all of this up is modest: a follow-up every two weeks. It’s not with the whole squads. It’s a small group, seven or eight people, with reps from product, engineering and design. I run it, and we kept adjusting the cadence until it became biweekly, when we saw that a shorter interval only generated a meeting with no real news to bring.

The follow-up isn’t a showcase. The idea is to hear the real difficulty (the tool that jammed, the limit that blew up in the middle of a long spec, the insecurity of someone afraid their own work is changing) and turn that into the focus of the next two weeks. Half the value is in the comments that don’t fit on a card, in the “this here isn’t working” said to your face. A plan this size doesn’t survive without a fixed place for the truth to show up.

And what comes out of these meetings doesn’t die in the minutes. The difficulty that shows up becomes the focus of the next two weeks, and a good chunk of it becomes training: someone on the team pairs with whoever’s stuck, and I’m recording an AI onboarding course so a new person comes in ready to play, instead of figuring everything out by trial and error like we did. It’s always people sitting together, getting it wrong together and passing on what they learned.

A win that wasn’t in the script

Not everything is dashboards and process, and the delivery that got me most excited so far wasn’t any of the ones I expected. A firmware problem in a new version we’re producing for one of our devices, the air retention of a new piece of hardware that not even our firmware supplier had cracked, was solved by the AI, in code alone. It landed in version 5 of the firmware, and from there it goes to every device. It’s not the kind of thing that crossed my mind when I started talking about agents in engineering, and it’s what convinced me most that this shift is broader than just building app screens faster.

A win like that is worth keeping. In a plan full of red blocks, the one that shows up on the side, off-script, is what reminds us the path is right even when the panel still looks ugly.

What I take from this part of the shift

Writing this was a bit uncomfortable, and that’s exactly why I wrote it. It’s a lot easier to publish the tidy concept than the plan with most of the blocks still open. But anyone can read the concept in an OpenAI article; what’s ours, and what might be useful to you who’s also in the middle of this, is the imperfect plan actually running.

If I had to sum up what this phase taught me, it’d be this: opening the whole plan, without hiding how much is missing, is what keeps me from fooling myself about where we are. The day these fronts all came into view, for the team and for me, with the green and the red side by side, it got a lot harder to sell illusion inside our own house. I’ll keep telling it as it goes, with the ugly number when it’s ugly.

Appendix: the whole backlog, front by front

Here’s the raw version, for whoever wants to see the real size of the thing. The eight fronts add up to 236 tasks and subtasks in our ClickUp, and below are the big blocks of each one, with a line on what it is. What’s inside each block changes every week, so treat it as a snapshot, not a closed list.

1. The base on Claude Code

• Finish migrating engineering to Claude Code Teams. All of engineering on the same tool.
• Expand Claude Code to Product, Design and Ops. Move past engineering and reach the rest of tech.
• Structure the org’s shared context. Common context, not each person in their own chat.
• Monitor Claude usage and cost after the expansion. See usage and cost per team.
• Centralize commands, skills and agents at the org level. A common library, without everyone reinventing.
• Define the dedicated person to own AI in engineering. An owner to drive this.

2. Review, QA and testing

• POC of the code review tools. Test and pick the AI review tool.
• Set up the trio of mandatory human-review rules. Define when a human has to review.
• Hire 1 cross-squad QA. The dedicated QA we never had.
• Define coverage targets per platform and module. How much test each product needs.
• Redesign the test pipeline. The pipeline that runs the tests end to end.
• Kick off the continuous test-implementation pipeline. Go back into the products and cover what was left untested.

3. The Design System

• Address the Design System’s structural problems. From the token milestones to applying them in components (React, Flutter, Widget Book).
• Decide the Design System’s path. Build in-house, buy or outsource.

4. The upstream flow

• Upstream System: enable Product and Design AI-first. Discovery, the problem statement and the PRD with the AI in the middle.
• Create, centralize and evangelize the process skills. The skills the team fires day to day, starting with the engineering processes.

5. Data as the owner of the truth

• Enable Data to operate as curator of the single source. Data stops doing on-demand BI and starts curating the truth.

6. The team’s operation

• Design and launch the AI-Native Innovation Pod. The lean team for bottlenecked deliveries (tires and lift axle were the first two).
• Run the microteam pilots. Break a team per delivery into pairs plus AI.
• Pair with devs to train on Claude Code. Pairing for folks to learn hands-on.
• Structure the formal onboarding on Claude. The course I’m recording.
• Update the onboarding for new hires. Whoever joins comes in ready to play.
• Update the performance criteria and the career path. How careers change from here.
• Run an AI Hackathon. A collective push.
• Create the biweekly exchange ritual between squads. A meeting for the squads to swap with each other what they’re doing with AI, what’s working and what’s going wrong.
• Implement Documentation-Driven Design. Document first, for the AI and for us to read.

7. Governance and security

• Review database user permissions across all applications. An agent with too much access is damage with no undo.
• Organize database users by project and least privilege. Each one only what they need.
• Define the sensitive-data policy for AI. What can and can’t go to the AI.
• Define the governance of internal skills, agents and MCPs. Who creates and who runs what.
• Communicate the AI-in-tech move to the whole company. Don’t leave it only in the head of whoever started.
• Openly communicate the team’s 4 asks. What changes for each person.

8. The infra underneath

• Kick off the technical brainstorm on the modular monolith. Technical debt: the monolith is too big and unmodularized, so for the AI it’s too big too, it gets lost and burns a lot of tokens. Rethink the architecture so it navigates better.
• Migrate from Notion to an open source tool. Legibility and MCP for the AI (we went with Outline, its cloud version, which has AI search).
• Merge the Intralog repos into a single monorepo. More context in one place.
• Stand up an analytics backend service for Intralog. Our own data in place of the old tool.
• Intralog MCP. Plug the internal platform into the AI.
• A fuller ProBot for questions via Discord. The internal assistant answering directly.
• Allow multiple staging environments. Stage safely, on Intralog and on Prolog.

Measurement (cuts across all fronts)

• Define the KPIs of the AI-Native restructuring. Throughput, human vs AI review, bug escape, test coverage, % of code by AI, internal AI NPS and time in staging.
• Build the initiative’s single dashboard. Everything in one panel.