Inside an AI-native engineering organization

That’s Juho Eräste, co-founder and CTO of Taito.ai, and former software engineer at Swarmia, opening a demo he gave our engineering team. He’s about to show us how his company builds software, so he shares his screen. He doesn’t open a code editor, because he rarely has one open anymore. Instead, he opens Linear, and starts talking.

Taito.ai is a people operations platform that was founded in 2024. Today, they’re eight people in total, four of them engineers. They’re ISO 27001 certified, and their product handles HR and salary data for dozens of paying customers, which means this isn’t a hobby project with a particularly forgiving audience.

There’s a lot of talk right now about engineering organizations reinventing themselves for the agentic era. There’s much less about how anyone actually does it. What follows is the method for one, very small but very agentic team, in the exact order Juho walked us through it: prototype, plan, split, delegate, review.

Before we jump in, note that this isn’t a recommendation on how everyone should run their engineering organization today. It’s an example of what’s possible for a team that doesn’t have a large codebase, a huge team, or hundreds of customers to worry about just yet. That said, while you’re unlikely to copy this approach to a larger organization as is, I believe there are lessons here for engineering organizations of all shapes and sizes.

The first version is meant to be thrown away

Greenfield work at Taito doesn’t start with a project or a ticket. It starts with someone building the whole thing end to end with agents, as fast as possible, knowing full well the code is going in the bin. The prototyping phase usually takes one engineer anywhere from two to three days, and happens organically. If an idea is interesting enough, someone will pick it up.

“The goal is to get into an end-to-end state as soon as possible,” Juho says, “to figure out if the workflow, and if the idea that we had in mind, was actually something that could be useful.” Sometimes they’ll take that prototype to a customer and let them poke at it before anyone commits to building the real thing. Other times the team decides among themselves that the prototype is worth promoting to a real feature.

At Taito, only about 25% of their prototypes make it directly to the planning stage, another 25% get a complete redo before they’re promoted, and the final 50% are scrapped entirely. After all, deciding what to build used to be expensive, because building the wrong thing cost you weeks. Now the first version is cheap enough that it becomes the artifact you make the decision against.

Our own team described the same shift after trying Anthropic’s campfire format: in the old way, the hardest part was prioritization and figuring out what to build. In the new way, you build a rudimentary version of everything and then pick what to deploy.

The plan is what separates the humans from the clankers

Once the team decides a prototype is worth building for real, one person sits down with an agent and works out how to break it into pieces. The agent drafts the issues. And then, before anyone writes production code, the whole team reviews the plan.

That’s where the architecture gets settled and where the awkward questions come out. “That’s the point when we raise discussion points about, okay, is that actually going to be secure?” Juho says. “Are we fine with this new functionality appearing?” Once everybody gives a thumbs up, one or two people start building. Two when they can manage it, because bus factor is still real. One person prompts and drives the code forward, the other reviews, and they swap.

Of everything Juho showed us, architecture is the thing he guards most carefully. He thinks that every person in the team should understand the shape of the system and be able to reason about it. The bar he sets is that they should all be able to explain what happens across the system when a user clicks a button. Where the transaction goes, what gets notified, which listener checks permissions and cascades the events.

Everything downstream works because of the human judgment calls that are made in this step.

Small batch sizes, from a former believer

“Coming from a Swarmia background, I was a huge believer in small batch sizes and all that,” he says. “I have to say I disagree nowadays.”

Two things changed his mind. The first is throughput. When one or two people are building a feature with current tooling, they’re opening ten to twenty pull requests a day, and review becomes the bottleneck immediately. The second is context. On a four-person engineering team, there usually isn’t a third person who understands the feature well enough to review it in fifteen slices anyway.

So they invert it. Build end to end first, then split afterward, and split for exactly one reason: to make review easier. The boring parts, mostly UI work, can happily sit in a two-thousand-line pull request and nobody loses sleep. Anything touching authorization gets deliberately pulled out into its own small PR, so that the human review is contained to the small part of the code that needs actual eyeballs.

“If we need to have a super strict review on some of those, it’s still easier to do if the PR is a couple hundred lines,” Juho says, “compared to 5k lines where you need to find those 200 lines that are meaningful.”

