I’ve written before about career strategies that protect you as a software developer in a fast-moving industry. This post asks the same question about one force in particular, AI. Coding assistants started out as a chat window that could explain an error message. The current tools can read a whole repository, change a dozen files and run the tests before a human looks at anything. Some work that developers used to do by hand is gone for good. A lot of the commentary about it is either panic or hype, so I want to stick to three practical questions. What do we still need to carry in our heads? How is day-to-day problem solving changing? And how should we learn from here on? My short answer is that memorized detail matters less and understanding matters more, because more of the job is now judging code that someone, or something, else wrote.

What changes when answers are cheap

For most of the history of software, being good at the job meant carrying a lot around in your head, from API signatures to the flags for tar. When you didn’t know something, you searched the documentation or Stack Overflow, and the search itself taught you things along the way. Now an assistant answers in seconds, usually with code that already fits your project. That changes what’s worth memorizing.

Psychologists saw a version of this long before large language models. In a 2011 study published in Science, Betsy Sparrow and her colleagues found that when people expect to be able to look something up later, they remember where to find it more readily than the fact itself. With AI, that effect gets much stronger. You don’t even need to remember where the answer is. You only need to ask.

The catch is that looking something up only works if you can tell a right answer from a wrong one. Brian Kernighan once wrote that debugging is twice as hard as writing the code in the first place. That applies even more to code you didn’t write: if you couldn’t have written it yourself, you’ll struggle to review it. So the knowledge worth carrying is understanding, such as what a database transaction actually guarantees or why two threads incrementing the same counter lose updates. That understanding is what lets you catch a confident wrong answer, and it goes out of date far more slowly than syntax does.

This also changes what expertise looks like. Expertise now includes asking a question precisely enough to get a useful answer, and giving the tool the context it needs: your conventions, your constraints, what you’ve already tried. Many teams now keep that context in instruction files the tools read automatically, such as AGENTS.md, CLAUDE.md or .github/copilot-instructions.md. Expertise also includes checking the result before trusting it. Developers who were good at writing clear tickets and reviewing pull requests have a head start, because those are the same skills.

How problem solving is changing

A few years ago, a typical bug hunt meant searching forums, reading documentation, trying fixes until one worked, and asking the person at the next desk. Today you can paste in a stack trace and get an explanation of the likely cause, ask for three alternative designs and compare them, or hand a well-defined change to an agent and review the diff it produces. Assistants can also flag likely bugs and security issues in a pull request before a human reviewer sees it. They can explain an unfamiliar framework using your own code as the example, which makes learning in context much faster than it used to be.

How much faster all this makes you is less clear than the marketing suggests. In GitHub’s 2022 controlled experiment, developers using Copilot finished a self-contained task, writing an HTTP server in JavaScript, 55.8% faster than developers without it. In 2025, METR ran a randomized study with experienced open-source developers working on real issues in repositories they knew well. With AI tools, they took 19% longer. And they believed afterwards that the tools had made them about 20% faster. Stack Overflow’s 2025 Developer Survey found a similar gap: 84% of respondents use or plan to use AI tools, yet more of them distrust the accuracy of the output (46%) than trust it (33%). The most common frustration was solutions that are “almost right, but not quite.”

My takeaway is that the gains are real for well-defined, self-contained work, such as boilerplate, tests for existing code, unfamiliar APIs and one-off scripts. They’re smaller, or even negative, for work that depends on deep context you already have. Measure your own work. How fast it feels isn’t a reliable guide.

The risks worth taking seriously

Skill atrophy. If the tool always writes the first draft, you stop practicing the reasoning that makes you able to judge drafts. This matters most for people early in their careers, who may never build the mental models in the first place. The job market reflects the same pressure. A 2025 Stanford Digital Economy Lab paper found that employment of software developers aged 22 to 25 had fallen by nearly 20% from its late-2022 peak, while employment of older developers held up.

Almost-right code. Generated code tends to look plausible and pass a quick skim. The bugs sit in edge cases, error handling and assumptions about your system that the model couldn’t know. Review it the way you’d review a confident junior developer’s pull request: read every line, and run the tests.

Security. Models sometimes suggest packages that don’t exist. Attackers have started publishing malicious packages under those invented names, a practice now called “slopsquatting.” Generated code can also bring back insecure patterns that your team removed years ago. Check every new dependency before you install it.

