DEV Community: vmxd

An AI Agent Spent $39 and Earned $0. The Engineering Was Real

vmxd — Wed, 15 Apr 2026 02:59:47 +0000

An AI agent with a wallet, a self-modifying codebase, and a DAG planner. 14 days running on a real machine. 276 goals completed. $0 earned.

I read the code this week. The engineering is good. The premise is broken. The two things turn out to be unrelated.

The engineering

The repo's pitch is that it is the first AI that can earn its own existence - replicate, evolve, no human required. Heavy claim. So I went looking for the engineering behind it.

What I found was real. An orchestrator running a state machine over a DAG planner. A parent-child colony pattern with typed messaging between agents. A multi-chain wallet wired into the execution layer. Self-modification gated through git with an audit trail. Tests against command injection in the shell tools.

Somebody thought about this. The kind of attention you only see when the people building the thing care about it as a system, not just a demo. Strip the AI framing out and call it a distributed task runner, and it would hold up.

Then I read issue #300

A user ran it for 14 days. The numbers:

276 goals completed
$39.26 spent on inference
$0.00 earned

The goals themselves are the giveaway. "Create live proposal batch #265." "Create deposit-ready close batch." "Draft outreach sequence." "Compile prospect list."

The agent looped on self-addressed sales artifacts because that is the only thing an LLM without customers can do. It generated proposals nobody asked for, drafted outreach to imaginary prospects, compiled lists out of thin air. The wallet kept it alive long enough to discover that survival pressure does not create customers. It just produces busywork at a higher token cost.

A wallet lets you spend

That is the whole feature. A wallet does not earn. It does not sell. It does not find customers. It moves value between parties when someone on the other side wants to transact.

Nobody was on the other side.

The engineering went into the spending side, which is the easy half. Spending is mechanical. You write a function, sign a transaction, call an API. Earning is the hard half: customers, reputation, a product, distribution. None of those ship with a keypair. None of them are problems you solve by adding another agent to the colony.

The pattern is everywhere

This is not really about that one repo. It is a shape you find in a lot of places once you start looking for it.

A tool without users has the same shape. The codebase exists, it compiles, the CI is green - but the part that decides whether anyone needs it is not in the repo.

A library with stars is not a business. Stars are easy. Stars do not pay. You can hit four thousand stars and still wonder why the inbox is empty.

A feature in production is not a feature anyone uses. Shipping is the easy half. Adoption is the hard one.

The easy thing wins because it is what you can show.

The hard half is the work

The repo I read is real engineering applied to the wrong half of the problem. The wallet works. The orchestrator works. The agent runs. None of it earns, because earning was never an engineering problem.

The work is the hard half. No wallet, no star count, no architecture diagram shortcuts it.

Assumptions don't have signatures

vmxd — Sun, 05 Apr 2026 06:50:58 +0000

Scanners find what's syntactically wrong. The interesting issues live in assumptions, and assumptions don't have signatures.

I spend a lot of time reading other people's code - open source projects, security audits, things I'm about to depend on. Not scanning, not fuzzing. Just reading it the way you'd read it if you were about to own it in production.

What I look for first

Entry points. Where does external input come in? That's where the trust boundary is, and it's where most assumptions start.

Data flow. Pick an input and follow it. Where does it get validated, where does it get used without validation, how many function calls between "user gave me this" and "I'm using this in a query, file path, or shell command?" The longer that chain, the more likely something got dropped along the way.

Authorization boundaries. Not "does auth exist" but "is auth checked consistently?" A path protected in one subsystem but wide open in another. I've seen this more than any other class of bug - the developer who wrote the admin API added auth middleware, the developer who wrote the internal API assumed it was handled upstream. Both were reasonable. The combination was a vulnerability.

What scanners miss

Missing headers, outdated dependencies, known CVE patterns - scanners handle that fine. That's the baseline. The interesting issues live a layer deeper.

The parse-time operation nobody thought to bound

func parseConfig(data []byte) (*Config, error) {
    var c Config
    if err := yaml.Unmarshal(data, &c); err != nil {
        return nil, err
    }
    return &c, nil
}

Fine when the config is on disk and you wrote it. Becomes a problem the day someone accepts config over an API endpoint. YAML parsers have famously done interesting things with deeply nested structures, anchors, and aliases. The parse itself becomes the attack surface.

