So Your Marketing Team Is Shipping Code Now

I've been watching two threads run in parallel on my feed lately. One is about vibe coding — how anyone in an organization can now spin up tools and ship software, how agents are touching production systems, and how little formal process exists around any of it. The other is about the software engineering profession — how a year ago the conversation was whether AI was going to end it, and how the conversation now is that we have more software being produced than ever and somebody still has to QA it, review it, and clean up after it.

These are the same observation told from two different seats. The amount of code being shipped has gone up. The amount of human attention available to vet that code before it goes live has not. Something has to give, and what's giving is the traditional model of review-before-ship.

Most of the responses I've seen to this are trying to re-impose a gate at the point of authorship. Require reviews. Restrict who can use which tools. Make people file a ticket before an agent touches anything. I understand the impulse, but I think it misunderstands what actually changed.

Here's what changed. For about forty years, the cost of writing and shipping software was high enough that the author was a reasonable proxy for quality. If a senior engineer committed it, you could trust the commit — not because commits are inherently trustworthy, but because the friction of getting to "commit" filtered out most of the bad ones. Code review, staging environments, QA — all of it was built on the assumption that a small number of identifiable humans were responsible for each change, and you could hold them to a standard before the change went live.

That assumption is dissolving. Not because agents are magic, but because the cost of producing a working-looking change has collapsed. A marketing manager can ship a landing page in an afternoon. An ops person can wire up an internal dashboard over lunch. An agent can open a PR, get another agent to review it, and merge. The author is no longer a useful proxy for anything, because "the author" is increasingly a probabilistic text generator operating on a prompt someone wrote while distracted.

This is also, I think, the real answer to the "is software engineering over" question. It isn't over. It's moved. The work that used to happen before the code shipped — the reviewing, the verifying, the catching of things that look fine but aren't — still has to happen. It just can't happen at the same place in the pipeline anymore, because the pipeline got too fast. The work moved downstream. And downstream is where the interesting tooling problem is.

Every industry that got here before us reached the same conclusion: when you can't vet the input, you verify the output.

Restaurants don't audit every cook's technique — they inspect the kitchen and test the food. Drug manufacturers don't interview each chemist — they assay the final product. Bridges aren't trusted because the welders were certified (though they were); they're trusted because they're load-tested after they're built. In every domain where production got faster than vetting, the governance layer moved downstream. It moved to the output.

Websites are overdue for this shift. And websites are, conveniently, one of the easiest things in the world to test from the outside, because the outside is where they live. A website is a public artifact. Anyone with an HTTP client can check whether it's up, whether its SSL is valid, whether its meta tags are sane, whether its Core Web Vitals are acceptable, whether its forms submit, whether its links resolve, whether its security headers are set, whether its content has silently changed, whether its domain is about to expire. You don't need to know who wrote the code. You don't need to be inside the repo. You just need to keep looking.

This is what SiteVitals does, and I think the current moment is what makes it interesting rather than merely useful. In the old world, external monitoring was hygiene — a thing you set up because your ops team was professional and wanted pager coverage. In the new world, it's the governance layer. It's the thing that notices when the agent that redesigned your pricing page also broke the canonical tags, tanked your Lighthouse score, and introduced a mixed-content warning that the agent's own self-review didn't catch because the agent was optimizing for "looks good in the screenshot."

A few things follow from this reframe that I think are worth sitting with.

First, the standard stops being "did a human approve this" and starts being "does the live site meet the bar." That's a more honest standard anyway. Human approval was always a lossy proxy; plenty of production incidents in the pre-AI era came from changes that a human did approve. What you actually care about is whether the site works, whether it's fast, whether it's secure, whether it's findable. Those are measurable. Measure them continuously and the question of who shipped the change becomes a forensic detail rather than a gate.

Second, this is not a story about stopping agents or stopping non-engineers from shipping. I want to be clear about that, because the governance conversation keeps reaching for the brake pedal and I don't think the brake pedal is where the value is. More people and more agents shipping software faster is, on balance, going to produce more good software than bad. The win condition isn't to slow them down; it's to make sure that when something broken goes out, you find out in minutes instead of when a customer emails you. External monitoring is the feedback loop that lets you run fast safely. It's the seatbelt, not the speed limiter.

Third — and this is the part I think most organizations haven't absorbed yet — the monitoring needs to be independent of the thing being monitored. If your agent writes the code, runs its own tests, and reports its own success, you have not verified anything; you've asked a student to grade their own exam. The verification has to come from outside the system that produced the change. A separate service, hitting the site the way a real visitor would, with no knowledge of what the agent thinks it did. That independence is the entire point. It's also why "the AI will monitor itself" is not a serious answer to this problem, at least not yet.

I'll close with the thing I find genuinely exciting about this moment, rather than just anxious. For a long time, the craft of shipping websites well was gatekept by people who understood a long list of invisible standards — accessibility, performance budgets, SEO hygiene, security headers, schema markup, canonical URLs, the difference between a 301 and a 302. Most of that knowledge lived in senior engineers' heads and got applied inconsistently. The current wave is going to flood the zone with people and agents who do not have that knowledge. That sounds like a disaster, and in the short term it will produce some disasters. But it also means that encoding those standards into automated, continuous, external checks — which is what SiteVitals is — suddenly matters much more than it did. The standards don't have to live in a person anymore. They can live in the monitor. And the monitor never gets tired, never skips a Friday deploy, and doesn't care whether the PR was opened by a principal engineer or a prompt.

The governance layer is moving downstream. If you're thinking about how to stay sane while your organization ships faster than it can review, the answer is not to slow the shipping down. It's to put something at the finish line that actually checks the work.