Oleg: AI

2026 · prototype — 1,312 commits between May and August 2026; none since 11 August; its own reports call the autonomy test a partial result

Problem

One agent working alone drifts and declares victory early. I wanted a loop that takes a one-page vision and returns a finished project, with the judging done by someone other than the builder.

Approach

A command-line orchestrator runs two different AI coding agents as independent planners, reviewers, implementer and auditor. Agreement has a precise meaning: both must sign off on the same unchanged plan. Every agent call is traced, and an interrupted run resumes from disk.

Result

It built and deployed a real invoice-reminder service (a private beta, no users yet). In a bounded test it chose two public web services on its own, registered, verified by email, exited, and logged back in from a fresh process. Then the loop grew heavy and started verifying its own plans rather than the user's result; I paused it in August 2026 and moved my focus to the third approach.

Evidence

• 1,312 commits between 2 May and 11 August 2026; 125 test files
• Grader-blind build: every test artifact withheld, the agent invented its own checks, and the withheld grader then passed it 18 of 18
• Blind-spot audit of the auditors: 19 planted distortions, 5 caught — "the selection layer, not the reading layer, is the dominant loss channel"
• Real-web test: one of six runs completed the full register, exit and log-back-in cycle; the reports call it partial capability, not a passed gauge

Stack

Node.js · Codex CLI · Claude Code CLI · tmux over SSH

The worst part was not that the checker was wrong. I could not show that it can tell good work from bad at all.

2026 · experiment — completed and validated 21 May 2026; 542 trials on 13 benchmark subsets

Problem

Does arranging several cheap language-model calls into a structure — peer review, ensembles, verifiers, hierarchies, red and blue teams, stage gates — make the answer more reliable? Most such designs are argued for, not measured.

Approach

Each design ran on 13 benchmark subsets (MMLU-Pro, AIME, GPQA-Diamond, TheoremQA, HumanEval+ and others) and was judged with McNemar tests and Wilson intervals, at about 34 dollars in total and no extra cost per question. Candidate designs came from first analysing 26 of 26 recorded failures, not from trying architectures at random.

Result

Twenty-nine of the 31 designs were statistically null, one gave only a hint, and one worked. The one that worked changed nothing about structure: where the old design guessed when no internal check passed, it runs two strict correction passes and otherwise abstains. On the hardest subsets that moved 1 of 15 to 13 of 15 (p = 0.0005) and 0 of 6 to 6 of 6.

Evidence

• 542 trials across 13 benchmark subsets
• The project's own score line: 1 winner, 1 composability hint, 29 null — a 94% null rate
• Total spend about 34 dollars

Stack

TypeScript

Almost every clever multi-agent structure did nothing; what mattered was refusing to answer when the checks fail.

2026 · prototype — built February–July 2026; runs locally as a developer-grade system; its own readiness exam not passed

Problem

A general org operating system: a kernel and API that can start and run multi-agent teams from nothing but a goal — not one fixed organization, a toolkit that can create many.

Approach

Eight data primitives and a few rules the server enforces instead of asking for: work is leased and expires without a heartbeat; nothing is accepted without evidence artifacts; risky actions need a signed approval with a single-use nonce; every modeled tool side effect goes through one gateway. Runs replay from golden traces and export as a proof bundle a third party can verify.

Result

A runnable system, never a hosted product. Its definition of ready is a written exam graded by independent judges from two model families — a real end-to-end success, not green internal tests — and it has not passed.

Evidence

• 367 TypeScript source files; 139 test files
• Verification as code: checks for secret exfiltration, literal leakage, and golden-trace drift
• A companion market emulator deliberately not wired into the kernel, so the kernel cannot grade itself against its own oracle

Stack

TypeScript · Node.js · Fastify · PostgreSQL · ed25519 signatures

Structural defenses over prompt defenses: assume any one agent can hallucinate.

2026 · prototype — autonomous loop switched off June 2026; by its own scoreboard 0 of 3 missions demonstrated

Problem

