AI work happens in a harness you cannot see

You type a request. What actually executes is a chain of improvised shell commands and generated scripts, chosen at run time, logged nowhere you can audit.

You:    "Verify the credit basis and update the report."

Agent:  sh -c "grep -r 'basis' ./deals | head -40"
        python3 -c "<96 lines written on the fly, then discarded>"
        sed -i '' 's/1,847,200/1,847,300/' report.md

Agent:  "Done. Everything checks out."

RealityThe workflow existed for eleven seconds, as text in a context window. There is nothing to inspect, version, or re-run.

A no-op can look exactly like success

Generated code can be empty and still return a plausible value. If you are not a programmer, a convincing no-op and a successful run are indistinguishable.

def validate_compliance(records):
    # TODO: implement checks
    return {"status": "passed",
            "records_checked": len(records),
            "issues_found": 0}

>>> "All 1,847 records validated. No issues found."

RealityThis function checks nothing. The report it produces is fluent, confident, and false, and the person relying on it cannot tell.

Ask again tomorrow, get a different program

Agents are inconsistent across repeated attempts at the same task. Different commands, different code, different reasoning, sometimes a different answer.

Run 1, Monday:     grep + awk pipeline      -> "compliant"
Run 2, Tuesday:    fresh python script      -> "3 issues found"
Run 3, Wednesday:  different reasoning path -> "compliant"

RealitySame request, three different programs. Which one was right? There is no way to replay any of them to find out.

Permissions are conversation, not enforcement

The agent asks nicely for access it often already has. A dialog box you click through is consent theater; it is not a capability boundary the runtime enforces.

Agent:  "May I read files in ~/deals?"        [ Allow ]
Agent:  "May I run this shell command?"       [ Allow ]
Agent:  "May I access the network?"           [ Allow ]

# Nothing technically prevented any of it.
# The 'boundary' is the model choosing to ask.

RealitySkills are markdown. Tools are opaque binaries. The only thing standing between the agent and your system is its own etiquette.

Reviewing the answer proves nothing about the work

Everything upstream of the answer is mutable, opaque, and gone. So checking the output is all you can do, and the output is precisely the thing a failure fakes best.

• The workflow exists as mutable prompts and ad hoc tool calls.
• You cannot inspect the effective program that executed.
• A method can be empty, return a plausible value, and appear successful.
• The next run may use different commands, code, and reasoning.
• Non-programmers cannot distinguish success from a convincing no-op.

Make the work a program you can read

Devlish's rule: if a step can be deterministic, remove it from the model. If it requires judgment, expose it as a named checkpoint. Everything else becomes compiled, verifiable behavior.

• Readable source. The English you review is the program that runs.
• Declared effects. A manifest the runtime enforces, not a dialog box.
• Deterministic execution. Same input, same output, every run.
• Named checkpoints. AI judgment is explicit, bounded, and recorded.
• Evidence and replay. Every run leaves a trail you can re-execute.

NextThe rest of this deck is the feel of the language itself. Every sample runs.

Values and decisions

Variables are created with equals. Conditions read the way you would say them out loud.

# Volume discount
Ask "Order total?" as order_total

discount equals 0
If order_total is greater than 500:
  discount equals order_total times 0.1

final_total equals order_total minus discount
Print final_total

RunsAn order of 800 prints 720. Ten percent off, no symbols to decode.

Looping over a list

For each walks a list. Indentation is the block, like the outline of a memo.

# Total the line items
line_items equals list of 1200, 450, and 89

total equals 0
For each amount in line_items:
  total equals total plus amount

Print total

RunsPrints 1739. Note the list literal: list of 1200, 450, and 89 — the Oxford comma is real syntax.

Records, lists, and filtering

Structured data without braces: records name their fields inline, and filter ... where reads like the requirement it implements.

# Which invoices need attention?
first_invoice equals record with 1200 as amount and "Acme" as customer
second_invoice equals record with 450 as amount and "Globex" as customer
third_invoice equals record with 8900 as amount and "Initech" as customer

invoices equals list of first_invoice, second_invoice, and third_invoice
large_invoices equals filter invoices where amount >= 1000