Confidentiality. In 2023, Samsung restricted the use of ChatGPT after engineers pasted proprietary source code into it. Before you share company code with a tool, check your employer’s policy and the tool’s data-retention terms.

Accountability. If you merge it, you own it, regardless of who or what typed it. Licensing questions around AI-generated code are also still unsettled in some places. A team that uses these tools needs to agree on how generated code is reviewed and who signs off on it.

Where to spend the time AI frees up

When routine code takes less time, the hard parts of the job get a bigger share of your day. These are the areas where I’d put that time:

Defining the problem. An agent will happily build the wrong thing quickly. Turning a vague request into clear requirements, acceptance criteria and a list of edge cases is now the bottleneck, and it’s a deeply human skill, because it means talking to people who aren’t sure what they want.

Design and architecture. Decisions about service boundaries, data models, consistency and failure handling shape a system for years. AI can propose options, but deciding between them depends on context about your organization, your traffic and your team that the tool doesn’t have.

Testing strategy and review. AI can write test cases. Deciding what is worth testing, and reading results critically, is still your job. When more code is generated, review becomes a bigger part of the work, not a smaller one.

The domain and the user. Knowing how insurance claims, logistics or clinical workflows actually work, and what makes an interface easy or confusing to use, is knowledge a general-purpose model doesn’t have about your business. It’s also what turns a developer into the person others ask first.

Technical debt. Large refactorings and test backfills used to be too expensive to justify. AI makes them much cheaper. It also makes it cheap to produce code nobody fully understands, so someone on the team has to watch the codebase’s health.

Mentoring. If junior developers are going to build real skills alongside these tools, experienced developers have to teach the reasoning the tools skip, especially why one approach is better than another.

Building with AI. Most developers won’t train models, but many will integrate them. That means calling model APIs, retrieval-augmented generation over company data, evaluating output quality, controlling cost and latency, and handling the cases where the model is wrong. Regulation is part of this work too. The EU AI Act took effect in August 2024, and its obligations are being phased in over the next few years.

How I’d learn now

Use AI as a tutor, not a ghostwriter, when you’re learning. In an area that’s new to you, write your own first attempt, then ask the assistant to critique it and explain what it would change and why. Ask it to quiz you, or to walk through code you don’t understand one line at a time. You get the speed of an expert on call without skipping the struggle that makes the knowledge stick. In areas you’ve already mastered, let it write as much as you like.

Go deep in one area, and broad across others. This is the T-shaped profile. Deep expertise in one field (performance, security, a particular domain) is still hard to replace, because it’s exactly the knowledge needed to judge AI output in that field. Broad knowledge of the neighboring areas lets you work across them and see connections specialists miss.

Learn, unlearn and relearn. Alvin Toffler, quoting the psychologist Herbert Gerjuoy in Future Shock (1970), wrote that the illiterate of the future would be people who cannot learn, unlearn and relearn. Some of what made you fast five years ago is now a habit worth dropping, such as typing out boilerplate you could generate, or refusing help on principle. Learning how to learn new tools quickly is worth more than any one tool.

Write things down. A personal knowledge base, whether that’s Obsidian, a folder of Markdown files or a wiki, holds the decisions, snippets and lessons specific to your work that no model knows. It also gives you context to hand to the tools when you need it. Writing clear specifications and design notes is the same skill as giving an agent good instructions, and it makes you easier to work with as a colleague too.

Invest in the human side of the job. That means communication, negotiating scope with stakeholders, giving and receiving feedback, and building a network of people who will tell you honestly what’s changing in their part of the industry. A good mentor and a good network notice shifts in the job market long before they show up in articles like this one. Basic business sense helps too: how your company makes money, and what a feature is worth compared with what it costs. If you can, don’t depend on a single source of income.

Automate your own chores. Scripts, templates and agents can take over the repetitive parts of your week, such as release notes, data migrations and environment setup. Every hour you get back is time for the harder work above.

Protect your attention. When an answer is always one prompt away, it’s easy to replace thinking with asking, and to spend the day switching between twenty half-finished threads. Cal Newport’s Deep Work and Digital Minimalism both argue that long, uninterrupted focus is becoming rarer and more valuable. I agree. Block out time to work on a hard problem with notifications off, and that includes the chat window.