He’s honest that this is a trade-off rather than a free win. A tall stack of tiny pull requests is something the reviewer can’t test as a working whole, and he still has an internal debate running about where the line sits.

It’s also worth noting that Taito is not an outlier here. Across 1,450+ engineering organizations in Swarmia, median batch size roughly doubled between Q1 2025 and Q1 2026. Juho is describing, in some detail, one of the reasons why.

Then you hand it to the agents

Taito runs two named agents you’d notice in a day of work: Jeeves is the generalist coder and Fixer investigates and fixes bugs.

Jeeves and its specialized subagents do most of the feature development work.

Fixer is the more interesting one. Grafana alerts create Linear issues automatically. The customer-facing team pings the Linear agent from Slack when someone reports something. Fixer picks it up, goes digging through traces, logs, and metrics with read-only access, and writes what it found into the issue. If the fix looks simple, it delegates to an implementer, which starts by writing a test that fails, then fixes the code, then confirms the test passes. That sequence is documented as a skill, so it happens the same way every time.

The delegated agent also can’t declare itself finished on vibes. Its goal is defined as meeting the requirement written in the Linear issue and passing the full QA command, static analysis and end-to-end tests included. If it can’t do both, it isn’t done.

Juho’s favorite result from all of this is a small yet convincing one. Before Fixer, they had the bug backlog every team has: growing, mildly embarrassing, never quite worth anyone’s afternoon.

Around 70% of reported issues now get a fix within half an hour. Almost none of them were hard. They were the annoying ones that never made it high enough up the list for a person to pick up, which turns out to be a category that agents are very good at eating.

The other change is where the work happens. Juho mostly has Linear open, not a terminal, because that’s where the conversation with the agent lives. He’ll correct it there in real time when it starts doing something strange. The terminal is reserved for work where he wants to be in the driver’s seat.

Code review will make or break your agentic process

This is the part Juho thinks everything else depends on, so it’s worth going slowly. (It’s also worth reading this post Juho made a few weeks after demoing their setup to us.)

At Taito, every pull request gets automatically reviewed before a human sees it. The first pass is fixed and deterministic: static analysis, dependency graphs, and an explicit list of boundaries in the codebase that always pull in a human, whatever the change looks like.

A review agent runs on top of them, working from a skill that’s somewhere between five hundred and a thousand words. Together, they pick up any tripwires: cryptography, authentication, authorization, personally identifiable information, secrets, database migrations. If a pull request comes through all of it clean, it’s fine to merge. If anything trips at any layer, the bot slaps a human review label on it and writes guidance for the human on what to actually look at.

About 30% of pull requests land in that bucket today. It used to be closer to 90%, back when the rule was a blunt “any migration needs a human.” Adding a column with a sensible default doesn’t need a person. Migrating existing customer data with a long SQL statement does.

And when a human does get pulled in, they’re not expected to read the whole thing. “They need to review the points that are touching this,” Juho says. Most of them don’t do it by reading line by line either. They open their own agent session and interrogate the change: I have these doubts, can you verify whether this is happening.

What they’re really reviewing is the tests. Is there a case for the happy path? For the unhappy one? When Juho suspects something might leak, he simply asks for a test case that proves it does or doesn’t.

He thinks that humans are not in the loop to work out whether a migration will deadlock, because agents are better at figuring that out than we are. Humans are in the loop for the sentence that comes after: this will lock a table for a minute, and someone needs to decide whether that’s okay.

One of our engineers pushed back here, reasonably: if nobody reads the code and the trust sits in the tests, how do you know the tests are any good? Plenty of tests look great and check nothing. Juho’s answer was that test code is one of the things most likely to get a human read, and that the first time the team builds something new and foundational, he still reads all of it.

Turning repeat review comments into routinely updated skills

So if the bot catches the defects and the humans take the judgment calls, where did everything else go? All the “use the other pattern here,” the “we don’t structure services like that,” the semicolons?

They became skills.

Taito’s skill library covers browser testing, real-time collection sync, their RPC protocol, Go style lifted more or less straight from Google’s own guides, React testing, the replication protocol, how to do a review, and copywriting, because one person had strong opinions about how the app reads and got tired of saying so in comments. Now the agent just knows.

