Bo Frese
Wary of pointing AI at critical production code? Start by building the internal tools your team has always wanted. A System Atlas is one example, and it can return a lot of time to developers, testers and operations.
Read
AI
Not just AI.
Not just AI.
The whole system it lands in.
Every organisation is building with AI now. The ones doing it well got the foundation right first.
What changes with AI
AI is a tool that simulates intelligence. Understanding that distinction is where everything starts.
The productivity gains are real. They're not the 10x the vendors are selling, but they're big enough to matter. Teams that use AI with discipline ship faster and take on harder problems, while keeping the quality that makes that speed last.
There are two ways to miss this.
The first is to take the hype at face value and let the AI run. Velocity climbs fast and the demos look right. But AI-generated code passes review in ways it wouldn't if a developer had written it, because nobody recognises the patterns the way they do in code they own. Problems compound quietly, and at some point neither the humans nor the AI can find their way around what was built. You can't sprint your way out of that.
The second is to step back entirely and wait for the right policy, the right evaluation framework, the right moment. In the meantime, competitors who use AI with discipline pull ahead, and the gap keeps growing.
The organisations that do well take a disciplined approach, based on how AI really works and where it falls short. Experienced developers stay at the centre of the work the whole way through, not as reviewers at the end of a pipeline. They use AI to explore architectural options faster, test decisions earlier, troubleshoot more deeply, and keep the system understandable as it grows. The humans stay in control and take full ownership of what gets built.
AI doesn't replace good engineering judgment. It depends on it.
— Bo Frese
What it actually requires
Building software well has always required knowing four things: what to build, how to build it, whether it works as designed, and whether it was built in a maintainable way. In most organisations, most of that lives in the heads of the people who built it.
AI starts every session like a new developer on day one: no memory of last month's architectural decisions, no feel for the conventions your team developed over years, no understanding of why the product exists. It doesn't always know what it doesn't know, so it won't always ask. And when it does ask, you're explaining the same context again. It's like onboarding a new developer who starts from scratch every week, and at some point the overhead cancels out the gain.
That raises the priority of things that have always been good practice but were easy to put off. Architecture decisions written down where people can find them, not in someone's memory or a three-year-old Slack thread. Tests and CI pipelines that catch problems automatically, instead of relying on someone remembering. And documentation that adds to what the code says instead of repeating it: the decisions, the constraints, and the reasoning that won't survive the next sprint otherwise. What matters is the right documentation, not more of it: what a capable developer needs to understand the system without having to ask. All of this was always a good idea. Now it's essential.
The second thing AI changes is ownership. An AI can't take responsibility for what it builds, so that has to stay with the humans. But responsibility doesn't transfer automatically when a developer approves a pull request. Real ownership means being part of the process: the reasoning, the decisions and the implementation. A developer who rubber-stamps AI-generated code hasn't taken ownership of it, however fast it passed review. That's why ownership has to be built into how AI gets used from the start, not added as a compliance step at the end.
The organisations that get this right end up more explicit about how they build software. That turns out to make them better at building the right thing, with people who can stand behind what they ship.
How we can work together
I spent more than a year and a half building with AI full time. I also scrapped two of the products I built along the way. Both looked right on the surface, and both fell apart under sustained development. What I do now is shaped by what went wrong.
There are three ways I work with teams on this, depending on where you are.
01
The talk for your whole team
One hour on the real risks of AI adoption, without the marketing gloss. What the tools really do, where quality breaks down, and what discipline looks like in practice. It works for mixed audiences, with decision makers, architects and developers in the same room.
See the talk
02
The course for your developers
A full day of hands-on work for developers. It takes you from chatting and vibe coding to a disciplined agentic development process, where you don't just stay in the loop but keep ownership, and can take responsibility for what gets built. We cover context engineering, structured process, review discipline, and how to build a framework your team can repeat.
See the course
03
The AI Team Kickoff on your codebase
Two days building your team's AI development process on your own project, followed by regular follow-up. You end up with working skills, documentation and a backlog built on your real code.
See the kickoffAdvisory work often connects to the broader structural questions underneath AI adoption. Here's what an advisory engagement looks like.
Thinking on AI
What AI adoption really demands, technically and organisationally.
Most people use AI backwards, asking it for answers instead of bringing it their own ideas. I get the most from it as a thinking partner that challenges me. Here is what that looks like, and a prompt you can try.
Read
Most organisations already carry more technical debt than they can handle. AI is about to make it much worse, unless you deal with the quality culture first.
Read