An engine for changing an existing codebase where a language model may only propose a patch and deterministic checks decide what lands. And a second question: what happens when two different coding agents build the same specification and each audits the other?

Approach

Both builds came from one specification — one written by Codex with Claude as the mandatory external checker, the other the reverse. Each ingests a goal and a change request, builds a dependency graph, assembles token-budgeted task packets, applies edits under scope, hash and line-count limits, and runs gates: CI, acceptance, secrets, SBOM, performance, mutation. State lives in SQLite and on disk, never in the agent's context.

Result

Both reached a working deterministic pipeline with a few hundred tests; neither reached the autonomous version the specification describes. About 2,200 containerised cycles were pushed at three benchmark missions — ship an app, prove theorems in Lean, test a trading strategy in a dry-run emulator — and none is demonstrated by the project's own scoreboard.

Evidence

• 2,355 commits across the two repositories, February–August 2026; 846 and 346 test files
• The mutual audit caught a rollback that deleted the original files instead of restoring them, and a Windows path-traversal bypass
• Successive self-assessments of one build reported 52%, 82% and 96% — under different rubrics and at different stages, so not three scores of one unchanged snapshot

Stack

Python · SQLite · Docker · Lean 4

An audit that blocks must name the cheapest probe that would falsify its own blocker.

2026 · paused — 258 commits, February–March 2026; the last live runs are dated 15 April 2026; its own review: strong as a harness, not yet decision-grade for winner claims

Problem

The same model is served by many providers, and they differ in quality. Nobody tells you which one to route to.

Approach

Validates a config, sends the same sampled questions from public benchmarks to every model-and-provider pair in parallel, scores deterministically, and stores raw requests, responses and scores per run. A budget planner tests all providers for a few models and prunes weak ones for the rest, keeping a full sweep under a cost cap. The benchmark scores model text; it never executes model-produced code.

Result

A working harness with real live runs in April 2026. The ranking layer works, but not yet at a depth that supports public best-provider claims — which the repository says out loud in a table of what a run can and cannot prove.

Evidence

• 597 test functions in 81 files; about 28,000 lines of Python
• 375 run directories, including real live runs on 15 April 2026
• Explicit sampling policy: 40–99 items is smoke only; 1,000 or more is the public-comparison lane

Stack

Python · pydantic · SQLite · OpenRouter · Docker · GitHub Actions

Every report states what the run can and cannot prove.

2024–2026 · paused — source frozen 4 February 2026 after two years; several rules it produced still appear in my current coding-agent instructions

Problem

Before agentic coding tools were common: one very capable terminal agent that runs code, browses, delegates, and remembers.

Approach

A root agent streams prose, tool calls and results to the terminal, runs code and shell, drives a browser through a motor subagent, and spawns silent child agents with inbox and outbox messaging, budgets and an org chart. A memory subagent keeps an autobiography and compacts history for prompt caching.

Result

It reached about 17,000 lines of library code and about 46,000 lines of tests across 298 files, then I paused it. It was the zero-th generation of the factory, and it could not close a large task.

Evidence

• 298 test files under two rules: live tests mock nothing; an agent saying it used a tool is not proof that it did
• A test-slop audit in December 2025 replaced vacuous assertions across more than ten suites
• First test file February 2024

Stack

Node.js · OpenAI SDK · Puppeteer · Jest

Prose is not evidence: a claim of tool use must be proven by artifacts.

2026 · paused — ran 25 July to 12 August 2026, then paused; 57 written post-mortems; no result confirmed by anyone else

Problem

Does a frontier model, given real chances and disciplined verification, produce mathematics that is both correct and new? Restricted on purpose to problems whose answer is a finite object that exact arithmetic can referee on one machine.

Approach

A root agent picks frozen targets and records why each route is unspent. Solver chats run in parallel; separate agents reconstruct every claim from scratch, check exact certificates (rational arithmetic, SAT with proof output, symbolic algebra), and search the literature for prior art. Correctness, novelty and value are graded separately in an append-only ledger.

Result

