Rethinking Assumptions - When Agents Write the Code
Most dev tooling was built on assumptions that no longer hold: humans write code with effort and expertise; changes are scarce and valuable; linear workflows make sense. When agents write 90% of the code, those assumptions break. The tools we rely on - tickets, PRs, sprints, branching - were designed for a different world. It's time to re-examine them from first principles.
The Old Assumptions
Humans write code. The developer is the scarce resource. Work is queued, assigned, and scheduled around human capacity.
Changes are valuable. Each commit represents significant effort. PR reviews are careful; merging is deliberate. Emoji reactions and "LGTM" acknowledge the human behind the change.
Linear workflows. Bug reported → ticket created → assigned next sprint → developer picks up → fix. Handoffs are sequential because humans are busy.
Branches isolate work. Feature branches, PR workflows, code ownership - all assume that changes are discrete, authored, and need isolation.
The New Reality
Agents write code. Capacity is less scarce. You can spawn multiple agents to investigate, fix, or explore in parallel.
Changes are abundant. An agent can generate 10 variations of a solution in minutes. The perceived value of any single change drops. "You're wrong - ask your agent friend to spin up another chain" becomes viable.
Immediate action over queuing. Why create a ticket when you can send an agent to investigate immediately? The agent can diagnose and fix in the time it would take to write the ticket.
Continuous generation. Code isn't discrete anymore - it's a "primordial soup" of variants, always bubbling. The mental model shifts from "distinct changes" to "streams of output."
What Changes in the Tooling
| Old Tool | Old Assumption | New Reality | Design Implication |
|---|---|---|---|
| Linear tickets | Developers busy, queue work | Unlimited agents | Send immediately; ticket optional |
| PR reviews | Changes are precious | Changes are cheap | Auto-merge with tests; review for intent |
| Emoji reactions | Social bonding around code | Code is commodity | Repurpose or remove |
| Branching | Careful isolation | Parallel generation | Direct to main, feature flags |
| Sprint planning | Limited human capacity | Agents scale | Continuous flow, real-time prioritization |
What to Keep
Not everything should change. We still need:
- Accountability: Who requested what? Why?
- Traceability: Why was this changed? What was the intent?
- Quality standards: Tests, linting, security checks
- Learning: Post-mortems, documentation, pattern capture
The shift is from human-centric process to agent-aware process. The human role moves from "doer" to "orchestrator and verifier." The tools should support that.
The Design Challenge
Existing tools won't disappear overnight. The transition will be hybrid - humans and agents both in the workflow, old tools and new patterns coexisting. The design challenge is: audit your tools for outdated assumptions, then iterate. What breaks when agents write most of the code? What new interfaces do we need? What becomes obsolete?
The answers will shape the next generation of dev tooling. The teams that question their assumptions first will have a head start.