The Economics of Software Are Changing
And our habits need to catch up
Today’s agenda
- What’s actually changing
- What’s no longer worth optimising
- What becomes the new constraint
- New skills to build
- A workshop to work through it together
Why now?
This isn’t about individual productivity tools.
It’s a structural shift in where the leverage is — and most teams haven’t updated their processes to match.
Code is now cheap to produce
A first draft — component, migration, test suite — costs minutes, not days.
The bottleneck has moved from writing to reviewing, deciding, and integrating.
What this unlocks
- Exploration is now affordable — try three approaches before committing
- One person can span more — backend engineers draft frontend, PMs build prototypes
- The cost of being wrong early has dropped dramatically
- Thin vertical slices beat elaborate upfront planning
The uncomfortable implication
When execution is fast, the scarce resource isn’t effort.
It’s clarity.
What’s no longer worth optimising
| Before | Now |
|---|---|
| DRY code, premature abstraction | Duplication is fine — AI regenerates |
| Boilerplate and scaffolding | Near-zero cost, not worth a process |
| Seniority = how to implement | Seniority = what to build and what not to |
| Elaborate task decomposition | Fast feedback loops beat upfront planning |
A direct question for this team
What are we still doing the old way — not because it’s better, but because we haven’t stopped to ask?
New bottleneck: decision latency
When code is fast, unclear requirements become visible immediately.
The team blocks on decisions, not execution.
Decision speed is the new lead time.
New bottleneck: handoffs
Every handoff loses context that AI can’t reconstruct.
Fewer handoffs — or richer async context — aren’t just nice to have anymore.
They’re the critical path.
New bottleneck: review capacity
Output volume goes up.
Review capacity doesn’t.
Code isn’t safer just because AI wrote it. Judgement at review is now a genuine constraint.
New bottleneck: system-level thinking
AI excels at local solutions.
It doesn’t hold your architecture in mind.
That role gets more important, not less, as generation scales up.
New skills that compound
- Prompting as craft — specifying constraints, decomposing problems, knowing when to steer
- Critical review — reading for intent not syntax, spotting confident mistakes
- Architecture ownership — holding system coherence, resisting local-optima traps
- Decision velocity — async frameworks, fewer approval layers, reversible defaults
- Context writing — rich specs, decisions logged with rationale, less tribal knowledge
“The most valuable thing a senior engineer does is knowing what not to build.”
The skill that ties it all together
Taste and judgment — knowing good from good-enough, maintaining user perspective at speed, knowing when to ship vs keep iterating.
This is the one thing AI doesn’t have. It compounds with experience. Build it deliberately.
Today’s workshop
Four phases, 90 minutes.
The goal isn’t to produce a perfect plan. It’s to surface what’s actually slowing us down — and commit to three specific bets.
Phase 1 — Ground truth
15 minutes
Before theory, map reality.
Where has AI changed your daily work most? Where hasn’t it? What are you still doing the old way?
Format: popcorn sharing → cluster on whiteboard
Phase 2 — Obsolescence audit
25 minutes
Go through our ceremonies, processes, and work patterns.
Mark each: still valuable / diminishing returns / should stop
Format: 10 min solo sticky notes → 15 min group discussion
Questions for the audit
- What are you still doing manually that AI could handle?
- What meetings exist to compensate for slow async processes?
- What parts of our spec, design, or review process are ceremony now?
Phase 3 — Constraint mapping
25 minutes
In small groups, map a recent feature from idea to shipped.
Mark every waiting point, handoff, and slow decision.
Format: groups of 3-4, each map a different project → compare patterns
Questions for constraint mapping
- Where did we wait? For what? For whom?
- Which handoffs lost context that had to be rebuilt?
- Which decisions slowed execution that should have been defaults?
Phase 4 — Three bets
25 minutes
Don’t solve everything.
Pick three specific changes to try in the next 6 weeks.
The three bets
One thing to stop.
One thing to change how we do it.
One new practice to build — with a clear owner.
The constraint isn’t effort
It never really was.
The constraint is clarity, judgment, and the courage to change what isn’t working.
Let’s map it.
Scan to follow along
The Economics of Software Are Changing
manishrc.folderpress.com/decks/the-economics-of-software-are-changing