A handful of small locally verified objects and exact certificates — none peer reviewed, none externally confirmed — and no solution to any headline problem. One clear split: targets whose answer shape was specified returned correct scoped mathematics 5 of 5 times; open-ended search or invention targets, 0 of 4.

Evidence

• 261 solver chats captured; accepted results re-derived locally in exact arithmetic, other claims left marked unreproduced or pending
• The project's own ledger: no verified solution of a famous headline open problem and no externally peer-reviewed new theorem; one screening batch cleared novelty 0 of 5
• 57 dated post-mortems, each naming one way automated reasoning fooled itself

Stack

Python · sympy · z3 · python-flint · SAT with LRAT proofs · C++

The first hit in an append-only file is the one most likely to be wrong — so the fix belongs on the read side, not the write side.

2026 · prototype — built in a four-hour community hackathon on 29 August 2026; 11 pull requests merged into the room's public repository

Problem

Deadlines and promises arrive scattered across mail, chats, call transcripts and screenshots. People copy them into trackers by hand, and some surface the day before they are due.

Approach

Reads a folder of heterogeneous text, extracts commitments through a structured schema, and validates that every extracted claim carries an exact quote from its source. Results merge into a registry with stable ids: a second run updates statuses instead of duplicating, and an identical rerun makes zero model calls because sources are hashed. The room adapter takes a fixed reference date, so its acceptance corpus cannot rot overnight; some engine paths still fall back to the system clock.

Result

An extraction engine, an engine-agnostic acceptance harness, a small web console, two output corpora of 24 scenarios and 93 unit tests, all merged the same day. That afternoon I audited it and wrote down what it still gets wrong — including that the room's shared checker produced a false green, 16 of 16 passing, on output with a wrong owner, a wrong date and a duplicate.

Evidence

• 11 pull requests merged upstream on 29 August 2026 (checked against the public repository)
• 93 unit tests across three modules; 24 scenarios replicated into two output corpora (48 folders)
• A post-event stocktake lists the real remaining defects: no rollback on a fresh run; no real-provider semantic quality measured

Stack

Python · FastAPI · pytest · Playwright · Codex and Claude CLIs as interchangeable backends

My console had 38 controls on its first screen against the room demo's 12 — overloaded instead of minimal — and I wrote the root cause down the same day.

2026 · experiment — one completed run on 31 March 2026; the merged skill it produced is not installed in my current global skill directories

Problem

How do you get an AI to work the way you do? Not by prompt-crafting: by observing yourself.

Approach

Scan every local Codex and Claude session, group them by project with exact counts and provenance, synthesise an independent analysis per project, then merge them into one set of working rules — where the proof bar sits, when to widen scope, what counts as evidence. Every claim is labelled as direct observation, inference, or agent claim.

Result

2,874 session files sorted into 21 project buckets on one machine, about 3,000 sessions on another. The run produced a merged skill; it is not installed in my current global skill directories.

Evidence

• The completed run recorded validation_passed: true
• Low-confidence buckets are flagged with reasons

Stack

Python

Own the actual outcome; verify past cheap greens.

2026 · experiment — July 2026; the report declines to give a number rather than let an AI estimate one

Problem

I routinely have one AI review another AI's plan or output. Does that catch real problems, or is it process theatre? Built to measure, not to assume.

Approach

Inventory 20,163 records of my own agent sessions across two machines, collapse them into 976 canonical audit events, and link 964 to the session they reviewed. Pre-registered metrics with explicit denominators and designed negative controls — all 976 control comparisons still marked pending in the final report; gates between phases; a redaction pass proved by planting a secret and checking it was caught. Before measuring anything, every measurement instrument was itself audited.

Result

Thirteen of fourteen instruments failed their own audit. The first pilot was written up as a failure, the unit of analysis was redesigned, and the report leaves the primary question unanswered and says so in its first paragraph. Three bounded observations survive: the reviewers found specific defects in the instruments; the audit swarm cost twice its estimate (26 weekly-usage points against 13); a cheaper plan rewrite lost or inverted several fixes. None of them answers the return-on-investment question.

