In 2019 a client paid me for two days of work to build a WordPress custom post type with a filtered archive. In 2026 I can describe that to an AI assistant and have a working draft in four minutes. The same client still pays me, for more than before, because the four-minute draft is the least valuable part of the job. This is what changed, what did not, and how I restructured my own learning so I would be on the right side of it.
What actually got cheaper
The honest list of what AI now does as well as or better than a mid-level developer, on a good day:
- First drafts of well-specified functions, components, migrations and configs.
- Boilerplate: CRUD endpoints, form validation, test scaffolding, Dockerfiles, CI YAML.
- Translation between languages and frameworks, and explaining unfamiliar code.
- Recalling APIs and syntax, the thing Stack Overflow used to be for.
- Small, contained bug fixes where the error message points at the cause.
If most of your day was that list, the market has noticed. Rates for "convert this Figma to HTML" and "build me a basic CRUD app" have fallen, and the volume of that work has fallen too, because the client's nephew can do it with a chatbot now.
What did not get cheaper
Every project I worked on this year spent most of its budget on things the assistant could not do alone:
- Deciding what to build. The client wanted "AI search". The actual problem was that their category pages were badly organised. A semantic search was the right answer, but only after a conversation nobody could have had with a model.
- Debugging across boundaries. A checkout failing 2% of the time turned out to be a race between a WooCommerce hook, a Redis cache and a CDN rule. No single file contained the bug. Finding it needed a mental model of the whole system and an afternoon with logs.
- Reviewing generated code. The AI's draft of an auth flow was 95% right and put the refresh token in
localStorage. Catching that requires knowing why it is wrong, which is exactly the knowledge that the "just generate it" approach never builds. - Trade-offs with consequences. Monolith or services, headless or not, build or buy. The model will argue either side convincingly; someone has to be accountable for the choice a year later.
- Communication. Explaining to a non-technical founder why the two-week estimate is now five, in writing, without losing the client.
These were always the senior skills. AI did not create them; it removed the junior work that used to hide whether you had them.
The shift: from writing code to owning outcomes
The rough shape of where my billable hours go, then and now. The bottom two rows shrank; the top two grew, and they pay better per hour. The job title did not change. The job did.
How I actually use the tools
The mental model that works for me: an AI assistant is a fast, well-read junior developer with no memory of the project and no accountability. I delegate the way I would to that person.
- I design, it drafts. I write the interface, the data shape, the constraints and the edge cases first; then I ask for an implementation. Asking for "an order service" gives you generic code; asking for "a function with this signature, transactional, idempotent on this key, throwing these errors" gives you code you can review in two minutes. The prompt engineering post is really about this.
- I review everything, and I review harder than I would review a human, because the code looks confident regardless of whether it is right. Security, concurrency, error paths, and "does this match the actual API" are where it fails.
- I use it most for the unfamiliar. A Rust tool, a Terraform module, a Cloudflare Worker: the assistant gets me to a working draft in a stack I do not know well, and my general engineering judgement carries the rest. The range of what I can ship went up more than the speed.
- I keep doing hard things by hand. Once a week or so I solve something without the assistant: a tricky query plan, an algorithm, a debugging session. Not for purity; because the review skill in point 2 decays if it is never exercised.
- I write more, not less. Design docs, decision records, PR descriptions. The tools make writing cheap and the writing is what makes the delegation precise.
What to learn now
This is how I reorganised my own study time in the last two years, roughly in priority order.
1. Systems, not syntax
How a request flows from the browser through a CDN, a load balancer, an app server, a cache and a database, and where each can fail. Caching, queues and rate limiting; how databases actually execute queries; networking basics; what happens during a deploy. This knowledge transfers across every language and is what debugging across boundaries requires.
2. Shipping AI features, end to end
Not prompt tricks: the engineering around a model. Retrieval and chunking, embeddings and vector indexes, evals that catch regressions, cost and latency budgets, tool-calling architectures, safety and access control. I wrote up what I learned building these as RAG pipelines, MCP servers and agent patterns. The developer who can do this reliably is scarce, and clients will pay for the reliability far more than for the novelty.
3. Reading and reviewing code, fast
You will read ten times more code than you write. Practice: review open-source PRs, read the source of the libraries you depend on, do code review for colleagues with an explicit checklist (correctness, security, failure modes, performance, clarity). This is the skill that makes AI output safe to ship.
4. Product and business literacy
Why the client wants the feature, what it is worth to them, what the simplest version is. The developers I see winning remote work are the ones who can push back on a spec with a better idea. That comes from talking to users, reading about the client's industry and asking "what does success look like" before "what stack".
5. Writing
Clear written communication was always undervalued in engineering and is now the primary interface to both the tools and remote teams. A precise spec gets a precise draft from the model and a precise estimate from a colleague. If you do one thing from this post, write a short design doc before your next feature.
What not to do
- Do not refuse the tools. "I don't use AI" is not a principled stance; it is a productivity handicap, and clients can tell.
- Do not become dependent on them. If you cannot explain the code you shipped, you did not ship it; the model did, and you are the liability.
- Do not chase every framework. Breadth of shallow knowledge is exactly what the model already has. Depth in a few things plus systems understanding is what it lacks.
- Do not stop building things. Side projects, this portfolio, open source. The habit of finishing is a skill, and a public record of finished work is still the best hiring signal there is (see the portfolio guide).
AI made average developers faster and made the gap between average and senior more visible. If your value was typing speed and recall, that is a threat. If your value is judgement, debugging, review and communication, the tools are the best thing that has happened to your career, because they took away the parts of the job that were never the point. I am considerably more useful to clients than I was in 2019, and I write far less code by hand. Both of those are true at once.
If you are preparing for the interviews that test these skills, the remote interview prep guide is the practical companion to this post: system design, live coding with tools allowed, and the written communication rounds that remote-first companies now use.