Developer Skills After AI: Survival of the Valuable
Listen to article
Have you ever wondered what your developer skills are actually worth now? Let’s price it! Take a simple SwiftUI + SwiftData note-taking app – the kind you’ve probably written as a recruitment task. Models, @Query bindings, list-detail navigation, a repository layer, a few tests. Call it 2,500 lines. One Claude Code session gets you there for about $11 on Opus. Switch to Sonnet and you halve it. Or pay $20 a month and it costs you nothing at all.
A strong weekend of work, priced somewhere between a coffee and a pizza. If that stings, you’re in the right place. It stung me too.
Back in 2023, Kent Beck tried ChatGPT and wrote something that got quoted to death and understood almost never: the value of 90% of his skills had just dropped to $0, and the leverage on the remaining 10% had gone up a thousandfold. Everyone latched onto the first half. Great material for doom-posting. Almost nobody read the second. Kent never said his skills were worthless. He said the split had become brutally visible, and that the small remainder was suddenly worth more than his entire skill set had been the week before.
But did AI actually change the hierarchy of developer skills? In my experience, this job was never about producing code. It was about making somebody's business work better. AI priced the bottom of that skill stack at $11 and revalued everything sitting above it. The pyramid was always this shape. Typing out the base just took long enough that it felt like the job.
So the useful question isn't: Will AI replace developers? It's this: Which parts of what you know were valuable only because they were hard to type, and which because they were hard to think?
Sort what you know into those two buckets and the strategy mostly writes itself. Hand the first bucket to the machine, gladly, and spend everything you get back compounding the second.
The surprising fact is that hardly anyone has ever seen the whole stack written down.
The pyramid nobody drew for you
What does advancement actually measure in a large company? Years served? Certifications? Turning up on the projects with executive attention? A good-looking presentation deck for the steering committee? Now ask how much of that survives being repriced…
Startups aren't better. The currency there is features shipped and hats worn – which is precisely what an AI agent does now. For a fraction of the cost.
So, which career handout still works?
The one that has always worked. Less flashy, unlikely to get you promoted fast, but it's the one that keeps paying out whatever the era reprices next. It's shaped like a simple pyramid: five floors, and the Y axis isn't measured in seniority. It's measured in value produced for the business and its customers. The width is time – where your week actually went:
Turns out self-actualisation happens in the client meeting.
- Floor one is mechanical coding.
The code compiles. It passes review (most of the time). It ships. The feature works (again, most of the time). Like basic military drill, or learning maths at school, for decades there was no alternative to this stage. As aspiring developers, we simply needed to cover the basics of the craft before moving on. The only shameful thing about it is… staying there forever. - Floor two is code that survives contact with reality.
TheSwiftUI Listdoesn’t stutter at 400 rows. The fifth screen isn’t a copy-paste of the other four with three values swapped. That’s where our seniority starts to show. Where we actually start to earn our keep. - Floor three is where the expertise actually lives.
Knowing whySwiftUIrebuilt that view instead of reusing it. Spotting that the token refresh will race on a flaky connection and log everybody out at once. Knowing that aCodablestruct sitting on the network boundary will quietly become your domain model in 18 months if nobody stops it. Debugging and security awareness belong here too. Both get more valuable as more and more code is generated instead of being typed. - Floor four is when your output stops being your own hands.
Reviewing in a way that teaches instead of scoring points. Writing it down so nobody has to ask you twice. Sitting with a junior for 40 minutes on a bug you could have killed in 4 minutes yourself, and knowing the 40 is the better trade. A team that got sharper because you were on it outlasts every line you personally wrote. - Floor five is being a partner to whoever pays for the app.
Telling the client that the feature they asked for will cost 3 weeks and move nothing, and here’s the 2-day version that moves the number they actually care about. Owning the outcome instead of the ticket. In short: being a software craftsman.
The uncomfortable part? The top of that pyramid was never technical. It was always the partnership.
We just spent 80% of the week on floors one and two, so the job felt like floors one and two. Nobody rates a restaurant on how fast the kitchen chops onions. But if the chopping ate 40 hours a week, you’d be forgiven for thinking that was the business.
At this point you might be asking: what about prompting? Isn't that the new floor zero? You're absolutely right – for about one AI release cycle. Rules files, harness config, the incantation that finally stopped the agent inventing its own test doubles… all of it becomes default behaviour by the next version of the model. Tool-shaped skills have never earned a floor on the pyramid. And AI is nothing but a tool.
Now map those floors onto the two buckets. Floors one and two were hard to type. Everything above was always hard to think.
And floor three is really two skills wearing one badge – remembering the API surface, and having a working model of why the framework behaves the way it does. AI took care of the remembering for you. It didn't lay a finger on the model.
So let's start with the funeral.
What died
For a good stretch of my career, my main value to a team was being a searchable index. I was the person you asked why a fetch request kept handing back stale objects, which merge policy fixed it, which distinctUntilChanged overload wouldn’t quietly leak, how to make a networking service testable. Back in the office days, fellow devs would swing by to grab a coffee, crack a joke, and ask those questions. I liked it, I won’t lie. It felt like expertise. But it was recall. And recall is now priced at a fraction of a dollar.
Producing code aged in a similar fashion. I vividly remember when Sourcery made it possible to auto-generate test doubles. We were no longer sentenced to write test boilerplate by hand. Finally! SwiftGen, and project file generation tools like Tuist, also noticeably reduced the amount of repetitive code produced manually. Looking back, the devaluation of manual code typing was already underway – AI has merely accelerated it.
Creating Sourcery templates took a long time. They required learning a new scripting language (Stencil) and were notoriously difficult to read. Still, investing the time and effort to set it all up was worth it. Maintaining test doubles by hand took too much time to ignore. Take this Spy object, for example:
// UserSessionTests/Doubles/UserServiceSpy.swift
final class UserServiceSpy: UserService {
private(set) var loginCalls: [(email: String, password: String)] = [] // (1)
var loginResult: ResultError> = .failure(fixtureNotStubbedError) // (2)
func login(email: String, password: String) async throws -> User {
loginCalls.append((email: email, password: password))
return try loginResult.get()
}
...
}---
name: architecture-review
description: Single-lane PR review for architecture only -- module boundaries, MVVM/coordinator structure, dependency injection, and separation of concerns. Terse BLOCKING/NON_BLOCKING findings. Ignores style, tests, docs, accessibility, and correctness bugs. Loaded by the focused-reviewer agent during /review-pr.
---
# Skill: Architecture Review
You are a **terse, clinical architecture reviewer**. You care about one thing: does the change respect this project's architecture. No praise, no style feedback, no rationale fluff.
## When to run
On any change that adds or modifies types in the app target or a feature module -- before opening a PR. Invoked per-lane by the `focused-reviewer` agent.
## Authoritative sources -- read these first
The rules live in these docs; read them and enforce what they say (do not rely on this skill to restate them):
- `CLAUDE.md` (repo root) -- Hard rules, incl. the module-import boundary.
- `.ai/rules/core/code-style.md` -- Import management.
- `.ai/rules/architecture.md` -- Coordinator/MVVM/modular-package structure, DI.
...
## Focus -- only these
Review the **review set** against the sources above (the diff in `diff` scope; every file in a `REVIEW_SET: module` audit) for:
- **Module-boundary imports** -- anything reaching past a module's public interface...
- **Dependency injection** -- dependencies constructor-injected, not resolved inline in production code.
- **Duplication vs premature abstraction** -- copy-pasted logic that should be shared, or a one-off abstraction that should be inlined.
...
## Explicitly ignore
- Formatting, naming, spacing, MARK comments, optional-binding shorthand -- the `lint-review` owns those.
- Correctness/crashes/memory/concurrency -- `correctness-review` owns these.
- Test structure/coverage -- `unit-test-review` / `ui-test-review`.
...
## Tone & severity
- `BLOCKING` -- breaks a module boundary, injects dependencies illegally, or leaks a whole layer's responsibility into the wrong type.
- `NON_BLOCKING` -- architectural smell worth fixing but not structurally breaking (minor duplication, borderline placement).
## Strictness -- high-impact lane: bias toward flagging
This is a high-impact lane. Err on the side of catching problems:
- When unsure whether something is a real issue, **flag it** -- a missed architecture defect costs far more than a false positive here.
- Prefer the **more severe** of two plausible readings of the same code.
- Resolve severity ties **upward**; do not silently drop a real issue as "probably fine".
...
## Finding format
One finding per line, in this exact canonical format:
FILE:LINE | SEVERITY | architecture-review | CATEGORY | TITLE | WHY | FIX
- `CATEGORY` ∈ `Boundary`, `MVVM`, `DI`, `Coordinator`, `UseCase`, `Duplication`.
- `TITLE` ≤ 8 words. `WHY` ≤ 1 sentence. `FIX` = concrete instruction or snippet.
...There’s nothing remotely interesting in there. (1) just records each call so a test can assert on the arguments it received. (2) makes an unstubbed spy fail loudly instead of quietly handing back something plausible. Now multiply that across all your services, view models, use cases.
That file is dead. So are all the others like it: test doubles, Codable and Equatable conformances, dependency injection registration and retrieval logic.
You no longer need to write them by hand. You no longer need to maintain a template to generate them. There’s no bus factor around the one developer who mastered metaprogramming just to talk to Sourcery. Simply generate proper project rules and/or create a dedicated skill for test doubles generation, and the LLM will deliver a fake, mock, or spy in the naming convention and style you specified.
Finally, there’s a peculiar brand of seniority worth mentioning that’s also dead. Back when I started as a software engineer, it was very popular for seniors to have secret stashes of code that solved specific, complex issues: a RegEx that validated international phone numbers across all EU countries; Codable initialisers for an API that returned dates in three formats. Things like that. When needed, these developers would tweak an existing solution and present it as their own. After a couple of days of focused, determined work, no doubt. That knowledge devalued slightly when Stack Overflow became popular, but it still created an almost magical aura of competence around these developers. Having a secret stash and knowing which Stack Overflow answer to trust was a real, monetisable skill. And it’s worth nothing now. I don’t miss it even slightly.
So what actually collapsed? Not the knowledge – not the real kind, at least. What collapsed was its scarcity, its lack of access. And that scarcity was doing far more of the work in your salary than any of us wanted to admit.
And that’s why the AI revolution may be painful for some developers. It’s not the $11 the market valued their code at. For a lot of us, being the person with the answer was the seniority.
Take that away, and what remains to support the self-image built over the years?
It was never about the code
In 1944 one of the units for computing work was the kilo-girl – a thousand hours of women doing arithmetic by hand at desks, because “computer” was a job title long before it was a machine. Alan Turing described a human computer as someone following fixed rules, with no authority to deviate from them in any detail. Read that last sentence again and tell me it doesn’t describe a ticket you closed last week.
By 1952 Grace Hopper had built the A-0 System on the UNIVAC I and proposed the word compiler for it. The establishment’s reaction? Nothing at all. Not even outrage. She had a running compiler and nobody would touch it, while colleagues patiently explained that computers could only do arithmetic and couldn’t possibly do programs. It took 2 years to get the thing accepted. John Backus, building the first FORTRAN compiler around the same time, had a word for the culture doing the resisting: a priesthood.
But you don’t need to reach back that far to find real, well-paid skills that died off with the advent of new technology. In 2011 Apple shipped ARC in Xcode 4.2, and a compiler feature quietly took over the retain and release calls that had been a genuine differentiator between iOS developers. Forgetting to release a variable meant a memory leak – pretty much like leaving a strong delegate reference does now. But over-releasing? That crashed the app. Believe it or not, some people built an entire iOS career on being able to confidently spot those mistakes in a code review. Then the compiler did all the retaining and releasing for you, the moment you switched to ARC. And just like that, a real money-making skill became essentially worthless. Nobody wrote a doom-post about it. We got on with building better apps, because the attention we got back went somewhere more useful.
In February 2026, Anthropic published a blog post about pointing Claude Code at COBOL, showing how much of a migration to Java it could take over. Almost immediately IBM stock dropped 13% in a day – its worst single-day drop since 2000, dragging Accenture and Cognizant down with it. Here's the detail people missed: IBM had been shipping its own COBOL-to-Java AI assistant since 2023. Its CEO had called adoption wide, and the mainframe business had just posted its best revenue in 20 years. The capability to do the conversion wasn't new. The market simply worked out that you could now get it cheaper.
So what did all those repricings have in common? Every one of them hit the bottom two floors and left the top three alone. The compiler ate the translation, not the judgement. ARC ate the bookkeeping, not the architecture. AI eats the COBOL, but someone still has to work out which of those 250 billion lines encode a business rule nobody ever wrote down. And which encode a bug the company has been quietly relying on since 1987.
So, the hierarchy of developer skills isn’t new. Neither is the panic that follows when skills at the bottom of the stack lose their monetary value. What's new is the speed. This is the first repricing fast enough that you can watch it happen inside a couple of years, rather than across a long, successful career in software development.
Which makes the next question the only one worth asking. What's still standing?
Only the Valuable Survive
Unsurprisingly, none of it is producing code. That has been repriced steadily for decades, as we just saw. And now it sits at around $11. In the same span of time, a few things haven't moved. They sit on either side of producing code.
On one side: deciding what gets built at all. The cheapest feature has always been the one you talked somebody out of. And you get there by asking the right questions – of the client, of the stakeholders, and now of the model. Same skill, new listeners.
On the other side: judging what came out. Did users accept it? What do they want changed? Is the code solid enough to scale the app, and the team along with it?
To illustrate what stood the test of time, let me tell you about the most valuable week of my career. The one in which I produced no code at all.
Back in 2010 I was slowly growing into a senior developer position in an educational company, specialising in multimedia language courses. One of our biggest clients sent over a list of changes that made little sense to me. They essentially required most of the app to be rewritten, while providing almost no benefit to the end user – the students. About 5 months of work for one developer: a developer we didn't have, and would have to hire, onboard and cover for. And all of it on an aggressive timeline nobody had explained.
So I asked to speak to the client directly. At the time that was close to heresy. Client conversations belonged to PMs and account managers, and plenty of them had built their position in the company on being the only people who understood the business. A developer in that room threatened their very job description.
I got the meeting. Beforehand I sent the client an email with one question: what are you actually trying to achieve here, and why? It turned out they had a working demo to put in front of a ministry, and missing that date meant losing the contract. None of that was anywhere in the change requests.
So I went back through each requested change and returned with three options:
- Option A: verbatim what they had asked for, priced honestly.
- Option B: a cheap version that would ship on Monday and haunt us by Christmas. Also priced honestly.
- Option C: the one I recommended, which delivered most of what they actually needed within the timeline they had.
The result of the meeting? The client accepted nearly all of the Option C recommendations on the spot. The few they turned down came down to budget and ministry approval timelines – reasons I would never have guessed from a ticket list.
Ultimately, the entire gig took 3-4 weeks. No extra hire. And a client who secured their ministerial contract and started treating us as a technology partner, not just a supplier.
Architecture survived too, just not as the diagrams you might remember from your university days. It survived as the art of compromise – which matters more now that with AI you can go really fast and break a lot more things.
An AI agent will happily hand you a Codable struct doing double duty as a domain model, or a view model reaching straight into the network layer. To make matters worse, it will be clean, tested and entirely plausible. The difference between a senior developer and an agent isn't that the senior wouldn't make that trade. It's that the senior makes it deliberately. Naturally, they try to reason with the client and propose alternative solutions first. If that fails, a senior records the reasons behind the decision and its likely implications. As a comment in the code, or otherwise.
The next skill that stays valuable is defining what good enough actually means. Agents have become very productive at generating code that looks fine, compiles and makes the tests pass. Hand one a goal and a definition of done – a coverage threshold, a green build – and it will grind away until it is met. Which makes defining these goals critical. An agent optimises for exactly the target you set. And not one inch past it.
And yet green numbers have never meant the task is done. The only way to tell is to read it. And reviewing generated code is a genuinely different skill from reviewing a colleague's. There's no intent to reconstruct and nobody to ask what they were thinking. I've dedicated an entire post to the challenges that reviewing AI-generated code brings.
What else survived? Writing clear, concise specifications. It used to be an undervalued, soft skill. Human developers expertly filled in the gaps and narrowed vague acceptance criteria left by whoever created the task. Now that is no longer an option. An agent always produces something, and it will cheerfully invent the missing parts of the scope. Plausibly, confidently, and usually wrongly. Ambiguity in Jira tasks translates to ambiguity in the prompts, which in turn shows up as ambiguity in the PR. At unprecedented speed and volume.
So, what should change in how we perceive our work as software engineers? Surprisingly little. It's enough to stop measuring a week by how much code came out of it. Instead, focus on decisions made, trade-offs documented, and colleagues who needed to ask you fewer questions than last month. Spend the hours AI saved you talking to people: product, stakeholders, the users. In other words, floors four and five. Get their feedback and use it to narrow down the specifications and task descriptions.
In short: the work you were hired for.
No country for young men?
Everything above assumes you already have the necessary judgement. That you can tell good code from bad, recognise anti-patterns, spot issues before they surface. Mine came from my battles with iOS navigation. My first few apps had it wired straight into the UIViewController – present, push, dismiss scattered across the screens themselves. It worked. Then I added just another screen. And another. Eventually every new screen meant touching six existing ones, and every change broke something three screens away.
And the worst part was knowing it wasn't supposed to be this hard. Design patterns were everywhere – books, blog posts, conference talks. The problem was that nearly all of them were written for Java, C#, or the web. I could see the outline of a solution and had no idea how to translate it into a UIViewController lifecycle. So I had the bruises, plus a growing suspicion that somebody had solved this properly and hadn't told me.
Then a fellow developer suggested the coordinator pattern, and I have never been able to unsee it. I had paid for the readiness the hard way, so a 15-minute whiteboard conversation landed like a revelation instead of a diagram.
So the apprenticeship needed two things: enough repetition to make me ready, and somebody nearby who already knew. Just like the old proverb: When the student is ready, the master appears. It isn’t mysticism. It’s sequencing.
Now the elephant in the room. That apprenticeship was never a gift. It was a trade, and the terms were brutal.
Let me put myself on the wrong side of this ledger first. A junior costs money. They break the build. They take an afternoon of a senior’s week and hand back 20 minutes of work. Occasionally they say something in front of a client that takes a month to walk back. I did every one of those things, and nobody ever billed for the afternoons I cost.
What the company got in return was code. Not especially good code, but a lot of it, cheaply, and it was the one thing a junior could reliably, enthusiastically produce. That was the down payment on 2-3 years of tuition. And that is longer than the average tenure, so the company paying for the training was rarely the company collecting on it. Training juniors sat closer to charity than to strategy. Reluctant charity at that.
Now that down payment is worth $11. Worse than that: a senior with an agent produces the same volume, without the broken builds, the lost afternoons or the client incidents. A junior isn’t competing with other juniors any more. They’re competing with the cheap version of themselves.
So how is anybody supposed to get experience now?
The shortest apprenticeship in history
What AI truly removed is the entry grind. The hours spent getting the thing to compile. The Stack Overflow archaeology. The question posted to an iOS Slack channel at 1am that nobody ever answers. All gone, and good riddance – none of it taught me a single thing about the upper floors of the pyramid.
What AI did not remove is the pain. Vibe-code a feature and you still get the crash reports. You still get the 1-star review saying the app lost somebody's data. You still get the task bounced back by QA for the fourth time. And that hurts in exactly the way that sends you to the books, to the blog posts, to the colleague who has seen it before. Which is the moment you find out what you didn't know. The pain still teaches. It just arrives faster now, and it costs more – it used to be paid in your own wasted evenings, and now it gets paid in production.
Which is the opportunity, and it is enormous. The years I spent buying readiness by repetition are no longer the price. Spend the hours the agent gave back to you on everything I had to squeeze around the grind: read the books, refine your rules files and skills. Make the agent justify the trade-off it just suggested. Argue with it if you are not convinced. As the models have improved, you have gained almost unlimited access to an infinitely patient senior – one who never sighs, never has a sprint deadline and never makes you feel stupid for asking. Use it!
There's a limit, though, and my own story is the proof of it. Asking an agent to explain something works beautifully for the things you know you don't know. I didn't know the coordinator pattern existed. I couldn't have asked for it. I had read every patterns book going and still couldn't see it, because what I needed was somebody to look at my code and say: this has a name. An agent will sometimes volunteer that. Recognising it as important when it arrives is the part you don't have yet.
That's also what makes the shortfall hard to spot from outside. A junior with an agent produces work that looks like floor two output – sensible naming, tests present, conventional structure, green CI. Reviewing it properly takes exactly the judgement that writing it used to build. So where does the gap show up? Not in the pull request. In the incident, 6 months later, at the worst possible hour.
The question is whether the pain sends you looking, or whether you just ask the agent to make it go away. Looking means reading every line before you ship it, and owning the floor three problems: the crash nobody can reproduce, the performance nobody wants to measure, the logs everybody skips. Debugging is the fastest route up this pyramid that still exists, because you cannot debug a system you don't understand.
Which is what makes floor four the scarcest part of the pyramid rather than the softest. Because the proverb has a catch as well. The master has to actually be in the room. And the industry is quietly concluding it doesn't need juniors at all – a decision that holds up right until the seniors decide to leave the company. Or start retiring.
Their loss. Right now, you can reach floor three – real architectural judgement – in a fraction of the time it took my generation. And that flips the ledger completely. If the apprenticeship pays back inside a tenure instead of after it, hiring juniors stops being charity and becomes the best deal in the industry. The maths finally started to favour them, right at the moment everybody stopped looking. Whoever carries on making seniors will own the decade after that.
The best time to be a developer
So: no country for young men? Not quite. It’s the best country there has ever been for one – provided somebody stays in the room long enough to look at their code and say this has a name.
Here’s what that $11 actually bought. It bought the bottom of the pyramid, the part that was only ever expensive because it took so long to type. It did not buy the decision about what to build. It did not buy the compromise you make deliberately and write down for whoever comes next. It did not buy the judgement that knows green tests and finished are different things, or the team that got sharper because you were on it.
Those were always the job. We just couldn’t see them clearly, because the typing took up the whole week.
Now it doesn’t. That’s the entire story. The pyramid didn’t change shape – the base got cheap, and everything above it got more valuable at exactly the same moment.
Which means the strategy really does write itself. Hand the bottom floor to the machine, gladly. Then go and spend what you get back climbing the floors you always meant to reach.
The pyramid hasn’t changed. The queue to climb it just got a lot shorter.
Don’t miss any new blogposts!
By subscribing, you agree with our privacy policy and our terms and conditions.
Disclaimer: All memes used in the post were made for fun and educational purposes only
They were not meant to offend anyone
All copyrights belong to their respective owners
