DEV Community: Nenad Mićić

The same tiny GPT in SQL, PostScript and Brainfuck, byte for byte

Nenad Mićić — Fri, 02 Oct 2026 09:54:22 +0000

This post continues the int-llm hobby experiments from my earlier post. The earlier repositories are int-llm (Q16.48 fixed-point training and TinyLlama inference), int-llm-precision-ladder (reduced stored weight precision checked against the Q16.48 reference), int-llm-coordinate-permutation (reversible coordinate permutations of Llama checkpoints), and int-llm-viz (visualization of the integer GPT weights and inference path).

Those projects produced a C program whose output is deterministic down to the last byte. This post describes three new repositories that reproduce that output in SQL, PostScript, and Brainfuck.

The reference and the gate

The model is Andrej Karpathy's microgpt: a character-level transformer with 1 layer, 32 embedding dimensions, 4 attention heads of 8 dimensions each, an MLP width of 128, a context length of 8, and a vocabulary of 26 lowercase letters plus one BOS token. It has 14,272 parameters and was trained on a list of names.

The int-llm C implementation performs every operation in Q16.48 fixed point: a signed 64-bit integer with 48 fractional bits. RMSNorm, the attention projections, softmax, exp, inverse square root, and the xorshift64 sampler are all integer code. Because no floating-point operation participates, the output depends only on the weights and the RNG seed. In this post, "the oracle" means that C program, and "the gate" means the comparison of a port's output against it.

The oracle loads a 115,576-byte MGW checkpoint, runs 122 forward passes, and prints 20 sampled names (kayla, daia, lee, …, karin). Each port must print the same bytes. Each port also computes two FNV-1a checksums inside its own code, one over every raw logit word and one over every sampled byte, and both must equal the pinned values. The checksums detect regressions; they are not cryptographic integrity checks.

A deliberately corrupted checkpoint serves as a negative control. The corrupted model prints the same 20 names but a different logit checksum (b10c3a08150e95c6 instead of 0610f72f01c199cb). A port that passes the gate with the canonical model and fails it with the corrupted model is comparing arithmetic, not only text.

int-llm-sql

microgpt.sql is a 1,410-line SQLite script. It runs with:

sqlite3 :memory: < microgpt.sql

The script calls readfile() once to load the committed model, decodes the little-endian weights into tables, runs the forward pass and the sampling loop, prints 20 names, and compares its own checksums and step count against the pinned values before it prints SQL_GATE=PASS. No stored procedure, user-defined function, loadable extension, or floating-point value participates. The repository tests the script with SQLite 3.51.0; the shell must support recursive CTEs, generated columns, window functions, ordered aggregate arguments, and readfile().

SQL lacks four things the forward pass needs, and the script supplies each:

Sequencing. SQL has no loop. An insert trigger fires the next forward pass. The script delivers 160 ticks; 122 of them reach a forward pass before BOS tokens end the samples.
128-bit integers. SQLite integers are signed 64-bit. The script splits each Q16.48 multiplication into limbs and implements division, exp, and inverse square root as recursive CTEs.
XOR. SQLite has no XOR operator. The script computes XOR(x, y) as (x | y) - (x & y).
Overflow detection. SQLite silently promotes an overflowing + or * to REAL. The limb arithmetic keeps every intermediate in range, and SUM() serves as the accumulator so that an overflow fails loudly.

Matrix multiplication needs no workaround: it is a join followed by an integer SUM(). During development, the SQL implementation was checked against the oracle at all 69,748 recorded activation, logit, and probability rows and at all 122 sampling records.

int-llm-postscript

microgpt_infer.ps is a 512-line PostScript program. Ghostscript runs it in about 2 seconds:

gs -q -dBATCH -dNODISPLAY -dNOSAFER microgpt_infer.ps

PostScript provides floating-point exp, ln, and sqrt. The program uses none of them; every operation is integer add, mul, idiv, bitshift, xor, or and. The program parses model.mgw directly (header, config, tensor index, little-endian two's-complement payloads), runs the 122 forward passes, and prints the same 485 bytes as the oracle: the Machin-series Pi banner (Pi = 3.141592653589782, including the oracle's integer-truncation error in the last digits) and the 20 names.

