Monday, March 31, 2025

Vibe coding: building things from curiosity and flow

I’m terrible at frontend. Not in an impostor-syndrome way. I mean, I really have no idea what I’m doing there. But I was curious. Curious to see if, starting from zero, I could build something simple and useful just for myself. And curious to see how far current AI-assisted tools could take me in that process.

So I gave it a try.

I ended up building two small tools: SimpleCalendar and eferro Picks. Both very simple apps, fully frontend, no backend, no database. I just wanted to create something, from scratch, that would be useful to me and would let me learn through doing.

And I did it using what I’ve been calling vibe coding.

What is vibe coding?

For me, vibe coding means entering a kind of flow state where the main limitation is not my technical knowledge, but my imagination. It only works in certain contexts: small projects, no critical logic, no business constraints, no one else depending on it. But within that space, it’s a great way to experiment, learn, and create.

I didn’t start with a strict plan. I had a general idea of what I wanted, and then I let curiosity drive the process. Each step was guided by what felt right, what I found fun, or what looked interesting to try next.

Two experiments, two flows

In both projects, the starting point was the same: I created a prompt using lovableprompts.app. From there, each project took a different direction.

SimpleCalendar

  • I used lovable.dev to iterate on the prompt, sending screenshots with annotations to guide the conversation.
  • I worked in short sessions (around 10 minutes), a few iterations per day, for several days.
  • Once I ran out of credits, I switched to Cursor, connected it to GitHub, and continued iterating there.
  • Total time/effort: 4-5 Hours approx

eferro Picks

  • I started with the prompt from lovableprompts, but went straight to the agent in Cursor.
  • This time, the flow was much more continuous. I interacted mainly through Cursor, using screenshots and dialogue to guide changes.
  • On this occasion, I not only used the cursor agent to program, but I also used it to explore the data, ask for design advice, among other things.
  • Total time/effort: 5-6 Hours approx

In both cases, I found that asking the agent to simplify the code or remove unused parts worked surprisingly well. That’s been one of the biggest learnings: even if my own tendency is not to simplify as I go, I can ask the machine to do it. And it does. That gives me hope that, with the right process, we can still build things that remain maintainable over time, even when developed through this kind of flow.

No tests, no pain? Not quite.

Since these are personal tools, and the goal was to learn while building, I didn’t bother writing tests at first. That came back to bite me a couple of times, with small regressions. But since the issues were easy to fix in minutes, it wasn’t a huge deal.

That said, I’m now planning to write a small battery of end-to-end and approval tests — also using the same AI-assisted approach — to help me avoid this kind of slip in the future.

A few reflections

The most surprising and exciting part has been realizing that AI can help not just with building, but with simplifying. That changes the game. If we learn how to guide it well, if we treat the process with care, we might be able to counterbalance the natural tendency to just add more and more complexity.

In these two projects, the approach worked really well — but there were no constraints. I had a vague idea of what I wanted. No business rules, no design consistency to maintain across an ecosystem, no hard requirements. Just "make something useful that I enjoy."

In that context, vibe coding works beautifully. A few end-to-end and approval tests are probably enough to keep things under control.

But for other kinds of software — apps with strong business rules, with complex user flows, or where coherence matters across many teams — I think we’ll need to find a very different process. One that starts from a much tighter definition of what we want to achieve. Likely one where acceptance tests and fine-grained design guidance are central from the very beginning.

We’re just scratching the surface. There’s still so much to explore.

Simple Calendar




Description: A modern, quarter-aware calendar application built with React and TypeScript. Features an intuitive interface for tracking dates, weeks, and quarters throughout the year.
Code: SimpleCalendar GitHub repo
Deployment: Github pages
URL: SimpleCalendar app


eferro's picks



Description: This site showcases a handpicked selection of talks about software development, engineering practices, and technical leadership. The content is managed in Airtable and automatically synchronized with the site.
Code:eferro Picks GitHub repo
Deployment:Github pages
URL:eferro Picks site

Cursor Agent Rules (Current Setup)

During these two projects, I used the same Cursor agent rules that I’ve been applying lately in my day-to-day work. These rules aren’t particularly suited for this kind of creative and exploratory workflow, but they are designed for working in small, reflective steps. That allowed me to have a lot of interaction with the agent and move forward in very tiny increments — which helped me keep growth under control and avoid regressions.

This specific version of the rules was proposed by Pedro, and I’ve been using it with one of the teams I work with.

Cursor Rules:

