Building Think-o-matic: A Vibe-Coding Journey with Amazon Q

We’ve all had those moments where inspiration strikes, but the traditional coding workflow — planning, scaffolding, testing, debugging — feels like too much friction.

What if instead, you could prototype with a different mindset? One that prioritizes momentum, creativity, and just enough structure to explore an idea?

That’s where vibe-coding comes in.

This unconventional approach flips the traditional dev cycle on its head. You don’t manually write every line or carefully craft a layered architecture — instead, you describe what you want, and let AI tools do the heavy lifting.

Vibe-coding isn’t about writing perfect code. It’s about describing intent, trusting the process, and shipping fast.

Vibe-coding: what it is and why it matters

This term comes out from this Andrej Karpathy’s X post, just few weeks ago, and the industry is trying to converge on a definition and to standardize it.

A few weeks later, distinguished authors are writing and publishing books about this techniuqe, just the mention some:

• Vibe-Coding by Gene Kim and Steve Yegge

• Beyond Vibe-Coding by Addy Osmani

I tried to summarize the key points of vibe-coding from Karpathy’s post.

Vibe-coding is:

• Letting AI tools write, fix, and modify the code.

• Embracing feel and flow over full code comprehension.

• Typing as little as possible — mostly just describe, accept, and run.

• Skipping diffs, skimming errors, and trusting AI suggestions.

• Supervising the AI rather than driving every keystroke.

This is not traditional coding. It’s prototyping for the AI-native era — perfect for weekend projects, experiments, or validating ideas before investing in full-scale development.

If you ever had some idea about building something on your own, it is very clear why it matters: it makes prototyping fast, cheap, and easy.

A Quick Reminder: What’s Prototyping?

In software engineering, prototyping is about:

Creating a preliminary version of a system to explore ideas, validate functionality, and gather user feedback before full-scale development.

It’s low-commitment, fast-paced, and feedback-driven — which makes it the perfect playground for AI-powered workflows.

Fast-prototyping steps:

I have tried to define some steps to structure my vibe coding sessions:

1. Have an idea: this seems obvious, but it's not. You can create something if you have an idea that is clear enough to be built and executed, but also leaves some room for exploration.

2. Set up tools: You need a toolbox that is easy to set up, quick, cheap and that you trust. In these times, I don't think it's worth spending too much time finding the perfect tools or optimizing them: Your perfect tool could be obsolete tomorrow.

3. Describe your idea: This means you tell your tools what you want to build together.

4. Follow the vibes: This step is actually an inner loop consisting of three sub-steps:

   1. describe, Accept, Execute: You ask to build something, accept and execute what you've built.

   2. check the results: Confirm what's going on and hold the wheel.

   3. determine cooperation style. From time to time, you'll need to refine the way you want to collaborate with your toolbox.

5. Enough is enough: you are building a prototype, not a product: this means you are not looking for perfection nor a complete system.

i have schematized these steps like this:

A Real Example: Building Think-o-matic

To make this more tangible, here’s how I prototyped a tool called Think-o-matic — an AI-powered copilot to help structure workshops, generate agendas, create Miro boards, and summarize outcomes into actionable Trello tasks.

Having an idea

My ideas comes out most of times from real-life problems that i can’t fix. I’m often wondering if i could build something to make my life easier, and this helps me in three ways:

First, i love build, i find it fun.

Second, i go deep in my problem understanding: if you want a solution, you have to target your problem.

Third, i got the problem solved! One less…

This is exactly what happend with Thinlk-o-Matic.

In my current job role i need to put stakeholders around a table, often virtual, and making them working togheter to target problems, find solutions and explore ideas.

In other words, i need to extract information from them, and one effective way to do this is to running workshops.

Running a workshop involves the following steps, and that is exactly what i need help on:

Between steps 3 and 4 there is the workshop run tself.

I also draft a high-level architecture of the prototype:

A front-end webapp backend by an ExpressJS server running on nodejs environment, that provides integration to miro and trello, and to Amazon Bedrock to provide “intelligence” to the system: Amazon Nova would generate the workshop agenda and summarize the Miro Board.