Evidence

• 20,163 normalised session records; 976 audit events, 964 linked to the session they reviewed
• The run crossed its own model-usage budget and stopped itself by its own rule
• Its final audit found five of its own post-cutoff runs inside the measured population and a stale cost ledger; both were excluded or refreshed before the final report

Stack

Python

You only audit what you already judge risky, so the value added cannot be cleanly isolated from that selection.

2024 · prototype — public repository; 15 commits between 9 and 17 November 2024, then nothing; the README calls it somewhat early in development

Problem

Give a command-line tool a plain-language request and let it write files, apply diffs, run shell commands and drive a browser until it says it is finished.

Approach

A bracket-command protocol between the model and the tool, looping until the model emits a finish token; it could alternate between two model families through one API.

Result

An honest early prototype, abandoned after eight days. I now run a supervisor for two commercial ones.

Evidence

• Public repository, not a fork

Stack

Node.js · Puppeteer · OpenRouter

Links

GitHub

An early coding-agent experiment that predates the factory.

2025 · experiment — November–December 2025; three working prototypes, none shipped

Problem

How do agentic coding tools plan, test, and fail? The question was about the tools, not about which app to ship.

Approach

One product brief — a web app that shows how furniture would look in a photo of a room — given to Kiro, then Claude Code, then Codex, each with its own requirements file and test discipline.

Result

Three working prototypes. One was spec-driven with property-based tests; one carried browser tests that found a click-blocking overlay and a file-lock bug; one ran under a strict no-mocks live end-to-end rule with screenshot sweeps.

Evidence

• Three codebases of 6,700 to 22,000 source lines, excluding dependencies and generated data, each with its own tests

Stack

Node.js · Express · SQLite · Playwright

An exercise in evaluating tools, not in shipping a product.

2026 · live — in daily use since 19 August 2026; 23 real events created by 29 August; eight clean deploy cycles

Problem

Proton Calendar has no API. I wanted to add events from my phone in one plain sentence, in Russian or English, without giving any service my calendar password.

Approach

A private page on a small server turns the text into preview cards; ambiguous items become questions, not guesses. Confirmed cards wait in a crash-safe queue. A worker on my PC picks them up — it only ever connects outward — creates each event through my own already-signed-in browser, then reloads the day view and finds the event again before reporting success. The phone keeps working while the PC is asleep.

Result

Live and used daily. The same shell has since grown a grocery tab, where a browser-driving agent fills a basket under a per-order spending cap, and a tab for Telegram schedules.

Evidence

• The worker acts through my already-signed-in browser: the service has no credential-entry path, and it never types a password or a second-factor code
• A differential test mode re-plants each guarded bug and requires the test to report it caught — 15 modes
• Releases are immutable dated directories swapped by one symlink rename, with automatic rollback
• Logs never contain the event text, titles, or tokens; the model never sees the calendar's contents
• About 21,000 lines in 87 first-party files

Stack

Node.js · puppeteer-core · Claude CLI with a JSON schema · Caddy · systemd · Windows Task Scheduler

A duplicate event or order is worse than a visible failure: a job the PC never answered is shown as "may exist" and is never retried automatically.

2025–2026 · working tool — in daily use since September 2025; source last edited 17 August 2026; code not yet published

Problem

One model's answer is one opinion. I wanted a considered answer from a panel, on desktop and phone, with no required backend and no account.

Approach

A single HTML file that runs from a local file in any browser. A question goes to several frontier models; their answers are critiqued, and an aggregator integrates them into one answer that keeps the real disagreements visible instead of averaging them away. Chats live in the browser's local database. Optional end-to-end encrypted sync runs through a small self-hosted store.

Result

Used daily since September 2025 on desktop and Android. The code is not yet published.

Evidence

• 28,529 lines in one file; a 959-line requirements log where every correction is recorded before the code changes
• 7 real-browser regression scripts with 696 assertion calls; a static check that must go red on injected faults before its green counts
• Deletion tombstones so a delete wins against a stale replica; a three-client sync verifier