microgpt_train.ps is a 1,090-line trainer. It initializes the model, runs the whole-sequence forward and backward pass, applies Adam with gradient clipping and bias correction under a CORDIC cosine learning-rate schedule, writes an MGW v1 checkpoint, and samples 20 names. All model and optimizer state is Q16.48. On Ghostscript 10.04.0, 5,000 steps took 3,712 seconds (about 62 minutes). The 5,000 loss lines, the 20 samples, and the 115,576-byte checkpoint matched a fresh C run byte for byte, and the checkpoint matched the committed model.mgw at the same SHA-256.

The PostScript-specific hazard: Ghostscript's mul returns a real when the product overflows 64 bits, instead of raising an error. The program therefore splits each wide product into 24-bit limbs with a carry chain, and splits division remainders into two 31-bit limbs, so that no intermediate exceeds 2^63 − 1. If any limb were wrong, the gate would fail on the first affected sample.

int-llm-brainfuck

This is the one I run once and never again, so you don't have to.

Brainfuck has eight commands: > < + - . , [ ]. A cell holds one byte. The language has no multiplication, no comparison, and no conditional other than [ ], which repeats its body while the current cell is nonzero.

The repository pins its own machine profile, because Brainfuck implementations disagree on cell width, EOF, and tape size: 4,194,304 zero-initialized cells, 8-bit wrapping arithmetic, binary stdin and stdout, pointer underflow and overflow as errors, and , writing zero at EOF. Each Q16.48 value occupies eight little-endian cells.

Python generators emit the program. A generator may expand macros and allocate static tape regions; it may not precompute logits, samples, checksums, losses, or checkpoints. The interpreter executes commands, enforces tape limits, and counts executed commands; it does not parse the model or recognize tensors. All model work happens in the eight commands.

The generated programs are not committed, because they are too large for an ordinary Git repository. The repository holds the generators, the tape map, the oracle corpus, the fixtures, and the verification logs. make regen and make training-full-program regenerate the programs.

Phase 1, inference:

microgpt.bf: 16,395,194,474 bytes (16.4 GB)
46,883,492,331,121,926 source commands executed (about 47 quadrillion)
70,843 seconds (about 19.7 hours) for 20 names
sample and logit checksums equal the pinned values; the corrupted checkpoint produces the expected distinct logit checksum

Phase 2, training, 5,000 steps:

microgpt_train.bf: 210,300,828,662 bytes (210 GB)
484,906,588,575,174,327,064 source commands executed (about 485 quintillion)
409 hours 29 minutes wall time on the Linux x86-64 runner, including cold AOT compilation
all 5,000 loss lines, the 20 samples, the wide checkpoint, and the F12 checkpoint equal the oracle's output byte for byte

The trainer also computes Pi inside Brainfuck with the oracle's integer Machin series and passes the value into the CORDIC cosine schedule, because the oracle does the same and the gate accepts nothing else.

A full run is not required to check the repository. make bootstrap verifies the pinned artifacts and runs 39 unit tests in about one second. make test-model-validation generates a 2 MB program that loads and validates the model image; it passes in about 13 seconds. make TRACE_STAGE=logits test-model-trace generates a 3.2 GB program that runs one position through the complete transformer and compares its 27 logits against the oracle; with the optimized interpreter it executed 166,850,840,789,467 source commands in 18 seconds and passed. One detail: the model image is 29,944 bytes, and the generated program contains exactly 29,944 , commands to read it.

The verification log keeps failures. The first exact stop-after-20 training run stopped with a pointer underflow on both runners. The cause was uncleared Adam serial state overlapping the next forward pass's row-copy controls. The fix clears that workspace and has a regression test. The log records the failed run as FAIL next to the fixed rerun; it does not relabel it.

The full Brainfuck training run took 409 hours. I ran it so that “it should work” could become “it did work.”