No deployment needed, frontend and backend app would run locally.

Set up tools

My toolbox is very easy: terminal, Amazon Q CLI (agentic) backed by Claude Sonnet 4.0. That is.

Describe your idea

I used a greatly simplified version of a technique called memory banking that I learned from this blog post from Cline.

In a few words, it’s a way to remember what's going on in the project and between you and the agent, because otherwise it would easily forget what’s going on and have to recreate the context for your agent, leaving the vibes.

Creating a memory bank helps your AI:

• Stay aligned with goals across sessions.

• Remember decisions already made.

• Reduce repetition and confusion.

In vibe-coding, memory banking becomes your anchor — keeping prototypes from drifting too far off course.

I have provided two files:

Prototype Guidelines: Instructions on what is a prototype, what is not, and how I want to build prototypes. This prompt does not refer to a specific prototype and is reusable

Think-o-matic specific guidelines: Instructions about this specific idea.

The prompt style is a mix of the Risen framework (role, input, steps, expectation, narrowing) and the Rodes framework (role, objectives, details, examples, sense check).

Again, I don't want to spend too much time on prompting, and of course I used LLMs to write my prompts.

My session started with these two files in a folder and a little prompt that went something like this:

before doing anything, read these two files and tell me what you think about. Please use the same folder to create your checkpoint files.

In this way i also instructed the agent to update the memory bank while going on with the work.

Follow the vibes + Check Results + Make friends

After this little prompt, the agent red the specs i provided and proposed me an action plan.

We agreed on the steps and to check-in with me after every step.

The first iteration result was this:

Basically the first iteration covered the working app with all integration mocked, in about 15 minutes.

What Went Well vs. What Went Weird

✅ Good:

• AI nailed the folder structure and scaffolding.

• The prototype ran with minimal setup.

• I stayed in the creative zone.

❌ Bad:

• Wrong AWS region.

• No documentation, even if i asked for.

• Laughably bad UX.

• A few silly bugs.

But that’s okay — vibe-coding isn’t about perfection. It’s about fast feedback and learning by doing.

Making Friends: Tune Your Cooperation Style

Vibe-coding isn’t autopilot. You’re not giving up control — you’re adjusting how you cooperate.

I think of this part as “making friends” with the AI. Like any relationship, it needs clear communication and trust — but also healthy boundaries.

Here’s a real example: I forgot to specify the AWS Region in a prompt. The AI defaulted to us-east-1 (no idea why). I needed a Bedrock model that was only enabled in eu-west-1. Instead of asking me, the agent silently changed the model to something available in us-east-1.

That’s when I stepped in. I told the agent:

“For small things, go ahead. But for big architectural decisions — ask me.”

That balance is key. You want the AI to be proactive, but aligned. Let it move fast — just not in the wrong direction.

The final result: think-o-matic

I worked with the agent for a few hours: We added one feature after another: Agenda creation, Miro Board creation, Miro Board summary, Trello integration.

For each feature implemented, Q updated the memory bank.

The result? You can try it out for yourself by running it locally.

Here is the github repo with the code and instructions to run it.

If you look at the repo, you might wonder why there is only one branch and one commit: I created it as a private repo and before I made it public, I searched it for secrets and found that Q wrote my secrets to the memory bank. Trust, but verify.

Final Thoughts

This is just from my own notes i took after those few hours:

Pro tip: Let the AI drift a bit. Sometimes, the best ideas emerge sideways.

Waiting for the Doom Moment

A few weeks ago, I had the pleasure of leading a roundtable discussion with Jeff Barr, Chief Evangelist for AWS and one of the most influential engineers in software engineering and cloud computing, and I asked him about the future of Gen AI. I asked, what’s next?

He responded with a story from 1992 - 1993.

in 1992, we all loved Wolfstein 3D.

Despite the name, it was not real 3D, but it was the first in-person shooter game.

A year later, John Carmack developed the Doom Engine using basically the same technology, and we were all shocked by Doom

That’s where we are with AI and prototyping right now.

We’re still building Wolfensteins.

But Doom is coming.