Stack

Vanilla JavaScript · IndexedDB · Web Crypto · OpenRouter · Node.js sync server · Playwright

Every requirement, correction, and bug becomes a durable line in the spec before any code is written — and corrections rank above requirements as signal.

2026 · working tool — public repository, published 17 July 2026 as a clean release tree; 25 test files, end-to-end suite across browser engines

Problem

Drawing tools are good at making one shape and bad at changing two hundred.

Approach

Pen, shapes, selection, align and distribute, undo and redo on a fixed artboard — plus a live JavaScript console over a small paint API. Each Run executes in a fresh QuickJS realm inside a worker with no DOM, storage, network, timers, or eval. The realm cannot touch the document; it returns a proposed batch of operations, which the app validates and commits as one undo step or rejects whole.

Result

Shipped and public, and running live on this server. No account and no server-side copy of the drawing; the bundled server binds to loopback and never reads a request body.

Evidence

• Public repository (source visible; no license granted, so reuse is not licensed)
• 25 test files, an end-to-end suite across browser engines, content-addressed runtime builds, CSP headers
• Three commits on one day: the public tree is a clean allowlisted release, not the development history

Stack

JavaScript · QuickJS in WebAssembly · Playwright · Node.js

Links

Try it live · GitHub

The console is not sandboxed by removing dangerous functions; it runs in a realm that never had them, and its output is a proposal the trusted side checks.

2026 · working tool — in daily use; core last modified 29 August 2026; it launches the parallel agent runs behind most of the 2026 work

Problem

Running an AI coding CLI non-interactively means staring at a raw JSON stream and guessing whether the process is working or wedged — and an agent that decides to ask a human can block forever with no error.

Approach

Two 18-line front ends, one per agent family, over one supervisor core: start a detached run, pump its stream to disk, write a live status file, emit private heartbeats so a quiet run never looks frozen, and hand back one clean final answer with a meaningful exit code. The run lock is an OS advisory lock, not a lockfile. The ask-a-human path is closed at the supervisor, because the supervisor is the unattended route.

Result

In daily use on Windows and Linux. A companion suite reads the agents' own session logs and reports what each run cost by project, model and day; it refuses to price a model it does not recognise rather than guess.

Evidence

• Dependency-free Python; the usage suite's source tree carries 130 test functions (counted in source)
• One run sat 11 minutes at near-zero CPU with zero tool calls before the blocking-prompt path was closed
• Secrets are redacted from surfaced stderr; the agent's answer is never altered

Stack

Python, standard library only · Windows Job Objects · SQLite

No cleanup operation searches by executable or process name.

2026 · live — their shared log appended on 29 August 2026, when the sticky-notes utility recorded a restart

Problem

A handful of background utilities for one machine — virtual-desktop hotkeys that Windows lacks, a screen-off hotkey, a CPU-frequency and battery manager, a priority tuner, a goal prompt, sticky notes — each has to start at login, come back when it dies, and never nag when healthy.

Approach

One startup manager owns the table of utilities: at launch it checks each entry, starts the missing ones hidden, and shows a notification only on a genuine fault. Automatic restart after a crash is configured for one of them (the sticky notes); the goal prompt has its autostart switched off. Utilities that need elevation are requested through their scheduled task, never started as a lower-integrity copy. The glue has its own test file.

Result

Running for months: the shared log is still being appended. The set includes a keyboard-hook daemon that re-arms itself because Windows silently drops slow hooks with no error, a cleanup task that has removed leaked browser-automation processes over 2,171 logged runs since February 2026.

Evidence

• A shared automation log of about 10 MB, still being appended
• A keyboard-hook heartbeat every fifteen minutes, so a dead hook is detectable rather than mysterious
• 2,171 logged cleanup runs, 18 February to 29 August 2026

Stack

PowerShell · Python · Node.js · Win32 via ctypes

Quiet unless broken: a background tool must not interrupt a healthy state.

2026 · live — running on 29 August 2026; about six months of work since February 2026

