On October 15, developer Pinecoder published a post titled "My old job feels very distant now." It resurfaced on GeekNews on the 18th.

The value of the piece is not its conclusion but its path. It lays out, step by step, how AI coding tools changed the developer's work itself over a few years, and it ends with one honest question: "As the code moves faster, how can I continue to understand it?"

One caveat up front. This is a personal essay, and the productivity figures are self-reported. It is not a benchmark. So do not generalize the numbers; read it for the direction of change and the practices.

The shift, stage by stage

Here is the path in order.

[The stages Pinecoder passed through]

1. ChatGPT as a better Google
   - when coding search results were useless, "just ask" became the start

2. Copy-paste code
   - generating Ruby specs he did not want to hand-write
   - an escape hatch that deferred a learning curve

3. Tab completion + copy-paste in a new domain
   - Cursor, forked from VSCode
   - learning computer vision (Python) via search + generation
   - felt that hallucinations appear at the boundary of what it knows

4. Agentic coding (Claude)
   - from tab completion to prompting
   - "the codebase was still fully in my head, every line reviewed"
   - PRs started to become the bottleneck

5. Opus 4.5/6
   - about 3x productivity (merged PRs over a few months, self-reported)
   - got better at scanning, focusing on "the important parts"

6. Opus 5
   - code kept improving, but cost and verbosity became the problem

7. Opus 5.5
   - "frozen, at zero" - another round of adaptation

The insight from stage 3 is worth keeping. AI hallucinations appear at the boundary of what it knows, and that boundary is exactly where a person has to fill in. The more useful AI gets, the clearer it becomes where the human contribution sits.

What actually changed

The observation after stage 5 is the heart of the essay.

[Where the center of gravity moved]

Planning
  before : plan the work, then implement it in phases yourself
  now    : think about "the QA I want to do," not
           "the code review I want to do"

Architecture
  - assume decisions are reversible
  - unsure about the UI? just make more of them
  - three similar ideas? make all three
  - can this be broken out into a single HTML page?

Artifacts
  - have Claude dump plan, progress and project notes into a notes app
    (sometimes he works from these rather than the chat)
  - generate more artifacts, now backed by data
  - turn them into tools the AI uses to track working state and history,
    and tools he uses to visualize progress
  - vulnerability reports fixed in batches
  - burndown charts with ticks of key moments
  - when performance worries him, have it monitor performance too

Most striking is the "subagents" and "supervisor" pattern.

[Running many agents]

subagents split up the work
        ^
a supervisor stands above to see the whole picture

The follow-up questions he raises:
- what level of architecture do I need to dictate?
- what kinds of outcomes should I focus on instead?
- if gaps appear, can I have another model try to exploit them,
  report the results, and have the models coordinate to harden the design?

This is not tool usage; it is workflow design. The "review" of the era when a person wrote all the code turns into supervising and verifying several agents.

Constraints replace instructions

The most practical passage is an anecdote from stage 7. He wanted a snappy UI. In the past he would have dictated the use of observables or a specific optimization. This time he did it differently.

[Instruction -> constraint]

before: "use observables and optimize like this"
now   : "the image should process within 15ms" <enter>

him: oh, I meant to type 150ms... let's just see if the model can do it
result: the model did it

-> what he had to reconsider:
   "I need to re-evaluate what I think of as possible."

Then a decisive anecdote. He prompts the model to port his Electron notes app to the iPhone, native Swift, rewriting whatever it wants. He tosses the idea in and walks away. A few hours later, checking the news on his phone, a working app interrupts him — installed over the network so the model could ask him to QA it. It used 40% of the 5-hour limit on his $20 subscription. Not feature complete, but it worked.

The moment he stares at the screen, dumbfounded, is where the essay's power as personal writing comes through.

The question that remains

The post closes like this:

"As the code moves faster,
 how can I continue to understand it?

 -> I come up with new metrics, new dashboards
 -> I think harder about the most important parts of
    the design and the constraints
 -> that is the only place that deserves attention and effort
 -> I build tools to help me understand, and tools for the model to use"

That ending fits the path exactly. When reading every line collapses, the way you understand has to be redesigned. The proof of "I understood it" moves from code review to metrics, dashboards and constraints.

There is a piece that takes the same worry from another angle. Anthropic's Claude Code team abandoned the question "did a human read the code" and moved to automated review with risk-based approval (The Claude Code Team's Six Layers of Code Review). The two essays push on the same wall from different sides.

Conclusion: turn the briefing's action into a protocol

The briefing's action was "record completion criteria, test results, performance metrics, and revert steps for every agent task." Polished into a protocol:

[Recording an AI agent task, a mini protocol]

Leave four things after every task

1. Definition of done
   [ ] one sentence for what counts as finished
   [ ] write it as a constraint (e.g. render within 150ms)

2. Verification evidence
   [ ] test results
   [ ] performance metrics
   [ ] how to revert (is it reversible?)

3. A trace of understanding
   [ ] one paragraph on the important parts
       (business logic, customer data, irreversible changes)
   [ ] mark any change you cannot explain as "needs understanding"

4. Metrics and dashboards
   [ ] make progress visible
   [ ] batch vulnerabilities and performance into trends

One line captures it.

A developer's edge expands from writing code
to defining problems, designing systems, and verifying results.

The real message is not "AI is amazing." It is that as the tools improve, what a person must hold moves upward. Pinecoder calls that "the most important parts of the design and the constraints," and says focusing there is the job now. For supervising several agents and designing loops, continue with Agent Performance Metrics and What Is Loop Engineering?.

Further reading

References

Go deeper with a course

Supervising agents, defining completion criteria, and designing verification loops all sink in by building a harness and a loop yourself. Wiring several agents into a graph and verifying their results shows you why the protocol above matters.