The old software economy let bad teams hide. They could buy a respected product, adopt its workflow, hire a consultant, and call the result a best practice without ever proving they knew what the system should actually do.
AI removes that cover. When implementation becomes cheap, teams must define correct behavior themselves, and many cannot.
That is the real risk behind “vibe coding.” It is not that an LLM will write bad code. It is that it will faithfully expose bad judgment.
The criticism focuses on authorship: software produced by a model must be less trustworthy than software produced by a person. Compilers made the weakness in that argument obvious decades ago.
Before compilers, programmers wrote machine instructions or assembly directly. Compilers let them work at a higher level while a machine generated the implementation—something that probably looked like vibe coding to an assembly programmer. Compilers could produce inefficient or incorrect output, but we learned to judge their results by behavior rather than authorship.
An LLM is not a compiler; its probabilistic output creates different risks and requires different validation. But the relevant questions remain whether the system works, whether failures can be detected, and whether the result is better than the alternatives, not who or what typed the code.
That last clause is a product requirement, not a slogan. If behavior is the standard, a team needs the machinery to state behavior, to give a model the context that behavior depends on, and to observe the running result. That machinery is what we build.
Working behavior is the source of truth#
Code, historically the slowest and costliest step, is only a means; the objective is verified behavior. “Sync customer data” is not a specification until it defines scope, authority, timing, conflicts, and failure handling.
A team unable to make those decisions cannot reliably build or buy software. It will substitute feature lists for requirements, demonstrations for evidence, and completed implementations for solved problems. When the result fails, blaming the vendor, consultant, developer, or model obscures the original problem: the team never defined what working meant.
Substituting demonstrations for evidence is the failure worth dwelling on, because it is the one that scales badly. A demo is a single traversal of a happy path, chosen by whoever is presenting. Evidence is the system exhibiting the specified behavior on your data, where you can inspect why. This is why every Miriel product returns its sources: the context engine attributes each answer to the records it retrieved and lets you inspect the whole pipeline rather than trusting a black box, and PerceptDB returns the evidence — the clip, the row, the record — alongside every answer. A team that has defined correct behavior can check an answer against the thing it came from. A team that hasn't will accept the answer because it sounded right, which is exactly the habit the old bundle rewarded.
Software bundles provided cover#
The classic advice was to use best practices for non-core functions and innovate only where the business differentiated itself. This made sense when custom software was expensive, but in practice the tools often defined those best practices.
Vendors supplied the data models, workflows, permissions, and exceptions. The CRM defined a customer; the project-management tool defined a project; the support platform defined a ticket. Some defaults reflected accumulated expertise; others reflected legacy architecture, marketability, or configuration limits. Both were presented as best practices.
The constraint underneath most of those defaults was storage. A vendor's schema was the price of not building storage and retrieval yourself, and that price was worth paying — so companies inherited a definition of customer from whoever solved persistence for them. It is most visible in the data no traditional bundle would hold at all. A company whose real operations are video, audio, sensor streams, telemetry, and events had no product-shaped place to put them, so those signals were split across buckets, a warehouse, and a vector store, and the questions worth asking spanned all three. The answer was usually to ask a smaller question. PerceptDB exists because that compromise is no longer necessary: objects, streams, SQL metadata, and embeddings live in one system of record, with perception — embeddings, detections, OCR, transcripts — built into ingestion, so “did the package get delivered at dock 4 yesterday, and was the door left open afterward?” is a query rather than a project.
Companies therefore selected whichever available process they could tolerate rather than defining the correct process themselves. The vendor supplied the concepts, the consultant supplied the workflow, and the internal team managed the compromises.
That arrangement rewarded procurement, configuration, and vendor management while concealing weak first-principles judgment. People who were poor at defining correct systems could still appear competent by adopting standard tools and treating their constraints as wisdom.
Cheap implementation removes the cover#
AI makes workflows, integrations, and internal tools far cheaper to produce, shifting the starting point from available products to required outcomes:
Available products → acceptable compromises → configured process
Correct outcome → explicit behavior → implementation → validation
When vendors no longer define the process, teams must. Procurement and vendor management remain useful, but value moves toward specifying correct behavior and proving that the system exhibits it.
A model can propose designs, expose edge cases, generate tests, and improve an imperfect implementation. It may even catch mistakes the team missed. It cannot remain accountable for deciding what correct means.
It also cannot do any of that on a system it cannot see. A model reasoning about your business from a prompt will produce the generic answer; a model reasoning about your business from your documents, databases, conversations, and history will produce edge cases you had not written down. That is the Miriel context engine's job — ingest your sources and turn them into a live, queryable context layer, with indexing and retrieval tuned per source, so the model's proposals are grounded in your organization rather than in the average of everyone's. Permissions are enforced at the token level rather than the file level, which matters more once agents rather than people are doing the reading.
Each of the two arrows in that second line is a distinct product problem. Implementation is a coding agent that can actually make changes that build and run — that is Autodev. Validation is the harder half, and it is where most AI-assisted work quietly stops: a diff that compiles is not behavior. Autodev deploys every change to servers that match your real dev and prod environments and makes those targets observable by default — logs streaming back over MCP, Playwright enabled for driving the UI, traffic and DNS handled — so the question “does it do the thing we specified?” is answered by watching it run, not by reading the diff. Releases stay under human control and route through GitHub, so the audit trail is the one your team already trusts.
Start with the theoretical best#
This kind of first-principles reasoning was common at Google, Facebook, and NVIDIA. When I worked at those companies, discussions often began with some version of: What is the theoretically best way this could work? Start there.
Jensen Huang gave the idea a memorable formulation at NVIDIA: determine the “speed of light” (the limit imposed by physics or logic) then measure how close the current system gets to it. NVIDIA eventually codified “Speed of Light” as a management philosophy.
The point was not to ignore practical constraints, but to avoid confusing them with the objective. Starting with an existing product or process produces incremental improvement; starting with the theoretical outcome reveals how much compromise has accumulated and which constraints are real.
Best practices still matter, particularly in regulated, standardized, or security-sensitive domains, but they become evidence rather than authority. A standard pattern may be correct, a useful starting point, or a product limitation repeated until it acquired the status of wisdom. Competent teams know the difference.
Applied to our own roadmap, the speed-of-light question is what produced these products rather than better versions of the existing ones. The limit for retrieval is not "a good vector database," it is that an application should get exactly the context a question requires. The limit for operational data is not "cheaper object storage," it is that a question about the physical world should be answerable in one query, with evidence. The limit for shipping is not "faster CI," it is that the interval between specifying a behavior and observing it in a real environment should approach zero.
We are the first team this applies to#
We test this on ourselves, which is the only honest way to sell it.
The work in our repositories is specified as an outcome in Linear, implemented by an agent through Autodev, and deployed to a preview environment that matches production before anyone reviews it. Pushing the branch is the deploy; there is no separate button. The agent then drives that preview in a real browser and reads real container logs, and what it observed goes into the pull request — because "the change works" is a claim about a running system, and we do not accept it from ourselves without evidence either. Human review and the release itself stay ours.
This is also true of the page you are reading. This blog, its admin surface, and the import pipeline that put this post here were built that way, and the pipeline is deliberately an API rather than only a UI, because the authoring path has to be usable by an agent to be worth much to us.
None of that would rescue a team that could not say what it wanted. That is the point. Our tools compress the distance between an explicit outcome and a validated system; they have nothing to offer a team that never made the outcome explicit.
Build versus buy comes afterward#
Once the required behavior is explicit, the implementation choice becomes clearer. Buying is sensible when an existing product provides that behavior. Building becomes attractive when the available products require distorted workflows, inaccessible data, expensive integrations, or permanent compromises.
Note what that shift does to the category of thing worth buying. The products that survive it are not the ones that define your process; they are the ones that remove a genuine constraint and then get out of the way — storage and retrieval you would otherwise spend months building, a multimodal system of record you cannot reasonably assemble from three services, an environment where a change can be deployed and observed. Infrastructure is a good buy precisely because it does not tell you what a customer is.
The same weakness produces bad buying and bad building. Without a behavioral definition, vendor demonstrations look like evidence, feature lists look like analysis, and generated prototypes look complete.
AI will not make bad teams good. It will let them produce the wrong system faster, with fewer people available to absorb the blame.
Strong teams will use the same leverage differently: define the outcome, generate the implementation, validate the behavior, and own the result. That sequence is the whole thesis of what we build: the context engine so a model reasons about your business, PerceptDB so the data your behavior depends on is actually queryable, and Autodev so the implementation lands somewhere you can watch it run.
The old software bundle made those teams difficult to distinguish.
AI will make the difference obvious.
