Bo Frese
Most people use AI backwards - asking it for answers instead of bringing it their ideas. The real unlock is using it as a thinking partner that challenges you.
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 — not the 10x figures the vendors are selling, but significant enough to matter. Teams that use it with genuine discipline ship faster, tackle harder problems, and maintain the quality that makes velocity sustainable.
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. 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. At a certain point neither the humans nor the AI can navigate what was built. That's not a problem you sprint out of.
The second is to step back entirely. Wait for the right policy, the right evaluation framework, the right moment. In the meantime, competitors using AI with discipline pull ahead — and the gap keeps growing.
The organisations that win take a disciplined approach grounded in how AI actually works — including where it falls short. Experienced developers aren't reviewers at the end of a pipeline. They're the central piece throughout it — using AI to explore architectural options faster, stress-test decisions earlier, troubleshoot more deeply, and keep the whole system legible as it grows. The AI extends their reach. It doesn't replace their judgment. With humans in control and taking 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 this lives in the heads of the people who built it.
AI starts every session as 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 re-explaining the same context every time. Like onboarding a new developer who starts from scratch each week — at some point the overhead cancels the gain.
That changes the priority of things that have always been good practice but were easy to defer. Architecture decisions captured where they can be found, not in someone's memory or a Slack thread from three years ago. Test coverage and CI pipelines that catch problems automatically instead of relying on someone remembering. And documentation that adds to what the code says rather than duplicating it — the decisions made, the constraints, the reasoning that won't survive the next sprint. Not more documentation. The right documentation: what a capable developer needs to understand the system without having to ask. All of these were always a good idea. Now they are essential.
The second thing AI changes is ownership. AI is not intelligent despite the name — it cannot take responsibility for what it builds. That must remain with the humans. But responsibility doesn't transfer automatically when a developer approves a pull request. Real ownership requires being in the process: the reasoning, the decisions, the implementation. A developer who rubber-stamps AI-generated code has not taken ownership of it, however fast it passed review. Human-in-the-loop is not a compliance step at the end — it's the central piece of how AI gets used well.
The organisations that get this right don't just use AI better. They become more explicit about how they build software — and that turns out to make them better at building the right thing, with humans who can vouch for what they shipped.
How we can work together
I spent the past year building with AI full time. I also scrapped two of the products I built — both looked right on the surface, 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. The real risks of AI adoption, not the marketing version. What the tools actually do, where quality breaks down, and what discipline looks like in practice. Works for mixed audiences: 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. The mental model shift from AI user to AI delegator. Context engineering, structured process, code review discipline, and the tools to build a repeatable framework — not a list of prompts to copy, but a way of thinking to take back.
See the course
03
Hands-on advisory
Helping your team actually put it into practice. Structured process, context architecture, and the conversations the whole organisation needs to have — not just the developers. Get in touch to discuss what makes sense for where you are.
Advisory work often connects to the broader structural questions underneath AI adoption. Here's how I work in that context.
Thinking on AI
What AI adoption actually demands — technically, organisationally, and structurally.
Most organisations already carry more technical debt than they can handle. AI is about to accelerate the problem significantly — unless you address the underlying quality culture first.
Read