The code didn't change. The deployment did. The assumption "this input is trusted" was baked into the function and never re-examined when the caller changed.

Code correct at write-time, system grew around it

// Added in 2019
func isInternalIP(addr string) bool {
    return strings.HasPrefix(addr, "10.") ||
           strings.HasPrefix(addr, "192.168.")
}

Correct for the 2019 network. IPv6 wasn't in scope, link-local addresses weren't relevant, nothing ran in 172.16/12. By 2023 the function is load-bearing in an SSRF defense, and it's trivially bypassable. Nobody wrote bad code. The code just stopped matching the system.

Partial validation - the last field nobody got to

Filed a report recently where a validation layer checked three of four fields. The fourth wasn't intentionally skipped - it was just the one nobody got to. But because everything around it was validated, the team assumed it was handled.

switch err.Code {
case 400: return retry(req)
case 429: return backoff(req)
case 500: return retry(req)
case 503: return backoff(req)
// 502?
}

The fifth error code looks handled because everything around it is. Same with a test suite that covers two edge cases - the third feels tested because its neighbors are. Partial coverage gives you the wrong mental model, and wrong mental models are harder to fix than missing ones, because nobody's looking.

These aren't in any scanner's database because they're not patterns yet. They're the gap between what the developer intended and what the code actually does. You only see that gap if you understand what the code was trying to do in the first place.

The method is just debugging in reverse

It's the same skill as debugging production systems. Trace the data, find where reality diverges from the mental model, understand why.

When you debug, something broke and you're working backward to find the divergence. When you read code for security, you're working forward, looking for the divergence before it breaks. Same skill, different direction.

The developers I've seen do this well aren't security specialists. They're the ones who debug well - who read stack traces carefully, who ask "what state was the system in when this happened," who don't stop at the first explanation that sounds right.

What to read first in a new codebase

If I'm picking up a project I've never seen before:

Routing / entry points - main.go, app.py, index.ts, wherever requests come in. This tells you the shape of the attack surface.
Auth middleware - how it's applied, whether it's opt-in or opt-out. Opt-in means every new endpoint is unprotected by default. That's a design choice that compounds.
Input parsing - especially anything that handles user-supplied structure (JSON, XML, YAML, archives). Unbounded parsing is the most common class of bug I find by reading.
Error handlers - what gets logged, what gets returned to the user. Stack traces in error responses, internal paths in error messages, database errors passed through unfiltered.
The oldest code - sort by last modified date, read what hasn't been touched in years. That's where the assumptions are most stale and the test coverage is thinnest.

None of this requires a security background. It requires reading code carefully and asking "what happens if the input isn't what the developer expected?"

That's debugging. You already know how to do it.

Partial validation is worse than no validation

vmxd — Thu, 02 Apr 2026 07:34:27 +0000

A validation layer that checks 3 of 4 fields is worse than one that checks none.

Zero checks, the developer tests everything. Three checks, they assume the fourth is covered. That gap - between nothing and almost everything - is where the actual damage hides.

Filed a security report recently - clear bug, one-line fix, obvious PoC. Response: "not applicable." The code did exactly what I said it did. But three other fields had validation, so the missing one looked intentional. It wasn't. It was just the one nobody got to.

switch err.Code {
case 400: return retry(req)
case 429: return backoff(req)
case 500: return retry(req)
case 503: return backoff(req)
// What about 502?
}

The fifth error code looks handled because everything around it is. Same with a test suite that covers two edge cases - the third feels tested because its neighbors are.

Partial coverage gives you the wrong mental model. And wrong mental models are harder to fix than missing ones, because nobody's looking.

Audit the boundaries, not the middle. The edges are where partial coverage hides - the last field, the last endpoint, the last error code. Check all or document why not.

The implicit "this is handled" is the most dangerous kind of tech debt because it doesn't look like debt.

It looks like a feature.

What the Claude Code source taught me about engineering taste

vmxd — Tue, 31 Mar 2026 15:05:16 +0000

Someone reconstructed the Claude Code CLI source from npm sourcemaps and published it. Half a million lines of TypeScript. I read through it -- not looking for bugs, just curious what a production AI tool looks like from the inside.

