Keep the Programmer in the Driver's Seat: Cursor's Founders on Tab, Agents, and Zero-Entropy Editing

Lex Fridman opens with a deliberately blunt question for Cursor's four founders — Michael Truell, Aman Sanger, Sualeh Asif, and Arvid Lunnemark: what is a code editor even for? Michael's answer is practical. For a long time the editor has been the place you build software by text-editing a formal language, which, for non-programmers, is a souped-up word processor. Code has structure, so the tool can do things writers never got: syntax coloring so you can scan, hyperlink-style jumps to definitions, and basic error checking.

He is careful not to freeze that definition. What a code editor *is*, he says, will change a lot over the next ten years, because what it means to build software may start to look different. The point of the product is not to preserve today's text box. It is to stay the place where software gets made as that act itself mutates.

Arvid adds a criterion the team uses as a kill switch: a code editor should be fun. A lot of things they build, try, and then throw away fail that test. Fun, in their shop, is tightly coupled to speed. "Fast is fun," he says, and the group treats it as T-shirt material. Michael notes that what draws people to computers in the first place is insane iteration speed: you and the machine, no waiting on a committee, building something cool quickly.

All four founders started as pure Vim users — Vim and a terminal, not even Neovim. The break was GitHub Copilot in 2021. Aman wanted to try it, and the only editor that had it was VS Code; the Copilot experience was good enough that he never really went back. Lex compares a good completion to a close friend finishing your sentences: when it gets you, the feeling is addictive, and when it misses you delete and type. Arvid's underrated point is that a miss is cheap. Type one more character and the suggestion regenerates. Sualeh goes further: Copilot was the first real consumer product for language models, the first killer app that took them out of papers and demos.

Cursor's origin, Michael says, sits on the 2020 OpenAI scaling-laws papers: predictable gains from more compute and more data, even without new ideas. Theoretical conversations about knowledge work became concrete in two moments — playing with Copilot's beta, then getting early access to GPT-4 at the end of 2022. The jump in capability made earlier point solutions (tools for finance people in Jupyter, static analysis experiments) feel too small. If they were being consistent, *all* of programming was going to flow through these models, which demanded a different environment, not a plugin bolted onto the old one.

Sualeh tells the story that, inside the group, still reads as a character test. In June 2022, Aman and Sualeh's roommate Shengtong — an IMO gold medalist — bet that by June or July 2024 models would win IMO gold. Arvid and Sualeh had both competed; Sualeh's reaction was that Aman was delusional. He now says he was very wrong. DeepMind's later system came one point short of gold. Aman's enthusiasm had a costume: a scaling-laws T-shirt with the charts on it. He also caveats the bet. Math, especially formal theorem proving, is a domain with a clean verifier, so you can get superhuman math without AGI.

Forking VS Code was, to them, self-evident. As a plugin you do not control enough of the editor, and they expected capabilities to rewrite how software gets built. Aman frames AI programming as unlike earlier tech waves: every model jump unlocks a new wave of features, so being months ahead makes the product much more useful. "The Cursor a year from now will need to make the Cursor of today look obsolete." Microsoft has done fantastic things, he says, but is not in a great place to keep running the research and experiments that raise the ceiling. Sualeh's version is personal: they were building it for themselves, watching models get better while Copilot felt stale — "where's all the alpha features?" Arvid's organizational edge is that the person making the UI and the person training the model sit about 18 feet apart, and are often the same person.

Michael boils current Cursor down to two jobs. One is looking over your shoulder like a fast colleague and jumping ahead of you — not merely completing characters after the cursor, but predicting the next entire change, the next diff, the next place you will jump. The other is the reverse: you jump ahead of the AI with instructions and go from intent to code. Both need to be ergonomic, smart, and fast. Sualeh says they wanted a model that could *edit* code, not just fill blanks, and it took multiple attempts before they had one that was actually good at it.

