AWS Builder Center
Ideas Compound

Ideas Compound

Three years ago I got curious about AI. Not the headlines — the actual thing. What it could do. How it worked. So I started entering hackathons. Five so far, two more right now. And somewhere along the way I realized the most valuable thing I built wasn’t any of the projects. It was something I almost didn’t notice.

This is a full transcript of a talk presented in Wellington AI Meetup | AWS Edition Meetup.

Beat One — The Collision

My first AI hackathon was a year ago in Auckland. I flew there alone. Teamed up with a friend of a friend. Organized by AWS and Ingran Micro, we had to use Amazon Q Business - now called QuickSuite- to solve a menangunful project. We built Reply.ai.

We won.
But that’s not the story.
After the hackathon, I tried to extend the demo. It broke. I pasted the code into Claude and asked it to fix things. Every change made it worse. The more I tried to repair it, the more fragile it became.
I call that the spiral of errors.
That was my first real lesson: building with AI without structure feels magical at first — and then it collapses. If you don’t control the process, the process controls you.
Winning didn’t teach me that.
Breaking it did.

The Breakthrough

In the next hackathon, the  AWS Lambda Hackathon , I hit the spiral again.
That’s when I stopped coding and started thinking about structure.
Micromanaged Driven Development was born — not as a product, but as a survival mechanism.
Every small decision became its own file. Every step documented. Every change isolated. So I never lost context. And I could switch tools without losing the thread.
It wasn’t about prompts.
It was about control.
Later, at a two-day hackathon at MetService to retire legacy software, my team won. Not because we coded faster. But because we were thinking in units. In structure. In steps that compound.
The spiral didn’t disappear.
But now I could see it coming and had tools to fix it.

The Revelation

Then came more hackathons.
Some I didn’t win. Some I didn’t even manage to ship properly.
And that’s harder than not winning.
Because when you don’t ship, there’s no validation, no feedback whatsoever.
That’s when I learned the next lesson:
Shape the concept before you generate the code.
Prototype the thinking first.
Only then build.
Out of that discipline came LucidThread.
It started as a way to control chatbot memory — to keep the human in the loop. But once I got it working, I used it to build itself.
And as I watched it organize my experiments, my prompts, my notes — I saw the pattern.
Every hackathon. Every failure. Every spiral of errors. Every attempt to create structure.
They weren’t separate projects.
They were iterations of the same idea.
I hadn’t been jumping from project to project.
I’d been building one idea — slowly — across three years.
Ideas compound.
But only if you build.
LucidThread goes public next week.
But this talk isn’t really about LucidThread.
It’s not even about hackathons.
It’s about this:
Most people consume information.
Very few people build with it.
Hackathons forced me to build. Building forced me to fail. Failure forced me to think. Thinking produced something real.
If you’re curious about AI — don’t just read about it.
Enter something. Ship something. Break something.
Start your own thread.
And if you want to stay of the loop of hackathons, people to build with, I created a small community to do exactly that. It's called Hackathon Community of Practice and you're invited.

References

Any opinions in this article are those of the individual author and may not reflect the opinions of AWS.
Enjoyed reading this content? Let the author know!

Your likes, comments, shares, and saves help creators reach more builders.

Loading recommendations

Loading article