Weve 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?
Thats where vibe-coding comes in.
This unconventional approach flips the traditional dev cycle on its head. You dont 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 isnt about writing perfect code. Its 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 Karpathys X post, just few weeks ago, and the industry is trying to converge on a definition and to standardize it.
Few weeks later, distinguished authors are writing and publishing books about this techniuqe, just the mention a few
I tried to summarize the key points of vibe-coding from Karpathys 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. Its 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: Whats 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.
Its 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:
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.
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.
Describe your idea: This means you tell your tools what you want to build together.
Follow the vibes: This step is actually an inner loop consisting of three sub-steps:
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, heres 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 cant fix. Im often wondering if i could build something to help me, 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 taget you 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 itself.
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.
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, its a way to remember what's going on in the project and between you and the agent, because otherwise it would easily forget whats 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 was 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 thats okay vibe-coding isnt about perfection. Its about fast feedback and learning by doing.
Making Friends: Tune Your Cooperation Style
Vibe-coding isnt autopilot. Youre not giving up control youre 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.
Heres 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.
Thats 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 two hours:
| do | don't |
|---|---|
| State clear goals | Over-engineer |
| Define wont do | Forget the code exists |
| Use memory banks | Ask for endless validation |
| Work in small chunks | Force AI to stick to one approach |
| Create checkpoints | Ignore drift, it happens! |
| Tune your cooperation style | Expect the AI to guess your intent |
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, whats next?
He responded with a story from 1992 - 1993
in 1992, we all loved Wolfstein 3D.
Despite the name, it was not real 3D, and it was the first in-person shooter game.
A year later, John Carmack developed the Doom Engine using the same technology, and we were all shocked by Doom
Thats where we are with AI and prototyping right now.
Were still building Wolfensteins.
But Doom is coming.
Top comments (0)