The jump-to-next-edit idea came from a feeling after you accept a change: the next place is often obvious, 18 lines down. A Vim user could type `18jj`; why should a human count? So you press Tab, it jumps, shows the next edit, and you Tab again. Internally there was a competition: how many Tabs can we make someone press? The abstraction is zero-entropy editing. Once the intent is determined, the remaining characters carry no new bits — you are just teaching the computer what you already mean. The model should read your mind and tab those bits away.

Aman supplies the modeling intuition. Bits-per-byte loss on code is lower than on natural language, so many tokens are already predictable; predicting the user's next *edit* to existing code is more predictable still. The goal of Cursor Tab is to eliminate low-entropy actions inside the editor and jump you forward in time. The near-term list is ambitious: generate and edit across lines, jump inside a file, then across files, then suggest a terminal command, then even take you to a definition so you have the knowledge to verify the next completion. Programming is a weird discipline, Michael notes, because the next five minutes are sometimes predictable from what you just did.

The systems work is what makes that feel instant. The task is extremely prefill-hungry and generates few tokens, so they train small mixture-of-experts models rather than throwing a frontier model at every keystroke. Prompts have to be cache-aware, or every keystroke would rerun the whole context and melt the GPUs. They also built speculative edits, a cousin of speculative decoding: instead of a tiny draft model, the prior *is* the code already on screen. Feed original chunks back in; the model usually agrees and those lines process in parallel until it diverges, generates the new tokens, then speculates again. The UX bonus, Sualeh says, is that the rewrite streams, so you start reviewing before a loading spinner would have finished.

Lex latches onto Cursor's red-and-green diff UI: suggestions in the buffer, Apply in the chat, accept or reject. Sualeh says they will probably ship four or five kinds of diffs, because autocomplete (eyes locked on one spot) is not the same problem as reviewing a multi-file change. The current side box is already the survivor of several failed attempts. An early version used Google Docs-style strikethrough plus new code, which was wildly distracting. The next asked you to hold Option: a blue highlight hinted that the AI had a suggestion, hold to see it, release to return to your code. Lex's objection is the whole UX in one line — "you have to know to hold the Option button."

Arvid names the deeper issue the verification problem. Diffs are fine for small edits; for large or multi-file changes, line-by-line review becomes prohibitive. One idea is to split high-information hunks from low-entropy repetition, highlighting the first and greying the second. Another is a model that looks at the diff, suspects a bug, and drops a red squiggle on the part you should actually read. Current diff algorithms, he says, are ordinary algorithms: intelligence went into designing them, but at runtime they do not care what the change *means*. You want a model to guide the human through what they need to read and nothing more.

Sualeh pushes the timeline: models will propose bigger and bigger changes, which means humans do more and more verification, and he does not want to spend all his time reviewing code. GitHub-style PR review is the obvious template and a bad one. Aman says code review "kind of sucks" — you grok unfamiliar code and still miss bugs — and it was designed for two humans. When the author is a language model, you can ignore the author's feelings and rebuild the whole experience around the reviewer. Ordering matters too: PRs are read top to bottom, but the logical order is different, and the model should walk you through it. Arvid does not think all programming becomes natural language. Sometimes the easiest way to tell a pair is to grab the keyboard and show an example; sometimes you drag UI around. Natural language will have a place. It will not be how most people program most of the time.

Lex remarks that the editor feels thick with machine learning underneath. Aman describes an ensemble: frontier models for reasoning-heavy work, custom models for the jobs those giants still botch. Cursor Tab is one example, where a specialized model can beat frontier models on their own eval. Apply is the unglamorous other. Frontier models are good at sketching a change and bad at emitting a precise diff — they mess up "stupid things like counting line numbers," especially in huge files. Cursor lets the big model draw a rough block, then trains a model to apply that sketch onto the file. Sualeh's punchline: contrary to popular perception, merging suggestion and original is not a deterministic algorithm. Shallow copies that try matching fail at least 40% of the time and ruin the product. Apply has a second payoff: the expensive model emits a tiny sketch, and cheaper models implement it — a pattern Aman expects to deepen, with something like o1 writing a high-level plan that is recursively applied.

