Notes — Michael Truell on Cursor and the World After Code

Four questions [Adler frame]

Q1 — What is it about?
A CEO-level thesis on what programming looks like after formal languages, grounded in Cursor’s product development experience. Central argument: software engineering is transitioning from imperative code-writing to intent specification; engineers become logic designers; taste replaces carefulness as the irreplaceable skill.

Q2 — How is it argued?
By contrast with two wrong futures (nothing changes; chatbot Slackbot), Michael positions a third path: a terse, human-readable logic representation that evolves from code toward pseudocode. Supported by: Cursor’s unexpected journey into custom model development (“every magic moment involves a custom model”); the origin story of observing insufficient ambition in the space; the historical analogy to search in 1999. Practical grounding via the “chop things up” usage pattern and the junior/senior anti-pattern observation.

Q3 — Is it true?
The “logic designer” thesis depends on models improving to the point where intent specification is sufficient and the pseudocode-to-executable translation is reliable. The current state of vibe coding (creates things you cannot maintain) illustrates the gap. Michael acknowledges this is not the end state but a direction. The custom model ensemble is verifiable — Cursor’s performance in autocomplete and multi-file prediction is empirically differentiated. [?] The specific timeline for “world after code” is unspecified.

Q4 — What of it?
For product builders: the world after code is a product design problem as much as a model problem — the interface that makes intent specifiable without formal language is unsolved. For engineers: the “chop things up” pattern is immediately applicable; the taste thesis suggests investing in design sensibility and domain understanding, not just coding speed. For wiki synthesis: this is the most precise formulation of the Vibe Coding → Agentic Engineering trajectory in the wiki.

Glossary

World after code — Michael’s vision for programming’s future: software logic is represented in a terse, human-readable pseudocode-like form that humans can edit directly, rather than imperative code in formal languages. Distinct from both “nothing changes” and “chatbot Slackbot” visions.

Logic designer — Michael’s term for the post-code engineer role: someone who specifies the intent, logic, and behaviour of software at a high level, rather than writing the low-level implementation. Analogous to how architects specify buildings without laying bricks.

Chop things up — the iterative AI coding usage pattern: specify a little → AI produces a little → review → repeat. Contrasted with waterfall AI (giant spec → large output → accept or reject). Most successful Cursor users today use this pattern.

Autocomplete layer — Cursor’s fully custom model layer that predicts the next set of code diffs the user will make, within 300ms, on every keystroke. Task is diff completion (not generic next-token completion).

Retrieval layer — Cursor’s custom model layer that searches a codebase to find the relevant sections to show a large foundation model. Described as “a mini Google search” for codebases. Sits on the input side of the large model.

Sketch-to-diff layer — Cursor’s custom model layer that takes a large model’s high-level sketch of code changes and fills in the full executable diffs. Sits on the output side. Combines large-model reasoning quality with small-model execution speed.

Model pragmatism — my term (not Michael’s) for Cursor’s approach: not trusting foundation models to improve fast enough for all sub-tasks (cf. Model Maximalism), but training custom models where foundation models are too slow, too expensive, or misaligned with a specific task.

The world after code [§ The world after code]

The dominant visions in the popular consciousness are: (1) formal code editing remains central; (2) chatbot-style requests to an AI engineering department. Michael’s critique of (2): it lacks precision. Humans need to gesture at changes in a form factor that is more precise than “change this about my app” in a text box removed from the code.

The third vision: a representation of software logic that is terse, human-editable, and closer to English than to TypeScript. Not vague natural language, but something between pseudocode and a high-level programming language — a form that makes logic comprehensible without being impenetrable.

This is specifically framed as going through professional engineers, not around them. The transition is gradual. The human stays in the driver’s seat.

Connection to Vibe Coding: vibe coding is the messy present (generate and iterate, don’t understand details). The world after code is the end state (the representation is designed to be comprehensible, so you do not need to understand what’s underneath). Michael explicitly says the lack of control over vibe-coded software is a product design problem Cursor intends to solve.

Taste and the logic designer [§ Taste as the post-code skill]

Carefulness — the ability to get implementation details right without errors — is currently the most important software engineering skill, and the hardest to develop. In the world after code, models handle the implementation details, so carefulness becomes automatable.

What remains irreplaceable: taste — having the right idea for what should be built, how the logic should work, what the interaction should do. This is not primarily visual/aesthetic taste but functional taste: the ability to specify correct, useful behaviour at a high level.

This resonates with Karina Nguyen on Model Training and AI Product‘s claim that soft skills (aesthetics, management judgement) outlast hard technical skills as AI automates hard skills first. Michael’s “logic designer” is Karina’s “soft skills last” applied specifically to software engineering.

Custom models and the ensemble [§ Cursor’s model stack]

The counter-intuitive finding: Cursor did not plan to do model development. The calculation showed pre-training from scratch was infeasible. But as product development progressed, custom models kept being the differentiating factor.

The ensemble architecture:

Autocomplete: fully custom, no foundation model. Task specificity (diff completion) + speed/cost requirements make this impractical for any foundation model.
Retrieval: custom model on the input side of the large model. Solves the context window curation problem.
Sketch-to-diff: custom model on the output side. Translates a large model’s efficient sketch into executable changes.

Each layer addresses a specific weakness of relying on foundation models alone: speed, cost, task alignment, and context quality. This is operationally the most detailed description of a production AI ensemble in the wiki.

Key principle: “picking your spots carefully, not trying to reinvent the wheel” — focus custom development on foundation model weaknesses and task-specific gaps, not on replicating what the best foundation models do well.

Chop things up [§ Chop things up]

Observation from Cursor’s user data: the most successful power users adopt an incremental pattern rather than a waterfall pattern. Junior engineers tend toward over-reliance (go too wholesale, accept too much AI output). Senior engineers tend toward under-reliance (stick to existing workflows, underestimate what AI can do).

The right pattern today: small task specification, immediate AI response, immediate human review. This is not a limitation of vision; it is a calibrated response to current reliability levels. As reliability improves, the iteration loop can expand.

This aligns with Agentic Engineering‘s framing of the engineer as orchestrator: the role is not to write code but to specify, review, and direct. The question is not whether to use AI but how tightly to loop the human review.