Article 006: From keystrokes to supervision
Key Message: The developer’s role becomes more supervisory. This is not a loss of agency.
Series: B — Reframing the work (Part 1 of 6) Publish Date: Monday 2026-02-23
Story Outline
Opening hook
Start with the developer identity crisis: “I’m not really coding anymore.” The uneasy feeling when most of your day is reviewing agent output, directing architectural changes, evaluating pull requests. The hands-on keyboard time has shrunk. Does that mean you’re not a real developer?
The identity of “developer” has always been tied to creation - typing, building, making things work with your hands. The satisfaction of writing a clever algorithm, debugging a complex problem, seeing your code run. Now that work increasingly happens elsewhere - delegated to agents, automated processes - what are we?
The shift
From operator to supervisor. What this actually looks like:
- Morning: review overnight agent work (refactoring, documentation, test coverage)
- Set direction for next set of changes
- Evaluate architectural decisions agents propose
- Correct mistakes, approve changes, reject approaches that won’t work
- Decide what gets merged, what gets reworked
- Still write code - but less creation from scratch, more intervention and refinement
The ratio has flipped. Used to be 80% typing, 20% reviewing. Now it’s inverted. Most time is spent evaluating, directing, deciding - not typing.
Evidence / Examples - Supervision is technical work
Example 1: Reviewing a large refactoring Agent touched 70 files overnight. I review it this morning:
- Evaluate whether the pattern fits the existing codebase conventions
- Verify the refactoring preserves the original intent across contexts
- Check if the abstraction level is appropriate for each module
- Identify edge cases the agent missed
- Approve 90%, reject 10%, explain why
This isn’t “management.” It’s deep technical judgment. I need to understand the codebase, architectural principles, type systems, dependency patterns. The skill requirement is the same - or higher.
Example 2: Evaluating agent-generated abstractions Agent creates a new abstraction layer. I evaluate:
- Does this simplify the system, or just add indirection?
- Will this pattern make sense to someone reading it in six months?
- What are the performance implications?
- Does this fit with the rest of the architecture?
- What breaks if we accept this? What breaks if we reject it?
The agent can generate code. It can’t (yet) evaluate whether the abstraction is right. That requires experience, judgment, understanding of tradeoffs. Supervisory work, but deeply technical.
Example 3: The value of “no” Agent generates comprehensive test coverage. I review, reject 30% of it:
- These tests are brittle
- These test implementation, not behavior
- These will slow down CI without adding value
- These miss the actual edge cases
Knowing what not to do requires as much skill as knowing what to do. Maybe more.
Implications - Why this isn’t diminishment
The skill is different, not less:
- Evaluation requires deeper understanding than creation
- You need to spot what’s wrong without writing it yourself
- The bottleneck shifts from implementation to evaluation
- Experience compounds in judgment
Agency remains:
- You still decide what happens
- You direct the work
- You determine what’s good enough
- You set architectural direction
- Agents execute; you evaluate and approve
The craft evolves:
- Orchestration is a skill
- Knowing what to delegate matters - and when:
- Urgent + Important = Do it yourself (critical bugs, architectural decisions)
- Urgent + Not Important = Delegate to agent (routine refactoring, test coverage)
- Important + Not Urgent = Schedule (major rewrites, tech debt)
- Not Urgent + Not Important = Delete (or let agent handle entirely)
- Pattern recognition across large changes
- Maintaining coherent vision across async work
This progression has always existed:
- Senior developers have always moved toward supervision
- You supervise junior developers; you review their PRs; you guide architectural decisions
- What’s different now: the ratio flips much faster
- Agent work executes at 10x speed
- You’re supervising output at a scale that would require a team of 10+ humans
- The question isn’t whether supervision is real work
- The question is: how much supervision can one person effectively do?
Close
The developer role is reframing from creation to supervision. That feels uncomfortable - we’re trained to value hands-on keyboard time, to equate coding with creation.
But this progression has always existed. Senior developers supervise. They review PRs, guide architecture, decide what’s good enough. The supervisory role isn’t new.
What’s new is the scale and speed. You reach that supervisory role faster. And you’re supervising output that would require a team 10x the size of what you’d manage with human developers. The agent executes instantly; you evaluate constantly.
I still write code. But increasingly, my value isn’t in the typing - it’s in the judgment. Knowing what should be built. Evaluating what was built. Deciding what’s good enough. Directing the next iteration.
The craft hasn’t diminished. It’s evolving. From keystrokes to supervision. Same agency, different expression.
The open question: how much supervision can one person effectively do?
Notes
Phase B positioning: This is the Phase B opener - “Reframing the work.” It explores how the role changes without prescribing what to do about it. Phase C will address tensions/implications.
Tone:
- Observational, not prescriptive
- Acknowledge the discomfort (identity crisis)
- Validate that supervision is real technical work
- Don’t oversell or dismiss concerns
Key point to maintain: The shift to supervision is NOT a loss of agency or technical depth. It’s a different application of skill. This needs to land clearly.