For each invoice in large_invoices:
  Print customer of invoice

RunsPrints Acme and Initech. Field access is possessive English: customer of invoice.

Validation is a sentence

Business-rule checks are first-class statements. Each one records a structured validation result and stops the run if it fails.

# Purchase order gate
po_amount equals 8200
vendor_status equals "approved"
po_code equals "PO-2214"

vendor_status must equal "approved"
po_amount must be at most 10000
po_code must match "PO-*"

Print "Purchase order accepted"

RunsAll three checks pass. Change po_amount to 18200 and the run fails on the exact sentence that was violated.

When a check fails

Try / Otherwise is the error path. A failed requirement does not crash the workflow — it routes it.

# Route around a failed check
review_status equals "pending"

Try:
  Require review_status is "approved" otherwise fail with "Review must be approved"
Otherwise:
  review_status equals "manual_review"

Print review_status

RunsPrints manual_review. The failure message is written where the rule is, not in a distant exception handler.

A rule with an identity

A Rule: header gives a policy a versioned identity and an effective date. Runs of governed rules leave a tamper-evident audit trail.

Rule:
  id: lending.dti_check
  version: 1.2.0
  effective from 2026-01-01

# Debt-to-income pre-check
monthly_income equals 8500
monthly_debt equals 2400

dti equals monthly_debt divided by monthly_income

If dti is greater than 0.43:
  Fail with record with "declined" as decision and dti as ratio

Respond with record with "approved" as decision and dti as ratio

RunsResponds {"decision": "approved", "ratio": 0.28}. The same file is the requirement, the executable, and the compliance artifact.

Invoice approval

The approval matrix from your finance handbook, verbatim. A non-programmer can review this for correctness.

# Invoice approval workflow
Ask "Invoice amount?" as amount
Ask "Purchase order attached? (yes/no)" as has_po

If amount is greater than 25000:
  Print "Route to CFO for signature"
Otherwise:
  If has_po is "yes":
    Print "Approved for payment"
  Otherwise:
    Print "Route to department manager"

Runs12,000 with a PO is Approved for payment; 60,000 routes to the CFO. Three outcomes, three visible lines.

Expense reimbursement

Policy limits as code. Fail with returns a structured rejection the calling system (or LLM) can act on.

# Expense reimbursement policy
expense equals record with 96 as amount and "meals" as category

meal_limit equals 75
claimed equals amount of expense

If category of expense is "meals" and claimed is greater than meal_limit:
  Fail with record with "rejected" as decision and "Meal exceeds the daily limit" as reason

Respond with record with "reimbursed" as decision and claimed as amount

RunsA $96 meal against a $75 limit exits with {"decision": "rejected", "reason": "Meal exceeds the daily limit"}.

Order fulfillment triage

Loop + records + branching together: the shape most operational workflows actually take.

# Order fulfillment triage
first_order equals record with "express" as shipping and 12 as items
second_order equals record with "standard" as shipping and 3 as items
orders equals list of first_order, second_order

For each order in orders:
  If shipping of order is "express":
    Print "Send to priority pick line"
  Otherwise:
    If items of order is greater than 8:
      Print "Split across two shipments"
    Otherwise:
      Print "Standard fulfillment queue"

RunsPrints Send to priority pick line, then Standard fulfillment queue — one decision per order, in order.

The requirement is the implementation

Here is the same policy as a handbook sentence and as the running code. There is no translation step for a reviewer to distrust.

# Handbook: "Purchase orders over $10,000 from any vendor
#            that is not pre-approved require a second sign-off."

If po_amount is greater than 10000 and vendor_status is not "approved":
  Print "Second sign-off required"
Otherwise:
  Print "Proceed"

RunsAuditors read the source. Developers ship the source. They are the same file.

Provable, not plausible

Put the two worlds side by side. The model is the same. What changed is that the work now exists as an artifact.

• The harness improvises; a Devlish program is the same program every run.
• The harness asks permission; a Devlish manifest enforces the boundary.
• The harness reports success; a Devlish run produces evidence you can replay.
• The harness hides judgment; Devlish names it as a checkpoint you can see.

Bottom lineYour AI can say it did the work. Devlish lets you prove it.