Human code review is welcome. The generated Brainfuck program is 210 GB, so reviewers wishing to avoid AI assistance should probably clear their calendars for the next few centuries.

Why

These are hobby projects, done for fun. The question behind them is how far a transformer can go, not whether it should.

Integer-only arithmetic is what makes the question answerable. A floating-point port of the same model would produce slightly different rounding in each host, and "close enough" has no gate. With Q16.48, every host either reproduces the oracle's bytes or fails on the first divergent sample. That strictness turns an unusual host into a precise test of what the computation needs: 64-bit integers, a logical right shift, a loop, and nothing else. SQL supplied the loop with a trigger. PostScript supplied the wide multiply with 24-bit limbs. Brainfuck supplied everything from eight commands and a tape of bytes.

The original int-llm project asked whether fixed-point integer arithmetic can replace floating point in training and inference, and int-llm-precision-ladder asked how little precision the stored weights can keep before the output changes. These three repositories ask how little the host language can offer. The answer so far is that the floor is low, and the gate is the reason the answer is exact.

Every result is reproducible from the repositories with a compiler, the pinned tool versions, and time.

These projects were developed and tested with AI assistance. The correctness claims do not rest on that; they rest on the byte-for-byte comparisons recorded in each repository.

Lesson learned: trust AI-assisted work through validation, not through the assumption that a human reviewed every generated line.

Repositories: int-llm-sql, int-llm-postscript, int-llm-brainfuck. Everything else is at github.com/nmicic.

The next one will be something different.

Unmoor: another take on a roaming remote terminal

Nenad Mićić — Tue, 15 Sep 2026 09:30:44 +0000

I published Unmoor, an experimental encrypted, authenticated UDP terminal and file transport for Linux and macOS.

The basic idea is not new. Mosh solved the roaming terminal first. Unmoor explores a different set of trade-offs around the same general problem.

The session is identified by a cryptographic identity rather than an address tuple, so an address or NAT change doesn't end it; the session can resume once a usable UDP path exists again.

The main trade-off

Mosh and Unmoor differ in what they treat as the terminal.

Mosh synchronizes screen state. It can skip older output when newer state supersedes it, and its speculative local echo makes typing feel responsive before the server confirms each keystroke.

Unmoor sends the stream.

Once a terminal byte has been admitted by Unmoor, it is delivered or kept for repair. The client reports SYNC, OUT-OF-SYNC or STALLED, so a gap isn't silently treated as delivered.

That has a couple of useful consequences: normal terminal scrollback, search and copy work because the bytes really arrive, and someone who disrupts the path can stop output reaching you but cannot leave the client claiming that it received the complete stream.

There is a real price for that choice. When retained history fills, the sender applies backpressure, which can block the command producing output until the receiver catches up. Mosh can instead skip ahead.

If responsiveness on a bad link matters more than receiving the full terminal stream, use Mosh.

Some other differences

SSH authenticates Unmoor's initial exchange, but it carries public records rather than an Unmoor traffic key. Each endpoint derives fresh session keys locally using hybrid X25519 + ML-KEM-1024 key agreement.

Post-quantum key agreement is required by default. --pq=prefer and --pq=off are explicit downgrades, and rekeys use the same hybrid exchange.

After bootstrap, terminal and file traffic runs over encrypted, authenticated UDP.

A few other properties:

a listener adopts a new return address only after a fresh authenticated packet advances the replay window, so a replayed packet can't redirect the session
multiple authenticated UDP legs can belong to one session
single-file push and pull verify the whole file before installing it atomically; a partial destination is never reported as success
on Linux, the client confines itself by default using no_new_privs, Landlock and seccomp
no root, capabilities or kernel module are required

"Multiple legs" does not necessarily mean multiple physical network paths. Different UDP source ports can exercise different RSS/ECMP choices, but that alone does not prove path diversity.

Unmoor is not a VPN, relay or NAT hole-puncher. The client still needs to be able to reach the listener's UDP port.

Where this came from

