"Vibe coding" notes
Everyone wonders how the tech world is going to look after the emergence of LLMs.
There is already a generation of programmers who have not seen the world without Cursor and its auto-complete, and "vibe coding" is an important part of their daily routine.
Who is a good engineer nowadays, and what skills should one possess? I spent some time vibe coding a web app, I have a tech background as a frontend engineer, but I have chosen technologies I've never worked with before. My main goal was to check how well an LLM can follow instructions, how well it can make tech decisions, what the main limitations are and what the human part in such type of coding is.
Project idea and initial prompt:
Idea: Create a web application that will allow users to build travel routes from the starting point to the destination point through the most interesting places of interest. User preferences for places of interest are defined by checkboxes below the form.
Simple initial prompt:
Create a web app according to the following requirements:
Functional requirements:
1. It should consist of one page which includes:
- 2 form fields on the top (from and to)
- 1 button to submit the form
- Map below the form
- Time, distance below the map
2. Fields should work as autocomplete for origin and final locations.
3. The map should use the Mapbox Directions API to show the route between two locations.
4. Directions are available only for cars.
5. Directions are available only for USA locations.
6. A marker of a location should be a cat icon.
Technical requirements:
- Use Svelte
- Use GraphQL
- Use Mapbox GL JS
- Use Gemini 2.0 flash
- Use Mapbox Directions API
It took me 3 attempts and about 16 hours to finally come up with a simple MVP. I bet it can be faster for those who have already tried "vibe coding", but it took me some time to identify the best approach.
Before sharing the observations, I wanted to mention that you can find a fully working project by following this link: Vibe maps.
You will need to add your own Unsplash and Gemini API keys to check its work (they are free).
These are some screenshots from the app:
Insights
So here are the main insights I've obtained:
① You can not skip the planning phase if you want to create a good quality solution.
It's ok not to give it much thought until you are going to scale or it is a relatively small project or feature. Otherwise, LLM will create a chaotic structure that will be difficult to maintain.
② The more details, the better!
Define as many rules and requirements as you can:
- architecture
- technologies used
- design
- functionality in details
- external services
- documentation requirements
- performance requirements
③ Keep an eye on unused, legacy code.
After several iterations, LLM can rewrite the initial version of the implementation in favour of the better one but leave legacy code in a codebase.
④ Check all features that are intended to use external services are actually using them.
Interestingly, LLMs prefer to mock requests or simulate interaction with external services.
⑤ Provide examples where possible.
LLMs are good at mimicking, and the result will be more likely to
meet expectations.
⑥ Break everything down into small clear steps; otherwise, LLM can mess it up.
⑦ Save every successful step. The next one can ruin everything :)
⑧ Human guidance and verification are necessary.
Some generated code can be obviously unoptimal or require a better algorithm. So my experience is based on coding in JS, which is quite popular. LLMs are more likely to produce better code in JS than C++.
The working solution can be generated, but in order to scale and make it production-ready, human agency is a must-have.
The easier LLMs make coding, the harder it is to dive deeper into the details. I believe engineers will still require all the same skills: good language understanding, system design, ability to orient in modern tools. Code review might become a must, as all the code LLMs produce should be reviewed now.
My feeling is that "vibe coding" can be used to adapt some small features quickly and with human guidance in order to minimise the risk of errors that it might make due to the lack of context. It can also be used for the initial structure, configurations, and foundation to build upon. But for now I would use LLM as a smart assistant for brainstorming or breaking up difficult concepts rather than a full member of the team.
Tools used:
IDE: Cursor in agent mode
Model: claude-3.7-sonnet
External APIs: