Natural-Language Code: G5 Labs' Bet, Examined

By Lazar Milicevic · Published September 24, 2026 · 9 min read

You just merged a PR from an AI agent. It works. Two days later, another agent refactors half of it, introduces a subtle contract mismatch with a third agent's job runner, and now your Stripe webhook is retrying every 30 seconds. Nothing is broken enough to page you. Everything is broken enough to bleed money.

This is the actual problem G5 Labs is trying to solve with their pitch: stop treating code as the source of truth. Make natural-language specifications the source of truth, and let agents regenerate the code beneath them. It sounds like a rebranded low-code play. It isn't — or at least, not entirely. Let's take it seriously and figure out what's real, what's marketing, and what a solo builder or 5-person shop should actually do about it this quarter.

What G5 Labs is actually proposing

G5's core claim: as AI agents write more of the codebase (Anthropic has publicly said agents author a large majority of their internal code), the bottleneck shifts from writing code to coordinating what many agents write. Their fix is to move the canonical artifact one abstraction layer up — from code to natural-language workflow specs that a platform compiles, executes, and monitors.

In practice this means:

• A workflow (say, "when a support ticket mentions a refund, verify order, check policy, either approve or escalate") is written and versioned as structured English.
• The platform compiles that spec into executable steps, tool calls, and guardrails.
• Agents modifying the system edit the spec, not the generated code. The code becomes disposable, like assembly output from a compiler.

If you've been writing MCP servers and Claude Skills, this pattern is not new to you. What G5 is doing is packaging it as a full enterprise platform with governance, observability, and a compiler in the middle. The bet is that the spec, not the code, becomes what your team reviews in pull requests.

The real problem: agents at cross-purposes

The reason this matters isn't productivity — it's coordination cost. When one human writes code, they hold the mental model. When ten humans write code, you invented code review, style guides, and architecture docs to preserve coherence. When twenty agents write code across a codebase in parallel, none of those artifacts scale, because:

1. Agents don't read your architecture doc unless you shove it into context every time.
2. Two agents can each pass tests and still produce incompatible assumptions (one thinks user_id is a UUID, another treats it as an integer from a legacy table).
3. Rollback is meaningless when three agents have layered changes across the same modules in the same afternoon.

A single natural-language spec addresses this by making the intent the reviewable unit. If two agents want to change the refund workflow, they both propose edits to the same 40-line spec, not 800 lines of Python across four files. Merge conflicts happen at the semantic layer, where humans can actually adjudicate them.

That's the real thesis. Whether G5's specific platform delivers on it is separate from whether the thesis is right.

Where natural-language workflows genuinely work today

Not every part of your system should be a natural-language spec. This is where I part ways with the maximalist version of the pitch. Based on what I've shipped over the last year, the pattern works cleanly in three zones:

1. Business logic with high change frequency and low latency requirements. Things like lead qualification, ticket routing, invoice reconciliation, contract review triage. The rules change monthly. They're currently either in someone's head, a Notion doc, or a spaghetti Zapier flow. A spec here is a strict upgrade.

2. Cross-tool orchestration. When a workflow spans Slack, HubSpot, Stripe, and Gmail, hand-writing glue code is a tax you pay forever. MCP servers plus a natural-language orchestrator eat this class of problem.

3. Human-in-the-loop review flows. Anything that ends in "and then a human approves" is a natural fit, because the spec is also what you show the approving human.

Where it fails, or at least where I'd push back hard:

• Hot paths. Your payment processing code should not be regenerated by an agent every sprint. Latency, determinism, and audit requirements make code the right artifact.
• Anything with strong invariants that don't compress to English. Cryptography, concurrency primitives, financial calculations with regulatory precision. Write the code, test the code, sign the code.
• Systems where the cost of a subtle bug is asymmetric. A spec that reads "correctly" but compiles to slightly-wrong code is worse than code you can read line by line.

A concrete example: the same workflow, three ways

Here's a refund-approval flow you might actually run. First, imperative Python — the way most SMBs have it now:

def handle_refund_request(ticket):
    order = shopify.get_order(ticket.order_id)
    if not order:
        return escalate(ticket, "order_not_found")

    days_since_purchase = (now() - order.created_at).days
    if days_since_purchase > 30:
        return escalate(ticket, "outside_policy")

    if order.total > 200:
        return escalate(ticket, "requires_manager")

    stripe.refund(order.payment_id, amount=order.total)
    shopify.mark_refunded(order.id)
    return reply(ticket, template="refund_approved")

Fine. Works. But every rule change — "raise the auto-approve limit to $300 for Gold customers" — is a code change, a PR, a deploy, and something an agent will happily rewrite next week in a way that quietly breaks the tier check.

Now the natural-language spec version:

workflow: refund_request_handling
trigger: support ticket contains refund intent

steps:
  - fetch order from Shopify using ticket.order_id
    if not found: escalate with reason "order_not_found"

  - check order age
    if older than 30 days: escalate with reason "outside_policy"

  - determine approval threshold
    default: $200
    if customer tier is Gold: $300

  - if order total exceeds threshold: escalate to manager queue

  - otherwise:
      - issue Stripe refund for full order amount
      - mark order refunded in Shopify
      - reply to ticket using template "refund_approved"

