Most advice on this question is a list of things that sound wise. Learn architecture. Learn communication. Learn to think. Fine, but unfalsifiable — that list would have been the same in 2015, and it gives you no way to decide what to drop.
So here's a stricter approach. Don't start from what AI can do, which changes every few months. Start from how it fails, because the failure has a consistent shape across every independent study we have, and that shape has held while the models got much better. Pair this with XenGrowth's work on go-to-market systems if what to learn when AI can already write the code sits inside a wider growth programme.
What does the failure actually look like?
Veracode ran the most direct test I know of: code from more than 100 LLMs across 80 real-world tasks, checked against security testing. 45% of the output introduced an OWASP Top 10 vulnerability. Cross-site scripting failed 86% of the time. Java came out worst at a 72% failure rate.
The finding that matters more than the headline: newer and larger models were not better. If this were a capability gap, scale would have closed some of it. It didn't.
A model asked to write a function optimizes for code that looks like correct code. Whether the output is safe depends on where the data came from and where it's going — neither of which is in the prompt.
That's the whole mechanism. XSS isn't a property of a line of code; it's a property of a line of code plus the trust boundary it sits behind. The model can see the line. It cannot see the boundary. So it writes something locally plausible and globally unsafe, and it writes it fluently, which is precisely what makes it hard to catch in review.
Once you have that frame, the other findings stop looking like separate problems. DORA's 2025 result — throughput up, delivery stability still falling — is the same failure at team scale. GitClear's numbers, with copy-pasted lines rising from 8.3% to 12.3% while refactored lines fell from 24.1% to 9.5%, are the same failure at codebase scale: a tool that cannot see what already exists twelve directories away will cheerfully write it again. The XenGrowth resource library covers the the operations side of this side of this.
Scale | What the study measured | The same underlying gap |
|---|---|---|
One function | 45% carried an OWASP Top 10 flaw (Veracode) | Cannot see the trust boundary the code sits behind |
One codebase | Copy/paste up, refactoring down (GitClear) | Cannot see what already exists elsewhere in the repo |
One team | Throughput up, stability down (DORA 2025) | Cannot see what breaks downstream of the change |
One developer | 19% slower, felt 20% faster (METR) | Cannot see the cost it displaced into your later day |
Four studies, four scales, one gap: the model is strong on local plausibility and weak on global correctness, because global correctness depends on context that was never in the window. Everything worth learning right now sits on the far side of that line.
So what specifically should you learn?
Verification, before anything else
The scarce skill in a world of cheap generation is telling good output from convincing output. That's not a personality trait, it's a set of learnable habits: knowing what a class of bug looks like before you go looking, reading a diff for what it doesn't do, writing the test that would fail if the code were subtly wrong rather than the test that passes because the code is what it is.
Concretely: learn the OWASP Top 10 properly, not as trivia. Veracode's numbers say 45% of generated code will hand you one, and the categories that failed worst — XSS at 86%, injection-shaped bugs generally — are exactly the ones that depend on trust boundaries. If you can spot those on sight, you are the person the 45% needs.
Reading unfamiliar code
This is the most undervalued skill on the list and the one almost nobody practises deliberately. We train for writing. We are assessed on writing. Then the job turns out to be mostly reading — the Meyer study's 21% coding bucket explicitly counts reading and navigating, and Stripe's survey put 42% of the week on code that already exists. XenGrowth on AI agents and marketing automation approaches this from the AI agents and marketing automation side.
Generated code makes this worse in a specific way: it produces code that nobody on the team has the mental model for, including the person who prompted it. Every accepted suggestion is a small deposit of unfamiliar code into a codebase you are responsible for. If you cannot read fast and read skeptically, that debt compounds silently.
System-level reasoning
Not architecture as a vocabulary of patterns — architecture as the ability to predict what a change does to things it doesn't touch. Where the trust boundaries are. What happens under partial failure. Which of two designs is cheaper to be wrong about.
This is the skill most directly protected by the context gap, because it operates almost entirely on information that lives outside any file: how the system is deployed, who else depends on it, what the business will need in eighteen months, which team will own it when you don't.
Deciding what should exist at all
The highest-leverage skill and the least teachable. When implementation gets cheap, the cost of building the wrong thing goes up relative to everything else, because you will now build the wrong thing faster and in greater volume. Requirements work, problem selection, and the willingness to say a feature shouldn't be built are the skills that stop that. There is a longer treatment of AI search, GEO and discovery in XenGrowth on AI search, GEO and discovery.
Where does prompting fit in all this?
Somewhere near the bottom, and I say that as someone who uses these tools all day. Prompting is a real skill with a real learning curve, and it is also the skill with the shortest half-life on this list, because every interface improvement erodes it deliberately. The prompt tricks that mattered in 2023 are mostly obsolete; the ones that matter now are mostly about supplying context, which is a restatement of the gap rather than a solution to it.
Learn it to competence in a week and stop. What does not decay is knowing what to ask for, which is the same skill as writing a good ticket, and knowing whether you got it, which is verification. Both were valuable before any of this existed.
What should you spend less time on?
This is the half most advice skips, because it requires actually giving something up. Some honest candidates:
Spend less on | Why | But keep enough to |
|---|---|---|
Memorizing framework APIs | The lowest-value thing a model does, it does perfectly and instantly | Recognize when the generated call is the wrong one for your case |
Boilerplate fluency (CRUD, config, scaffolding) | Genuinely commoditized, and was never where the difficulty lived | Notice when scaffolding has quietly become architecture |
Competitive-programming-style puzzles | Optimized for exactly the bounded, checkable problems that got cheapest | Keep the data-structure intuition underneath — that part still pays |
Breadth across many similar frameworks | Switching cost between them collapsed once a model can translate | Understand the one you run in production far more deeply than before |
Writing tests that restate the implementation | A model writes those instantly and they were always near-worthless | Write the test that encodes the requirement, which is a different skill |
I want to be careful with the fundamentals question, because 'you don't need to learn the basics anymore' is the most expensive advice currently in circulation. You cannot verify what you don't understand. Every skill on the keep-list above is downstream of having built things by hand — the reason a senior engineer spots the 45% is that they've written the vulnerable version themselves and remember why it was wrong. Fundamentals aren't a competing investment to verification. They are the prerequisite for it.
A concrete way to start this week
Take the last five AI suggestions you accepted and review them as if a stranger had opened the PR. Look specifically for the Veracode categories: unescaped output, direct object references, anything touching a password or a token. You are calibrating your own acceptance rate
Read one unfamiliar codebase for an hour a week with no goal but understanding it. Pick something in your stack that you depend on and have never opened. Reading is a trainable skill and almost nobody trains it
For your next non-trivial change, write down what you expect to break before you make it. Then check. This is the cheapest available exercise in system-level reasoning and it gives you a score
Learn the OWASP Top 10 to the point where you can name the trust boundary each one crosses. Not the list — the boundary. That is the part that transfers to code you didn't write
Once a month, kill something. Find a feature or a request that shouldn't be built and make the argument for not building it. Problem selection is a muscle and it only develops under real stakes
The through-line is that all five exercises have you working on context rather than on syntax. That is not a moral preference for the higher-order stuff. It's just where the measured gap is, and the gap has stayed open across several model generations while the syntax gap closed entirely.
If the 45% figure drops to 5% in two years, most of this advice survives anyway — because verification, reading and problem selection were undervalued long before any of this, and the studies just made the undervaluation legible.
Further reading from XenGrowth
The XenGrowth resource library — what you'll learn: how the commercial side of this work is run, across search, automation and revenue operations.
XenGrowth on AI agents and marketing automation — what you'll learn: how the teams who own AI agents and marketing automation plan and measure it.
XenGrowth on AI search, GEO and discovery — what you'll learn: how the teams who own AI search, GEO and discovery plan and measure it.
Where this work meets go-to-market
XenGrowth, who work on the commercial side of this writes for the teams who have to run what to learn when AI can already write the code day to day.