Asked whether GPT or Claude wins at coding, Aman refuses a single champion. No model Pareto-dominates on speed, editing, long context, and coding skill. Net best, and the community consensus, is Sonnet. o1 is a strong reasoner on interview and LeetCode-style problems, but it does not seem to understand rough human intent as well as Sonnet. His quiet criticism of some frontier models is distributional: they look great on benchmarks and on tasks near those benchmarks, then sag when you push them a little outside. Sonnet is the one that keeps the same capability when you just ask it to do something with code.

The gap between benchmarks and real programming, Sualeh says, is specification. Real work is half-broken English: "do what I did before," "add this, then that, and change that UI." Interview problems lean on a complete spec; humans do not. Michael adds the public-benchmark mess. SWE-Bench, a popular agent eval, is heavily contaminated in foundation-model training data. Ask a model to do a SWE-Bench problem *without* the repository and it can hallucinate the right paths and function names. Aman notes the labs will not omit sympy and other popular Python repos from training just to keep a leaderboard clean. So teams cheat toward the truth: humans play with the models and give qualitative feedback. Arvid calls it the vibe. Lex admits he does the same on Reddit and X, including the recurring "Claude got dumber" feeling. Aman relays a speculation that AWS chips and a quantized Bedrock build might differ in numerics from Anthropic's own GPUs. Sualeh's moral is not a conspiracy. Chips are messy, flop counts are huge, and it is hard to overstate how hard bugs are to avoid.

Arvid's internal prompt system is called Preempt, built when GPT-4-class models had 8,000-token windows and the editor had too much candidate context: docs, attached files, chat history. Filling the window is still costly even now — slower, more expensive, and some models get confused. He stole a metaphor from the web. Print magazines know exactly where every story goes; a site has dynamic input and must still layout. So Cursor writes prompts in JSX. There are components, including a File that takes the cursor position: the current line gets highest priority, each farther line one less, and the Preempt renderer packs as many lines as fit, centered on the cursor. Retrieval scores can set priorities on code blocks the same way. The abstraction is now less about squeezing 8k and more about detaching raw inputs from rendering, so you can change the renderer and replay it on old prompts across an eval set.

Should users write JSX too? Arvid's answer is no. The goal is that you do whatever is most natural; Cursor's job is to retrieve the relevant bits so your thought makes sense. Lex recalls Perplexity's Aravind arguing you should let people be lazy, then pushes back: you *can* ask more of programmers, a tension between laziness and being inspired to think harder. Aman offers two ways to resolve missing intent: the model asks a clarifying question, or, if the search space is small, it shows five or six generations and lets you pick. A recent, still-experimental feature guesses uncertainty while you type and suggests files to attach — if you are changing an API, commits in the same file may imply that client and server belong in context too, before you even hit Enter.

On agents, Arvid is both excited and sober. Demos look like a step toward AGI; for many real tasks, agents are not yet that useful, though they are getting close. The example he wants is painfully concrete: Command+C / Command+V sometimes fails in Cursor's chat input. That bug is well specified in two sentences. He would love an agent that finds the files, reproduces, fixes, verifies, and is waiting a day later. What he does *not* buy is the belief that agents take over all programming. A lot of the value is in iterating: you cannot specify the thing up front because you do not know what you want until you have seen version one. For that work you want something instant. Background agents still have a shape he likes — while you work the frontend of a PR, an agent drafts the backend — and tedious environment-setup work is in scope for making programming more fun, even if they are not actively building a full deploy agent today.

Lex observes that Apply is the only part of Cursor that feels slow, and it is maybe one or two seconds — which is how you know everything else is fast. Arvid's face, Lex notes, shows they already feel that pain. Aman's first trick is cache warming: as you type, the system can guess context you will need, prefill the current file into the KV cache, and cut time-to-first-token when you hit Enter. He walks through why the cache exists. Attention needs keys and values for every previous token; without storage, every new token reruns the whole prompt. Keep KV on the GPU and the next token is a forward pass on the last token plus attention over cached state — the only sequential dependence in the Transformer, mostly paid for.