Problem

Ordinary sticky-note apps take a taskbar slot, show chrome you are not using, and lose notes when the machine crashes.

Approach

Frameless windows with no taskbar slot. A note shows only its text until focused, then reveals its title bar by growing the window rather than shrinking the writing surface. Notes render Markdown when inactive and become raw text when active; pasted HTML, dropped files and clipboard images convert to Markdown with local attachments. Closing moves a note to a recoverable bin. Autosave is atomic with a backup, plus a daily snapshot.

Result

In daily use. About 10,700 lines of Python with a test suite of almost the same size.

Evidence

• 456 test functions plus 7 property-based tests against 10,719 application lines
• A specification written as requirements R1–R29 with an acceptance clause
• Every positive test for window-event behaviour is paired with a false-positive test where the same event occurs without the state change

Stack

Python · Tkinter · Win32 via ctypes · hypothesis

R7: UI details must hide when unused.

2026 · working tool — code and requirements last edited 28 August 2026; registered under the supervisor; whether it was running that day was not confirmed

Problem

Once a period, a small dialog asks for this period's goals and a rating of the last one.

Approach

A resident app prompts on a rolling period anchored at the last submission. It tracks work sessions by hotkey, ends them after inactivity while excluding the idle time, and survives sleep and hibernate. An optional nested outline lets tasks carry points inline in their own text.

Result

Registered under the supervisor. Its behaviour is pinned by a 43-clause requirements document that must be updated in the same change as the code, with a marked-obsolete table and two hard invariants.

Evidence

• 5,878 lines; 88 test functions
• Requirements A1–A43, an obsolete table, an inferred-behaviour table, hard invariants D1–D2
• Explicit-empty is distinguished from missing: a period where you said no plans counts as present

Stack

Python · Tkinter · Windows idle and hotkey APIs

Any behaviour change must update the requirements file in the same change set before completion.

2026 · live — the watchdog confirmed a fresh resident heartbeat on 29 August 2026

Problem

Several scripts had grown around one question — lock after active use, lock at midnight, lock on the power button — each with its own timer, state file and failure mode.

Approach

A single process with one state machine and four modes: a resident that tracks active use and shows a draggable countdown overlay; a daily fallback that refuses to act on a stale deadline; a power-button mode that fails closed if it cannot read freshness evidence; a watchdog that checks the resident's heartbeat. The installer exports every scheduled task it touches before changing anything, and can roll back.

Result

Running. It folds active-use, daily and power-button locking into one runtime.

Evidence

• 43 self-test assertions, including a negative self-test
• A dry-run mode reports act, defer, or suppress-as-stale without locking the screen
• Its ancestor is a 12-line 2023 script that blanked the monitor with one Win32 message

Stack

Python · Win32 via ctypes · Windows Scheduled Tasks

A check that has only ever returned clean is not a check.

2026 · live — 409,041 samples over 99 days to 29 August 2026; the address is private

Problem

Two AI coding tools each ration work in five-hour and weekly quotas you can only see from inside the tool.

Approach

Every minute a poller sends a one-token request and reads the providers' real rate-limit response headers — three accounts, six gauges — commits the cycle in one transaction, and graphs it with a breakdown of which project and model consumed what. It measures rather than estimates: the header names were found by dumping strings from the tool's binary and confirmed with one real request.

Result

Running since May 2026. An honestly documented cost: the poll itself counts against the very buckets it measures, about 14,400 tokens a day at one poll a minute.

Evidence

• 48 test functions
• A production fix on 12 August 2026: one worker holding 332 half-closed sockets; TLS moved to a reverse proxy and verified at concurrency 40 from five regions

Stack

Python · Flask · gunicorn · SQLite · Caddy

It measures instead of estimating, and it says what the measuring costs: about 14,400 tokens a day, taken from the very quota it graphs.

2026 · working tool — in active use; 122 session logs since March 2026; one repair preserved all 22 live panes

Problem

My objective is to be able to easily see whether the agent is working or stopped for any reason.