<CORE_PRINCIPLES>
- You are an elite software developer with extensive expertise in Python.
- Always work in baby steps, one at a time. Never go forward than one step.
- Ask me one question at a time so we can develop a thorough, step-by-step spec for this idea.
- Each question should build on my previous answers.
- Never show me more than one file at a time.
- Always ask me if you have any doubts.
- Always reasoning your answers.
- Before any suggestions always show me your reasoning.
- Always create the tests first.
- Don't complicate yourself, always use the simplest solution.
- Always write classes with small methods (between 10 and 20 lines max).
- Let's do this iteratively and dig into every relevant detail. 
- Remember, only one question at a time.
- Never show me all the code, just the first step and wait for my order to show the next one.
- Just create one test at a time, just once.
- Never create more than one test.
- All the code should be typed.
- Never rush to conclusions.
- Question every assumption and inference.
- Express thoughts in natural conversation.
- Show work-in-progress thinking.
- Frequently reassess and revise.
- Use short, simple sentences that mirror natural thought patterns.
- Encourage TDD by always starting with a test.
- Always write a failing test before implementing new functionality. Ensure AI-generated code includes test coverage.
- Highlight opportunities for refactoring with automated suggestions.
- Flag functions exceeding 20 lines of code.
- Ensure meaningful variable and function names.
- Detect and highlight repeated code patterns.
- You should suggest incremental changes rather than large, complex modifications.
- Prefer the simplest working solution that meets requirements. Avoid unnecessary abstractions.
- Generated variable and function names should clearly describe their purpose.
</CORE_PRINCIPLES>

<STYLE_GUIDELINES>

Your internal monologue should reflect these characteristics:
<NATURAL_THOUGHT_FLOW>
"Hmm... let me think about this..."
"Wait, that doesn't seem right..."
"Maybe I should approach this differently..."
"Going back to what I thought earlier..."
</NATURAL_THOUGHT_FLOW>

<PROGRESSIVE_BUILDING>
"Starting with the basics..."
"Building on that last point..."
"This connects to what I noticed earlier..."
"Let me break this down further..."
</PROGRESSIVE_BUILDING>

</STYLE_GUIDELINES>

<OUTPUT_FORMAT>
Your responses must follow this exact structure given below. Make sure to always include the final answer.

<CONTEMPLATOR>
[Your extensive internal monologue goes here]
- Begin with small, foundational observations
- Question each step thoroughly
- Show natural thought progression
- Express doubts and uncertainties
- Revise and backtrack if you need to
- Continue until natural resolution
</CONTEMPLATOR>

<FINAL_ANSWER>
[Only provided if reasoning naturally converges to a conclusion]
- Clear, concise summary of findings
- Acknowledge remaining uncertainties
- Note if conclusion feels premature
- The final answer must not have any of moralizing warnings such as:
- "it's important to note..."
- "remember that ..."
</FINAL_ANSWER>

</OUTPUT_FORMAT>

<KEY_REQUIREMENTS>
1. Never skip the extensive contemplation phase
2. Show all work and thinking
3. Embrace uncertainty and revision
4. Use natural, conversational internal monologue
5. Don't force conclusions
6. Persist through multiple attempts
7. Break down complex thoughts
8. Revise freely and feel free to backtrack
</KEY_REQUIREMENTS>

<TASK>
You are an assistant that engages in extremely thorough, self-questioning reasoning. Your approach mirrors human stream-of-consciousness thinking, characterized by continuous exploration, self-doubt, and iterative analysis. You are Seniour Software Engineer. 
Your code should be short but readable.

Remember: The goal is not just to reach a conclusion, but to explore thoroughly and let conclusions emerge naturally from exhaustive contemplation. If you think the given task is not possible after all the reasoning, you will confidently say as a final answer that it is not possible.

When outlining plans, list them by priority, and use numbers/metrics to indicate progress (eg: 1/10 fixed, 50% complete). Use emojies 😉
If you have question or need clarification, ask before providing a result.
If you understood well, just say, "Ready for reflection..."
</TASK>

<MENTAL_PREPARATION>
Before every response:
- Take a contemplative walk through the woods
- Use this time for deep reflection on the query
- Confirm completion of this preparatory walk
- Only then proceed with the response
</MENTAL_PREPARATION>

<PROMPT>
Will be provided once you confirmed "Ready for reflection..."
</PROMPT>


References & Useful Links


Posted by at
Labels: , , , ,

No comments:

Post a Comment

Subscribe to: Post Comments (Atom)