Treating Vibecoding Like Engineering | Thoughts by Javier

Treating Vibecoding Like Engineering

Before, I wrote about vibecoding when I was just starting out to seriously try the approach. I've been doing something that more 'serious' people are calling agentic engineering which is clearly an attempt at sounding more legitimate when doing the same thing. I have updated my thinking about this process and want to document my learning here.

The harness and its boundaries

The first time that I was able to structure a task into smaller instructions and feed that into a ralph loop, I had a moment of realization(1). Even if the tools were not there in its current capabilities, there was a clear and significant benefit as I was able to make a (slightly lower quality) version of an app that would take me probably a few days of full time work. It finished in about an hour of prompting and an hour of letting a harness run and about a $10/month subscription. I made a blog editor that used git as a back end and simplified my blog's interface significantly. Even if the code was by all intents and purposes bad, the application clunky and the UI ugly the ability to produce something remotely close to what I was able to was significant. I simply developed a prompt and handed it off to an agent, and that is revolutionary. I realized there is no way that this will not become the future for creating applications.

I give this background as the context of the next iteration of this idea. Knowing the limits of agentic engineering, the question at the current state of LLM generated code is whether we can we give the agents enough of a railway to avoid some of these issues and create something a bit more 'useful'. How far can a guardrail take this process? I started by creating a new project. I chose Go as the back end, mostly because the tooling is already there out of the box for being strict. If I am going to take this seriously, I need strict guidelines for the code that will be generated that can be analyzed statically.

The following are the guidelines that I made for my next application:

0. Provide the Scaffolding

If you tell the LLM to build a UI, it might dump a bunch of in line styles in a single html page, or make a React app, or put the entire back end in a single file, or do a lot of things that we simply don't want. Give the agent a scaffold, lean into frameworks for this and generate it before giving the agent the wheel. Don't start a blank project with a blank folder. I made this mistake once and I ended with a Node app that also used Bun.

1. Lean on Compilers, and every commit should be compileable

This is how I program, but not necessarily how the LLM does. With git, you can add a pre-commit hook that runs this out of the box. This is a fundamental step, we have decades of research, development, and practice with compilers. They are great. Interpreted languages are a liability when combined with statistical text generators, do not use them.

2. Statically Typed Languages are no longer optional

This is related to No 1, but worth repeating. If using a dynamic interpreted language, use either a superset that is typed or lean on type hints and use a linter that prevents the machine from commiting something that is not typed. This is a non-negotiable.

3. Linting and static analysis on every step.

This is  way to harden the app. Again, these first three steps are a way to superset deterministic tools to your probabilistic text generator. Use them, and use them before EVERY commit. Not by providing instructions to the LLM, which will be read most of the time, but by giving the LLM hard checks to use every time.

4. Testing, testing, testing

Every task should have a corresponding integration test that you could verify. For better peace of mind lean more on integration and e2e tests. These allow you to verify things, not just assume correctness.

5. For UI use a component library.

There are skills for making UIs, but they don't work so well. The best is to give the agent a component library and a reference document on how to use it. This makes the app feel more polished and will be easier to extend later.

6. Pieces of work should be atomic

Never tell the agent make a feature. Tell the agent let's make all the tasks for this feature, break down the plan into its constituent parts, and use an issue tracker where one issue is an atomic task. The agent WILL drift, even if the task is miniscule, but it will do so less, the smaller the task. Work with it to break down the steps.

7. One piece of work is one agent session

Here is where the SDLC can be leaned on. Epics, stories, tasks, spikes, and sprints are all still useful. You are the orchestrator for your agents. You can still have the PM agent that shapes the work in conversation with you, but the outcome of a planning session is the individual pieces of work, not the feature. Don't plan and execute in the same session, that pollutes the context. Once the...