Tab adds a higher-level trick: speculate as if the user already accepted, fire the next request, and have the following suggestion waiting when they actually press Tab. It is speculation mixed with caching, and it *feels* fast even when the model did not get faster. Shrink the KV cache and you can speculate more aggressively — ten possible next actions, any one of which is a hit. Sualeh ties that to pass@k: one sample may be mediocre, ten samples much more often contain a good answer, which is part of what RL exploits. When they RL the Tab model, they are scoring which of many suggestions humans actually like. Architecturally, the field moved from multi-head attention toward grouped-query and multi-query attention to compress KV, which does not help prefill but does help memory-bound generation and larger batches. DeepSeek's MLA (which they describe as multi-latent attention) compresses all heads' keys and values into one latent and expands it when needed, trading compute for memory bandwidth. Smaller KV means more cache, longer prompts, bigger batches, without tanking decode latency.

Arvid's Shadow Workspace post is about spending compute on a longer horizon than the next few lines — maybe the next ten minutes — which only helps if the model gets a feedback signal. o1 shows that thinking longer can work; iterating with feedback is the other path. For programmers the crucial signal is the language server: type errors, go-to-definition, find-references, wired into VS Code via LSP so the editor does not ship every compiler. Shadow Workspace spawns a hidden Cursor window on the same folder. The agent can edit freely as long as it does not save, and it still gets lints and definitions. On Linux you can mirror the filesystem in memory so the model thinks it is touching files; Mac and Windows are harder, which is why the problem is interesting. Aman likes a hackier lock-on-save: the model holds the disk lock, you edit an in-memory shadow that still lints, and a warning appears if you need the lock back. Minutes-scale work should stay on the user's machine so the environment matches; longer, larger jobs probably belong in a remote sandbox, which is its own nightmare of reproducing a real setup.

Lex's wish list is not only coding. Much of his podcast pipeline is already code driving Premiere, YouTube uploads, translation, overdubbing. Inside coding, he wants agents that find bugs, including large-scale logical ones. Aman's reply is blunt: even the smartest models, including o1, are "incredibly poorly calibrated" when naively asked to find bugs. They are a strong reflection of pretraining. GitHub-scale code and Stack Overflow / GitHub-issue Q&A exist in trillions of tokens; "detect a real bug in existing code" barely exists. Push into a rare objective — Cursor Tab's next-edit prediction, or bug detection — and the brittleness shows. He still expects transfer, the way pretrained code models transferred into Tab after a nudge.

Sualeh thinks the model often *knows* something is sketchy and still cannot score how much it matters. A few bugs in an experiment are fine; an edge case in Postgres or Linux is not. Staff engineers carry cultural memory — the sketchy function that took the server down three years ago — which the model does not have, plus a read on how paranoid this user is right now. Arvid's practice, which Sualeh finds ugly and useful, is that if a function can do huge damage, every line inside it says DANGEROUS in all caps, repeated on the order of ten times. Humans skim docstrings and forget; today's models also pay more attention when the warning is that loud. Until formal verification is everywhere, Arvid says, you always have to worry about a silent bug.

The future he wants is that people stop writing tests. You write a function, the model proposes a spec, you review the spec, and a strong reasoner proves the implementation matches. Michael objects that intent is often as hard to specify as the code; a formal spec language will miss things you care about. Arvid thinks spec languages can evolve, and that whole-codebase verification is possible in principle: there is already work formally verifying C through GCC and Verilog down to hardware, which is a huge layered system, not unlike a large repo. Aman asks about Stripe APIs and about programs that call a language model as a primitive. Arvid is willing to dream as far as proving a model is aligned. On the training side, one dinner-table idea is that introducing a plausible bug is easier than finding one, so you train a bug-inserter and then a reverse model on that synthetic data. Another direction is not more staring: give the model traces, a debugger, and the right to run the code. Michael sketches two product shapes — a fast specialist hunting in the background, versus zapping a known bug with a lot of compute, even tens of dollars.

