It’s incredibly easy to get an LLM to emit just a ton of code that may or may not do what you ask. It’s not free, you still have to do the work to understand the code. Otherwise you and the LLM are just wasting time, writing something destined for the trash bin.

It is very powerful. This is a way to learn about new technologies, new techniques, and to get a lot of tech in place quickly that you have little familiarity with. It’s also easy to get lost in a muddle of broken code you don’t understand and you can’t see a way forward and the LLM is fighting your every request.

You must temper your expectations and, yes, spend more than a little time thinking to make a real project. Here’s three tips to get the most out of vibecoding a new project from scratch:

1. Get a Build Environment Working Early…

… and get it as close as possible to the LLM producing the source. Even the agentic-type tools that can work on your filesystem can do altogether too much work without every verifying anything. And if you find yourself copying, pasting, cleaning up, checking in, and deploying before you can even find problems with the build, your project is at serious risk.

Get a build working early on. Ask your LLM to add this setup info to a project readme. And then run regularly. If you’re using an agentic tool, get it to validate its own work with these commands.

Every time you get to a good spot or a worth checkpoint, use version control to save a checkpoint.

2. Be Ready to Learn a Different Way…

… and learn different things. For a scratch project you’re a manager. For something you’re well-versed in, you may be an engineering manager, helping with architecture and technical decisions. For new domains or ones you haven’t touched in even a couple years, you’re going to be closer to a product manager, and the LLM is going to be making a lot of decisions you won’t know to be right or wrong until you dig in.

You will necessarily be an outsider to this project. You will see a forest, not the trees. A couple pertinent comments on hackernews:

LLMs are exciting but they produce messy code for which the dev feels no ownership. Managing a codebase written by an LLM is difficult because you have not cognitively loaded the entire thing into your head as you do with code written yourself. (source)

you’re essentially the new guy on your own project. (source)

This 10,000 foot view and separation is not all bad. It will give you exposure to new technologies and standards. But you won’t feel like it’s yours until you start to really spend time and understand it. To pull it back into an engineer’s focus, you’ll have to learn it like a new engineer on the team. Piece by messy piece.

3. Be Prepared for a Fight…

… because the LLM will forget, forge, and gaslight you the whole way through. Do a lot of planning and discussion with the LLM and produce a simple document outlining the expected project. Then consider starting over with your finalish decisions in a new session.

In particular, in long sessions, major decisions can be randomly forgotten. Or the LLM may outright refuse to do something on the grounds that it’s a major architectural change. Or its knowledge cutoff may not have all the latest answers and it will refuse to admit, say, a version upgrade.

Plan for succession and the future of the project. When a chat or session goes too long and starts becoming eccentric, figure out a way to start again without losing all you’ve gained. Produce a strong README file and TODO list is one way. Be sure to read them carefully for accuracy.

Bonus Wisdom: Don’t Replace Existing Intelligence and Tools with “AI”

There are many tools and already-built methods of processing and extracting data. You don’t have to force an LLM to do this work. For example, find and replace has a large amount of tooling. We know how to process vast datasets with machine learning best practices and tools. Modern IDEs can extract and refactor existing code. You could ask an LLM to do these things, but it will be slower and less precise. You may just end up burning budget when a tool with a tiny footprint can do the work easier and better.

There are times where it’s just best to step in and use these tools and fix things, then get the LLM back on track doing what it’s best at.

For large existing projects on which you want to make a change, it’s often better to have your LLM make you a tool or script to operate on files, rather than try and pipe every source file through the LLM and hope it can make some sense of them all.

This concept is equivalent to the problem many early AI projects have: run customer data “through AI” and generate… something. When you could have just as easily used old-fashioned artisanal “I” to do the same at a smaller price and with better results. An LLM isn’t magic, it’s a probability-based knowledge search engine.

Coming up

I’ll continue this series with some concrete examples. Next up: using Gemini Canvas to build my Farm project. After that, I’ll switch to some other providers, maybe discuss a local agentic setup, and such.