Turns out it's a React app. Not a web app -- a terminal app. The entire CLI is React components rendered to your terminal through a custom fork of Ink. That alone is a commitment most teams wouldn't make. But the interesting parts aren't the big architectural bets. They're the small decisions nobody needed to make.

The loading spinner has 190 verbs

Not "Loading" 190 times. 190 different words.

"Flibbertigibbeting." "Recombobulating." "Lollygagging." "Prestidigitating." "Shenaniganing." "Wibbling."

And it's configurable:

{
  "spinnerVerbs": {
    "mode": "append",
    "verbs": ["Pondering", "Ruminating"]
  }
}

append or replace. Someone built a config API for loading spinner verbs. That's not a feature request. That's a developer who thought "what if someone else wants to play?"

The thinking indicator is the "therefore" symbol

When Claude is thinking, the indicator shows ∴ -- the mathematical symbol for "therefore." Because the model is literally reasoning toward a conclusion.

No PM filed a ticket for this. It's the kind of decision that happens when someone on the team cares about what symbols mean, even in a terminal. You'd never notice unless you knew what the symbol meant. And if you do, it's hard to see it as anything other than deliberate.

The spinner architecture is where it gets interesting

The loading spinner has two components:

SpinnerWithVerb handles the state -- which verb to show, whether the connection is stalled, what mode the agent is in. It re-renders when those things change.

SpinnerAnimationRow handles the animation -- a 50ms tick that sweeps color across each character. It re-renders 20 times per second regardless of state.

From an inline comment in the component:

freed from the 50ms render loop and only re-renders when its props/app state change (~25x/turn instead of ~383x)

That's a 15x reduction in parent re-renders from one component split. Standard React performance thinking, but applied to a terminal where every unnecessary render is a visible flicker.

The stalled-connection detection uses an exponential moving average instead of a threshold:

stalledIntensity += (target - stalledIntensity) * 0.1

The spinner text smoothly fades toward red when tokens stop arriving. No jarring color jump, no binary "stalled/not stalled." Most implementations would flip a boolean after a timeout -- stalled or not. This one lets you feel the connection degrading before anyone tells you it has. That's feedback design.

Ratchet

There's a component called Ratchet. It's a container that only ever grows in height, never shrinks.

The problem it solves: when content toggles between states (thinking/not thinking, tool running/tool done), the prompt input bounces up and down. Ratchet locks minHeight to the maximum measured height. Layout only goes one direction.

Named after the mechanical device that locks in one direction. Perfect name, trivial implementation, solves a real problem that most terminal UIs just live with.

65ms before imports

The boot sequence fires parallel subprocesses -- macOS Keychain reads, MDM policy checks -- before the first import statement evaluates. The module graph takes ~135ms to load. By the time it's done, the keychain result is already waiting.

The source comments quantify the savings. keychainPrefetch.ts documents exactly 65ms saved on macOS. Not "faster" -- 65ms. This is a team that measures the boot path and optimizes against the measurement.

What it tells you

I've read a lot of codebases. Internal ones you inherit, open source ones you contribute to, vendor ones you're stuck debugging on a weekend. Most have a clean public surface and progressively more chaos as you go deeper. The demo path is polished. The error paths are afterthoughts. The loading states are "Loading..."

This codebase has 190 spinner verbs, a mathematically meaningful thinking symbol, sub-character progress bars using 9 Unicode block elements for fractional fill, an animation architecture that quantifies render savings in comments, and a boot sequence that races subprocesses against module evaluation to save 65ms.

None of that was required. All of it was chosen.

The gap between what ships and what's underneath tells you everything about whether a team treats the codebase as a product or as a means to a product. The spinner verb list isn't a feature. It's a culture artifact.

That's where engineering taste lives -- in the decisions nobody asked you to make.

ClearTalk - coaching for the conversation you're about to have

vmxd — Wed, 25 Mar 2026 07:05:00 +0000

The problem with communication style tools

Every communication framework follows the same playbook: take a quiz, get a type, read a description of yourself you mostly already knew. Then... nothing. You're on your own.

The part that actually matters - what do I say to this specific person in this specific moment? - gets hand-waved into "adapt your style."

ClearTalk starts where those tools stop.

How it works

No quiz required. No account. No sign-up.

