What's Left to Do: Software Development in the Age of AI

01. Architecture, Guidelines, and Review: What's Left

These three jobs used to be spread across a career, junior engineers wrote code, senior engineers reviewed it and occasionally weighed in on architecture. When code generation itself gets cheap and fast regardless of who, or what, is doing the typing, that split stops making sense. The value concentrates in the three things a fast typist never actually provided:

• Architecture: the shape of the system, where boundaries go, what talks to what. An agent can implement inside whatever boundary it's given, it won't tell you the boundary is in the wrong place.
• Guidelines: the written conventions, style rules, and repo-specific instructions that keep a hundred small decisions consistent across a codebase, regardless of who or what is generating the code that day.
• Review: the judgment call on whether a specific change, generated or handwritten, actually does the right thing for the right reason.

A codebase with excellent architecture and clear guidelines but no real review still accumulates rot, someone has to actually look. A codebase with rigorous review but no architecture just gets a series of locally-reasonable decisions that don't add up to a coherent system. All three are load-bearing.

02. Specs Before Code: A Workflow, Not Just a Style Guide

Claude Code's Superpowers workflow is a concrete version of this: before writing a line of code, the agent classifies the request, a quick spike, a bounded change to something that already exists, or a new architectural piece, and scales its process to match. A bounded change gets a short design proposed in chat. An architectural one gets clarifying questions asked one at a time, two or three approaches with trade-offs, a written spec, and a hard gate: no implementation starts until a human has actually said yes to the design.

The gate is the point. It's not that the agent can't write good code without it, it's that even good code built on a misunderstood requirement is wasted work, and catching a wrong assumption in a two-sentence design proposal costs a fraction of what catching it in a finished pull request does. It's the same logic as a failing test written before the implementation, cheap to be wrong early, expensive to be wrong late, just applied one layer up, to the requirement itself rather than the code that satisfies it.

03. Copilot as a Reviewer, Not Just an Autocomplete

The autocomplete framing undersells what's actually useful here. An automated reviewer that reliably catches the shallow stuff, missing null checks, inconsistent naming, an obvious off-by-one, frees a human reviewer to spend their limited attention on the part that actually needs it: whether the change is a good idea. A real review thread makes the split concrete:

AI-generated image

Copilot's comment is correct and worth having, that bug would have shipped otherwise. But it's Priya's comment that actually protects the system: a duplicated business rule that can silently drift out of sync is a much more expensive problem than a missing None check, and it's exactly the kind of thing an automated reviewer, human or not, has no way to see without understanding why the code exists in the first place.

04. Why Juniors Need More of This, Not Less

There's a version of "AI makes juniors more productive" that's true and a version that's a trap. The trap is a junior who ships a steady stream of accepted suggestions, all individually reasonable, without ever developing an opinion about which ones were actually right. They get faster at prompting and no better at engineering, because the skill that was supposed to develop through struggle, reading unfamiliar code, forming a hypothesis about why it's wrong, defending that hypothesis to someone more experienced, never gets exercised.

That skill doesn't disappear as a requirement just because generating the first draft got easier. If anything it's promoted: reviewing well is now closer to the center of the job than it used to be, for everyone, and a junior who never built the underlying judgment is a junior who can't do the part of the job that's actually left.

05. Pair Programming as the Transfer Mechanism

A review comment communicates the conclusion. Pairing communicates the reasoning that got there, which is the part a junior actually needs to internalize. Sitting next to someone as they read a Copilot suggestion, pause, and say "that would work, but it's the third place we'd be checking this permission, we should pull it into the auth layer instead" teaches a lesson no comment thread captures: not that the suggestion was wrong, but the specific shape of reasoning that noticed it.

This is also where a junior's own suggestions get exercised safely. Proposing a rejection out loud, being wrong about it, and hearing why, in real time, with someone who can immediately clarify, builds the same judgment faster than the same exchange spread across asynchronous review comments over the following two days.

06. What Good Review Looks Like Now

• Match against the spec, not the output: a change that passes its own tests but doesn't match the behavior the test was supposed to pin down is a review looking in the wrong place. This is the same discipline behind writing the failing test first, a passing test is only meaningful if it was actually testing the right thing.
• Look for the edge case an agent wouldn't think to generate: agents are good at the cases a codebase already has examples of and weaker at the ones that are specific to this business, this data, this regulatory constraint. That gap is exactly where a human reviewer's domain knowledge earns its keep.
• Check the change against the architecture, not just against itself: a locally reasonable change that duplicates logic, crosses a boundary it shouldn't, or quietly introduces a second way to do something the system already does one way, is a design problem wearing a passing test suite.

None of this is really new. It's the same discipline good review always required, it's just that skipping it is now easier than it's ever been, which makes actually doing it worth more than it used to be.