You Can’t Direct What You Can’t Interrogate

The throwaway that never gets thrown away

At Amazon, incubating a new business felt like building the train while it ran, laying rails just ahead of it. Everything was a prototype, and everything would be rebuilt later.

I've seen the same pattern at nearly every company I've worked for. The proof of concept ships, the first revenue arrives, and "later" never does.

Vibe coding didn't create that failure mode. It amplified it. When a working demo takes an afternoon, every demo looks 90% done.

Confidently wrong

Ask an agent to build a chat feature and it may well key your messages with UUID v4. It will work in the demo.

Then real traffic arrives, with messages landing back to back. A v4 ID is random, so it carries no order. You fall back on timestamps, and timestamps tie, drift, and arrive out of sequence. Ordering breaks, and ordering is the whole product.

The agent wasn't being careless. It picked something reasonable-sounding and said so with total confidence. You only catch it if you know why v4, v7, and sequential IDs behave differently under load. (Even v7 needs care when many messages land in the same millisecond.)

Works on your laptop is not the same as works well at scale

Getting something running on your laptop is not remotely the same as working well at scale, or even across two running instances. Ask yourself:

Data

• Can you interrogate an ERD? Do you know the three normal forms, why they matter, and when to deliberately break them?
• Do you understand race conditions, and what happens when two instances read, modify, and write the same row?
• Do you know when a relational database is the right tool, and when a document, key-value, or wide-column store earns its trade-offs?
• Can you change a schema without downtime? Do you know how to run a migration safely on a table that is being written to right now?
• Disaster recovery: do you have recovery targets, and has anyone rehearsed a restore from backup? Can you upgrade the database version without an outage?
• What happens when a request is retried, or when two systems briefly disagree?

Scale and performance

• Do you know why a traditional CRUD app can choke on its own reads and writes at scale, and what CQRS buys you? (And when it's overkill.)
• Do you know the difference between scaling horizontally and vertically? Can you build for autoscaling that works under real-world conditions: stateless services, cold starts, the right scaling signal, and a database that can't autoscale along with you? Autoscaling is never a toggle you switch on and walk away from.
• Caching: do you know when to cache and where (browser, CDN, application, database)? Do you know the trade-offs between cache-aside, write-through, and write-behind, how you'll invalidate, and when and how to warm a cache before traffic arrives?
• CDNs: do you know how to set one up and manage it thoughtfully? What to cache and for how long, how to purge, and what must never be cached?

Security, identity, and compliance

• Do you understand security beyond "add login"? OWASP, CSP, encryption in transit and at rest, end-to-end encryption, key rotation?
• Networking: are your VPC and network rules controlling every way into your environments? Do you know how to audit for open ports, and what is allowed to leave? Would you notice if data were being exfiltrated?
• Authentication: do you know when you need OAuth, OIDC, or SAML, and what each one actually proves? Who owns the identity, you or your customer's identity provider?
• Auditing: can you answer "who did what, to which record, and when" for an auditor? SOC 2, HIPAA, and their cousins turn that from a nice-to-have into a requirement.
• Privacy: do you know what counts as personal data, where it lives, and what GDPR, CCPA, or data-residency rules require you to do with it?

Quality and operations

• Do you know what each layer of automated testing buys you (unit, integration, contract, end-to-end, synthetic, load, stress, performance), and what it costs? Every layer up is slower, flakier, and harder to maintain. Do you know what belongs at which layer, what mocks hide, and what a green suite doesn't prove?
• CI/CD and infrastructure: do you know what a pipeline should gate, and how to ship small and limit the blast radius? Do you roll forward by default and roll back only when you must? Is your infrastructure code, or clicks in a console that nobody can reproduce (ClickOps vs. DevOps)?
• Environments: do you know what local, dev, sandbox, staging, and production are each for? How closely do they match, and how do you keep production data and credentials out of the others?
• Monitoring and alerting: do you know what to measure, and what deserves to wake someone at 3 a.m.? Silence from a system is not the same as health.
• Reliability: do you know what happens when a dependency is slow or down? Timeouts, backpressure, graceful degradation.
• Cost: do you know what this costs at 100x the traffic, and when optimizing is a waste of time?

Design and dependencies

• Interfaces: can you design and version an API without breaking everyone who depends on it, and do you know which seams to expose?
• Do you know when to reach for a synchronous API, RPC, or events, and what each costs in coupling, latency, and failure handling?
• Build, buy, or adopt open source? What do a dependency's license, upkeep, and supply-chain risk cost you later?
• Dependency management: do you know what is actually in your build, including the dependencies of your dependencies? Do you track CVEs, pin and update versions deliberately, and know what to do when a critical vulnerability lands in a library you never chose directly?

AI features

• How do you evaluate output that is non-deterministic? What can prompt injection reach through your agent? What does each call cost?

That's a sample, not the list. Engineers answer them daily, often without noticing. An agent answers them too, quietly, whether or not anyone asked. Agents optimize the happy path. Judgment is mostly about the unhappy ones: failure, scale, abuse, change, and confused humans.

Start with a monolith. Don't stay a blob.

A monolith is the right way to start. It's fast, and it avoids splitting services around your org chart too early.

But the seams, meaning how you'd decompose into services along single-responsibility lines, have to be drawn from day one. You can't bolt them on later.

I've watched a single code base run everything from the public website to the internal CRM. Every production push took down the sales team's VOIP calls. That is the bill for a throwaway nobody ever revisited.

It isn't only code

The same holds for product and UX. Does the early praise for your prototype count as signal, or are five friendly users telling you what you want to hear? What is the smallest thing worth shipping, and what should you refuse to build? What happens on the empty screen, the error state, the slow connection, or the accidental click on "delete"? Is it accessible?

A demo hides all of this as well as it hides the engineering gaps.

The vocabulary is the interface

If you can't read what the agent produced, you can only accept or reject it by feel. You can't tell it why it's wrong.

Fluency means the patterns Fowler and others spent careers naming, and automated testing with all its nuances, including TDD red/green. It means PRD → ARD → HLD, and functional vs. non-functional requirements. Without that language, you'll never direct an agent with enough clarity or nuance.

For product managers and non-technical founders

Agents are the biggest lever you've ever had, and you should pull it hard. But the less you can interrogate the output, the more you operate on trust, and trust without verification is how throwaways become production. Learn the vocabulary, or bring in someone who has it.

For engineers

Agentic engineering solves one problem: compressing code generation. Edge cases, tradeoffs, scope, and collaboration across silos stay human, along with the hardest skill: knowing what not to do.

Sketch vs. system

Vibe coding is a sketch. It's valid and cheap, and it produces signal. Just call it a sketch. Agentic engineering starts with a measurable goal and an automated SDLC that lets an agent reliably reach it.

The rule

Set a decision point before you start: at the first customer or the first dollar, you either rebuild or you consciously accept the debt.

Agents made code nearly free. That makes judgment the scarce part. Software engineering was never about the code, any more than building a house is about the nails.