The Developer's Job When AI Writes the Code: Seven Skills That Now Decide Your Value

When AI can generate a working-looking pull request in ninety seconds, the developer’s job is no longer to produce code. It is to produce evidence: that the change is correct, that it is safe, that the people it affects understand it, and that the team is better at its job afterwards. Seven skills now decide a developer’s value in the AI era: testing, code review, quality ownership, presentation, release notes, proactivity, and coaching. Only two of them are about code.

Last quarter a developer on a payments team I work with shipped a change to the fee calculation for cross-border transfers. The code was clean. The tests were green, all fourteen of them. The assistant had written both. On the first business day after release, operations found that transfers with ChrgBr set to SHAR were charging the full fee to the debtor, because the tests asserted what the code did rather than what the rule said. Fourteen tests, all confirming the bug.

Nobody in the incident review blamed the model. They asked the developer how they had verified the change, and the honest answer was: I ran the tests. That answer used to be fine when a human had written the tests with the rule in their head. It is not fine any more, and that shift is what this article is about.

I have spent ten years on delivery teams in banking and payments, sitting between business, developers, QA, and production support. The developers I now see pulling ahead are not the fastest typists or the best prompters. They are the ones who can prove, explain, and own a change. The testing half of that is where most teams are weakest, which is why I built API Testing and QA Mastery for BAs around deriving tests from rules rather than from code. This guide is the map. Each skill below has its own deep dive.

What actually changed for developers when AI started writing code?

Three things changed, and they compound.

Generation became cheap and verification did not. Producing a plausible diff went from hours to seconds. Proving that diff correct still takes the same effort it always did, and arguably more, because the author no longer carries the reasoning in their head. The ratio of code produced to code understood has shifted, and every team now carries more code that nobody fully reasoned through.

The volume of change went up. A team with assistants opens more pull requests per week. Every one of them still needs review, testing, release communication, and support readiness. If those activities do not scale, they become the bottleneck, and the bottleneck is where the value sits.

The author became the reviewer of their own work. When you write code by hand, you review it as you type. When a model writes it, you receive it finished and must review it cold, like someone else’s pull request. Many developers never learned to do that well because they rarely had to do it to their own work.

The practical consequence: the developer is now paid for judgment and accountability. The skills that express judgment and accountability are the seven below.

What are the seven developer skills that matter in the AI era?

Skill	The question it answers	Where AI helps	Where AI cannot sign
Testing	Does it do what the requirement says?	Drafting cases, fixtures, data	Choosing the oracle: what “correct” means
Code review	Is this diff safe to merge?	Summaries, lint, static analysis	Judging intent, fit, and risk
Quality ownership	How does it behave under load, failure, and time?	Suggesting checks	Owning the non-functional contract
Presentation	Does the stakeholder understand enough to decide?	Slides, script drafts	Choosing what to show and what it proves
Release notes	Does every affected reader know what changed for them?	Drafting from commits	Stating impact and action per audience
Proactivity	What is going to go wrong that nobody has asked about?	Surfacing patterns	Deciding it matters and raising it
Coaching	Is the team better at this next month?	Explanations on demand	Building judgment in another person

Read the right-hand column. That is the job description now.

Testing: why is it the first skill to upgrade?

Because it is the one AI most convincingly fakes. An assistant asked to “write tests for this function” will read the function and assert its current behaviour. That produces high coverage and zero protection: the tests pass for the bug and will keep passing for it forever. I call these mirror tests, and in the fee example above every one of the fourteen was a mirror.

The upgrade is to derive tests from the requirement, never from the implementation. Give the model the rule, the boundaries, and the examples, and withhold the code. Then test the tests: mutation testing tools such as Stryker for JavaScript and TypeScript, PIT for Java, and mutmut for Python deliberately inject bugs and report which ones your suite failed to notice. A surviving mutant is a test you do not have.

Three techniques carry most of the weight: boundary and equivalence analysis for inputs, property-based testing for rules with large input spaces (Hypothesis in Python, fast-check in TypeScript, jqwik in Java), and contract tests at every service boundary. The full method, with code, is in Developer Testing in the AI Era.