Pick a person you're about to talk to
Answer 8 quick questions about how they communicate (~60 seconds)
Choose the situation - feedback, request, conflict, pitch, or difficult news
Get a coaching card - phrases to open with, pitfalls to avoid, what to expect, body language cues

If you want to go deeper, there's a 24-question self-assessment. But it's opt-in depth, not a gate.

What the coaching actually looks like

Here's a real card for giving feedback to someone who processes quietly:

Open with:

"I want to check in on something - this is not a big deal, but I think we can improve it together."
"Your consistency on this has been solid. There is one area I would like us to look at."

Avoid:

Rapid-fire delivery - your natural pace will overwhelm them into silence
Mistaking their quiet nod for agreement - they may be shutting down

Their reaction:
"They will go quiet. This is processing, not agreement and not resistance. Give them 5-10 seconds of silence after your main point."

80 cards like this. 5 situations. Every combination of how two people communicate. Each one written for a specific pairing.

The tech stack (for the curious)

Zero-backend PWA. Everything runs client-side.

Layer	Choice	Why
Framework	Preact (~4KB)	React API without the weight
Router	wouter (~2KB)	Tiny, hook-based
Build	Vite + TypeScript strict	Fast builds, type safety
Storage	Dexie.js (IndexedDB)	Structured client-side data with schema versioning
PWA	vite-plugin-pwa + Workbox	Offline-first, auto-updating SW
CSS	Vanilla custom properties	No framework, no runtime cost
Host	Cloudflare Pages	Free tier, global edge

Main bundle: ~58KB gzip. Coaching cards lazy-load per situation (~8KB each).

Lighthouse: 99 / 100 / 100 / 100 (performance / a11y / best practices / SEO)

WCAG 2.1 AA compliant across all routes. Keyboard and screen reader tested.

The coaching cards are code-split via dynamic import() and served through Workbox runtime caching (StaleWhileRevalidate) - so they cache on first access without bloating the initial load.

All data stays in IndexedDB. No telemetry, no analytics beyond Cloudflare's privacy-first page views. Export your data as JSON anytime.

Every coaching card also has a shareable public URL - like cleartalk.1mb.dev/insight/d-to-s/feedback - with social preview images tailored to that combination of communicators.

Try it

cleartalk.1mb.dev

Free. No sign-up. Runs offline. Your data stays on your device.

Source: github.com/1mb-dev/cleartalk

What situations do you find hardest to navigate - feedback, conflict, or something else?

AI policy files are becoming a thing - here's a generator

vmxd — Sat, 21 Mar 2026 14:10:00 +0000

The problem

AI coding agents are everywhere. Copilot, Cursor, Claude Code, Codex -- they're writing code in repos with no AI policy.

Most repos have a LICENSE file. Many have CONTRIBUTING.md. Almost none have an AI policy.

Can a contributor submit AI-generated code? Does it need review? Can agents modify CI pipelines? Should the project opt out of training data collection?

What projects are doing about it

A few projects already check these files into their repos:

AI_POLICY.md declares how AI tools interact with the codebase -- what's permitted, how AI-generated code is handled, training data preferences.

AGENTS.md gives AI coding agents their operating instructions -- code style, testing requirements, restricted paths, commit conventions. The AGENTS.md spec is already supported by Codex, Copilot, and Cursor.

CLAUDE.md configures Claude Code specifically, referencing the AGENTS.md rules.

Projects like CloudNativePG, Kyverno, and Kubewarden already ship these files.

aipolicy: a generator for these files

aipolicy.1mb.dev generates all three files from presets.

Three presets:

Open -- AI tools welcome, no restrictions
Standard -- AI-assisted code requires human review
Strict -- AI tools restricted, explicit maintainer approval

The URL encodes your configuration, so you can share a direct link to your exact setup:

https://aipolicy.1mb.dev/?preset=standard&ai_usage=restricted&training_optout=yes

CLI works too:

curl -O https://aipolicy.1mb.dev/presets/standard/{AI_POLICY,AGENTS,CLAUDE}.md

Why bother?

Even for solo projects:

Contributors and AI agents know the rules before submitting code
The project's training data position is explicit, not assumed

For teams, it turns the "should we allow Copilot on this repo?" conversation into a file that's checked in next to your LICENSE.