“Everything that I would care to argue in a PR should be documented in a skill,” Juho says. And then the review prompting has to be strict enough that a difference between the skill and the implementation doesn’t pass.

The piece that makes this stick, rather than rot the way documentation usually rots, is a weekly routine that reads the codebase against the skills and the docs and flags where they’ve drifted apart. When it finds a mismatch, something has to change. Either the code gets refactored or the document gets rewritten.

Speaking of written standards, they matter more now than they used to. A year of normal drift leaves you with five ways of doing the same thing, and a human can usually tell which one is current. An agent can’t. “If the agent sees there’s two ways of doing things, it’s going to toss a coin.”

He’s realistic about the limits. The thing that annoys him most about agents is watching them take shortcuts to please you and produce something ugly in the process, and skills only catch what you thought to write down. He’s made peace with that, as long as the behavior is right, the architecture holds, the thing is testable, and it’s not in the areas defined as security-critical. “I don’t exactly care how it’s actually doing the thing.” He used the word freeing, specifically about frontend and React, where there are a million ways to do anything and most of them are fine.

Somewhat surprisingly, Taito’s agentic workflow didn’t break compliance either. Juho explains that ISO 27001 and SOC 2 care that you follow the process you defined for yourself and can prove it. So Taito rewrote their software development lifecycle policy and took the change to a board meeting to have it accepted. Now they can point at every pull request carrying a human review label and show a review rate of 100%, which more than most teams can say about the reviews they’re doing today.

The floor all of this stands on

None of the above works without a solid infrastructure.

Their dev environment runs on Tilt, spinning up a local Kubernetes cluster with one command. Ports are randomized so the environments don’t collide, which means Juho can have up to five tasks running at once in separate worktrees, each with its own stack. CI runs everything on every pull request: about five minutes without end-to-end tests, another three or four with them, most of that spent bringing services up.

The test suite is enormous, at the unit, integration, and end-to-end levels. End-to-end tests used to be the ones Juho hated, flaky and miserable to keep alive. They’re fine now, because an agent watches CI failures, works out whether a test is genuinely flaky or whether the code is broken, and opens a pull request either way.

Agents run in Docker sandboxes. They reach GitHub through a separate app with its own permissions, Grafana through read-only access, and production databases not at all.

It’s the same lesson our own team took from running campfire sessions: a prototype in ten minutes only happens when the design system, the pipelines, the guardrails, and the repo instructions are already in place. Speed is a consequence of that groundwork.

What still needs a person?

First, and most importantly: the trade-off calls.

Are we fine with the tool being unavailable for a minute? Are we fine with these older customers needing a manual migration? We’re changing how authorization works, so people who couldn’t see a salary field are about to be able to see it. Are we fine with that?

“That’s something I don’t trust agents to do,” Juho says.

Besides, when you cause a customer-facing regression, people want a face behind the decision rather than an explanation that the AI did something.

There’s one more category. The first time the team builds something foundational, he still reads every line. He did it for the replication protocol that keeps every client’s local database in sync, because he wanted to be able to reason about it for years, not just confirm it behaved correctly this week. For everything built on top of that protocol since, he doesn’t go into line-by-line detail. He trusts it to follow the patterns already established, and he checks that the test cases are there.

The easy mode of becoming an agentic engineering org

Juho volunteered the caveat before anyone asked for it: small team, young company, no accumulated legacy to fight. “We are playing this on easy mode.”

It’s a fair disclaimer and it should temper how directly you copy any of this. Four engineers who all sat in on the same architecture discussion are a different animal from four hundred engineers across a decade-old codebase. But the direction struck everyone in the room as correct, and his closing argument is hard to disagree with:

His view is that the traditional model, where every line is read and understood by a human before it merges, can’t coexist with this way of working. One of them has to give.

What nobody has worked out yet is where the balance actually sits. Which changes earn a human, how much of the system people need to hold in their heads, and what gets lost when the knowledge sharing that used to happen through reviews stops happening there.

“I think we’re on the right track,” Juho says. “But I don’t think we’re fully there.”

But then again, neither is anyone else.

Is your engineering org on the right track?

Whether you’re leading a small or large engineering organization, the Build framework helps you understand if your AI investment is really paying off.

Read the Build framework