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.
Use AI, but never ship what you do not understand.
Using the model is not the mistake. Shipping code you cannot explain is. So make it a rule with no exceptions: do not commit a line you could not defend to someone who asks why it is there. When the model writes something you do not follow, stop. Ask it to explain what it did. Then ask why it chose that over the alternative you were thinking of. The same tool that wrote the code is an inexhaustible, patient tutor that will walk you through it. And unlike a senior colleague, it never sighs!
Used that way, AI is the fastest path to competence anyone has ever had. Used the other way, as a vending machine for code you paste and pray over, it quietly prevents you from ever learning anything. The whole game is to come out of each session understanding more than you did going in, because the scarce, valuable skill is no longer producing the code. It is being the person who can read what the machine produced with a sharp enough eye to catch what is subtly wrong.
Get in front of people and take the feedback.
You improve fastest where someone who knows more than you tells you what is wrong with your work. A maintainer who rejects your pull request and explains why teaches you more in three sentences than a week alone. So put your work where it can be seen and corrected: contribute, open issues, join the discussion, ask the question you are slightly embarrassed to ask.
This is also, quietly, how credibility gets built. Experience is something you can claim. Credibility is something other people can see: a trail of contributions with your name on them, a record of showing up and delivering and being reliable. In a world where anyone can generate plausible code, the person with a visible track record of work that held up is the one who gets trusted, and trust is the thing that is getting scarce.
Show up in person.
Do not do all of this from behind a screen. Go to the meetup, the local dev group, the conference, even when you feel too junior to belong in the room. It is one of the highest-return things you can do, for three reasons. You learn in a way documentation cannot teach you: a hallway conversation, a talk that reframes a problem you have been stuck on for weeks, the chance to watch how people further along actually think. You collect ideas, the real-world friction I wrote about in the last piece, where the best product idea I had all year came from standing in a room at a conference and not from a month of reading. And you meet people you would never reach otherwise: the maintainer of a library you depend on, someone who later hires you or recommends you, a person you end up building something with. That last one only gets more valuable. When everyone is heads-down alone with a model, the people who actually show up, who are real and memorable in a room, are rarer than they have ever been, and a network of real relationships is precisely the kind of thing a model cannot generate for you and cannot replace.
Build your own things.
Contributing teaches you to work inside someone else's vision. Building teaches you to have one. They are different muscles and you need both. Your own project, however small, is where you confront the real world with nobody between you and it: the requirement that is messier than it looked, the user who does something you never imagined, the decision that no ticket hands you because you are the one who has to make it. That friction is the source of taste and of ideas, and it cannot be borrowed or prompted out of a model that has never run a thing it built. Make the small tool you wish existed. Use it. Ship it. Watch what breaks when a real person touches it. That experience is yours in a way nothing you read can be.
An example, from my own life.
For a few years I have been a member of an association in my town. It is based in France, but most of its members come from Japan, so while the official paperwork that has to satisfy French law is in French, the internal documents and discussions are all in Japanese. I was born and raised in France and only started learning Japanese as an adult, twenty years ago. Six months ago I joined the board. The board gets at least a dozen emails a day, sometimes several dozen, almost all in Japanese. Most are not addressed to me, and I only really need to act on a handful, but everything is shared so everyone can see what the others are doing.
I can read and write Japanese, but nowhere near well enough to keep up at that volume, and between work, a wife, kids and a house, I am not swimming in spare time. So six months ago I wrote a small tool in Python, with AI. It downloads my received association emails, pulling in new ones periodically, and processes them programmatically as far as it can, falling back to an AI model only when it has to. I did not want it to have much freedom: it can only report to me. I wanted it secure, and as sparing with tokens as possible while staying accurate. Extracting the text of a PDF, for instance, is a job for a library, not the AI. Whether an email actually needs my attention can often be settled in code too, and only when it cannot does the script ask the AI what it thinks.
Over about a month, I built it, tested it, fixed what broke, improved it. It has saved me a lot of time: instead of skimming emails for hours every day, I spend a few hours a week on the things that genuinely need me and read short daily reports on everything else. Talking it over with other board members, I realized a more general version, one that could work with AI tools other than the one I happen to use, in whatever language the user needs, would be useful to other people too. So a month ago I started building that generalized tool. I called it JARLIS, switched to it for my personal use, and I published it a few days ago at https://github.com/hikashop-nicolas/jarlis
Does anyone but me use it yet? Probably not. Will that change? Maybe. Does it matter? No. I built it for myself, first and foremost.
Know your domain, to vet and to steer.
It is tempting to think the answer is to specialize so deeply that the machine cannot follow you into your corner. Drop that idea now. Frontier models already beat specialists at recall and application in domain after domain, and that gap is closing, not opening. You will not win a knowledge contest against a system trained on everything ever written about your field, and pretending you can is a bad plan to build a career on. But out-knowing the model was never the reason to learn your domain. You learn it for two things the machine cannot do with it.
The first is vetting. The model can be far more knowledgeable than you and still be confidently, specifically wrong for the situation in front of you, and you cannot catch that if you do not understand the domain at all. You do not need to out-know the model. You need to know enough to judge what it hands back and to put your name on it.
The second is the big picture. The model can ace every local question and still have no idea where the product is going or what actually matters here, because it has no stake in either. Domain knowledge is what lets you hold the direction while the machine handles the pieces. The same logic covers the fundamentals, how computers and networks and data actually work: you do not learn them to out-type the machine, you learn them because they are what let you catch it when it is wrong. Learn your domain not to hoard expertise as a moat, but to earn the judgment to vet and the standing to steer.
Take charge of your future.
Notice what none of these six is. None of them is "memorize the framework" or "out-type the machine." You will lose that race, and so will I. All six are about building the things the machine cannot hand you: the judgment to know what is worth making, the real-world contact that produces ideas, and a name people trust to deliver. The genuinely good news for someone starting today is that the same tool that threatens the old on-ramp also hands you a new one. You can build and ship whole, real things on your own and in public, years earlier than my generation could, and you can use the model as a tutor to understand every piece of them. The path is no longer years of tickets before anyone lets you near a real decision. You can start collecting the real experience now.
The hard part, the part I will not dress up, is that you have to be deliberate about it. The lazy version of using AI, paste and ship and never look closely, produces someone who cannot do anything the machine cannot already do better. The deliberate version produces the one kind of engineer that keeps getting more valuable: the one who understands the code the machine wrote, brings ideas back from a world the model cannot enter, and has the receipts to be trusted with the result. The machine writing the code does not close the door on you. It just changes what is on the other side of it. Walk in as the person who decides what is worth building, not the one who was only ever there to type.
Top comments (1)
Great point about shipping code you can explain — that same principle applies to agents. When I was testing AI coding agents, the biggest issue wasn't bad code, it was agents that would jump from "let me think about this" straight to rewriting files without any planning phase.
Put together Brainstorm-Mode (mehmetcanfarsak/Brainstorm-Mode on GitHub) which enforces that boundary at the hook level. Three modes (divergent, actionable, academic) so the agent stays in thinking mode when that's what the task needs. Forces the same discipline you describe — think before shipping.