A follow-up to "What's left when the machine writes the code"
In my last piece I argued that even as language models absorb the everyday work of writing code, three things stay hard for a machine in a box to reach: taste about where a product should go, the ideas that only come from friction with the real world, and a reputation for work that holds up. I also admitted the obvious objection. All three reward experience, and the traditional way to earn experience, the grind of junior work, is exactly the part being automated. I said those fronts are still open to people starting out, just reached differently, and then I owed you the "differently how."
This is that article. One caveat first, because I will not pretend it away: there is a structural problem underneath all of this. Companies used to train juniors as a side effect of needing the grunt work done, and if that work is gone, many will quietly skip the junior. That is a collective problem, and it is not yours to solve. What follows is about the part that is in your control: how to make yourself, as an individual, obviously worth betting on even in that environment. Six moves.
Learn on real projects, not in a sandbox.
The tutorial where everything works is the least useful place to learn right now, because that is precisely the kind of well-trodden, self-contained problem the machine already solves perfectly. You learn the things that still matter by working on code that already exists, has users, and carries constraints nobody chose on purpose. Open source is the obvious door: pick a project you actually use, read its issues, fix a small one. Real code with real history is where judgment forms, because it is full of decisions you have to understand before you can change anything. You are not learning syntax. The machine has the syntax. You are learning how a real system holds together and what happens when you push on it.