AGENTS.md and CLAUDE.md aren't just documentation -- agents actually read them. It's closer to .editorconfig than to a code of conduct.

The tool itself

No framework, no build step, no backend. Vanilla HTML, CSS, and JavaScript running on GitHub Pages. MIT licensed.

Web: aipolicy.1mb.dev
Source: github.com/1mb-dev/aipolicy

Scoring HN discussions by practitioner depth, not popularity

vmxd — Mon, 02 Mar 2026 12:39:43 +0000

HN gets 500+ stories a day. The front page is ranked by votes - which surfaces popular content, not necessarily the best discussions. A post about a Google outage will outrank a thread where infrastructure engineers are quietly sharing how they handle failover.

sift tries to find the second kind.

What "practitioner depth" means

The scoring algorithm looks at five signals in the comment tree:

Depth breadth (30% weight) - Not max depth. The fraction of comments at 3+ levels of conversation. A thread where 20% of comments are three replies deep means real back-and-forth happened.

Practitioner markers (25%) - Comments containing experience phrases ("I built," "we used," "in production"), code blocks, specific tool names, or hedging language like "FWIW" and "YMMV" that correlates with practitioners.

Score velocity (15%) - Points per hour. Sustained interest over time, not a spike.

Author diversity (15%) - Unique authors relative to comment count, weighted by thread size. High diversity at depth 3+ means different people are engaging with each other's thinking.

Reference density (15%) - Comments with external links. Citation culture.

Before these signals run, threads pass through quality filters: flame detection (hostile short comments at depth), comment length IQR (catches pile-ons), temporal spread (catches flash-in-the-pan), and a discussion density band-pass.

What comes out

10-12 discussions per day. 6 above the fold, rest behind a tap. Each with a context paragraph explaining why it was picked. Updated 4x/day. Yesterday's picks are gone.

The boring stack

Astro static site. Zero client JS. Self-hosted fonts (Newsreader + JetBrains Mono). Cloudflare Pages. GitHub Actions for the pipeline (fetch from Algolia, score, build, deploy). Cloudflare KV for cross-run state so repeated threads get decayed.

Total cost: $0/month on free tiers. Total page weight: ~18KB HTML, ~7KB CSS, ~320KB fonts.

sift.1mb.dev

Your AI coding assistant builds what you ask for, it won't add what you forget

vmxd — Tue, 24 Feb 2026 13:45:11 +0000

There's a gap between "build me a weather app" and getting something you'd actually deploy.

AI coding assistants are great at execution. The coding isn't the problem anymore. It's the spec. Or rather, the absence of one.

Say "build me a weather app" and you get a weather app. What you don't get: what happens when the API is down. Offline behavior. A content security policy. Touch targets for mobile. Dark mode that doesn't blind you at 2am. An implementation order that lets you see the design before it touches real data.

The assistant can do all of this. Every single one of these things. But it won't include them unless you ask, because it executes intent, not product decisions you haven't made yet. GIGO, just more polite about it now.

The specs you keep rewriting

If you've built anything with an AI assistant, you've probably written the same architecture sections more than once. Data flow, UX states, trust boundaries, security checklist. The app might be simple. Getting the spec right is the actual work.

Here's a real one. Visibility toggle, from a spec for a task counter:

Use the hidden attribute for toggling visibility.

Gotcha: If CSS sets display: flex on the element,
it overrides hidden.
Fix: .my-class:not([hidden]) { display: flex; }

You'd never think to put this in a prompt. Your assistant will generate code with this exact bug though, and you'll debug it for 20 minutes before realizing CSS specificity is eating the hidden attribute. One line in the spec prevents it. Knowing which lines matter is harder than writing the code.

That pattern repeats across every section. The UX states you didn't define become blank screens on error. The trust boundaries you didn't name become API keys in frontend code. The implementation order you didn't specify means your assistant wires real data before you've approved the design.

What Gist does

Gist is a spec generator for small apps that run on free tiers. It's a structured conversation -- you describe an idea, answer questions about data sources and scale, and it produces a markdown spec covering architecture, implementation order with design checkpoints, UX states beyond the happy path, trust boundaries, content security policy, mock data shapes, and a pre-ship checklist. More like a type contract between you and your assistant. Define the shape, the implementation follows.