Code review: what is different when the diff was generated?

The failure modes are different. Human-written bugs cluster around fatigue and misunderstanding. AI-written bugs cluster around plausibility: a method that does not exist in your version of the library, a package name that looks right but is not the one you meant, an exception caught and logged instead of handled, a helper duplicated because the model did not know one already existed, a test quietly edited so it passes.

Review order matters more than it used to. Intent first: does this change do what the ticket needs and nothing else? Then the tests: were they derived from the requirement, and did any existing test change? Only then the code. Mechanical checks (formatting, types, lint, secrets, known-vulnerable dependencies) belong to the pipeline, so human attention goes to behaviour. The checklist I use and the pull request template that makes it fast are in Code Review When AI Wrote the Diff.

One rule deserves stating here because teams keep getting it wrong: a pull request produced with AI is still the author’s pull request. “The model wrote it” is not an answer in an incident review, and a team that accepts it slowly loses the ability to reason about its own system.

Quality ownership: what does a developer own beyond the tests?

Everything that the tests do not naturally reach. The behaviour at month-end volume. What happens when the downstream sanctions screening service times out. Whether a retry is safe, which is the question idempotency testing answers. Whether the log line on the failure path carries the end-to-end identifier that support will search for at three in the morning.

AI assistants are weakest exactly here, because non-functional behaviour is rarely visible in the code they are given. They write the happy path fluently and the timeout path vaguely. A developer who owns quality asks four questions of every change: what happens when it is slow, when it fails, when it runs twice, and when someone has to debug it without me. If you cannot answer one of them, that is a non-functional requirement nobody wrote, and you have just found it.

Quality ownership also means making production observable before you need it. Structured logs with correlation identifiers, a metric on the business outcome and not only on the HTTP status, and an alert that someone has agreed to act on. None of that appears in a generated diff unless someone insists.

Presentation and release notes: why are they now engineering skills?

Because the bottleneck moved downstream. When a team ships twice as many changes, the people who absorb them (users, support, operations, compliance, other teams) do not double their capacity. A change that is poorly explained creates tickets, workarounds, and mistrust, and each of those costs more than the change did to build.

Release notes are written for readers, not for the git log. A commit message says fix(fees): apply SHAR split in cross-border calc. A release note says: cross-border transfers with shared charges now split the fee between debtor and creditor agents as the rulebook requires; transfers booked between Monday and today were overcharged and are listed in the attached report; support should use macro FEE-12 for customer queries. The first is for developers. The second is for the people who will be asked about it.

Demos exist to let someone decide: accept the story, go live, change direction. A good developer demo shows the before, the change, and the failure path, and ends on the decision it is asking for. The structure, the release note template per audience, and how to use AI to draft both without shipping AI prose are in Release Notes and Demos for Developers.

Proactivity: what does it look like in practice?

It is not volunteering for more tickets. It is finding the problem before it becomes one. In practice, four habits:

1. Read the ticket for what is missing before you prompt anything. The assistant will build exactly what the ticket says, including the gaps. The three questions I ask at kick-off: what happens when this fails, who else reads this data, and how will we know in production that it worked.
2. Watch the first 24 hours. Open the dashboard after release, search the logs for your new error codes, and check the business metric. Most regressions are visible within a day to anyone who looks.
3. Raise risk in writing, early, with a proposal. A two-paragraph note that states the risk, the evidence, the cost of doing nothing, and one option is worth more than a warning in stand-up that nobody records.
4. Leave the area better than you found it. One characterization test, one renamed variable, one deleted dead flag per change. AI makes this cheaper than ever; doing it is still a choice.

The developer who does these things becomes the person the team brings problems to early, which is the most reliable signal of seniority I know. The prompt patterns I use to interrogate a ticket for gaps before building are in The Tech BA Prompt Toolkit, and they work just as well from the developer’s seat.

Coaching: why does it matter more when juniors have AI?

