Writing Code Is No Longer Enough Link to heading

Agents have commoditised software output. That is the uncomfortable fact at the centre of every conversation about AI and engineering that most people are still dancing around.

The role of the software engineer has not disappeared. But the part of the job that most engineers spent their careers getting good at - the part where you sit down, understand a problem, and write code that solves it - is increasingly the part that agents do well. They do it quickly, at volume, without interruption, and at a cost that continues to fall.

The question is not whether this changes things. It already has. The question is what the job looks like now, and what skills actually matter.

The Pair at the Keyboard Link to heading

Most engineers who have done pair programming know the dynamic. One person drives - hands on the keyboard, focused on the immediate problem, solving for exactly what is in front of them. The other navigates - not typing, but holding the broader picture in their head. The navigator spots the inconsistency in a naming convention three files back. They remember the architectural decision made an hour ago. They notice that the solution being built will work for the happy path but break on the edge case discussed in planning.

Being on the keys narrows your focus. That is not a criticism; it is how concentration works. When you are solving for the code in front of you, some of the broader context drops out of view. The navigator’s job is to hold that context and speak up.

AI is now on the keys.

An agent will write code confidently and quickly. It will solve the immediate problem you put in front of it. It will also, if you let it, miss the edge case, break the convention, or produce something technically correct that does not fit the system it is being added to. The human is now the navigator - and being a good navigator is not a passive role. It requires knowing the system well enough to recognise when the agent has gone off-course, and being confident enough to redirect it rather than just approving the output.

That confidence does not come from knowing syntax. It comes from domain knowledge.

There is a real risk worth naming here: if you are not confident in your own capabilities, you end up saying yes to everything. The agent produces output, you approve it, and you ship its mistakes as your own. A navigator who cannot read a map is not a navigator; they are just a passenger.

Two Paths Forward Link to heading

There are two ways to be genuinely valuable in this arrangement.

The first is deep domain knowledge. If you understand a problem space thoroughly - the real-world constraints, the commercial realities, the way the moving parts interact across the full stack - you can direct an agent to produce useful output without the work passing through a chain of other specialists. Previously, a domain expert with a problem needed a solution designer, an architect, a project plan, and a development team before anything was built. That chain exists to transfer knowledge between people who each hold a part of the picture. Now a domain expert who can drive an agent can go from problem to deliverable directly, collapsing those handoffs and the meetings where context gets lost in translation.

The second path is genuine breadth - a spread of adjacent skills across systems, disciplines, and domains. The person who understands enough of the front end, the back end, the infrastructure, the product side, and the commercial context to navigate an agent across all of them. This is not the old-fashioned generalist who knows a little of everything. It is about having enough of the map that you can direct the agent, even in territory you have not fully explored before.

What is not a path forward is being very good at writing code. That is what the agent does now.

What This Actually Looks Like Link to heading

I was made redundant as a senior software engineer.

I then landed a platform architect role - not because I had prior experience as an architect, not because I passed a coding challenge (there was not one), and not because I knew the company’s technology stack. I landed it because I have deep domain knowledge in identity and Customer Identity and Access Management (CIAM), I understand how those systems interact across the full stack, I understand the commercial realities of the space, and I could demonstrate the ability to turn that knowledge into deliverables in a very short space of time.

The interview was not about code. It was about the shape of the problem space, how identity infrastructure interacts with product decisions, and what it takes to move from a current state to a better one. Domain knowledge carried the conversation.

What I have done since starting is not what a new architect would typically do in their first weeks. The existing codebase had been built over several years and no single person on the team was fully across all of it. Rather than spend months reading through it, I deployed agents and had them do it.

The agents worked through the written corpus in the codebase - the code, the comments, the config, the existing documentation - combined with my own product and domain knowledge expressed through prompting. The output is roughly 200 pages of documentation; code docs, flow charts, as-is architecture, all in markdown and checked in as source. That is not a personal reference. It is output for the team. Anyone can read it to understand how the system works, and a new agent session can read it at the start of a task and have the context it needs to make useful recommendations without needing a lengthy briefing.

The point is not that the documentation is impressive. The point is that it was produced in a fraction of the time it would have taken any single engineer working conventionally - because the knowledge I brought to the prompts is what shaped the output. The agent was on the keys. I was the navigator. The navigation required knowing identity systems well enough to direct what the agent produced.

The Skills That Actually Matter Now Link to heading

Prompt engineering and specification writing. Knowing how to brief an agent precisely enough that it produces what you actually want. This is a real skill. Vague prompts produce confident but inconsistent results. If you have not spent time getting deliberately better at this, start.

Building agent capabilities. The meta-skill: making agents better at specific tasks by giving them reusable context, constraints, and instructions. The agents that produced the documentation at my new role work as well as they do partly because of how they were set up, not just what they were asked to do. A well-configured agent that understands its task, its constraints, and the standards it is working to produces better output than a capable model receiving a vague prompt.

Critical evaluation. If you cannot tell good output from bad, you will approve the agent’s mistakes and ship them. This is the most important skill of all, and it is entirely dependent on domain knowledge. The navigator is only useful if they can read the map.

Preparing for the Interview That Matters Now Link to heading

The hiring process has not changed much. Screening call, technical assessment, culture fit, offer. HR moves slowly and that will not change quickly. But what you should be preparing for is different.

The role you should be applying for is one that agents cannot replace; domain knowledge roles, architecture roles, product-informed engineering roles where the value is in understanding the problem space rather than writing the code.

Preparation is also different now. I did four mock interviews with an AI agent before the real one. The experience is genuinely useful in a way that reading interview tips is not - you get the discomfort of answering under pressure, you get feedback, and you can run it again until you are not guessing. I built a small tool to help with this (https://ace-my-screening.pages.dev/) that generates a prompt you take to Claude, ChatGPT, or Gemini; it runs you through a mock interview for a specific role and produces a markdown summary you can use to prepare your screening call answers in your own words. Sadly the source was on my old work laptop so I can’t change the published state, but it’s there if you want to give it a try.

The broader point is to use the tools available. The people on the other side of the interview who are already doing this have an advantage.

The Wave Is Coming Link to heading

There are going to be a lot of people competing for a lot fewer roles, and that is not a distant scenario. It is what is beginning to happen now.

The engineers who make the shift early - who recognise that their value is not in their ability to write code but in their ability to direct agents with authority, domain knowledge, and a clear sense of what good looks like - are going to land well. The ones who do not make that shift are going to find the market has moved around them.

The keyboard is still there. If it hasn’t already, it’s what you do with it that needs to change.