Bo FreseYour velocity is real.
Is your foundation?
A grounded hour on AI adoption — the genuine gains, the real risks, and what doing this right actually takes.
Image created with AI - obviously :-)
Who this is for
AI is moving fast. Genuinely fast - capabilities shift week to week, and the productivity gains are real. Anyone who has worked seriously with it on something that actually mattered has also hit the odd behaviour: the confident wrong answer, the subtle drift, the session that went sideways without warning. That is not a bug. That is how it works.
Some teams are held back by uncertainty - not sure whether to accelerate or slow down. Some are already moving and noticing things that are hard to name. Some are fully committed, velocity is climbing, and the question is whether what's being built at that speed will hold.
This talk is for all three. The failure modes go in both directions: move too fast without the right structure and quality degrades in ways that are hard to spot until they compound; wait for the right policy or the right moment and competitors using AI with discipline pull ahead. Neither is a safe position. Both are avoidable.
It is for the people responsible for what gets built - decision makers, product owners, architects, developers, testers. Not a pitch for AI adoption. An honest account of what it actually takes to do this well.
I scrapped two projects last year. Both built with AI. That's what I'm here to talk about.
— Bo Frese
How AI actually works
Under all the hype: this is simulated intelligence, not actual intelligence. It predicts the most likely output - and it does that exceptionally well. Understanding what that means in practice is what separates teams who benefit from those who get burned.
That means understanding the context window - the hard limit on what the AI can see at any one time. It means understanding that every session starts fresh: memory tools exist, but they are too generic for serious engineering work. In practice, every session is still close to day one. It means knowing what the tool can own and what it cannot - and staying in the loop on the things that only a human can hold.
The better you understand what is under the hood, the better you can work with the tool, work around its limitations, and keep the work yours.
What the talk covers
One hour. No hype. Three things.
How the tool actually fails
Not the catastrophic failure mode, but the subtle one: the confident wrong answer, the session that accumulates small errors, the code that looks right and isn't. Where to watch, and why.
Where the real risk is
Not what AI produces. What happens when a powerful, misunderstood tool runs inside an organisation without the discipline and human ownership it requires. Quality culture at the centre.
What discipline looks like
A live walkthrough of a structured AI development process, from business vision to implementation to review. What it means to stay in the loop and own the outcome.
Three questions to take back
The talk ends with three questions. The first two point toward work AI can help you do right now — if you point it in the right direction. The third is the one only a human can answer.
Do your developers have a structured process?
Habit and behaviour — but it can also be encoded into a set of AI skills and commands. That takes real work and a genuine understanding of how AI works. If the process doesn't exist yet, use AI to build it. That is the first job.
Is your foundation ready?
Could a new developer be productive on their first day? If not, neither can the AI. Every session is day one. Documentation, architecture decisions, product vision, CI/CD, test coverage — use AI to build what is missing. Not features. Foundation. Then build faster.
Is there a human who understands what was actually built?
Not the plan. Not the spec. The code, the architecture, the debt accumulating, the maintainability. Someone who could look at what exists and say: I stand behind this. That is the one thing AI cannot do for you.
About this talk
I built real AI-assisted products for a year, full time. Two of them I scrapped.
I went in as an experiment - deliberately giving the AI more latitude than I would normally allow, curious about what it could do. I was also wearing the product-owner hat: eager to get something to market, finding a tool that generated features at impressive speed. That combination is a trap. It is so easy to keep moving forward - building the next feature instead of understanding the last one. And gradually the code becomes foreign. I had been talking specs, not implementation. I had handed off something I didn't fully own.
AI has improved significantly since then. But at its core it is still the same kind of model, with the same fundamental limitations. What changed was how I worked with it. Staying in the loop. Treating it as a partner, not a delegator - something that works with me on the code, not something I direct from a distance and review at the end. That shift made the work better. It also made it considerably more fun.
That is what this talk draws from. Not theory. What actually happened, what I rebuilt, and what the difference was. I am not here to tell you whether to adopt AI. I am here to tell you what it takes to do it in a way you can stand behind.
I am more enthusiastic about AI today than when I started - but only when it runs inside a structured process, with the right context and a human who genuinely owns the outcome. That is the version I want to help your team reach.