FIG J · the journal

Notes from the source.

Long-form pedagogy on Intent as Code — why useful AI work belongs in a file, why the language locks at four verbs, and what local-first actually buys you. Two flagship reads live; more are on the way.

2 live · 2 upcoming

FIG J.1

Intent as Code: why your AI work should be a file

Manifesto · 2026-06

Think about the best thing you did with an AI last month. The careful prompt, the back-and-forth, the result that finally clicked. Where is it now? For most people the honest answer is: gone. Buried in a chat history you will never scroll back through, on a server you don't control.

We've accepted a strange deal: the more useful the work, the more disposable the container. Nobody would write software in a text box that forgets everything. Yet that's exactly how most AI work happens today.

Nika's bet is simple: useful AI work is worth writing down. Not as a transcript, as source. A small YAML file that says what you want: fetch this, think about that, run this command, save the result. The file is the workflow. Run it again tomorrow and it does the same thing. Change a line and git diff shows exactly what changed.

Four verbs cover the whole space: infer (call a model), exec (run a process), invoke (use a tool), agent (let it work a loop). Everything else is data flowing between tasks. The order falls out of the dependencies. Write depends_on and independent branches run in parallel, for free.

And it runs on your machine. One Rust binary. Your model keys, your files, your git history. No cloud between you and your own work, and a license (AGPL) that guarantees it stays that way.

Chat is a great place to figure out what you want. It is a terrible place to keep it. Explore in chat. Then write the intent down, and own it forever.

FIG J.2

Four verbs are enough

Language · 2026-06

Every workflow language faces the same temptation: keep adding verbs. A verb for HTTP. A verb for files. A verb for email, for SQL, for whatever last week's integration needed. Ten years later the language is a catalog nobody can hold in their head, and every file is written in a different dialect of it.

Nika locks the count at four, forever. The rule that makes this possible is strict: a verb is a distinct execution model, not a feature. infer generates with a model. exec runs a process. invoke calls a tool and returns. agent loops with tools until the job is done. Four genuinely different ways for a machine to act. There is no fifth.

Three verbs in one tiny plan

morning-brief.nika.yaml
nika: v1workflow: morning-brieftasks:  - id: fetch_news    invoke:      tool: "nika:fetch"          # a tool, not a verb  - id: build    exec:      command: "cargo build --release"  - id: digest    depends_on: [fetch_news, build]    infer:      prompt: "Summarize what changed"

The test case was fetch. Surely getting a web page deserves its own verb? It does not, and the reason is the whole design: fetching is not a distinct execution model. It is a tool call. So nika:fetch lives in the standard library, reached through invoke, next to read, write, jq and the other 19 builtins. Everything callable is a tool. Everything about ordering is the graph.

A closed language is a feature you can feel. You can finish learning it: four words and the file reads like prose. Your files never rot into an old dialect, because there is no new dialect coming. And tools keep growing where growth belongs, in the library: a new builtin, a new tool server (MCP), a new provider. The language holds still while the toolbelt expands.

That stillness is the promise. The file you write today is the file you run in ten years. Languages that stop moving are the ones you can build on.

FIG J.3 · in the pipeline2 upcoming

Enginesoon

The plan you get for free

depends_on is all you write. Parallelism, ordering and retries fall out of the graph.

Sovereigntysoon

No cloud needed

One Rust binary, your models, your files. What local-first actually buys you.

Intent as Code · 4 verbs · 23 builtins · 14 providers — written down, replayable, yours