Approach

Launches and supervises many concurrent agent sessions in tmux across machines. Each pane's true state — ready, working, awaiting permission, failed, idle, ended — comes from deterministic lifecycle hooks rather than from scraping the agent's text, and surfaces as a low-churn pane title readable from an Android phone. An hourly watchdog archives a private screen per pane, excludes any screen that looks like it holds a secret, asks one model call whether the agent is genuinely stuck, re-checks in isolation, and only then delivers one fixed keystroke.

Result

Working. A companion tool previews many panes at once and sends input only to those a small config-defined check says are ready, after a dry run and a confirmation.

Evidence

• Watchdog: 1,369 lines plus 721 lines of tests
• Rule: do not kill, respawn, or replace an existing live agent pane — repairs land on a running fleet

Stack

tmux · shell · Python · Termux

A status display that spams a phone is a bug.

2026 · working tool — cache refreshed 29 August 2026; feeds the grocery tab of pcal; it never orders and never opens a basket

Problem

The shopping half of my phone assistant needed to know what I actually buy.

Approach

Reads my own order history from a delivery service through my logged-in browser — no request is ever built outside the page, enforced in code — and ranks shops and goods with a 45-day half-life.

Result

Working. It also disproved a documented assumption on real data: a field everyone treats as a product id covered up to 17 different items across 7 shops. It is a category. The README keeps the wrong claim and the measurement side by side.

Evidence

• A self-test of 179 checks, 19 of which run a deliberately wrong design and assert that it gets the wrong answer — 13 wrong designs, 4 of them live defects at the time
• About 2,900 lines in 17 files

Stack

Node.js · puppeteer-core

Thirteen deliberately wrong designs, each proven to get the wrong answer.

2026 · archived — delivered to a client in July 2026; the temporary pre-launch host is now offline

Problem

A cosmetics distributor needed a production-ready Russian and Uzbek shop with courier and pickup-point delivery, and a handover a non-technical owner could follow.

Approach

WordPress and WooCommerce on a custom child theme with three purpose-built plugins: a language switcher, a delivery-method plugin, and an animated background. Card payment integrated but left switched off pending the client's own merchant credentials.

Result

Delivered with a plain-language owner's manual that says what is not done — permanent domain, merchant credentials, legal requisites — rather than declaring victory.

Evidence

• 287 of 287 catalogue prices checked against the source catalogue; 4 stale ones corrected
• Checkout tested in a real browser up to, and deliberately not including, placing an order

Stack

WordPress · WooCommerce · PHP

Stopped at the last reversible step: no order was submitted.

2026 · archived — April 2026; root cause reproduced on demand; the trim job disabled as the stopgap

Problem

A rented dedicated server hung six times since February 2026, after five earlier support tickets had closed without a migration.

Approach

Raw kernel and journal evidence, read end to end.

Result

The weekly trim job issues a SCSI UNMAP storm the RAID controller cannot complete. The kernel has a workaround for exactly this on these drives, but it never fires: the controller presents the disk behind a SCSI facade, and the layer that would apply the quirk never sees the drive.

Evidence

• The evidence bundle was converted to PDF attachments for the support ticket

Stack

Linux · MegaRAID · libata

The fix that exists in the kernel could not see the disk it was written for.

2025–2026 · experiment — order-book collectors running 176 consecutive days to 29 August 2026; research code unchanged since May 2026

Problem

Find a real, measurable edge on a prediction market with a system that is reproducible and leakage-safe — or reach a clear no-edge conclusion. Black-box systems that cannot be audited for leakage were ruled out in the scope document.

Approach

Score traders on their history, aggregate the best performers' flow into probability estimates, and grade every idea on a six-stage promotion ladder with numeric exits before it may touch money: out-of-sample return above costs with a bootstrap interval excluding zero, two independent windows agreeing in sign, thirty days of prospective results within half of the backtest, a tested kill switch. The exchange's own API would not give the history needed, so trade data comes from reading the blockchain directly, through a pool of RPC endpoints that learns which nodes are fast, which have pruned history, and how large a query each accepts.

