Unpopular opinion: plan mode is still good and correct. Now that models are more powerful and do longer horizon work it's more important to be aligned up front. A dedicated plan artifact is easier to read and review than inline chat content.

Okay I'm actually kind of enjoying the AI diss track battle.

I would estimate a high percentage of all software (80%+) would be totally fine with only automated reviews. Because 80%+ of software written is relatively low risk or changes are easily reversible. AI can free us to focus on the changes that actually do need expert attention.

It used to be that incomplete software was simply missing many things that needed building. Now incomplete software has all the pieces, but the pieces are bad (i.e. slop). Finishing a project is becomes more about removing bad ideas and polishing good ones. This isn't good or bad, just different.

I'm seeing SO MUCH Jev in my feed. My theory is this: most people don't want to train models, they want to build things. So just like how LLMs broke through to the mainstream because they didn't need to be trained to be useful, such is true for Jev and classification tasks.

When AI builds an interface.

It's amazing how frequently "AI did this really stupid thing" turns out to be "I gave AI a poorly-specified prompt and it made different assumptions than I expected". Current models are (usually, not always) good at following instructions if you give them good ones to follow.

Hot take: trying to be more careful about merging AI code is the wrong long-term approach. The better approach is to eliminate one-way doors and make most code more disposable. Sloppy code can be polished/replaced so long as you keep reins on API surface and storage schema.

I genuinely think the demand for tokens is effectively infinite and is bounded only by cost constraints. We will build legions of automatons that are experimenting, tweaking, optimizing, reviewing, condensing, and making sense of the universe of information 24x7x365.

It must be nice to work in a governing body so dysfunctional that you know nothing will ever pass so there's no need to think about the consequences of what would happen if your bill did pass. Like, say, the immediate end of essentially all economic growth in America.

AI code is like water: it will slosh around to fill whatever container it's poured into. If you don't provide any constraints you're going to end up with a big mess on the floor. The new job of software engineering is to specify verification+guardrails that hold the water.

An unintuitive thing about design docs: a doc that is clearly written but wrong on the substance is a better doc than a doc that is hard to read but flawless on the substance. Design docs are communication tools to align humans. You can win at design but fail at design docs. If I come across a crisp, five-page design doc that has two major flaws in its underlying assumptions I can identify them in a 10 minute read and we can have the needed discussion. If I have to review a 35-page AI-generated treatise, I'm going to miss important details. Use AI to help you research and even draft your design docs, but your goal is not an exhaustive survey of the subject. Your goal is to distill a complex subject into its essential elements. AI can't do that well yet, so you have to.

What we need as a companion to WebMCP is WebACP that lets me bring an agent of my choosing into the browser. I don't need my agent to build a browser and I don't need my browser to build an agent. I need my agent in my browser.

The primary artifact you need during design for agent-first development is a list of invariants. "Here are the things that absolutely must be true about the final result." This will often include a mix of user-facing and architectural concerns and will often include specific API contracts, specific test scenarios and expected outcomes, etc. I haven't really found "spec-driven development" where the spec is a gigantic long document to be very useful. The spec begins to rot the moment it's written, and the codebase is the actual source of truth. But maintaining a list of invariants makes it easy to put a verification loop at the end of an implementation cycle, and is also something that is easiest for a human team to align on. I'm experimenting with design docs whose primary tab is just "here's the list of agreed upon invariants" that I might use an LLM to assist me in writing but I carefully review and edit every line to make sure I agree. Then the secondary tab is a fully LLM-owned detailed design based on the invariants + codebase investigation. If I find something wrong in the design, I can update the invariants and redo the design. I can have the design pressure-tested against the invariants and then I can also have the implementation pressure-tested against same. You do have to be careful -- you can't put anything in the invariants that you don't actually mean is invariant, or you'll wake up to twisted code contorted around a false assumption. The process ends up being: DESIGN: Invariants -> Design w/ Milestones -> Adverserial Design Review IMPLEMENTATION (for each milestone): Implement -> Adverserial Code Review Loop -> Adverserial Verification Loop

Doing crazy esoteric stuff in Go: 3 stdlib calls Doing dead basic stuff in Rust: 3 crate installs

As companies grow, they build processes that leave no room for judgment calls. The default posture becomes oriented around fear of idiot / bad-faith actors, putting a huge tax on good-faith actors who have a good reason to do something a little bit risky. It destroys velocity.

Agents' overeager coding makes us all into editors. The PR is ready not when there's nothing left to add, but when there's nothing left to take away.