Hey there,
Last week, Superpowers hit #1 trending on GitHub. It went from ~15k to ~30k stars in a week.
I got curious. So I called Jesse Vincent, the creator, and asked a simple question:
How do you actually work?
His answer caught me off guard.
“I don’t read code anymore.”
No hedge. No disclaimer.
He wasn’t trying to provoke. He was describing a workflow that, for him, had made reading code mostly unnecessary.
That conversation changed how I think about agentic coding.
The Old Loop is Breaking
Most engineers are trained to verify by reading:
Scan the diff
Trace the logic
Check edge cases
Build confidence line by line
That loop made sense when humans wrote the code.
Jesse's loop looks different:
Define instructions up front — 5 minutes to an hour with Claude building out exactly what he wants
TDD everything — tests define correctness, not code review
Demand evidence — the agent proves it worked with screenshots and output
In this setup, the code is an implementation detail.
The instruction and the tests are the source of truth.
Why Simplicity Wins
I've been using Superpowers daily since Simon Willison flagged it. The brainstorm step alone changed how I work.
The first time I let Claude ship without checking the diff, I kept reaching for it out of habit. Old instincts die hard.
But the tests passed.
The feature worked.
That’s when something clicked.
I asked Jesse why Superpowers worked for him when heavier frameworks like Spec Kit, BMAD felt like overkill.
His answer was simple:
“You don’t need gigantic structures. You need small, clear instructions.”
He wasn’t guessing.
He started with a single prompt:
“Make me a React to-do list with local storage.”
Then he iterated on his CLAUDE.md - 30 to 40 times. Testing what actually caused Claude to follow TDD.
First run: ~30 seconds, broken on reload
Final run: ~20 minutes, ~$20, fully tested, solid behavior
Same model.
Same task.
The only thing that changed were the meta instructions.
That’s the real constraint in agentic coding, not the model.
How his Workflow Actually Evolved
Jesse's workflow didn't start with subagents.
Phase 1
Two Claude Code sessions open. One for architecture. One for implementation. Manual copy/paste between them.
Phase 2
Watching the implementer closely.
“They finished suspiciously quickly. Go check their work.”
Phase 3
Fully subagent-driven development. Always.
What enabled the transition wasn’t blind trust. It was a verification system:
Tests as the primary check
Specs detailed enough that agents don’t need to explore
Evidence-based confirmation, not vibes
At some point, reading code stopped being the fastest way to build confidence so he stopped doing it.
What This Means for Hiring
Jesse's take on hiring didn't surprise me. It clarified something I'd been circling.
"I have always believed that you hire the person who can write well."
His filter:
Writing ability — can they express themselves clearly?
Systems thinking — do they understand how things connect?
Open mind — will they adapt when the tools change?
What doesn't matter:
Leetcode scores ("zero value to me")
Specific technologies you know
The beauty of your code
"The engineer who understands business value has always been the right thing. That's only more true now."
The New Rule
At Jesse’s company, the default rule is explicit:
You don’t read or review code unless there’s a concrete reason to.
You might spot-check. You might dig into a specific implementation detail. But your job isn't lines of code. Your job is outcomes.
This mirrors a shift many ICs experience when they become managers:
First you stop writing code
Then you stop reviewing every line
Then you trust systems and focus on results
Agentic development compresses that transition from years into weeks.
A Quick Self-Test
How do you know if you’re ready to work this way?
Can you spec clearly?
Vague instructions produce vague output.
Clear constraints produce boring, correct software.
Can you verify without reading code?
Tests, runtime behavior, screenshots, metrics — not diffs.
Can you let go of craft attachment?
The value of code is customer impact, not aesthetic purity.
If all three are yes, you’re already most of the way there.
If not, start with the spec. That’s where the leverage lives now.
What I’m Taking From This
Jesse said something near the end that stuck with me:
"The era of competent humans writing programming language syntax is over."
That sounds dramatic. But the more I work this way, the more it feels accurate.
The leverage has moved upstream - from typing to specifying.
Here’s what I’m changing in my own work:
Spending more time on the spec. Ten minutes upfront saves an hour of back-and-forth.
Trusting tests and evidence over diffs.
Treating subagents like junior devs: clear context, clear scope, proof on completion.
If you want to try this:
On your next task, spend ten uninterrupted minutes tightening the spec before any code runs.
See what happens.
Something New I’m Trying
One thing that’s become clear to me is that this stuff clicks much faster when you see how other people are actually using it.
I’m starting a monthly Claude Code Show & Tell — a live session where people demo real things they’ve built or figured out.
This could be:
A plugin that saved you hours
A custom skill or setup you wrote
Your Claude Code workflow
If you want to demo something (or just watch), you can sign up here:
https://luma.com/0hovfeqt
The first one’s coming up on Jan 30th. I’ll share the recording afterward for anyone who can’t make it live.
Hit reply - what's one thing you'd want to see in a workflow breakdown like this?