Lex, delighted by three perfect YouTube-API functions Cursor wrote when the docs were a mess, wants a $5 tip button as a stronger signal than Accept. Arvid says the idea is controversial in the company. A version he likes: finding a bug costs $0, accepting it costs a dollar in parentheses — with the obvious honor-system failure of copy-paste, and the mood failure of putting a dollar sign in an editor where you want to think only about code. Sharing a great generation with friends may be the more natural reward. A technical way out of the honor system, Michael adds, is actually verifying that the bug is fixed. They do not yet close a loop of run-in-terminal, fail, patch, rerun; they suspect it belongs either in the foreground or in the Shadow Workspace. That leads Sualeh to databases: PlanetScale-style branches on the write-ahead log, and turbopuffer likely adding the same, so an agent can test against a branch. His slogan is that everything needs branching, including filesystems, with clever algorithms so the multiverse does not actually cost that much space or CPU.

Infrastructure starts with a joke question: why does AWS still win with a horrible interface? Arvid's answer is that AWS is really, really good. You know it will work, even if setup is hell; if something is wrong it is probably your problem. Sualeh calls that the nature of winning. Scaling Cursor has been the usual startup story of each extra zero of QPS breaking a new layer of caches and databases, now including table overflows. The custom system that keeps hurting is retrieval: a semantic index of your codebase for questions. They chunk code, embed it, and store vectors — not the code itself — with encryption and a paranoia about client bugs. The hard invariant is that local state matches the server after edits, deletes, and branch checkouts.

The naive sync is pulling every file hash every minute, which would hammer user Wi-Fi and read an approaching-20-terabyte database constantly. Instead each file has a hash, each folder hashes its children, up to a single root hash: a Merkle tree. Most of the time the roots match and you stop; on mismatch you walk down. Cost, Aman says, is not the vector database. It is embedding. N engineers at a company should not re-embed the same chunks, so they cache vectors keyed by the hash of the chunk. The nth teammate's index is fast, branches with a few diffs do not re-embed the world, and still no source text lives on their servers. The payoff users feel today is fuzzy "where do we do X?" search via codebase chat; Arvid thinks the retrieval ceiling is much higher than people credit.

Why not embed locally and skip this distributed puzzle? More than 80% of Cursor's users are on Windows machines, many of them not powerful, and supporting local-model branches is a large engineering tax. As models get bigger, local gets harder, not easier. Sualeh says it is not only weak laptops: even the best programmer at a 20-year-old company, on a beefy MacBook Pro, will have a horrible, un-fun time running approximate nearest neighbor over that corpus. Aman adds the modeling headwind. Mixture-of-experts helps local a bit because it is memory-bandwidth bound, but total parameter counts are growing past a single node, let alone a laptop. For coding, people do not want a model that is "good enough"; they want Sonnet and o1.

Arvid's preferred alternative to local weights is still research: homomorphic encryption for language-model inference. Encrypt on the laptop, let a datacenter run a model you cannot host, get back ciphertext, decrypt so only you see the answer. Overhead is currently huge. He wants it because as models get more economically useful, more of the world's information will flow through one or two centralized actors — not only hackable, but surveillable in plaintext. Safety monitoring starts with good reasons, then someone else comes in, and you are on a slippery slope. Cloud compute is different, he argues: you can often keep your own keys, and much of this personal data would never have gone to AWS in the first place. Sualeh worries about the same line at Anthropic's ASL-3 and ASL-4, where monitoring all prompts becomes reasonable for security and horrible if all the world's information is that centralized. Fine line: do not let models go rogue; do not trust every prompt to three providers.

Lex's friction is everyday Python: many imports, and Cursor's guess at context is not good enough. Michael says automatic context is not free. More tokens means slower, costlier requests, fewer background calls, and models that get confused when the prompt is stuffed, so the relevance bar has to be high. Paths they like include better embeddings and rerankers. The more academic stack is whether a model can *understand* a new corpus: infinite context, then actually attending to it, then caching it so you do not recompute. Another family is closer to fine-tuning — putting knowledge in the weights, which might be a qualitatively different understanding than in-context learning. The jury is out. In the interim, Cursor is betting on retrieval that picks the right slices of the repo.