I actually wrote the lossy version first.

URTB drops output under pressure because a LoRa link gives you very little bandwidth and sometimes there is no better choice. That trade-off makes sense there.

A normal network path doesn't have the same constraint, so with Unmoor I wanted to see what happens if admitted terminal output is never silently discarded.

This is version 0.2.0 / protocol v2. It is experimental and has not had an external security audit.

It is not intended to be exposed as a public service endpoint, and protocol v2 may change without a compatibility promise.

The project was developed end-to-end with AI assistance across implementation, specification, tests, reviews and documentation. The material design decisions and responsibility for what was accepted remain mine. That provenance should be part of how the code is evaluated.

Try it

git clone https://github.com/nmicic/unmoor
cd unmoor

make -j2
make check
make smoke

make smoke performs a real post-quantum bootstrap over loopback UDP with a live PTY.

The repository contains the usage instructions, protocol and design notes, security model, limitations and tests:

https://github.com/nmicic/unmoor

URTB: An Encrypted PTY Tunnel Over ESP-NOW and LoRa

Nenad Mićić — Fri, 17 Apr 2026 00:32:30 +0000

I have two personal laptops: a MacBook Air I carry around the house, and an old Lenovo that mostly stays in the garage. They sit on different VPNs. When WireGuard testing cuts me off I still need a shell on the other machine, and carrying a 5 kg laptop around the house is not practical.

A pair of Heltec WiFi LoRa 32 V3 boards, plugged into USB on each laptop, solve that problem. URTB is the host binary and matching firmware that give me an encrypted interactive shell over ESP-NOW, with LoRa as automatic fallback.

What it is

Two urtb processes, each holding the same passphrase-protected capsule file, establish an XChaCha20-Poly1305 session and carry a PTY shell between them. The primary transport is ESP-NOW. In my indoor tests on a clear 2.4 GHz channel, that meant roughly 1-2 Mbps and sub-5 ms latency. When ESP-NOW fails, the session continues automatically over LoRa: slower, but longer-range and sub-GHz. No session renegotiation. The same binary also works over a UNIX socket or through an SSH jump host, so you can try it without any radio hardware.

./urtb keygen --out pairing.capsule

# machine A
./urtb listen --transport heltec --device /dev/cu.usbserial-0001 --capsule pairing.capsule

# machine B
./urtb connect --transport heltec --device /dev/cu.usbserial-0002 --capsule pairing.capsule

Two scenarios worth explaining

ESP-NOW primary, LoRa fallback.
LoRa is useful as an emergency channel. I tested Reticulum's rnsh on real hardware. It works, but in my LoRa tests it was doing roughly 200-400 bytes/second and 200-500 ms per keystroke, which makes interactive use painful. top takes 10-15 seconds to redraw. The bottleneck is LoRa's physical layer, not rnsh. ESP-NOW fixes the throughput problem for short range. URTB uses both: ESP-NOW when it is available, LoRa when it is not, with the session staying alive across the switch.

Encrypted terminal through a restricted SSH jump host.
Say you need to reach a server in a DMZ through a jump host you do not fully trust. Only port 22 is open. AllowTcpForwarding is disabled. VPN and Mosh need additional ports. The jump host may be compromised.

URTB has two useful patterns here. The simple one uses --exec: the URTB AEAD-encrypted tunnel rides inside an SSH byte stream and does not need port forwarding, ProxyJump, or any extra listener on the jump host.

For the stricter case, pre-start a listener on the target with --loop and bridge through the jump host with ssh ... socat STDIO UNIX:/tmp/urtb.sock. That keeps the capsule passphrase local to the endpoints.

# target
URTB_PASSPHRASE=example-passphrase ./urtb listen --transport unix \
    --socket /tmp/urtb.sock --capsule cap.cap --loop

# client
URTB_PASSPHRASE=example-passphrase ./urtb connect \
    --exec "ssh jump ssh target socat STDIO UNIX:/tmp/urtb.sock" \
    --capsule cap.cap

