They hired me to add features. The codebase had less than 1% test coverage. Azure was retiring .NET 8, but upgrading seemed too hard, so they'd waited years. The kind of problems you know you should fix but never do.

Four weeks later: 560 commits, 65% test coverage, 13 database improvements, and yes, we shipped features too. Two programmers, four hours a day, one $17/month Claude subscription.

Here's what nobody tells you about AI: Day one, it took us eight hours to fix one nullable reference. Week four, I did fifty in under an hour with five minutes of my time. We didn't get faster because AI got smarter. We got faster because we built the infrastructure—scripts, CLIs, knowledge docs—that let AI scale what we'd already figured out.

This is a field report on what's actually possible when you stop thinking "AI makes me faster" and start thinking "AI lets me solve problems that used to be too expensive to touch."

Come see how we got a codebase under control.

If everyone agrees with you, you are probably not innovating, you are conforming faster. History’s real breakthroughs did not come from consensus but from heretics, hackers, and the endlessly curious. In this talk, Michael Carducci challenges the myth of collective wisdom and explains why the crowd is almost always optimized for the past. Through stories of unconventional thinkers, from computing pioneers to magicians who redefined wonder, he reveals the recurring patterns behind genuine innovation: discomfort, doubt, and persistence in the face of disbelief.

Attendees will learn how to identify the hidden forces that suppress new ideas, trust intuition even when it runs against consensus, and nurture the curiosity and courage that fuel meaningful change. This session is a call to those who question norms and experiment at the edges, the place where all real progress begins.

What You Will Learn

Who Should Attend

Developers, innovators, leaders, and creators who challenge convention and seek to build ideas that move technology, and people, forward.

Tests are code, too, but they don't get as much attention, often leaving messy, hard to understand tests. Poorly factored tests can also make refactoring production code more difficult, resulting in even messier code.

In this session, we'll start with what we need from a good test, using AssertJ and JUnit features to make it readable and maintainable. We'll walk up the ladder from Helper methods, shared Factory Methods, all the way to Test Data Builders, discussing how and when to make the transition between them. We'll look at test "smells" and how to repair them, using Parameterized Tests. If time allows, we'll see how to "retarget" your tests when extracting a new production class from existing code.

While the code is in Java, the principles and techniques apply to most languages.