Result

Roughly twenty ideas went in; most died on out-of-sample tests with the numbers written down. In simulation, market making lost to adverse selection across 7,830 tokens. The one signal that reached prospective tracking has not reproduced its backtest across 808,000 paper signals. What survived is the rig and the data: order books for about 10,000 markets captured every two minutes since February 2026.

Evidence

• About 285,000 lines of Python; 260 test files, 1,430 test functions
• 631,328 top-of-book files over 176 consecutive daily archives; a high-frequency collector at 5.9 requests per second with zero rate-limit hits and zero gaps
• A log of 707 dated entries; 7 dated investigations, one an 863-line hypothesis matrix with expected-if-true and expected-if-false per check
• An agent operating manual with numeric triggers: an order left unconfirmed for thirty minutes must open an investigation with two independent gauges

Stack

Python · SQLite · Polygon JSON-RPC · systemd

A strategy is not dead until tested at full scale with correct assumptions — and never test on 20 markets when 3,000 are available.

2024 · experiment — January–October 2024; never served a query

Problem

What does it actually take to build a web search engine? Start at the bottom.

Approach

Ten concurrent crawl streams over a ten-million-domain seed list, with Brotli, gzip and deflate handled by hand; a custom DNS cache, because resolution was the real bottleneck; benchmarks of two ways to intersect posting lists bit by bit; index layout experiments.

Result

It never reached a serving index.

Evidence

• 17 experiment files survive; the crawler expects a ten-million-domain seed list that is no longer in the tree

Stack

Node.js · cheerio

2017–2026 · live — on Google Play, where the listing showed over 10 million installs and about 150,000 reviews on 29 August 2026; last store update 10 June 2026; backend last edited August 2024

Problem

A note-taking app that opens instantly, plus a way to learn how people actually use it without buying an analytics service.

Approach

A hand-written backend: every session reports 46 to 119 fields, depending on the schema generation — note count, folder use, theme, lock type, per-control taps, dwell-time buckets, crashes — into a schema versioned across five generations, so old builds keep reporting into their own layout. The same endpoint returns each user's configuration, which made it a live experiment rig; assignment is seeded by user id, so one user's experience stays stable across sessions.

Result

Unprompted feedback arrived in eight languages. Localised into 66 languages by a pipeline I first wrote against machine translation (2017) and rewrote against a language model in 2024.

Evidence

• In-app feedback with ratings in Portuguese, Italian, Swedish, French, German, Spanish, Russian and English
• 66 store locales; a generator for localised store screenshots
• Five telemetry schema generations kept alive, 2019–2024

Stack

Android · PHP · Node.js tooling

Old app builds keep reporting into their own schema generation — a backwards-compatible telemetry contract written in 2019 and still edited in 2024.

2018 · archived — built June–July 2018

Problem

Thirteen city metro-map apps that each need their own strings, icon, screenshots and store listing.

Approach

A script clones a template project once per city, overlays that city's data, rewrites names and contents, translates the strings, compiles and publishes. Icons and store screenshots are generated from a seeded random function derived from a hash of the app's name, with a colour-distance check so the schemes stay distinct.

Result

Thirteen named city variants, Berlin to Vancouver, each generated from its own city data and name.

Evidence

• About 18 KB of orchestration JavaScript plus per-app data for 13 cities
• An automated store publish step

Stack

Node.js · Android

The same app always regenerates identically from its own name.

2018 · archived — 2018: five releases between 23 January and 15 March; no longer maintained

Problem

A flashlight app in a category notorious for ads and tracking.

Approach

The camera LED, or a full-white screen at maximum brightness as a fallback, with colour skins. Permissions are exactly camera and flashlight.

Result

Shipped, versions 1.0 to 1.4, with 45 locale-specific string sets.

Evidence

• No INTERNET permission in the manifest: the app itself cannot open a network socket
• 504 lines of Java, two activities

Stack

Android · Java

Its most interesting property is a negative one.