"How many tokens did you burn?" is the new "How many hours did you work?"
Both measure activity, not value.
There are two kinds of AI leverage and they look identical on a contribution graph:
Leverage through understanding — you know the domain, you know which tradeoffs matter, AI removes the friction between insight and implementation.
Leverage through abstraction — you don't fully understand the system but you generate enough volume that things seem to work. Green tests, big PRs, impressive commit graphs.
The tell is what happens at 3am when something breaks. One builder knows where to look. The other is staring at hundreds of thousands of lines they didn't write.
The human work doesn't shrink. It concentrates. The decisions about what to build, why, what constrains it, and what will go wrong — that's the whole game now. AI made everything else cheap. It made that part more expensive.
Whatever you don't inspect will break. That was always true. AI just raised the stakes.
“When execution is nearly free, taste becomes the moat but how a company organizes to make taste evident is still being decided.”
Whether they’re called product managers in the future or not, this is precisely the role they should be playing in these companies. At some point you can’t have a complete roadmap free for all because your constraint isn’t token output it’s customer reception to your features.
Vibe coding builds demos.
Specs builds products.
Two development styles are emerging.
One starts with prompts:
- Open the AI tool
- Describe the feature
- Iterate until it works
It’s fast. It feels magical.
The other starts with a spec:
- Define the system
- Outline the architecture
- Clarify product requirements
Then let AI generate the code.
Both move quickly at first. But as complexity grows, the difference shows.
Because AI does one thing extremely well:
- It amplifies whatever discipline already exists.
With structure, it accelerates the build.
Without structure, it accelerates chaos.
AI didn’t remove the need for solid system architecture. It made it more important than ever.
@manojdotdev Building anything hard always involve mentally taxing discussion with the AI both before (forming up the spec/intent, grounding it to reality) and after (probing and revalidating).
There's no 'better orchestration layer' that automates all that thinking and pressure-testing.
Something I keep coming back to: we gave code real infrastructure decades ago — version control, branching, merging. The thinking that shapes the code? Still scattered across Slack, markdown docs, and people's heads. Feels like a gap that only gets bigger as agents get faster.
Agents are getting good enough that the wrong decision now propagates at machine speed. That's a different kind of problem than we've ever had.
This is directionally right and I'd push it further. The .md-as-blueprint model works until you change a requirement and need to know which of your 30 spec files are now stale. Or until two specs contradict each other and nobody catches it until week 3.
Specs that don't know about each other are a better-organized version of the same problem. The instinct to move upstream is exactly right — but a folder of blueprints isn't the same thing as the infrastructure those blueprints need.
I went through this exact thing about ~8 months ago.
Everyone must pass through the phase of AI existential dread and developer ego death.
After much internal deliberation I've come to the realization:
The genie is out of the bottle, and instead of just three wishes, it comes with 𝗶𝗻𝗳𝗶𝗻𝗶𝘁𝘆 𝘄𝗶𝘀𝗵𝗲𝘀 😅
So, the focus changes from the artisanal line by line code crafting and shifts into deeper architectural & product decisions, that 𝗜 𝗱𝗿𝗶𝘃𝗲.
It's now 99% product planning & research around edge cases/what's possible/competitors and like 1% typing syntax. Instead of the 75% code / ~25% planning of yesteryear.
Once you see it, you see it.
Writing code by hand used to be where developers found clarity.
While typing out every line, you naturally thought about the data flow, edge cases, naming, structure, props, etc. Bugs often got caught before the code even ran.
Now, AI generates code at lightning speed.
If your thinking isn’t clear, you will spend your day debugging AI hallucinations instead of solving actual problems.
Clear intent is the bigger bottleneck now.
The best builders using AI spend MORE time on intent than they did before AI.
The .md spec iteration — shaping what gets built, with the agent, before building — is the highest-leverage hour in the day. The thinking isn't overhead. It's the product. Code is just the output.
@asaio87 Yes. So much unserious talk of “I can ship 10x faster so can do 10x the projects”. Anything that is going to matter is deeper/harder than that, and AI is a force multiplier to get to places you couldn’t have before, not just pad your GitHub counts.
@aakashgupta The whole manual PRD/backlog thing is becoming as stale as hand-writing code, but figuring out that thinking/planning/intent phase (w humans + agents) will be the critical control point/surface for humans
@aakashgupta Two ends of the spectrum that work— prototype prolifically for inspiration/clarity, and then make real by iterating hard and grounding .md (humans + agents) to nail the path/intent before each increment of real code.
@artman Why think/plan when you can just fire off a bunch of agents to prototype all directions. (Discovers the subagents have the same idea… and the sub-sub-agents…) Feeling like a Rick and Morty ep.
@uzair_dev_ Spend 2hrs iterating/designing/grounding the .md spec with Claude Code, then build, test and reverify against it. Best most-productive use of brain-power and gets you out of the slop slot-machine.
@wookash_podcast Yes! Just like managing a team, there are hundreds of judgement calls at all altitudes, and AI lets you decide where you want to be in the mix or not. Elon didn’t build SpaceX by saying “build me a rocket, make no mistakes”.