Moving into tech when AI writes the code

Two things happened at once

If you are moving into technical work from somewhere else, you are being told two contradictory things. One: it has never been easier, the model writes the code. Two: entry-level work is disappearing, because the model writes the code. Both are describing the same change and both are half right.

What actually happened is that producing a working first version got cheap, and everything after the first version did not. Deciding what to build, noticing that it is quietly wrong, keeping it running when the inputs change, explaining it to somebody who has to trust it: none of that got cheaper. The work did not vanish. It moved past the part that used to be the on-ramp.

So the honest version of the opportunity is narrower and more useful than the pitch. You can get to working software far faster than you could have five years ago. You will be judged on whether you can tell working from correct.

Build the thing, then break it on purpose

The fastest way to build real understanding in this environment is not to avoid the assistant. It is to use it to get something running, then to deliberately go looking for the places it fails.

Change an input to something the code never expected. Submit the form twice. Turn off the network partway through. Feed it an empty list, a date in another timezone, a name with an apostrophe in it. Each of these is a lesson that a tutorial teaches as a paragraph and that a broken build teaches permanently.

This is also the honest answer to the question of how you learn when you did not type most of it. You learn by owning the failure. Code you have debugged is code you understand, whatever wrote the first draft.

What is worth learning, in order

Breadth is the enemy at the start, and the list of things you could learn is now effectively infinite. This ordering is opinionated, and it is chosen for what a model cannot hand you.

1. 01Reading. Being able to follow code you did not write, out loud, line by line, is the single highest-return skill available to you and the one generation of tools makes most urgent.
2. 02Data shape. What a record is, what one row means, where duplicates come from, what happens when two things claim to be the same thing. Most bugs that reach users are shape bugs.
3. 03State and ownership. What is stored, who is allowed to change it, and what happens when two changes arrive at once. This is where confident generated code fails quietly.
4. 04Failure. Timeouts, retries, partial writes, and what your thing does when the service it depends on is having a bad afternoon.
5. 05The tools around the code: version control, a way to run it locally, a way to see what it did in production. Not glamorous, and the difference between a hobby and a job.

Evidence, not a certificate

The market for people entering technical work is full of completions. A certificate says a course was finished. It does not say what you can do when the requirements are ambiguous and the first approach did not work, which is the entire job.

What travels instead is small, dated, specific work you can talk about. A thing you built that somebody other than you used. A bug you found, explained in the terms of what it would have cost. A decision where you chose the boring option and can say why. Three of those, told well, outperform a list of course badges, because they cannot be produced without the underlying work.

Practice the telling as much as the building. Being able to say what you built, what broke, what you checked, and what you would do differently is the interview, and it is also the daily reality of the job you are trying to enter.

The two failure modes on this route

The first is the tutorial loop: months of guided material, high confidence, no independent artifact. It feels like progress because there is always a next lesson, and it ends with a person who has never once been stuck without a hint at the bottom of the page.

The second is newer and more common now. It is shipping generated code you cannot read, getting a demo that works, and building on it until the first real bug arrives in a part of the system you have never understood. That person is not further along than the first one. They are further from the ground.

The path between them is unremarkable and it works: build small things, read every line of what you keep, break them on purpose, and write down what you learned in a sentence a person could check.

Where Datum fits

None of this requires a product. Datum is one way to get the reps: short situations from real systems, where the code runs and the question is whether you would defend it. You write the call, you get feedback on where it was wrong, and the example is yours to keep. Core is free, and there is no account needed to try one.