Every conference has AI talks right now. Most of them are either a demo of how fast you can generate a to-do app, or a warning about how it's all going to fall apart. Neither one helps you on Monday, when you have real work, a real codebase, and a tool on your machine that will confidently write a hundred lines of anything you ask for.

So I did the boring version of the experiment. I had an actual problem: years of digital photos and video scattered across drives in no discernible order. I built a real .NET utility to fix it, leaning hard on AI assistance. Then I shipped it, used it on files I genuinely could not afford to lose, and kept notes the whole way.

In this session we'll go through that project honestly. Where the AI was legitimately faster than I would have been, and why. Where it produced code that looked completely correct and was subtly, dangerously wrong, the kind of wrong that only shows up when you point it at ten thousand irreplaceable files. We'll look at real diffs: what I accepted, what I rewrote, and what I deleted without reading twice.

From there we'll get to the part that actually matters, which is the review discipline. Reviewing AI-generated code is a different skill than reviewing a teammate's pull request. Your usual signals are gone: there's no author intent to ask about, no hesitation in the naming, no rough edges where someone wasn't sure. It's uniformly confident, which means uniformly plausible, which means you have to verify rather than skim. We'll cover concrete techniques: writing the test first as a specification, constraining scope so output stays reviewable, treating destructive operations as a special category, and knowing which kinds of problems to simply not delegate.

Whether you're already using these tools daily or still deciding how much rope to give them, you'll leave with a practical approach for getting real value without shipping something you can't defend in a postmortem.