The capsule is transferred out-of-band to the target; the jump host is not trusted with it and does not need to persist it. The jump host still relays bytes, but it is not trusted with session plaintext.

Once the capsule is loaded, --burn does a best-effort local wipe and unlink of the key files. After that, key material stays in process memory for the lifetime of the process, with mlock and MADV_DONTDUMP where the platform supports it. Add --otp and the attacker also needs a valid HOTP/TOTP code to open the PTY, even if they obtain the capsule file from another channel.

How I built it

This is an AI-assisted project. The implementation was generated with AI against a frozen specification that I wrote first and then reviewed in multiple rounds with different models before any code was generated.

The process, briefly:

Specification first. About 2,000 lines of markdown across SPEC.md, PROTOCOL.md, SECURITY.md, ACCEPTANCE_CRITERIA.md, and DECISIONS.md before any code was generated.
Adversarial multi-agent review. The spec went through seven review rounds using multiple AI agents with different remits: protocol correctness, crypto audit, numerical consistency, and state-machine verification. The 7th round caught a fragmentation logic contradiction that would have forced a rewrite of the channel multiplexer if it had survived into implementation.
Freeze, then generate. Once the spec was clean, I froze it and pointed the code-generation agents at it.
Implementation review, same method. Multiple blind agents reviewed the code, then a synthesis pass pulled the findings together. The OTP bypass in burn mode (if (s->otp_path) instead of || s->otp_key_mem) was caught this way.
Hardware in the loop. Two Heltec V3 boards stayed connected over USB during development. The models could run end-to-end tests on real hardware. I also had them write failure-injection code: the firmware has a test-inject build that can drop ESP-NOW TX, drop LoRa TX, and simulate link failure on command from the host.
Disposable VM for jump-host testing. Jump-host scenarios were tested against a KVM virtual machine that could be rebuilt on demand via a signed wrapper script. All eight HOWTO_JUMPHOST scenarios were validated end-to-end that way.

What came out

The host binary is about 8,000 lines of C with no dependencies beyond libc and Monocypher. The firmware is about 1,050 lines of C++ (Arduino/PlatformIO). Notable properties:

XChaCha20-Poly1305 AEAD, BLAKE2b key derivation, Argon2id-protected key storage
256-entry additive-fencepost replay window
PTY multiplexing with fragmentation for LoRa's 72-byte plaintext MTU
Automatic ESP-NOW-to-LoRa failover and recovery without session renegotiation
LoRa duty-cycle-aware batching for the EU 868 MHz 1% limit
Optional HOTP/TOTP second factor
--burn: best-effort local wipe and unlink of capsule and OTP key files after load
Signal handlers that wipe PSK from memory on SIGTERM, SIGHUP, SIGQUIT, and best-effort on SIGSEGV/SIGBUS/SIGFPE
MADV_DONTDUMP to exclude key material from core dumps on Linux
Landlock + seccomp sandbox profiles for both connect and listen modes
42 acceptance criteria passing, 8 failure-injection tests passing, CI on GitHub Actions

I ran cat /dev/urandom through the full stack — radio, USB framing, AEAD, reassembly — for 20 minutes without a crash. That was the test that satisfied me the code was not just correct on the happy path.

Limitations

Worth being explicit about what this is not:

Not audited. This is a personal project. The security surface was designed carefully, but it has not been reviewed by an independent security firm.
LoRa is very slow. In my tests it was around 200-400 bytes/second. Short commands work; anything that generates significant output needs the throttling mode or the session becomes sluggish.
Not a VPN. No IP routing, no general port forwarding. One encrypted PTY session between two named processes.
No general file transfer yet. This is terminal-first.
--burn is best-effort. On SSDs and modern filesystems, overwrite-before-unlink is not a guarantee of non-recoverability. It reduces exposure from filesystem access after the process exits; it is not cryptographic erasure.
Compartment sandbox is optional. The Landlock + seccomp profiles in compartment/ are not enabled by default. They require a separate tool ( compartment , also mine) and manual profile activation.

