Opinion - Where is it `I` more than `AI`
Bringing back the joy of building
AI lowers (has lowered) the cost of getting from zero to a running software prototype to near-zero. Many mid-to-senior teams already know that. The harder part is the second curve: keeping the system reliable as reality around us gets noisy and context diverges.
We can build autonomous loops quickly now. Keeping them correct under change is where total cost shows up. Plus, it’s a lurking feeling for the many that the joy of building or craft has been taken away by AI (rightfully so in many cases), where does one find that sense of joy.
Below are points that tends to get underestimated when “AI” builds:
Infra cost: model tokens, retries, tool-call fanout, queue/broker throughput, storage for traces/state, observability pipelines, network egress, and burst headroom for peak traffic.
Maintenance cost: prompt drift, model/version churn, schema evolution, integration contract changes, policy updates, and regression hardening as edge cases accumulate.
Debugging cost: non-deterministic behavior, partial failures across steps, weak replayability, missing correlation IDs, and long-tail failures that only appear under specific load and data shapes.
Scaling cost: latency budgets across multi-hop flows, concurrency controls, backpressure, idempotency guarantees, rate-limit strategy, and contention on shared dependencies.
Operational cost: on-call handling, runbook quality, incident triage loops, recovery automation, and the ownership tax of “works in dev, flakes in prod.”
Opportunity cost: time spent stabilizing orchestration instead of shipping product leverage tied to measurable outcomes.
None of this means “don’t build with AI.” It means choosing the autonomy level intentionally. Competing contexts that are often better than full autonomy:
Human-in-the-loop workflows for high-impact or low-frequency decisions where correctness matters more than throughput.
Deterministic workflow engines/state machines for compliance-heavy paths where auditability and replay are non-negotiable.
Simple queue-plus-worker pipelines for narrow, well-bounded jobs where complexity overhead of agentic control planes is not justified.
SaaS/off-the-shelf automation for non-differentiated operations where build cost cannot beat buy cost over 12-18 months.
Manual ops with strong tooling for early-stage capabilities where problem definition is still moving faster than architecture should.
A practical rule for I’ve found useful for experienced builders:
Autonomy is worth it when the task is high-volume, low-ambiguity, reversible, and measurable. The gains will compound.
Assistance is better when the task is light/sparse, high-ambiguity, or has large blast radius.
If success criteria cannot be expressed as clear invariants, don’t close the loop yet. It’s simply premature.
Build because it is useful or because it is a deliberate learning bet. Not because it is fun to automate everything that moves. Fun is a valid reason for exploration. It is a weak reason for production/business ownership.
With that context, it may even get easier to discover new paths to the joy of building.