Because juniors can now generate far beyond what they can judge. A junior developer with an assistant produces senior-looking code on day one and has no way to tell when it is wrong. The traditional apprenticeship, where you learned by writing a lot of mediocre code and having it reviewed, has been short-circuited. Someone has to rebuild it deliberately, and that is the senior developer’s job now.

Coaching in this setting looks like three things. The explain-it-back rule: before a generated change is merged, the author explains in their own words why it is correct and what would break it. Review as teaching: comments that name the principle, not only the fix. And pairing on verification rather than on typing: sit together while the junior writes the test from the requirement, which is where judgment is actually built. The formats that work, and how to coach someone on using AI well, are in Proactivity and Coaching for Developers.

A developer who coaches multiplies the team’s judgment, and judgment is now the scarce resource. Generation capacity is no longer the bottleneck on any team with an assistant.

How do you score yourself on the seven skills?

Use three levels per skill. Be honest; the point is to pick what to work on.

Skill	Level 1: does it when asked	Level 2: does it by default	Level 3: raises the team’s bar
Testing	Writes unit tests for new code	Derives tests from the requirement, adds negative and boundary cases	Runs mutation testing, owns the contract suite, teaches test design
Code review	Approves diffs that look fine	Reviews intent, tests, then code, with labelled comments	Sets the review standard and the PR template, automates the mechanical
Quality ownership	Fixes defects that are reported	Asks the four questions on every change	Defines non-functional contracts, owns dashboards and alerts
Presentation	Shows the feature working	Shows before, change, failure path, and the decision needed	Runs sprint reviews stakeholders look forward to
Release notes	Writes a changelog line	Writes per-audience notes with impact and action	Owns the release communication process
Proactivity	Flags blockers in stand-up	Raises risks in writing with a proposal, watches production after release	Is brought problems before they become tickets
Coaching	Answers questions when asked	Reviews to teach, pairs on verification	Builds juniors’ judgment deliberately, runs team learning

Most developers I work with score level 2 on one or two rows and level 1 on the rest. That is normal and it is the opportunity. Moving any single row to level 2 is visible to your manager within a quarter.

What should a developer do in the next 90 days?

One skill per month, each with a concrete artifact you can point to.

Days 1 to 30: testing. Pick the module you touch most. Run a mutation testing tool on it and record the score. For every change this month, write the tests from the requirement before you look at the implementation, generated or not. Re-run mutation testing at the end. The score difference is your artifact.

Days 31 to 60: review and quality. Adopt a pull request template with sections for intent, how it was verified, AI assistance, and rollback. Use it on every PR you open. Add the four quality questions to your own review checklist. Your artifact is ten pull requests that a reviewer could approve without messaging you.

Days 61 to 90: communication and people. Write the release note for every change you ship, per audience. Give one demo that ends on a decision. Pair once a week with someone more junior on verification, not on typing. Your artifact is a stakeholder who asks for you by name.

If you are thinking about where this leads, the same verify, explain, and own profile is exactly what the forward deployed engineer role hires for, and I mapped that route in The Forward Deployed Engineer Career Guide.

The takeaway

AI did not make developers less necessary. It moved their value from producing code to standing behind it. The seven skills that decide your value now are testing, code review, quality ownership, presentation, release notes, proactivity, and coaching, and the developers who own them ship more, break less, and get trusted with the work that matters.

Start with testing, because it is where AI most convincingly fakes competence and where your evidence is weakest. Then work outward, one skill a month, and keep the artifact each time.

For the test design that turns a green suite into real evidence, start with API Testing and QA Mastery for BAs. If you want a second pair of eyes on your own 90-day plan, book a 1:1 Tech BA Coaching Call, or browse everything at The Tech BA Toolkit. More on the coding side of the technical analyst role lives in the Developer Analyst hub.

Ahmed is a Senior Technical Business Analyst with 10+ years in banking and payments. He builds practical guides and tools for analysts at The Tech BA Toolkit.

Tags: Software Development, Banking, Career Growth, Testing, Artificial Intelligence