Aman's existence proof is VS Code itself. The code is public, so frontier models have seen it, plus Q&A, plus instruction tuning and RLHF; ask about VS Code and they are sometimes decent, sometimes hallucinated. What if you post-trained a model to actually know *this* repository? A naive recipe is continued pretraining on general code mixed with that repo, then instruction tuning that mixes a standard code dataset with questions about the repo — human labels if you can get them, or synthetic ones: take recently changed snippets, have a model ask a question, pair question and code. A further fork is still open: should one model retrieve internally end-to-end, or train a strong open retriever that feeds whatever frontier model appears a few months later?

o1, for Aman, is the interesting new curve: test-time compute, as pretraining hits a data wall. Some queries may need 100-trillion-parameter, 100-trillion-token intelligence, but that might be 0.1% of traffic. Train for the 99.9%, then think longer on the hard tail. Routing among 4o, Sonnet, and o1 is unsolved; even Cursor Tab's early routing does not obviously scale to that choice, and you might need o1-level intelligence just to know 4o is in too deep. Outside a few people at OpenAI, nobody really knows how o1 works. Public hints include process reward models and tree search. Outcome RMs score the final answer; process RMs score steps of a chain of thought. In the open literature, process RMs mostly rerank samples. The exciting unproven use is tree search — if step quality correlates with final quality, you can branch. Michael speculates that hiding o1's chain of thought makes distillation harder, the same way some APIs pulled logprobs. In Cursor, o1 is available and not default; they have not found a use they reach for every hour, partly because it does not stream, so you wait on a wall of text. They have ideas. They will not ship until something is genuinely useful.

Lex floats the internet line that Copilot integrating o1 means Cursor is done. Michael treats it as a joke with a serious doctrine. This space is different from 2010s software: the ceiling is incredibly high, and the best product in three or four years will be far more useful than today's best. You can talk about moats and brand, but if you stop innovating on the product, you lose. That is good news for startups, because you can still beat an incumbent by building something better. Aman's addendum: most of Cursor's extra value is not being first to wrap o1. It is the custom models you do not notice, and the UX obsessing behind every feature.

Aman splits non-natural data into three. Distillation: a strong model emits tokens or distributions, a weaker model trains on them. You will not beat the teacher, but you can pack an expensive skill into a small, fast specialist. Second: one direction of a problem is easier than the reverse. Planting a reasonable-looking bug is easier than finding one, so a weak model writes bugs and a detector trains on that synthetic set — probably true for humans too. Third, the lab-scale one: generate text that is cheap to verify. If you had a Shakespeare detector, monkeys on typewriters would eventually supply training data. Math in formal languages is the clean version; LeetCode-style code with a test suite is close. Category three is where he expects massive gains, and the hardest to generalize, because open-ended and long-horizon work lacks a perfect verifier. Michael's middle path is the model running the program and doing the human form of quality control on the output.

RLHF, in Aman's telling, needs a lot of human preference labels. RLAIF leans on verification being easier than generation, so a model can grade another model's samples. Cursor's actual mix is smaller than textbook RLHF: the Tab model is often already roughly right, and on the order of 50 to 100 human examples can nudge its prior onto the distribution they want. If you believe P is not NP, a huge class of problems should be easier to check than to solve. Lex jokes about AI proving that and taking a Fields Medal; Michael says whoever wrote the prompt gets credit. Arvid thinks Fields falls before a Nobel because math is a closed, verifiable system. Aman thinks they may get a Fields before AGI, but he has much less intuition than he did on IMO: the path then was visible, with solvable problems and known tactics. Open problems like the Birch and Swinnerton-Dyer conjecture do not even have a visible path. Sualeh's date guess for Fields is 2028 to 2030.

