chris.engineering
Back to blog
•
8 min read
Code Is Cheap. Show Me the Proof.

AI is making code generation cheaper than it has ever been. The bottleneck is shifting from “can we build it?” to “can we prove it’s safe, correct, and maintainable?”

This post is a practical take on a theme I keep seeing: the industry is drifting from implementation-heavy engineering toward verification-heavy engineering—and that will reshape teams, careers, and hiring faster than most people expect.

I’m using Addy Osmani’s “two plausible futures” framing as a starting point. The key idea is not “AI replaces engineers” vs “AI changes nothing,” but that organizations will choose how they integrate AI: replacement, amplification, or something messy in between.

My punchline: In the next two years, the winning teams won’t be the ones who generate the most code. They’ll be the ones who can ship the most proof.

Table of contents

1) The real shift: code is cheap, trust is not

When code is abundant, understanding becomes scarce.

The immediate temptation is to treat AI as a turbocharger for output. But output isn’t the same thing as value. In production systems, value is correctness, reliability, security, observability, and operability.

So the center of gravity moves:

  • From writing code → specifying behavior
  • From implementing features → verifying properties
  • From “it works locally” → it survives reality
  • From heroics → repeatable evidence

If you only adopt AI for generation, you get more code.
If you adopt AI for verification + governance, you get compounding velocity.

2) The junior pipeline problem (and how to fix it)

One of the most important second-order effects: companies can “do more with fewer people,” and the first place they often cut is junior hiring.

That looks rational in the short term. But it creates a delayed failure mode:

  • fewer juniors today → fewer seniors tomorrow
  • fewer seniors tomorrow → fewer leaders, fewer staff-level engineers, fewer “taste-makers”
  • fewer taste-makers → weaker architecture, weaker review culture, weaker incident response
  • weaker engineering culture → slower and riskier delivery (even with AI)

Fix: redefine what “junior” does

Stop thinking of juniors as feature factories. Think of them as leverage multipliers.

High-leverage junior ownership areas:

  • Test harnesses and regression suites (including property-based tests)
  • Observability dashboards and SLO instrumentation
  • CI reliability and build time reductions
  • Runbooks, playbooks, incident postmortem follow-ups
  • Contract tests between services
  • “Golden paths” for local dev + staging deploys

This makes juniors net-positive faster and hardens your system for AI-accelerated change.

3) The new T-shape: breadth is mandatory, depth differentiates

AI raises the floor on breadth. That means “generalist” competence becomes cheaper.

But it also raises the premium on domains where:

  • correctness is difficult to verify,
  • failure is expensive,
  • or the system is too complex for shallow intuition.

Depth will differentiate in places like:

  • payments and financial correctness
  • authN/authZ and policy
  • distributed systems and performance
  • security boundaries and threat modeling
  • data correctness and lineage

Practical model:

  • Everyone becomes “broad enough to integrate anything.”
  • The market still rewards the people who can say “this is correct, and here’s the evidence.”

4) “Developer as orchestrator” is real—if you build guardrails

I agree with the “engineer becomes orchestrator” prediction, with a caveat:

If you don’t build guardrails, you don’t get orchestration—you get roulette.

Orchestration means:

  • decomposing work into verifiable chunks,
  • designing constraints for agents,
  • requiring evidence for merges,
  • and controlling blast radius in production.

Here’s what that looks like as an engineering system:

flowchart TD
    A[Problem statement] --> B[Spec & constraints]
    B --> C[AI-assisted implementation]
    C --> D[Evidence generation]
    D --> E{Quality gates?}
    E -- No --> B
    E -- Yes --> F[Staged rollout]
    F --> G[Observability & SLO check]
    G --> H{Regressions?}
    H -- Yes --> I[Rollback + postmortem]
    H -- No --> J[Ship + learn]

The point is simple: AI should accelerate the loop, not bypass it.

5) A verification-first playbook you can apply this quarter

If you only take one thing from this post, take this:

Make it cheap to verify changes. Make it expensive to ship without evidence.

5.1 Quality gates that actually matter

For normal services:

  • Mandatory unit + integration tests for changed paths
  • Contract tests for service boundaries
  • Static analysis + dependency scanning
  • “No new endpoint without telemetry”
  • Performance budgets for critical APIs

For sensitive zones (payments/auth/security):

  • Explicit threat model notes per change
  • Stronger review policy (domain owner sign-off)
  • Mandatory staged rollout + monitoring window
  • “No-agent changes” unless paired with enforced checklists

5.2 A “proof checklist” template (copy/paste)

Use this in PR descriptions:

  • What changed?
  • What invariant must remain true? (e.g., “idempotency,” “no double-charge,” “authorization boundary intact”)
  • What evidence proves it?
    • Tests: (link / list)
    • Contracts: (link / list)
    • Observability: (metric/dash)
  • What’s the blast radius?
  • Rollback plan?

This is boring. It’s also how you scale velocity without scaling incidents.

5.3 Use AI where it’s strongest

High ROI uses:

  • generating test cases and edge cases from specs
  • proposing invariants and properties
  • diff-aware refactors with tight constraints
  • summarizing logs and incident timelines
  • producing runbooks and “what to check” guides

Lower ROI (unless your org is very mature):

  • generating large, ambiguous feature sets without crisp acceptance criteria
  • rewriting security-sensitive modules without domain review
  • “end-to-end” changes without independent verification

6) What I’d measure (because vibes don’t scale)

If you want to know whether AI is helping, measure outcomes that reflect trust:

  • Change failure rate (deploys that cause incidents/rollbacks)
  • MTTR (mean time to recover)
  • Escaped defect rate (bugs found in prod / after release)
  • Lead time for change (idea → running in prod)
  • Test coverage of critical invariants (not raw coverage %)
  • Deployment frequency with stable SLOs (velocity and health)

If AI increases output but worsens failure rate, you didn’t get leverage---you got debt.

7) Speculation: what might surprise us

(Flagged as speculation.)

  1. Teams will split into “proof cultures” and “output cultures.”

    Output cultures will look fast until they hit a wall of regressions and trust collapse.

  2. Senior engineers become more valuable, not less---temporarily.

    Not because they type faster, but because they can design constraints, spot failure modes, and build systems that scale.

  3. Junior hiring rebounds in companies that treat juniors as leverage.

    The apprenticeship model will outperform the “we don’t need juniors anymore” model.

  4. “AI governance” becomes a core engineering competency.

    Provenance, auditability, policy-as-code, and constrained agents become standard tooling.

Conclusion

More code won’t save you. More proof will.

The teams that win won’t be the ones generating the most code. They’ll be the ones who can specify the right thing, verify it cheaply, ship it safely, and build a culture where trust compounds.

If you’re a senior engineer or leading a team, your job is increasingly to design the system that produces correct software, not just the software itself.

References