The cost of human implementation shaped how we build software, organize teams, and sell engineering services. As agents take on more of that work, the economics behind those choices are changing. It’s time to revisit the processes, technologies, and assumptions we inherited, and ask which still earn their place.
1. Assumptions We Need to Challenge
- "Software delivery should be organized around scarce engineering capacity.”
Much of our delivery machinery exists to allocate costly human implementation time. As that constraint weakens, bottlenecks shift to business understanding, decision-making, integration, and verification. Our operating model should organize around those constraints.
- "Scrum and Agile ceremonies are the natural way to organize development.”
Sprints, estimation, backlog grooming, and velocity were shaped by the economics of human implementation. Agent execution changes those economics and makes continuous delivery loops more viable. Each ceremony must justify its contribution to decisions, learning, or quality. Feedback and adaptation remain essential principles.
- "Growing organizations need more management layers.”
Hierarchies perform coordination work: distributing context, assigning tasks, tracking dependencies, consolidating information, and escalating exceptions. Agents can increasingly perform these functions. Organizational design should reflect how much coordination requires a human, with explicit ownership of authority and consequential decisions.
- "A shared cross-platform codebase is the most economical choice.”
React Native’s economic justification weakens as agents make building and maintaining native applications cheaper. I predict it will lose its position as the default choice for resource-constrained teams. Native performance, platform integration, and experience quality will carry more weight as implementation costs fall.
- "Technology should primarily be developer-friendly.”
Human convenHuman convenience is losing its position as the dominant selection criterion. We need to evaluate technologies for agent reliability, context requirements, token consumption, verification cost, and runtime performance. Convention over configuration gains value from fewer decisions and less context needed to produce a correct result.
- Abstraction and less duplication always improve maintainability.”
Shared abstractions create dependencies and coordination points. With many agents working concurrently, these dependencies can become expensive. Cheaper implementation and synchronization may make some duplication economical. Architecture should account for the cost of coordinating change across the system.
- "Every implementation change requires a human to read the code.”
This assumption creates a verification bottleneck as generation accelerates. We need independent evaluations, executable contracts, behavioral checks, and risk-proportional review. Human attention should focus on changes where it adds the most confidence.
2. Beliefs We Need to Retire
- "Hours, tickets, and lines of code represent delivered value.”
These measure activity or production volume. Commercial value belongs to an operational business capability with demonstrated outcomes. Replacing story points with capability count would reproduce the same measurement problem.
- "More delivery capacity primarily means more people.”
Capacity increasingly depends on the quality of context, orchestration, reusable loops, and verification. A small senior team can expand execution capacity through agents. Human judgment, unresolved ambiguity, and integration complexity determine how far that expansion can go.
- "The codebase is the primary durable asset.”
Validated business knowledge, decision history, specifications, integration contracts, and evaluations become more valuable as implementation becomes easier to regenerate. Ground Truth preserves the understanding needed to rebuild and evolve the system across changes in models, languages, and platforms.
- "Humans must manually coordinate every step of delivery.”
Creating a ticket, assigning it, checking progress, requesting review, and scheduling another pass can become parts of an automated loop. People define objectives, resolve ambiguity, and own escalation points. The delivery system handles routine coordination.
- "Every application needs its own AI assistant.”
Users will increasingly expect their own agents to operate across applications. Products need reliable interfaces, permissions, and discoverable capabilities that make this possible. APIs and CLIs become important product surfaces for completing work across organizational boundaries.
- "Each client engagement starts with a largely new delivery process.”
Methods, domain patterns, evaluation suites, and integration knowledge should accumulate across projects. Client-specific information retains confidentiality boundaries. The reusable delivery infrastructure should make subsequent engagements easier to execute and verify.
3. Concepts We Need to Redefine
- Code quality
Quality expands to include how reliably a system can be generated, evaluated, changed, and operated. Readability remains useful wherever humans investigate or intervene. More weight goes to behavioral correctness, security, performance, explicit contracts, and the ability to detect regressions independently of the agent producing the code.
- Maintainability
Maintainability becomes the cost and confidence of changing a capability over its lifetime. That includes reconstructing intent, identifying dependencies, validating a change, migrating state, and recovering from failure. Clear Ground Truth and strong evaluations may make a component easier to replace completely even when its internal implementation receives little human attention.
- Darker boxes
We will increasingly use components whose internals require little ongoing human understanding. Their consumers should understand their responsibilities, interfaces, guarantees, and failure behavior. Internal opacity raises the importance of observable outcomes, traceability, independent verification, and clear ownership. Simplicity comes from limiting the knowledge required to use the component safely.
- The scope of a software component
Components will increasingly own broader business responsibilities. A box might manage client correspondence, follow up on outstanding documents, coordinate administrative work, and make routine decisions within an agreed policy. Producing an accounting statement becomes one operation inside that capability. Generality grows at the business interface supported by specialized tools and workflows underneath.
- What “optimal” means
Native applications and efficient languages become more attractive as the human cost of implementation falls. We can pursue better latency, smaller binaries, lower infrastructure costs, and deeper platform integration. The relevant optimization target is total lifetime cost and quality including agent execution, verification, deployment, and ongoing change. Token efficiency is one part of that calculation.
- Ground Truth
Ground Truth becomes an operational model that agents can query and act upon. It must represent business rules, exceptions, decision rights, sources, and uncertainty. As components take responsibility for broader functions this model defines the boundaries of their autonomy and the situations that require a human decision.
- The engineering role
Engineering increasingly includes designing the system that produces and evolves software: context, architecture, tool contracts, orchestration, evaluations, and feedback loops. Product judgment and UX remain central to defining a coherent experience. Senior engineers are responsible for the reliability of the whole production process.
- The unit we sell and own
Delivery can be packaged around a functioning capability and its continued evolution. Pricing depends on the clarity of its boundaries, integration complexity, acceptance criteria, and operational responsibility. Broader autonomous capabilities enable selling an ongoing business function with explicit outcomes and accountability.
