Agentic software is here: what changes when apps build themselves

The problem

Ask an AI model to write you a form, a workflow, a small internal tool, and it will. That part is solved, and it keeps getting cheaper. Ask the same question a year from now and the model won't just write the tool once — it will keep changing it: adding a field when your process changes, adjusting a rule when a customer complains, wiring up a new step because an agent noticed a pattern in your data. Software that edits itself, in production, without a human necessarily reviewing every line first.

That should make you nervous, and it should make you nervous in a specific way. Not "is the code any good" — models write serviceable code constantly now. The real question is: what is that generated code running on? Who guarantees it can't read another customer's data? Who guarantees it can't be told to lock a job in a state it should never reach, silently, forever? Who guarantees you can even reconstruct what it did after the fact? Most software stacks were built assuming a human wrote every line and a human would be around to explain it later. Take that assumption away and you notice how much weight it was carrying.

Why it matters now

The reason this is a 2026 problem and not a someday problem is that the cost of generating a plausible-looking change has collapsed while the cost of verifying it has not. A model can produce a new business rule, a new integration, a new report in seconds. Reviewing that output with the rigor you'd apply to a human engineer's pull request — for correctness, for security, for what happens to tenant data — takes real time, and that time doesn't compress the way generation time does. Something has to close that gap, or teams will either freeze (too slow to benefit) or wave things through unreviewed (too risky to sustain).

The gap doesn't close by getting better at prompting. It closes by changing where the trust boundary sits. If every unit of generated logic runs inside a substrate that mechanically enforces isolation, boundedness, and an audit trail — not because the generated code is well-behaved, but because the platform underneath it makes misbehavior structurally unable to spread — then the review question changes shape. You're no longer asking "can I trust this code with everything the process can touch." You're asking "did this code do what it was supposed to, within a boundary that was never going to let it do anything else." That's a much smaller, much more answerable question, and it's the only version of this that scales past a handful of hand-reviewed changes a week.

How FastYoke approaches it

We didn't build FastYoke anticipating a specific AI product moment. We built it because operational software — the workflows, forms, and business rules that run a logistics operation — is naturally described as data: states, transitions, guard conditions, field definitions. Once you commit to that shape, a few properties fall out that turn out to matter a great deal for software written by something other than a careful human engineer.

Logic runs in a sandbox, not as raw code. Every guard condition and every tenant-authored script in FastYoke is evaluated inside a WebAssembly sandbox — either the jsonlogic-rs evaluator for declarative rules, or a wasmtime-hosted path for heavier logic, including a QuickJS engine compiled to WebAssembly for tenants who write plain scripts. None of it is interpreted as raw strings; there is no eval of untrusted text anywhere in the path. Each evaluation runs under a fuel budget and a memory ceiling, and the sandbox has no inherited network sockets and no filesystem — a script cannot phone home even if it were told to. We wrote about the specifics of that sandbox in why FastYoke chose WebAssembly. The reason it matters here specifically: if a model is going to author or modify that guard condition tomorrow instead of a person today, the blast radius is already capped by construction, not by hoping the generated logic is polite.

Workflows are an explicit state machine, not opaque control flow. FastYoke's engine is a finite-state machine: a job has a defined set of states, and every transition between them is a named edge with a guard. There is no "just run this function and see what happens." A generated workflow is a graph you can render, inspect, and diff — you can look at it and ask "does this do what I asked for" without reading an implementation. That's a fundamentally different review surface than a pile of generated imperative code, and it's the difference between reviewing a workflow and reverse-engineering one.

The UI is generated from the schema, not hand-built. Custom entity screens in FastYoke aren't hardcoded forms someone wrote once — they're rendered dynamically from the same JSON schema that defines the entity. If a new field or a new entity type gets added, the interface for it exists immediately, because the interface was never a separate artifact to keep in sync in the first place. That closes off an entire category of drift where generated backend logic outruns the UI that's supposed to expose it.

Installed apps are data in your own database, not code shipped into your process. A marketplace app in FastYoke installs as rows — schemas, FSM definitions, seed records — into the tenant's own per-tenant database, not as a binary or a package dropped into a shared runtime. That means "add a new app," generated or not, doesn't mean granting it any more access to the host process than any other tenant configuration already has.

Every state change is a fact in an append-only log. The event_log table records what happened, and it is never updated or deleted — only appended to. Whether a transition fired because a person clicked a button or because an automated actor drove the job forward, the record looks the same and it's permanent. If you need to answer "what did the agent actually do to my data last Tuesday," the answer isn't in a chat transcript somewhere — it's a queryable, immutable ledger.

It's one binary, and it runs where your data has to stay. FastYoke ships as a single Rust binary that runs the same way in our cloud, inside a customer's own data center, on an edge gateway, or fully air-gapped. If part of the appeal of agentic software is that it can act autonomously, the deployment question — where does that autonomy actually execute, and does it ever leave premises it isn't allowed to leave — stops being theoretical. The substrate travels with the constraint.

None of this is "FastYoke has an AI app generator." We don't ship that today and this isn't a soft announcement of one. What we're describing is narrower and, we think, more durable: the pieces you'd need underneath any system that generates or modifies operational software safely — a sandboxed execution model, an explicit and inspectable state machine, schema-driven UI, tenant-owned data, and an immutable audit trail — already exist, because we needed them for human-authored tenant logic long before "an agent wrote this workflow" was a sentence anyone said out loud. The substrate doesn't care who or what authored the logic running on top of it. That's the point.

What to watch out for

Be skeptical of anyone, including us, who implies that generated software needs less scrutiny because a model produced it instead of a person. The opposite is true, for a simple reason: a human author can be asked why they made a decision, and their track record informs how much you trust the next thing they ship. A model has no comparable accountability, and its failure modes — a plausible-sounding guard condition that's subtly wrong, a workflow that technically satisfies the prompt but not the intent — don't announce themselves the way a human's obvious mistakes often do. Determinism and auditability aren't nice-to-haves you can relax once generation gets good enough. They matter more, not less, precisely because the author can't be interrogated the way a colleague can.

Concretely: don't let "an agent wrote it" become an excuse to skip the review step you'd apply to a contractor's first pull request. Keep the generated artifact inspectable — a rendered state graph beats a wall of generated code every time, for exactly this reason. And insist that whatever ran, ran inside a boundary that would have contained it even if it had been actively hostile, not merely well-intentioned. Trust the sandbox. Verify the logic.

Where to go next

If you want the detail on the sandbox that makes tenant-authored (and, increasingly, machine-authored) logic safe to run, we covered it in why FastYoke chose WebAssembly. To see what running your own workflows on that substrate looks like, take a look at FastYoke's runtime, or talk to us about building on FastYoke.