Repository

The project is public at github.com/nmicic/URTB. You can try it without hardware using --transport unix; the quick start in the README takes about 30 seconds once dependencies are installed. The name stands for USB-Radio Terminal Bridge.

The code is AI-assisted and I am not hiding that. The specification, the review process, the acceptance criteria, the testing methodology, and the decision to ship or not ship — those are mine.

I Built compartment to Sandbox AI Agents on Linux

Nenad Mićić — Thu, 02 Apr 2026 12:06:30 +0000

AI coding agents are useful, but in a corporate environment they are often too privileged by default.

They can read files, edit code, run commands, inherit environment variables, and talk to the network. I wanted a smaller trust boundary for tools like Claude Code and Codex CLI.

So I built compartment, a small Linux process isolation toolkit with:

compartment-user — rootless confinement using Landlock, seccomp, and no_new_privs
compartment-root — stronger namespace-based isolation when needed
one shared profile format
zero external dependencies

This is also a rebuild of an old idea. Back in 2003, I wrote shell-guard, a wrapper that intercepted shell execution and applied policy early. Modern Linux finally has the kernel primitives to do that idea properly.

I built compartment primarily for AI-agent sandboxing, but the same logic also applies to other semi-trusted local tools, including SSH.

Small tool. Explicit policy. Lower blast radius.

GitHub: github.com/nmicic/compartment
README: github.com/nmicic/compartment#readme

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

Nenad Mićić — Wed, 11 Mar 2026 09:42:27 +0000

**Update (March 17, 2026): Since publishing this post, the campaign found two first-kind CC18s with roots 106103983461039119546815109 (87 bits) and 214325014495971624590189129 (88 bits). A later prior-art review showed that first-kind CC18 had already been documented in John Armitage’s 2021 Oxford thesis via the smallest known example, so these are not the first known CC18s. They do, however, remain the largest listed first-kind CC18 entries on the current public Cunningham tables. The campaign has now finished because my available GPU compute time ran out. The original post below is left mostly unchanged as the March 11 baseline.

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

Nenad Mićić · LinkedIn · March 2026

What This Is

A visualization hobby project that turned into a high-throughput Cunningham chain search engine. More about HPC optimization and AI-assisted iteration than the math itself.

It started with mapping integers in a 2-adic geometry, noticing structured prime paths, recognizing Cunningham-chain recurrences, and then building a GPU/CPU pipeline to search for long chains.

Results

This project ultimately did reach its CC18 target, but not the more ambitious CC19 goal. It remained a compute-limited campaign.

As of March 2026, the public Cunningham chain tables at pzktupel.de list results under my name, Nenad Mićić, including:

new CC16 and CC17 entries
the largest listed first-kind CC16, CC17, and CC18 on the current public tables

The published data snapshot contains 929,574 roots in total, including 44 CC16 roots and 1 CC17. The main campaign was centered on the 89–91 bit range, and the release includes both the search code and derived analysis:

gap statistics and spacing distributions
immunization / residue summaries and immune-fingerprint distributions
p+1 breaker analysis
ghost chains — roots where prime links continue beyond the official chain break, tested to depth 20
closest CC-twins and CC-clusters (triplets, quadruplets, quintuplets)

I think this dataset is useful in its own right and deserves deeper study.

How It Works

Visual learning led to search design.

The 2-adic coordinate system made chain structure visible. The p+1 factorization view showed which small-factor patterns kill candidates early. That became the sieve.

For a first-kind chain, a root p generates: p, 2p+1, 4p+3, 8p+7, ...

The key optimization is depth filtering:

generate candidates on the CRT-and-wheel search lattice
test cheap modular conditions across the first d projected chain positions
reject any root whose chain is already doomed modulo a tracked small prime
send only the tiny survivor set to the CPU for probable-prime testing and full chain confirmation

Pipeline:

GPU (CUDA): 57–65 billion candidates/sec modular filtering (RTX 4090 / RTX 5090)
CPU (GMP): probable-prime testing, true-root recovery for non-roots, and chain-length confirmation

