Leading AI companies are currently exploring long-running autonomous AI work:
- building a browser (OpenAI, 2026/01)
- building a C compiler (Anthropic, 2026/02)
- building an operating system (Google, 2025/05)
Some of it works, some of it doesn’t. For now, these are experiments to gain experience.
What are the fundamental problems along this path?
- Specifications are never complete enough; a great many decisions are made outside of them
- Validation checks code, not specifications: implicit decisions partly survive and partly get corrected based on validation results
- You can validate the finished product as a whole or, conversely, a single minimal change. There is some increment size, determined by the current workflow, that is convenient for validation: not too big, but not too small either. Validating a complete operating system all at once is too hard and isn’t needed in practice. Similarly, the size of an MR in coding is usually limited, because past a certain size people simply stop reviewing thoroughly.
- Additionally, it’s economically beneficial to validate in parts, because then less needs to be redone (which saves time and tokens), since not all of the application’s code has been written yet.
Requirements can be divided into functional and non-functional:
- checking functional requirements doesn’t require programming knowledge
- checking non-functional requirements does require programming knowledge
On top of that, at the current stage AI still writes mediocre code, so practically every MR needs improvement.
What are the conclusions?
- Code is still primary. Specifications can be thrown away or kept, but (after the code is written and validated) they have already served most of their purpose. Later, they can be recovered from the code if needed.
- Even with perfect AI coding, you have to choose the size of the validated increments — it must not be too large.
- Even with perfect AI coding (which we don’t have yet), technical knowledge is still needed, albeit not in the same amounts as before. To clarify: the number of people decreases, but each person must know more (like the team as a whole used to know, which could afford to be more specialized).