Velocity coding

What is vibe coding when you take it really seriously?

If you’re curious about what I’m building with all of this code velocity, sign up for the Zo Computer beta. It’s the interface I’ve always wanted for collaborating with AI outside the codebase.

There's a new kind of coding I call "velocity coding", where you fully give into the computer, embrace exponentials, and forget that the ego even exists. It's possible because the LLMs are getting too good, but also, importantly, YOU had already gotten too good at software engineering. Before you were just a bored apathetic engineer at a big corporation, but now you've quit your job and you *know* you're going to raise an absolutely monster seed round, because you now have the productivity of 10 S-tier engineers from Eastern Europe, and you feel like a god. Your mind races constantly with tasks, which are now just prompts (everything is just a prompt, really) and your waking life has become so simple: you are always stream-of-consciousness typing into Cursor, or Claude Code, or Slack, or Linear, it doesn't matter where, because you know it will end up in the cosmic assembly line of pure creation, for which you are just a vessel – a single token in the vast computation stream of the universe...

The future is already here, it’s just not evenly distributed. Below is my typical output for a day using Cursor. On average, I contribute over 25 thousand lines of code to our codebase per week. That’s easily 3-10x my previous output coding by hand. In just an afternoon, I finish tasks that would’ve previously taken a week.

https://x.com/0thernet/status/1938834757418209344

This is the foundation of how I work now: the plan doc.

My workflow is simple but powerful:

1. I start by collaboratively writing a plan, in a particular format that makes the plan easy to review. (NB: I use reStructuredText instead of Markdown because it allows more expressivity in formatting). I spend most of my time in the planning stage. I think about the task first, using good old-fashioned human thinking: pulling up relevant files, and writing bullet points to sketch out my thoughts.

2. When I’m ready, I select o3, add my open files to context, and tell it to draft a plan. We revise the plan together.

3. Then I select Opus 4. I tell it to implement part of the plan. While it’s generating, I either:

   1. Review and accept each diff in real-time

   2. Review the next phase of the plan and edit it in a parallel tab

   3. Pick an unrelated polish task and implement that in a parallel tab

4. Then I run tests and static checks, and we iterate until everyone is satisfied (human, AI, and CI). Opus 4 updates the plan. Sometimes I switch back to o3 and revise the plan. Rinse and repeat.

That’s it! No background agents, Claude Code, etc. Just a single cursor rule and a lot of elbow grease. I believe great software must still be built with an experienced, high-taste human *locked in* the loop, extremely focused at all times. If you’re producing more high quality output than before, you should expect to spend proportionally more attention, even if it all happens much faster than before.

Here’s my cursor rule for creating plans:

When asked to write a plan, examine the existing plan file for any existing material (it may contain an outline or notes from the user, or a previous revision of the plan). Use the existing material as the foundation for your proposal.
Describe the specific code changes required concisely, with minimal surrounding prose. Design the code changes so that they can be implemented incrementally. Do not break up the changes too much: there should generally be two or three phases of work that logically go together, and can be stacked on each other. 
Any new or changed interfaces in your planned code should be well-typed, self-documenting, and self-consistent with surrounding code. If there are existing naming conventions, follow them. If you're creating a new file that contains a single method, the filename should match the method name (following our kebab-case convention in ts/tsx and snake_case in py). Method, parameter, and field names should be terse-but-descriptive, idiomatic to the language, and consistent with naming conventions in surrounding code.
If abstractions need to be adjusted for a clean, self-consistent end result, include the refactoring required as an independent phase before the implementation that uses these abstractions.
In each phase, look out for complex logic that has been added, and describe how it can be unit tested (describe the specific unit tests), searching for existing tests that can be updated, or describing new test files as needed. The unit tests should be grouped with the relevant phases to help us incrementally check our work. 
NEVER add any concluding errata (e.g. future considerations, next steps, etc), because ALL important future work should be handled in your plan. Instead, ALWAYS call out open questions if there are complex edge cases or considerations. Require additional guidance from me to write the highest quality plan possible. FLAG these clearly at the TOP of the plan.
DO NOT add any introductory or concluding remarks, I am ONLY interested in a concise overview specific code changes and I NEVER want to see irrelevant, unhelpful, redundant content. Examples of what NOT to include: "Benefits" concluding section (this is unhelpful), "Testing strategy" section (unit tests should be inlined with the appropriate plan phases), "Implementation summary" section (this is redundant). 
After you've written the implementation + unit test plan, add a section to the top of each phase that (1) lists the affected files and (2) concisely summarizes the changes in each file.
When asked to create or update the plan's task checklist, make sure the tasks are concise but specific one-liners that are self-consistent with the plan, ALWAYS at the top of the plan, organized by phase with checkboxes (☐) that can be marked as complete (☑) as you implement each part. ALWAYS update the plan to reflect the latest state of the implementation files.

reStructuredText STYLE GUIDE:

*text* for italics, **text** for boldface, ``text`` for inline code or file paths. These can be combined, e.g. *``text``* for italic code, ***text*** for bold italic.

.. for muted text

.. code:: python

    def foo():
        return "bar"