Start here
Read code well and write it rarely
Many roadmaps start with months of learning a programming language by hand. This one does not. Some AI-native companies now say in their job postings that models write all the code they ship. Time spent memorising syntax and writing boilerplate trains you for work that agents now do.
You still need to understand code, but you will not read all of it. Postings for both kinds of role hold you responsible for what agents produce, and an agent can write a thousand lines in a day. Nobody can review that much line by line. The bugs that cause real damage are the ones an agent writes with confidence: a blocking call inside async code, a retry that charges a card twice, a test that asserts nothing, or an authorisation check in the wrong service.
Machines do most of the checking, and practical tests do the largest share of it. A practical test runs the real system with real inputs and checks what the system does. Examples are end-to-end tests, tests that replay recorded production traffic, and property-based tests that try thousands of generated inputs. A practical test catches the retry that charges a card twice, whoever wrote the code. Types, static analysis, and reviewer agents that each look for one kind of bug cover much of the rest.
Your job is to design that checking, to read the small part of the code where a mistake costs the most, and to measure whether the reviewer agents catch what they claim to. Run the reviewer on a different model from the author, give it a narrow brief, and give it the spec and the tests. Two agents from the same model tend to miss the same bugs. No reviewer can tell that the spec itself is wrong, so that judgement stays with you. You also read code when something breaks in production and no agent can explain why.
Decide where your study time goes
The table splits code skills into three groups by how much time they deserve.
| Spend a lot of time | Spend a little time | Skip |
|---|---|---|
| Reading Python and TypeScript diffs and spotting what is wrong with them. Add C# if you target .NET teams. | Writing small snippets without help, enough to sketch an idea or get through a whiteboard interview. | Memorising syntax, library APIs, and framework boilerplate. |
| The concepts behind common bugs: async code and blocking calls, concurrency, types, error handling, idempotency, transactions, HTTP, and SQL. | The idioms of each language. Ask the agent to explain its choices instead of doing drills. | Courses that teach a language from zero. |
| Judging whether a test actually proves anything. | Build and packaging tools such as uv, npm, and dotnet. Learn enough to diagnose a problem, not to write the config from scratch. | Writing code by hand that an agent can write and a test can check. |
| Debugging from evidence: stack traces, logs, traces, and reproductions. | Profiling. Learn it when a real performance problem needs it. | Racing agents on typing speed. |
Build code literacy without writing code by hand
Use these five exercises. Do them on code that agents wrote for you.
- Explain it back. After an agent builds something, describe the control flow aloud or in a short note without looking at the code. Then compare your description with the code. Every gap is a topic to study.
- Predict, then run. Before you run a change or inject a failure, write down what you expect to happen. When the result surprises you, find out why.
- Find planted bugs. Ask an agent to add three subtle bugs to a working diff, such as a race condition, a missing authorisation check, and a retry that is not idempotent. Find them without help and track how many you catch.
- Review by risk. Read every line of code that handles authentication, authorisation, money, deletion, or concurrency. Skim generated UI code and glue code. Write down which files fall in which group for each repository.
- Ask the agent why. When you see an unfamiliar construct, ask the agent why it chose it, what the alternatives were, and what input would break it.