Shipping software takes three different jobs: producing the code, knowing what the code should do, and deciding whether it is worth building at all. Claude Code, Cursor and GitHub Copilot have automated the first one. The other two sit where they always did.

The idea

These tools are very good at producing code for a job somebody has already decided on and described clearly. They are weaker at holding a whole system in mind at once, and they do not decide what is worth building. The limit you run into is how much of a project one person can personally hold, decide about and check, not how fast code can appear. Better tools raise that limit and do not remove it.

code
   automated
   +--------------------------------------------------+
   |  producing the code                              |
   |  Claude Code, Cursor, Copilot. Fast, cheap,      |
   |  still getting faster.                           |
   +--------------------------------------------------+
                          |
   ====================== | ============================  the line
                          |
   +--------------------------------------------------+
   |  knowing what the code should do        |        |
   |  deciding what is worth building        |  YOU   |
   |  remembering why a past choice was made |  (one) |
   |  being awake when it breaks at 3am      |        |
   +--------------------------------------------------+
   not automated

How it works

The model works from the text in front of it and produces the most plausible continuation. Everything it appears to know about your project arrived during this : files it opened, command output it read, things you typed. The model itself keeps no memory between sessions. Products do now ship persistence, in the form of instruction files and stored project notes, and that is a file being re-read at the start of the next session rather than the model remembering you.

That gives a clean dividing line.

  • The parts of the job you can fully describe are the parts it can take.
  • The parts still only in your head, or in nobody's head yet, stay with you whichever model you pick.

A large company is not a large pile of code. It is many people holding different parts of one intention and keeping them aligned through documents and review. Give one person a very fast code producer and you have one person with a very fast code producer.

What to do

  1. Choose projects whose whole shape fits in your head. That is the real size limit, not the line count.
  2. Write down what "done" means before you ask for the work. No model supplies that half, and none will ask you for it.
  3. When a session starts going backwards, make the request smaller rather than louder. Repeating an oversized ask in firmer words almost never rescues it.

Where it breaks

This page is a snapshot checked on 13 August 2026, and the line it draws moves. Assume the producing half keeps improving, and check the claim rather than trusting this page in a year.

The ceiling is not a wall. One person does ship real products this way. What fails is expecting the model to supply the judgment: what to build, what "correct" means here, what is safe to change. The opposite mistake costs just as much, and it is common: deciding these tools are useless because one long session went badly, when the honest reading was that the ask was too big to hold.