The GPU sieve rejects about 99.9988% of candidates before expensive primality work is needed. Only about 0.0012% survive to the CPU path.

Interactive Visualizations

Each tool shaped the search design.

Cunningham Chain Mesh: 2-adic square-perimeter map with CC1/CC2 edges and chain paths
2-Adic Tree Explorer: inspectable tree with local chain structure
3D Fold: shell structure across levels; top view becomes the p+1 analysis grid
p+1 Analysis: factor coloring for primes, mod-p view for composites
Chain Analyzer: single-chain analysis, breaker autopsy, residue immunity
Campaign Dashboard: live campaign tracking across bit ranges and chain lengths
Immunization Dashboard: residue immunity analysis

Project Stack

Search: CUDA filtering, GMP proving, prefix sharding, checkpointing
Visualization: standalone HTML/JS tools
Analysis: Python plus HTML tools for autopsy and fingerprinting
AI-assisted: LLMs used for coding iteration; math direction and search decisions are human-driven
Extra: a PARI/GP library and a small MCP server wrapper for interactive Cunningham-chain analysis

Part of the project was also an experiment in AI-assisted iteration: not one-shot prompting, but many rounds of visual exploration, code generation, rejection, correction, and performance tuning. The transferable lesson for me was not number theory itself, but the workflow: isolate the hot path, turn it into something benchmarkable, iterate quickly with AI assistance, and only bring back changes that survive measurement.

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Nenad Mićić — Mon, 15 Sep 2025 08:42:38 +0000

I'm sharing this with the team as a summary of my personal workflow when working with AI on code. It's not an official framework, but rather a set of learnings from experience (polished with a little help from AI, of course). My main goal is to start a conversation. If you have a better or similar workflow, I'd genuinely love to hear about it.

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

AI can accelerate coding, but it can also drift, hallucinate requirements, or produce complex solutions without a clear rationale.
This framework provides the guardrails to keep AI-assisted development focused, deliberate, and well-documented.

Sailing Analogy (High-Level Intro)

Working with AI on code is like sailing:

Compass → Keeps you oriented to true north (goals, requirements, assumptions).
Steering Wheel → Lets you pivot, tack, or hold steady (decide continue vs. change).
Destination Map → Ensures the journey is recorded (reusable, reproducible outcomes).

This framework grew out of real-world experience. It’s not brand new theory, but a way to formalize a shared language for teams working with AI.

Step 1: Compass (Revalidation)

Purpose: keep alignment with goals and assumptions.

Template (copy/paste):

What’s the primary goal?
What’s the secondary/nice-to-have goal?
Which requirements are mandatory vs optional?
What are the current assumptions? Which may be invalid?
Has anything in the context changed (constraints, environment, stakeholders)?
Are human and AI/system understanding still in sync?
Any signs of drift (scope creep, contradictions, wrong optimization target)?

Step 2: Steering Wheel (Course Correction)

Purpose: evaluate if we should continue, pivot, or stop.

Template (copy/paste):

For each assumption: what if it’s false?
Does an existing tool/library cover ≥80%?
Does this map to an existing framework/pattern (ADR, RFC, design template)?

Alternatives:

Different algorithm/data structure?
Different architecture (batch vs streaming, CPU vs GPU, local vs distributed)?
Different representation (sketches, ML, summaries)?
Different layer (infra vs app, control vs data plane)?

Trade-offs:

Fit with requirements.
Complexity (build & maintain).
Time-to-value.
Risks & failure modes.

Other checks:

Overhead vs value: is the process slowing iteration?
Niche & opportunity: is this idea niche or broadly useful? Where does it fit in the landscape?

Kill/Go criteria:

Kill if effort > value, assumptions broken.
Go if results justify effort or uniqueness adds value.

Next step options:

Continue current path.
Pivot to alternative.
Stop and adopt existing solution.
Run a 1-day spike to test a risky assumption.

Step 3: Destination (Reverse Prompt)

Purpose: capture the outcome in reusable, reproducible form.