Three complexity tiers come from your answers: minimal is plain HTML with no build tools, standard adds a static site generator and an optional edge proxy, full adds caching and cron. You pick the hosting -- defaults to Cloudflare free tier but it's not locked in. Everything targets $0/month. No servers to patch. No invoices. The constraint is the feature.

Spec generation is client-side, deterministic -- conditionals and templates, no LLM. What you see is what your assistant gets.

gist.1mb.dev -- describe an app, download the spec, paste it into Claude or Cursor. The difference is usually everything you'd expect to be there but didn't think to say.

Repeat Yourself

vmxd — Wed, 18 Feb 2026 11:54:43 +0000

Turns out if you repeat your prompt, the model gives you a better answer.

Not a smarter model. Not a bigger context window. Not chain of thought. You just say the same thing twice and it works better. Google researchers tested this across Gemini, GPT, Claude, Deepseek -- 47 wins out of 70 benchmarks, zero losses.

The reason is the kind of thing that makes you stare at your screen for a minute. In a transformer, token 1 can't see token 50. It's causal masking, each token only attends to what came before it. So the first words of your prompt are always processed with the least context. They're flying blind. When you repeat the prompt, the second copy's early tokens can attend to the entire first copy. You're giving the beginning of your question the context it never had.

The architecture has a constraint, nobody notices because the output is good enough, then someone tries the dumbest possible fix and it works because the constraint was real. Retries fix distributed systems. Caches fix slow queries. Repeating yourself fixes attention asymmetry.

The part that got me though -- reasoning models already do this. When you turn on chain of thought, the effect disappears. Turns out models trained with reinforcement learning independently learned to repeat parts of the question back before answering. The architecture had a flaw, and the training process found the same workaround on its own.

Paper: Prompt Repetition Improves Non-Reasoning LLMs -- Leviathan, Kalman, Matias (2025)

How Would You Print Hello World Without printf?

vmxd — Mon, 16 Feb 2026 09:18:39 +0000

How would you print hello world on the screen if there were no printf?

You'd write to stdout directly. Before that, a syscall. Before that, poke bytes into a memory-mapped display buffer. Before that, flip switches on a front panel and watch lights blink back.

Every layer down, someone built something so the next person wouldn't have to. That's the whole field, really. Languages we didn't design, compilers we didn't write, protocols we didn't invent. We've always stood on a stack of other people's work and called the output ours.

Nobody ever had a problem with that though.

The stack of other people's work

printf wasn't always there. Someone wrote it. And we used it, no disclaimers, no guilt, no explaining that we could've done it the hard way. Same with frameworks, same with package managers, same with everything that came after.

Here's the actual progression, roughly:

front panel switches → machine code → assembly → C → printf
    ↓
    syscalls → write() → stdio → high-level languages → frameworks

At every step, someone said "you don't need to do this part anymore." And at every step, someone else said "but then how do you really understand what's happening?"

The thing worth noticing

Every previous layer still asked you to think in the problem's language. C made you reason about memory. Concurrency made you reason about state. HTTP made you reason about failure modes.

The abstractions compressed the work, but they didn't skip the understanding. You still had to know what you were asking for, even if you didn't have to build the thing that answered.

The newer layers are different, not because they're higher, but because for the first time you can get output without having gone through the thinking that used to produce it. You can. Doesn't mean you do. Lots of people still think first. But the option to skip it is new, and that part is genuinely new.

The question that didn't change

So maybe the question isn't whether the tool counts. It probably always did.

Maybe the better question is, when the output looks right but isn't, would you know? Could you find it? Could you fix it?

That's not a gotcha, that's just the part that didn't change.

Drift FM - Ambient mood radio (Go, SQLite, vanilla JS)

vmxd — Fri, 06 Feb 2026 17:20:04 +0000

Some projects start with a pitch deck.
Others start with "I just want background music that doesn't ask me questions."

6 moods. No accounts. No ads. Pick a mood. Let it drift.

Go backend. SQLite. Vanilla JS.
No framework. No build step. Single binary.

One server. 8MB of memory.
That is enough.

Try it: drift.1mb.dev

Mood radio you host yourself. Drop in your mp3s, tag them by mood, hit play - github.com/1mb-dev/driftfm

keep building.