invariants:
  - never refund an order that is already marked refunded
  - never refund more than order.total
  - all escalations must include ticket_id and reason

The compiler produces roughly the same imperative code, but the reviewable unit is now the spec. A junior ops hire can propose changes. An agent modifying it can't quietly delete the never refund more than order.total invariant without you seeing it in a two-line diff.

And the third option — Claude with MCP tools, no bespoke compiler — is closer to what I actually ship for clients today:

{
  "tools": ["shopify_mcp", "stripe_mcp", "helpdesk_mcp"],
  "system_prompt": "You handle refund tickets according to policy.md. Never bypass invariants. Escalate when unsure.",
  "policy_document": "refund_policy.md",
  "human_approval_required_above": 200
}

The spec here is a markdown policy document plus a small runtime config. No compiler, no new platform. This is the pragmatic version of G5's idea, and you can build it this quarter.

Should you rebuild your stack around this? Honestly, no.

If you're a solopreneur or running a small team, here's the sober take. Don't rip anything out. Don't sign a platform contract based on a thesis that has maybe 18 months of production data behind it industry-wide.

Do this instead:

The rule of thumb: if it changes more than once a quarter and doesn't have hard latency or correctness requirements, it belongs in a spec. If it changes rarely and matters when it fails, it belongs in code.

The three risks nobody at the platform demo will mention

Lock-in at the compiler layer. If your specs only run on G5's compiler, you have a new vendor with your entire business logic. That's not automatically bad, but it's a real dependency. Ask what happens on export. Ask if the spec format is open. If the answer is "you can export to PDF," that's not an answer.

The "spec that lies" problem. A natural-language spec can be internally consistent, read beautifully, and still compile to code that does something subtly different. This is the biggest unsolved problem in the whole approach. Mitigation: property-based tests generated from the spec's invariants, and dry-run modes that show the reader what the compiled behavior actually is on real data before it goes live.

Agents that edit specs they don't understand. An agent editing "raise auto-approve to $300 for Gold" is trivial. An agent editing a 4-page compliance workflow because a ticket said "make it faster" is dangerous. You need the same review discipline for spec edits that you have for code edits. Diff review, approvers, staged rollout. All the boring stuff that made software engineering trustworthy in the first place, applied one layer up.

What to actually build this quarter

If this thesis interests you and you want to test it without committing to a platform, here's the minimum viable version:

1. Pick one workflow. Something painful, high-frequency, non-critical. Ticket routing is a good starter.
2. Write the spec in markdown. Plain English, with sections for triggers, steps, invariants, and escalation paths. Version it in git.
3. Run it through Claude (or your model of choice) with MCP tools for the actual actions (Shopify, Stripe, HubSpot, whatever). Not a custom compiler — just the model reading the spec each run.
4. Add a dry-run mode. For the first two weeks, log what it would do without doing it. Compare against what your human would have done.
5. Add invariant checks in code. Not in the spec. Real, deterministic assertions that run before any external action fires. "Never refund more than order total" is a Python assert, not a promise in English.
6. Only then, flip it live for a subset of traffic. 10%. Watch for a week. Ramp.

This gets you 80% of what G5 is selling, in about two weeks of work, with none of the platform lock-in. And you'll learn — from your own workflow, not a demo — whether the natural-language-as-source-of-truth idea earns its keep on your specific problems.

How BizFlowAI approaches this

We've been shipping this pattern with Claude and MCP for the past several months for clients in ecommerce ops, professional services, and B2B sales. The setup is boring on purpose: markdown policy docs in git, MCP servers for the tools that matter, deterministic invariants in code, and a small dashboard that shows every action a workflow took and why. No custom compiler, no proprietary spec format.

The result is that when the client wants to change a rule, they edit a markdown file, review the diff, and merge. When an agent proposes a change, it does the same thing, and the human review is over English instead of Python. If you want to see one running end-to-end on a real workflow, book a discovery call and we'll walk through the invoice-reconciliation or lead-triage build.

The verdict on G5 Labs' bigger claim

Should all enterprise code and workflows become natural language? No. That's the maximalist version and it's wrong for the same reason "everything should be a microservice" was wrong: it ignores where the abstraction stops paying rent.

Should the business logic layer of most SMBs and mid-market companies move from code and Zapier duct tape to versioned natural-language specs backed by real invariants? Probably yes, and the shops that do it first will ship faster and coordinate agents better than the ones still writing bespoke Python for every rule change.

G5's framing of the problem is right. Their solution is one implementation of a pattern you can start on this week without waiting for a platform. Pick the workflow. Write the spec. Add the invariants. Ship it small. That's the work.

Work with BizFlowAI

If you'd rather have this built for you, that's what we do: production AI automation for solo founders and small teams — agents, integrations, and document pipelines that actually ship.

Book a free discovery call — 30 minutes, we map the highest-ROI automation in your workflow. No pitch deck, just engineering.

More guides like this on the BizFlowAI blog.