.png)
6 hours ago
1
I posted about my Cursor spend the other day and it seemed to strike a chord. Many people asked: how the f do you do it? Lots of smart people are posting about how they use AI, so I thought I’d join the fray. NB: I prefer Cursor, but the same rules apply wherever you generate code.
Sign up for the Zo Computer beta here. It’s like the early Gmail beta days! You’ll get <handle>.zo.computer and <handle>@zo.computer. It’s still pretty rough around the edges, but I promise you we’ll do amazing things together if you keep coming back. In a sense, Zo is a distillation of all the lessons we’ve learned from a lifetime of coding, and this new chapter of working with AI. It’s the interface we’ve always wanted for collaborating with AI outside the codebase.
As an engineer, I’ve always considered myself to be (a) not that skilled or knowledgeable, but also (b) hardworking and pretty opinionated on aesthetics. I always believed that wasn’t enough to really cut it as a staff engineer or IC6 or L8 or whatever you call it, so I became an engineering manager for a while. It was extremely boring! So I quit my job to become a founder. I coded a lot by hand, and I felt like I was getting better, slowly. Then I did a lot of sales calls (also extremely boring!). Then we pivoted, so I’m back to coding. But the tides have turned! The models got a lot better last fall, and all of a sudden I’m a 10x engineer.
My only secret is that you have to spend a lot. I’m being cheeky, but there’s a deep truth here. I only started using AI to code last winter, and I’ve come a long way. Even after you turn on the premium models + context, it takes a ton of practice, technique, and attention to get to these spend levels.
I believe in keeping it simple: we only have a handful of rules, and I don’t use any MCP plugins
I believe in the sanctity of having an attentive tasteful human locked in the loop. I don’t use the Cursor background agent, Claude Code, or Codex. I like to review the thinking trace in realtime. I like to interrupt the chat frequently. I don’t scroll Twitter while I wait – that would be extremely rude if you were pair programming with someone
You are a tiger mom and the success of your lineage depends on you helicoptering over your AI’s output, criticizing diffs and typing furiously into the chat until your eyes bleed and the tips of your fingers begin to feel numb*
*this actually happened to me, the tips of my right ring finger & pinky had lost sensation for a few days there but they seem to be recovering
Below is the exact content from our README on how to use Cursor effectively:
tl;dr: use the best models + maximum context + extreme planning + human LOCKED IN the loop
o3 for planning, debugging, and "underspecified spikes" (it tends to search a lot)
opus4 for everything else (high quality fast driver but tends to be overeager, so make sure it's running on well-planned guidance)
codeglish: be v specific abt impl details. make sure u type 2x faster than normal! remember ur talking to an llm: no caps min punctuation much shorthand dont correct typos
1. (required for large changes) create a `plan-<...>.rst` file
2. open all relevant files
3. in the chat type `/` to add open files to context
4. type codeglish fast + clearly (see above)
5. review + iterate on the plan
6. open each diff as it comes in, review in real-time, start queueing feedback in the chat box
4 stages of code review:
1. iterate on the plan a lot, and review with EXTREME attention before kicking off implementation. this is the MOST important part. spend an EXTRAVAGANT amount of time and attention here. for large changes i often spend 30m to 1hr in this phase. consider sharing your `plan*.rst` file in a draft PR for the team to comment on.
2. accept changes in cursor: you can skim but you _must_ understand what you're accepting. be a "tiger mom" and go back to the chat with feedback.
3. review staged changes: this is a matter of personal style, but these days because code generates itself quickly, i tend to leave a lot staged and commit fairly large logical batches of changes, making sure i've iterated to a point where tests/typechecker are satisfied. i like github desktop as my surface for reviewing at this stage. i write my own commit messages because it keeps me focused.
4. review the PR: you're going to end up with large PRs using this method, and you're responsible for reviewing them in great detail. i find the Graphite UI to be marginally nicer than GitHub (esp. for managing large diffs). if you enable the right extension in cursor, you can see PR comments, which makes it easy to "tiger mom" more feedback to the chat.