On scaling laws, Aman says the original OpenAI paper was slightly wrong, largely from learning-rate schedules; Chinchilla corrected the compute-optimal mix of parameters and tokens; then labs drifted off compute-optimal toward inference-budget optimal — spend more to train so serving is cheaper. The curves now have extra axes, including inference flops and context length. If you care about low-latency ultra-long context, you might train an SSM even if it takes 10× the train compute to match quality, because inference is the constraint you actually have. Bigger is still better for raw capability, what Sualeh calls raw intelligence. Aman is bullish on distillation as a way through the data wall: train an expensive teacher, then minimize KL against it the way Gemma did with a 27B teacher, getting more signal per token into a smaller student than over-training a 7B on extra tokens à la Llama.

Lex's hypothetical is $10 trillion over five years. Sualeh's simple answer is buy GPUs; researchers will tune. Pressed on whether they are compute-limited or idea-limited, he sides with Arvid: idea-limited, though compute lets you run more experiments. Aman thinks even infinite capital does not produce the people. Research is brutal engineering — joining ideas from the literature is one job, writing CUDA that saturates GPUs is another, and getting model parallelism across thousands or tens of thousands of V100s (he cites GPT-3) is another. If you made it 10× easier for someone with a good idea to stand up an architecture at 40–50% utilization, research would jump. Sualeh's sequencing: pick low-hanging fruit first. While scaling still works, there is no point stopping to experiment; with $10 trillion you would eventually re-evaluate. All four believe new ideas are needed for AGI and that those ideas can be tested small. The bind for labs is spending scarce talent on side paths while the core scaling recipe is still paying off.

Looking months to ten years out, Michael says Cursor is excited about a future where the programmer is in the driver's seat for a long time: speed, agency, control — modify anything, iterate fast. That is a different picture from the one that has captivated the industry, a lone text box you talk to as if it were an engineer or an engineering department on Slack. They are not excited about that, partly because of latency, mostly because it gives up control. If you can only speak to a bot like a department, you hand it a pile of decisions that *are* the job. People far from engineering imagine a finished spec and implementation as typing. The engineering they enjoy is thousands of micro-decisions and ugly tradeoffs among speed, cost, and complexity. As long as humans are specifying what to build, they will want to dictate those decisions.

One still-fuzzy idea is controlling the abstraction level you view a codebase at: digest it as pseudocode, edit the pseudocode, and have the change land in the real language, while keeping the right to drop into the actual text. Time will tell. For well-specified bugs, Arvid's handoff style still makes sense; that is not most of programming, and not most of the programming they think people value. On the fear that young people who love coding have no future, Michael is optimistic in a concrete way. Programming in 2012 and 2013 had more cruft, boilerplate, and gnarly lookups. Today is closer to "delight concentration." The things that attract people — building fast, individual control — are being turned up. Skills will change. Taste and creative ideas get magnified; boilerplate text editing, and even some of today's carefulness, matter less.

Arvid's recent example is a painful migration off Node's AsyncLocalStorage onto a context object, a change that touched the whole codebase. He and Sualeh spent about five days, even with today's best AI tools. The future he wants is showing two or three examples, letting the model apply them everywhere, highlighting novel cases for a demonstration, and finishing in ten minutes. Then you do not have to stand at a blackboard until the plan is perfect, because reversing a wrong try is cheap. Aman prefers that style anyway: take a crack, see how it lays out, iterate, rather than thinking of the optimal design and spending a limited engineering budget implementing it. Advice for learners is less about Java or PHP or the joke that vanilla JavaScript eats the world. The best programmers, he says, are the ones who simply love programming — teammates who come home, boot Cursor, and code side projects until 3 a.m., and who, when sad, say they just need to code.

Lex's last needle: what happens to that person when super-Tab works and they only press Tab? Sualeh and Arvid answer almost together: that person will love Cursor Tab more than anyone. Pressing Tab is the catchphrase; what you are actually doing is injecting intent the whole time — rejecting, typing a few more characters, shaping the thing. Communication with the computer becomes much higher bandwidth than typing every character. Lex reads their Engineering Genius note: an applied research lab building a human-AI programmer an order of magnitude more effective than any one engineer, with effortless control, no low-entropy keystrokes, iterating at the speed of judgment, out-engineering pure AI systems — and on the way, making programming more fun. His sign-off, a Reddit line, fits the whole field: nothing is as permanent as a temporary solution that works.