Template (copy/paste):

Instructions

Restate my request so it can be reused to regenerate the exact same code and documentation.
Include a clear summary of the key idea(s), algorithm(s), and reasoning that shaped the solution.
Preserve wording, structure, and order exactly — no “helpful rewrites” or “improvements.”

Reverse Prompt (regeneration anchor)

Problem restatement (1–2 sentences).
Key algorithm(s) in plain language.
Invariants & assumptions (what must always hold true).
Interfaces & I/O contract (inputs, outputs, error cases).
Config surface (flags, environment variables, options).
Acceptance tests / minimal examples (clear input → output pairs).

High-Level Design (HLD)

Purpose: what the system solves and why.
Key algorithm(s): step-by-step flow, core logic, choice of data structures.
Trade-offs: why this approach was chosen, why others were rejected.
Evolution path: how the design changed from earlier attempts.
Complexity and bottlenecks: where it might fail or slow down.

Low-Level Design (LLD)

Structure: files, functions, modules, data layouts.
Control flow: inputs → processing → outputs.
Error handling and edge cases.
Configuration and options, with examples.
Security and reliability notes.
Performance considerations and optimizations.

Functional Spec / How-To

Practical usage with examples (input/output).
Config examples (simple and advanced).
Troubleshooting (common errors, fixes).
Benchmarks (baseline numbers, reproducible).
Limits and gotchas.
Roadmap / extensions.

Critical Requirements

Always present HLD first, then LLD.
Emphasize algorithms and reasoning over just the raw code.
Clearly mark discarded alternatives with reasons.
Keep the response self-contained — it should stand alone as documentation even without the code.
Preserve the code exactly as it was produced originally. No silent changes, no creative rewrites.

When & Why to Use Each

Compass (Revalidation):
- Use at the start or whenever misalignment is suspected (context drift, new requirements).
Steering Wheel (Course Correction):
- Use at milestones or retrospectives to decide continue, pivot, or stop.
Destination (Reverse Prompt):
- Use at the end of a cycle/project to capture reproducible documentation & handover artifacts.

References & Correlations

This framework is simple, but it builds on proven practices:

Systems Engineering: Verification & Validation (build the right thing).
Agile: Sprint reviews (revalidation), retrospectives (course correction).
Lean Startup: Pivot vs. persevere decisions.
Architecture Practices: ADRs (decision rationale, alternatives).
AI Prompt Engineering: Reusable prompt templates & libraries.
Human-in-the-Loop Design: Oversight to prevent drift in AI systems.

By combining them under a sailing metaphor, the framework becomes:

Easy to remember.
Easy to communicate inside teams.
Easy to apply in AI-assisted coding where drift, misalignment, and reusability are everyday challenges.

Closing Note

Think of this as a playbook, not theory. Next time in a session, just say:

“Compass check” → Revalidate assumptions/goals.
“Steering wheel” → Consider pivot/alternatives.
“Destination” → Capture reproducible docs.

DEV Community: Nenad Mićić

The same tiny GPT in SQL, PostScript and Brainfuck, byte for byte

The reference and the gate

int-llm-sql

int-llm-postscript

int-llm-brainfuck

Why

Unmoor: another take on a roaming remote terminal

The main trade-off

Some other differences

Where this came from

Try it

URTB: An Encrypted PTY Tunnel Over ESP-NOW and LoRa

What it is

Two scenarios worth explaining

How I built it

What came out

Limitations

Repository

I Built compartment to Sandbox AI Agents on Linux

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

From 2-Adic Geometry to Cunningham Chains: Visualization-Driven GPU Search

What This Is

Results

How It Works

Interactive Visualizations

Project Stack

Links

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Compass, Steering Wheel, Destination — Framework for Working with AI on Code

Sailing Analogy (High-Level Intro)

Step 1: Compass (Revalidation)

Step 2: Steering Wheel (Course Correction)

Step 3: Destination (Reverse Prompt)

When & Why to Use Each

References & Correlations

Closing Note