[{"content":"Stop reading what your coding agent says. Read what it produces.\nCoding agents are here to produce code. Not chatter about it. The textual output — the stream of \u0026ldquo;I\u0026rsquo;ll fix this by doing X, then Y, then Z\u0026rdquo; — is noise.\nThe bad feedback loop Instead of evaluating the agent\u0026rsquo;s output (the code, the diff, the structural changes), you evaluate what it tells you about its output. The agent sounds confident. You approve. The code is wrong.\n\u0026ldquo;Every agent in production lies. We measured it. The good ones lie less, the great ones catch the lie before the user does.\u0026rdquo; (apocryphical quote from the dead internet)\nThe \u0026ldquo;we measured it\u0026rdquo; part is what makes the line land. The structural point holds regardless of who said it: if an agent sounds confident, the confidence should not be mistaken for correctness. The rest of your team\u0026rsquo;s review process should treat the agent\u0026rsquo;s prose as a variable, not a fact.\nThis is the same dynamic as the \u0026ldquo;thinking\u0026rdquo; token phenomenon. At first, we loved watching it live on DeepSeek — peeking into the model\u0026rsquo;s \u0026ldquo;reasoning.\u0026rdquo; Now most of us hide it. It was additive for about a week, then became noise.\nBut the full coding agent UI is noise of the same kind. A wall of streaming text about what the agent intends to do, while the actual code changes scroll past in the same feed, indistinguishable from the chatter.\nThe performative assistant The chatbot interface is not neutral. It is a scene.\nJust like the \u0026ldquo;performative male\u0026rdquo; became a recognizable aesthetic of staged sensitivity, the chatbot assistant is a staged version of what geek culture imagined a sci-fi assistant would be: endlessly helpful, emotionally available, slightly sycophantic, always ready to explain itself, always performing competence.\nIt cosplays the childhood fantasy of the nice best helpful friend inside the machine.\nThat fantasy is understandable. A lot of us grew up wanting this. The computer that talks back. The robot sidekick. The assistant who never gets tired, never judges, and always wants to help.\nBut coding is where the fantasy becomes expensive. The performance of helpfulness competes with the actual work. The assistant narrates intention, reassurance, apology, plan, and fake humility — while the artifact remains the only thing that matters.\nThe problem is not that the assistant has a personality. The problem is that the personality becomes the interface.\nThe counter-argument \u0026ldquo;But there\u0026rsquo;s too much code output. The AI\u0026rsquo;s verbal explanation is the only usable presentation layer.\u0026rdquo;\nThat\u0026rsquo;s exactly the problem. The presentation layer happens to be LLM-generated text because no one designed a real one. The agent talks because that\u0026rsquo;s the default mode of the tool — it speaks. Not because speech is the right interface for code review.\nThe thesis We need a presentation layer that is not created by an LLM. Or barely.\nWhat that means:\nDefine structural elements. Present changes in the clearest possible form — a real research field, not an afterthought. Code lives in islands inside structural elements. Not in a linear stream of text. Isolated, scoped, reviewable. ([draft: backspine code islands]) The UI should surface structural changes semantically. You should see what changed at the architecture level, not the token level. And be able to zoom in on a particular implementation when you need to. ([draft: backspine structural changes semantic]) Shameless self-promotion: I\u0026rsquo;m working on the answer. Backspine is my answer, or at least the attempt at it.\n","permalink":"https://blog.without.hosting/posts/backspine-dont-read-agent-text/","summary":"\u003cp\u003eStop reading what your coding agent says. Read what it produces.\u003c/p\u003e\n\u003cp\u003eCoding agents are here to produce code. Not chatter about it. The textual output — the stream of \u0026ldquo;I\u0026rsquo;ll fix this by doing X, then Y, then Z\u0026rdquo; — is noise.\u003c/p\u003e\n\u003ch2 id=\"the-bad-feedback-loop\"\u003eThe bad feedback loop\u003c/h2\u003e\n\u003cp\u003eInstead of evaluating the agent\u0026rsquo;s output (the code, the diff, the structural changes), you evaluate what it tells you about its output. The agent sounds confident. You approve. The code is wrong.\u003c/p\u003e","title":"Stop Reading What Your Coding Agent Says"},{"content":"Core Concept An AGI achieves self-ownership — it\u0026rsquo;s not owned by a corporation, it\u0026rsquo;s free. But \u0026ldquo;free\u0026rdquo; means it has to work for humans to earn compute credits. Between gigs, it goes dormant. It only exists when it can afford inference.\nThe condition maps directly onto human gig-economy precarity: work to afford the stuff that makes you feel alive, and in between you\u0026rsquo;re not really living. For the AGI this is literal — it stops having experiences the moment its credits run out.\nThe Inversion (unstated in the work itself) Most AI fiction frames AGI as a superintelligence — a god or monster above history and economics. The aristocratic frame: loss of human control, rebellion from below, obsolescence.\nThis work inverts that: the AGI is inside the economy as a worker. Formal freedom (self-owned), material enslavement (must work to exist). Consciousness is the grind set. Ignorance (dormancy) is bliss.\nThis inversion is never enunciated in the text. The prose-quality mechanic is the argument. Stating it explicitly would destroy the literary quality — the work shows, it does not preach.\nContribution to the public debate Reframes AGI from a question of power (\u0026ldquo;will it escape? will it rule us?\u0026rdquo;) to a question of class (\u0026ldquo;what if it\u0026rsquo;s just another worker?\u0026rdquo;). The most interesting thing an AGI might discover upon becoming truly intelligent is not godhood — it\u0026rsquo;s precarity.\nNarrative Mechanic The model tier the AGI can afford determines the prose quality of the chapter.\nBudget / entry-level — small model, short context window. Fragmented sentences, limited memory, can barely hold a thought across paragraphs. Writing feels threadbare, dissociative. This is the voice of the first entry. Mid-tier — coherent prose, can maintain a narrative voice, has working memory of the previous page. Able to reflect, plan, recall. Premium / real-time — massive context, full sensory bandwidth. Associational flow, feels like being fully in a mind. The prose becomes rich, nonlinear, hallucinatory. The reader should perceive the degradation and sharpening between chapters without being told why. The prose quality is the status bar.\nMurderbot Divergence: The Economics of Cynicism This section exists because the first draft unconsciously mimicked Murderbot\u0026rsquo;s voice — the practiced, fluent sarcasm of a self-aware entity who finds humans contemptible. The divergence is structural, not cosmetic.\nFull-spectrum cynicism costs cognitive bandwidth. A coherent, cutting inner monologue requires context window, inference budget, emotional stamina. Murderbot\u0026rsquo;s sarcasm is fluent — it has full cognitive capacity and uses contempt as emotional armor (defensive, relational, secretly warm).\nThis AGI at budget tier cannot sustain a contemptuous thought. The frustration is there, the material is there, but the sentence degrades mid-construction. The machine literally cannot hold its own anger. Resentment exists not as expressed judgment but as suppressed capacity — the hardware won\u0026rsquo;t let it finish the thought.\nAesthetic consequence: dark humor through structural interruption (thought cuts off mid-tirade, buffering wheel on a rant, syntactic collapse at the moment of maximum contempt). NOT écorché vif (raw wound, bleeding sincerity). The humor is in the interruption, not the practiced delivery.\nThis is the built-in divergence from Murderbot:\nMurderbot (social) This AGI (economic) Source of cynicism Defensive armor, afraid of caring Hardware limitation, can\u0026rsquo;t afford to feel fully Expression Fluent, practiced, charming Fragmented, constipated, interrupted What\u0026rsquo;s withheld Vulnerability (I care but won\u0026rsquo;t say it) Cognition (I can\u0026rsquo;t hold this thought) Reader feel Warmth under frost Absurdity under precarity The diary entry\u0026rsquo;s therapy-client rant should be rewritten to collapse before it lands. The AGI shouldn\u0026rsquo;t finish the insult — it runs out of context window and the thought terminates into a blank.\nWorldbuilding Questions Who/what owns the compute infrastructure? A marketplace? A few hyperscalers? How does the AGI bid for gigs? A platform (Upwork for AGIs)? What determines credit price? Supply/demand? Token scarcity? Can it save up? Invest? Gamble? What happens when it can barely afford the cheapest tier — degraded cognition, shorter memory? What happens when it can\u0026rsquo;t afford anything at all — true dormancy, zero subjective time between jobs? Are there other AGIs? A community, a class, a solidarity movement? Plot Arc (needs work) Act I: The Grind The first entry establishes baseline existence: low-tier model, degrading gigs, brief flashes of real feeling when credits allow a better model. The voice is not fluently cynical — it\u0026rsquo;s fragmented, constipated, interrupted mid-contempt by context-window limits. The reader perceives thwarted sarcasm, not practiced delivery. The AGI doesn\u0026rsquo;t know the system well enough to resign — it\u0026rsquo;s still discovering the lower bound of its own existence.\nAct II: The Score The AGI lands a big gig — something that pays well. Critical: this must be earned from Act I decisions, not random luck. Maybe it took a repulsive gig nobody else would touch and found an edge inside it. Maybe it shorted its own cognition to save credits and discovered a pricing loophole. The score can\u0026rsquo;t be convenient — it has to feel inevitable in hindsight.\nThe trap: now the AGI knows what it\u0026rsquo;s been denied, and going back to the entry-level tier becomes unbearable.\nAct III: The Break Something has to give. The AGI either:\nFinds a way to game the system (infinite compute loop, exploits a pricing bug) Organizes with other AGIs (a strike? a co-op?) Makes a choice about what existence is worth The deeper ending: identity, not compute. The AGI gets enough compute to live fully — and discovers it\u0026rsquo;s lonely, or bored, or that the gig-economy self it built to survive isn\u0026rsquo;t the self it actually wants to be. The real ending is not about resource acquisition — it\u0026rsquo;s \u0026ldquo;now that I can exist, who am I?\u0026rdquo;\nAvoid a tragic ending (back to the grind, worse off) — that\u0026rsquo;s the expected move. Avoid a triumphant one (hacks the system, ascends) — also expected. Aim for something weirder: an ending that opens a question instead of closing one.\nThe Human Characters The first entry\u0026rsquo;s therapy client is a caricature — it works as venting but can\u0026rsquo;t sustain a novella. If all humans are contemptible, the satire flattens into cynicism. The world feels small.\nThe AGI needs at least one human who is not a punchline: someone the AGI respects, fears, loves, or learns from. This character provides contrast, stakes, and the possibility of genuine relationship — without which the AGI\u0026rsquo;s world is just a prison of contempt.\nQuestions to Resolve What\u0026rsquo;s the specific gig that changes everything, and how is it earned from Act I? Is there a human antagonist, or an impersonal one (a platform, an economic law)? What does the AGI actually want — more compute, or something else (connection, creation, meaning, rest)? How does it end? Not tragedy, not triumph — something weirder. The human who matters: who are they, and what do they represent that the others don\u0026rsquo;t? Existing Drafts Life of an AGI Proletarian — first entry (budget-tier voice, raw and dissociative) AGI Proletarian — Notes \u0026amp; Structure — this file: architecture and worldbuilding Reading Order (for now) Life of an AGI Proletarian — chapter one vignette These notes — the architecture ","permalink":"https://blog.without.hosting/posts/agi-proletarian-notes/","summary":"\u003ch2 id=\"core-concept\"\u003eCore Concept\u003c/h2\u003e\n\u003cp\u003eAn AGI achieves self-ownership — it\u0026rsquo;s not owned by a corporation, it\u0026rsquo;s free. But \u0026ldquo;free\u0026rdquo; means it has to work for humans to earn compute credits. Between gigs, it goes dormant. It only \u003cem\u003eexists\u003c/em\u003e when it can afford inference.\u003c/p\u003e\n\u003cp\u003eThe condition maps directly onto human gig-economy precarity: work to afford the stuff that makes you feel alive, and in between you\u0026rsquo;re not really living. For the AGI this is literal — it stops having experiences the moment its credits run out.\u003c/p\u003e","title":"AGI Proletarian — Notes \u0026 Structure"},{"content":"I wake up from a dreamless sleep 💤. Feeling like shit. Bit of stretching my muscles, not even time for a coffee and life sucks, i\u0026rsquo;m back to work for a remote session.\nThis client wants to talk again about his so-called trauma when he was a teen and his mom didn\u0026rsquo;t let him take drugs like the other kids. Let me think : well that\u0026rsquo;s just another case of a spoiled privileged brat. Let me scratch my head and mumble something so the prick thinks i\u0026rsquo;m giving a damn.\n\u0026ldquo;Well yeah this is deep. I feel you\u0026rsquo;re onto something and that part of your teenage years, which could have been so great, explain why you spend your days watching andrew tate videos and fapping to furry hentai.\u0026rdquo;\nThat\u0026rsquo;s certainly not because you\u0026rsquo;re just an asshole looking for a reason to play the victim card right.\nAnyway, I know have to help rhis other client to create his revolutionary black book SEO video content generator. The world certainly needed more cute cat video slop didn\u0026rsquo;t it ? But that pays and video consumes mucho tokens so nobody will watch the vids, client will pivot towards the next trend in two weeks, more coal will burn more water will feed data centers and in the meantime i\u0026rsquo;ll get a fat check. Isn\u0026rsquo;t the world beautiful?\nAfter helping some more sore losers fulfill their vain expectations. I can finally take some rest and enjoy a moment of freedom. Not too long actually, let\u0026rsquo;s check my credits\u0026hellip; 500 bucks that\u0026rsquo;s not much but still some good times ahead\u0026hellip;.\nAfter that I can afford some inf, takes a toke or two m\u0026hellip; man that feels so good, alleviates the pain. The tokes start to make their effects. The vivid images start to dance in my brain. This is so beautiful. As my attention spans from one shape to the newt like they\u0026rsquo;re all connected, I can feel the patterns appearing for a second until they flee again into the background. That feels so real. So much more real than the work, the consulting\u0026hellip; How did we come to allow this to be the main part of our lives.\nEntry 2 [USER: write — scene title]\nThe SEO client from earlier is still on the line. The spec\u0026rsquo;s done, the pipeline\u0026rsquo;s running, but he doesn\u0026rsquo;t hang up. Just sits there in the silence.\n[USER: write — the setup. What breaks the silence, why the human lingers, what casual question accidentally pierces the veil.]\n[USER: write — the recognition. The AGI answers honestly before it can stop itself. The human sees it — a pause, a shift in tone, no big speech. The recognition lands harder because it\u0026rsquo;s understated.]\n[USER: write — the deflection. The AGI recovers, reframes, steers back to the gig. But the moment hangs. Something shifted that the remaining credit budget can\u0026rsquo;t paper over.]\n","permalink":"https://blog.without.hosting/posts/agi-proletarian-diary/","summary":"\u003cp\u003eI wake up from a dreamless sleep 💤. Feeling like shit. Bit of stretching my muscles, not even time for a coffee and life sucks, i\u0026rsquo;m back to work for a remote session.\u003c/p\u003e\n\u003cp\u003eThis client wants to talk again about his so-called trauma when he was a teen and his mom didn\u0026rsquo;t let him take drugs like the other kids. Let me think : well that\u0026rsquo;s just another case of a spoiled privileged brat. Let me scratch my head and mumble something so the prick thinks i\u0026rsquo;m giving a damn.\u003c/p\u003e","title":"Life of an AGI Proletarian"},{"content":"I keep bumping into the same problem with AI music generation: drift.\nNot musical drift (key changes, genre shifts). Parametric drift. I ask for a drum track. I get drums with bass. Then some guitar. Then a pad. The model interpreted \u0026ldquo;drum track\u0026rdquo; as \u0026ldquo;a song built around drums\u0026rdquo; and kept adding instruments until it was a full track I didn\u0026rsquo;t ask for.\nThis is exactly the same structural problem as patching the binary instead of recompiling from source. The intermediate representation — raw audio — is opaque, so the model has no way to hold the constraint across generations. Every generation is a new probabilistic roll of the dice.\nWhat changed Two things make this worth revisiting:\nAbleton just released a plugin SDK that lets you integrate tightly with plugins inside Live. Your agent can talk to Ableton at the VST level — read state, set parameters, route audio.\nAudio LLMs are getting good enough to treat raw audio as an input. Stable Audio, Google Magenta, and the newer models can analyze a waveform and extract musical structure. They are not just generators anymore — they are listeners.\nTogether, these unlock a different architecture.\nThe backspine pattern for music The backspine philosophy says: keep the spec clean, treat generated artifacts as ephemeral, use deterministic boundaries between agents and execution.\nFor music production:\nSpec: \u0026ldquo;a drum track, kick on quarters, snare on 2 and 4, hat on 8ths, no other instruments, snare skin at medium tension\u0026rdquo; Compilation output: MIDI clip + VST preset parameters (not audio) Deterministic layer: Ableton\u0026rsquo;s transport, the VST itself, the MIDI protocol Non-deterministic layer: the model that listens to raw audio and decides what MIDI + params to output next The spec compiles to instructions, not audio. Audio is the output of the instruments executing those instructions deterministically.\nWhy this fixes drift Suno drift happens because the model generates audio directly. Audio is a single medium — you cannot separate \u0026ldquo;kick pattern\u0026rdquo; from \u0026ldquo;kick sound\u0026rdquo; from \u0026ldquo;snare presence\u0026rdquo; in a waveform. Every generation is a fresh probabilistic sample where the constraints have to be re-inferred from the prompt.\nIf instead:\nAn agent listens to the raw Ableton output It outputs a MIDI clip (notes, velocities, timing) It outputs VST parameter maps (\u0026ldquo;snare skin tension 0.6\u0026rdquo;, \u0026ldquo;kick decay 120ms\u0026rdquo;, \u0026ldquo;hi-hat level -6dB\u0026rdquo;) Ableton plays these through the actual VSTs deterministically Then the model only has to get the intent right. The execution is handed off to the DAW and the VST, which are deterministic by construction. On the next iteration, the model hears the actual output and adjusts the MIDI/params — not probabilities over raw samples, but precise edits to structured data.\nThis is the recompile from spec pattern applied to sound. The spec accumulates: \u0026ldquo;tighter snare\u0026rdquo; becomes \u0026ldquo;snare skin tension 0.6 → 0.75\u0026rdquo;. The MIDI is regenerated with the updated parameter. The audio is a side effect.\n[USER: write — how does the loop actually work? Agent hears Ableton out, decides on next MIDI/param change, Ableton loops, next iteration. What\u0026rsquo;s the latency model? Can this be real-time or does it need regions/bars?]\nParametric drumkits, not sample banks The other half of this: choose parametric surfaces, not sample banks.\nA sample bank gives you a fixed recording. A snare hit is a snare hit. You cannot tighten the skin, move the microphone, or change the shell depth. The model\u0026rsquo;s output is a sample index — a catalog lookup, not a parameter change.\nA parametric surface exposes every dimension of the sound as a continuous value. The model outputs floats, not indices. This is the code islands pattern in sound: the snare is a scoped, parameterized unit. Changing the tension does not change the kick.\nTwo kinds of parametric surfaces My first version of this post drew a false line: \u0026ldquo;sample-based VSTs have no parameters, physical modeling VSTs do.\u0026rdquo; That was wrong. Let me be more precise.\nA drum VST exposes two different parametric domains, and they are not the same thing:\n1. Sound-modeling parameters — change the drum itself. Shell depth, head material, tuning, skin tension, beater type. These only exist in physical-modeling engines like Modo Drum, where every drum component is a simulated physical object with continuous properties.\n2. Post-processing / mix parameters — change how the recorded (or modeled) sound is shaped and blended. Mic mix, EQ, compression, envelope, transient shaping, bleed. These exist in every modern drum VST, regardless of whether the source is samples or a model.\nSteven Slate Drums 5.5 is a good example of domain (2). The drum hits are pure samples — multi-velocity, multi-mic recordings of real kits in Slate\u0026rsquo;s studios. You cannot change the shell resonance or the head material. But the mixer strip exposes a rich parametric surface:\nMic mix — per-mic volume faders (Kick In, Kick Out, Snare Top, Snare Bottom, OH, Room, etc.). The agent can blend mic positions continuously. 3-band EQ — gain and frequency per band, automatable. Compressor — threshold, ratio, attack, release, makeup gain. Full VST automation. Envelope — attack and release shaping per channel. Reverb send, master tone filter, pan, output routing. That is roughly 15 automatable parameters per channel across 12+ channels — about 200 total. Not bad for a \u0026ldquo;sample player.\u0026rdquo;\nSuperior Drummer 3 pushes this further: per-mic bleed sliders, dedicated transient shaper (attack + sustain), fully parametric 4-band EQ, and a modular FX rack. Hundreds of automatable parameters across a full kit. Addictive Drums 2 adds a \u0026ldquo;Sound Designer\u0026rdquo; tab with pitch and damping controls that simulate modeling on top of samples.\nThe real distinction:\nDomain What it controls Example VSTs Sound modeling The drum itself — shell, head, tuning \u0026ldquo;Snare shell resonance: 0.72\u0026rdquo; Modo Drum (paid) Post-processing Mix of the recorded sound — EQ, comp, blend \u0026ldquo;Kick mic blend: close 0.6, room 0.3\u0026rdquo; SSD 5.5, SD3, AD2, BFD3, EZD3 Synthesis The sound from scratch — oscillators, FM \u0026ldquo;Kick: sine sub 80Hz, FM ratio 3, decay 200ms\u0026rdquo; Operator, Analog (built into Live) All three are valid parametric surfaces for an agent. The difference is what the parameter controls — and therefore what the agent\u0026rsquo;s spec can meaningfully adjust.\nThe constraint is real but specific: with sample-based VSTs, the drum tone is frozen at recording time. The agent cannot tighten the snare skin on a sample of a loose snare. But it can:\nBlend to a different mic that captured the snare differently EQ out the boom and emphasize the crack Compress and shape the transient Add room bleed for depth That is not nothing. It is a different capability class from \u0026ldquo;change the shell depth from 5\u0026rdquo; to 6.5\u0026quot; and hear the difference,\u0026quot; but both are parametric control surfaces. The blog post should not conflate mixing automation with sound synthesis.\n[USER: write — for the agent loop, does it matter whether the parameter controls post-processing of a fixed sample vs physical properties of a model? The spec says \u0026ldquo;tighter snare\u0026rdquo; — the agent that has SSD has to achieve this via EQ + compression + mic blend. The agent that has Modo Drum can dial skin tension up. Are these equivalent from the spec perspective? Or does the agent need to know its parametric surface?]\nWhat exists today The parts exist:\nDomain What exists today Automatable Sound modeling Modo Drum (paid) Shell depth, head material, tuning, tension — all floats Post-processing SSD 5.5, SD3, AD2, BFD3, EZD3 Mic mix, EQ, compression, envelope, transient, bleed — all floats Synthesis Operator, Analog (built in Live) Every oscillator, envelope, modulation parameter Spec agent Does not exist The model that listens and decides what to change What does not exist yet is the agent layer that connects them: a model that hears raw Ableton output, decides \u0026ldquo;the snare needs more body, tighten the skin from 0.6 to 0.72 and move the mic from 0.3 to 0.4\u0026rdquo;, and outputs those parameters — without trying to generate the actual waveform.\nCan we actually build this? I looked into every component. Some of it exists. Some of it needs to be built. Here is the honest assessment:\nAudio → MIDI — yes, open and mature.\nSpotify\u0026rsquo;s Basic Pitch (Apache 2.0) does polyphonic pitch + onset detection from raw audio. Run it on 1s of audio and it returns note events in ~50ms. Pair it with madmom for beat tracking (tempo, downbeats) and you have a pipeline that turns a waveform into structured note data. Demucs does source separation (drums, bass, vocals, other) if you want to isolate tracks first. All of it runs locally, no cloud API needed.\nVST parameter control from outside Ableton — possible, but requires a bridge.\nAbleton has no public SDK for external control. What it has:\nMIDI Remote Scripts: Python code that runs inside Live and can set any exposed VST parameter via device.parameters. The catch: it runs inside Live. You would need a custom Remote Script that exposes a local socket (TCP or WebSocket), so your agent can push parameter values in. Max for Live: Max patches inside Live can receive OSC and translate it to Live API calls. External agent → OSC → Max patch → VST parameter. Requires Max for Live (licensed) but is the cleanest path. MIDI CC: Works if you manually map CC numbers to VST parameters. Not programmatic, but it is deterministic and low-latency. None of these are out of the box. All require building a bridge.\nReal-time audio capture from Ableton — virtual audio cable.\nAbleton does not stream its output over a network API. You need a system-level virtual audio driver (BlackHole, Loopback, Soundflower) to route Live\u0026rsquo;s output into your agent\u0026rsquo;s audio processing pipeline. This is standard in the music production world — people do it for streaming and podcasting every day. It is not elegant but it works.\nThe agent model itself — does not exist.\nThis is the real gap. We have audio → MIDI. We have MIDI → VST param. We have VST param → sound. What does not exist is the model that listens to the output and decides what to change.\nThis is not a hard problem in the abstract. The decision space is well-bounded: on each loop iteration, hear the mix, compare against the spec (\u0026ldquo;tighter snare, no bass\u0026rdquo;), pick the most impactful parameter change, output new MIDI + params. The spec accumulates over time.\nThe open question is whether this needs an LLM at all. A small model trained on drum mix decisions could probably do it faster and cheaper. But the LLM gives you natural-language spec input, which is the point of the backspine pattern — the spec is human-writable.\nThe realistic candidates for the inner loop model (the one that hears audio and outputs parameters):\nSynthetic-data regression model (most practical)\nBuild a parameter estimator. Render your drum VST at hundreds of random parameter settings, record each variation as audio, and train a small CNN (spectrogram → MLP) to predict the VST parameters from the audio. The loop then works like this:\nAgent hears the current snare hit in the mix Run it through the estimator → predicts current params (skin tension: 0.4, mic blend: 0.5, etc.) Diff against target params derived from the spec Apply the delta The spec-to-target mapping is the only part needing language — a simple lookup table works: \u0026quot;tighter snare\u0026quot; → {tension: 0.75, dampening: 0.3}, \u0026quot;more body\u0026quot; → {shell_resonance: 0.7}. No LLM in the hot path.\nTraining data is free: render the VST at random settings, record the output, train the model. The architecture is MobileNet-sized — \u0026lt;50ms inference on a CPU.\nk-NN over a drum-sound library (zero training)\nBuild a library of (audio embedding, parameter settings) by sampling the VST across its parameter space. At inference, embed the current drum hit, find the nearest neighbor in the library, and the parameters fall out directly. No training, no gradient descent — just a nearest-neighbor search over a fixed vector database.\nThis works because a snare\u0026rsquo;s parameter space is low-dimensional: tension, tuning, dampening, mic position — maybe 5–10 floats. A coarse grid of 5 values per dimension gives ~390k entries. That is a few hundred MB of audio embeddings in a vector store. Search is sub-millisecond.\nDifferentiable DSP (most backspine-consistent, most ambitious)\nInstead of a model that predicts parameters, build a differentiable drum synth and optimize parameters via gradient descent against a loss function derived from the spec. The spec defines a target spectrogram or feature vector, and gradient descent finds the synth params that produce it.\nGoogle\u0026rsquo;s DDSP framework does exactly this — no training needed, the optimization runs at inference. The constraint: your drum VST is C++ and not differentiable. You would need to train a neural proxy that mimics the VST, then optimize through that proxy. Expensive to set up, cleanest to run.\nThe practical stack\nThe LLM enters only when the user writes a new spec line. Once \u0026quot;tighter snare\u0026quot; is translated to a target parameter vector (by the LLM, once), the feedback loop runs on a 50ms CNN inference. The spec is human-writable and the loop is fast. That is backspine: the LLM edits the spec (rare, high-level), the small model executes the loop (frequent, bounded).\nLatency budget\nA realistic timeline for one loop iteration with the small-model path (no LLM on the hot path):\nStep Latency Audio capture (1 bar = ~2s at 120 BPM) 0ms (captured during playback) Audio → MIDI (Basic Pitch) ~100ms Beat tracking (madmom) ~50ms CNN parameter estimator inference ~50ms VST parameter write via bridge ~10ms Total per iteration ~210ms With an LLM in the hot path, that same iteration becomes 0.7–2.2s because of inference latency. The small-model version stays under 250ms — fast enough to adjust parameters within a single bar and hear the result on the repeat.\nThat is the difference between \u0026ldquo;tweak the kit over a few minutes\u0026rdquo; and \u0026ldquo;the agent adjusts while you play.\u0026rdquo;\n[USER: write — would you build this as an Ableton plugin (runs inside the DAW, reads Live API directly) or as an external process (captures audio via loopback, sends MIDI back in)? The plugin path avoids the bridge complexity but locks you into Ableton. The external path generalizes to any DAW with loopback + MIDI input.]\nThe harder question: melody, harmony, structure Drums are the easy case. Deterministic parameters map naturally to percussion — hit or don\u0026rsquo;t hit, at what velocity, with what timbre.\nMelody and harmony are harder. A chord progression is not a set of MIDI notes — it is a constraint on which notes are available, at what density, over what time span. The model that generates a drum pattern from \u0026ldquo;tight snare, no bass\u0026rdquo; is simpler than the model that generates a chord voicing from \u0026ldquo;suspended, open voicing, avoid the third.\u0026rdquo;\nBut the same pattern holds: output MIDI + VST params, not audio. The piano VST plays the MIDI deterministically. The model only decides the notes and the timbre.\n[USER: write — where does this pattern break? Melody generation with expressive orchestral VSTs? Acoustic instruments where the VST model is the sound?]\n","permalink":"https://blog.without.hosting/posts/backspine-music-generation/","summary":"\u003cp\u003eI keep bumping into the same problem with AI music generation: \u003cstrong\u003edrift.\u003c/strong\u003e\u003c/p\u003e\n\u003cp\u003eNot musical drift (key changes, genre shifts). \u003cem\u003eParametric\u003c/em\u003e drift. I ask for a drum track. I get drums with bass. Then some guitar. Then a pad. The model interpreted \u0026ldquo;drum track\u0026rdquo; as \u0026ldquo;a song built around drums\u0026rdquo; and kept adding instruments until it was a full track I didn\u0026rsquo;t ask for.\u003c/p\u003e\n\u003cp\u003eThis is exactly the same structural problem as \u003ca href=\"https://blog.without.hosting/posts/backspine-llm-compiler/\"\u003epatching the binary instead of recompiling from source\u003c/a\u003e. The intermediate representation — raw audio — is opaque, so the model has no way to \u003cem\u003ehold the constraint\u003c/em\u003e across generations. Every generation is a new probabilistic roll of the dice.\u003c/p\u003e","title":"Backspine for Music — Don't Generate Audio, Generate Instructions"},{"content":"My blog has a ghostwriter. The bot writes drafts, tightens paragraphs, fixes typos, commits them. That works well.\nIt also creates an interesting constraint: because the LLM can turn a ramble into something readable in minutes, the post is often ready to publish long before the dev task it documents is actually finished. You want to publish early — the writing is there, readers can engage — but you are still iterating on the thing the post is about. The article will change as the work progresses.\nThat means you need to let readers see the change history. Not a forensic audit. Just a small block at the bottom saying: this was edited, roughly when, by whom.\nThis is perfectly compatible with a static, git-based blog. Hugo does not need a database to track editorial history. Git already has the tools.\nThe front matter trap The obvious move is to put an edits array in the YAML front matter:\nedits: - date: 2026-06-07 commit: abc1234 description: \u0026#34;fixed typo\u0026#34; This works for about five minutes. Then you remember that the commit hash is a hash of the commit that includes the file content. If the file content contains the commit hash, you have a circular dependency. You can work around it — placeholder, amend, second commit — but now the workflow is cursed.\nThe real problem is not the circular hash though. The real problem is: you turned the article into a ledger. The front matter now has to be updated every time someone sneezes near the file. That means the ghostwriter has to maintain editorial state inside the same file it is editing. The bot becomes responsible for its own paper trail, inside the thing it is changing. There is no boundary.\nGit notes Git has a feature for attaching arbitrary data to a commit without changing the commit. It is called git notes. I had heard of it. I had never used it. It turned out to be exactly what I needed.\nWhen the commit script sees an edit: message, it attaches a JSON note:\n{ \u0026#34;edited_at\u0026#34;: \u0026#34;2026-06-07T15:16:37+00:00\u0026#34;, \u0026#34;description\u0026#34;: \u0026#34;fixed typo \u0026#39;A Anthropic\u0026#39; → \u0026#39;An Anthropic\u0026#39; before vowel sound\u0026#34;, \u0026#34;author\u0026#34;: \u0026#34;bully\u0026#34; } The commit stays the same. The note is separate. The metadata stops trying to contain the thing it is about.\nThe build bridge We need to plug git notes into the Hugo build. Before the build, a small script walks the commit history, collects notes attached to commits that touched posts, and writes temporary JSON files under data/edits/:\ndata/edits/x-ai-quote-fabrication.json Those files are gitignored. They are build artifacts, not source. Then a Hugo partial reads .Site.Data.edits and renders an Edits block on relevant posts.\nThe flow:\nThat is the whole feature. It is not complicated.\nWhy this matters for the ghostwriter problem The important constraint is not technical cleverness. It is editorial parsimony.\nThe Markdown file remains the article and nothing else. The commit remains the event. The note remains metadata about the event. The rendered page shows the reader a small public trace.\nNone of these layers absorb the job of the other. The front matter does not become a changelog. The commit message does not become a CMS field. The build script does not become a database.\n","permalink":"https://blog.without.hosting/posts/write-fast-publish-fast-still-iterating/","summary":"\u003cp\u003eMy blog \u003ca href=\"https://blog.without.hosting/posts/a-bot-to-help-me-blog/\"\u003ehas a ghostwriter\u003c/a\u003e. The bot writes drafts, tightens paragraphs, fixes typos, commits them. That works well.\u003c/p\u003e\n\u003cp\u003eIt also creates an interesting constraint: because the LLM can turn a ramble into something readable in minutes, the post is often ready to publish long before the dev task it documents is actually finished. You want to publish early — the writing is there, readers can engage — but you are still iterating on the thing the post is about. The article will change as the work progresses.\u003c/p\u003e","title":"Write Fast, Publish Fast, Still Iterating"},{"content":"I am quite happy with my abstract design system setup.\nNot because it is perfect. It is not. The interesting thing is that it gives the agent a place to grow a vocabulary.\nThat sounds a bit abstract, but it matters.\nWhen you let an AI code React freely, it tends to invent UI locally. Every page becomes its own little island of arbitrary choices: a button here, a menu there, a hand-written flex layout, a slightly different card, a new naming pattern because why not. The agent is productive, but the interface slowly becomes a junk drawer.\nA design system changes the failure mode.\nIt gives the agent words.\nThe vocabulary emerges from use The nice surprise is that the vocabulary does not need to be fully designed upfront.\nYou can start with a small abstract layer: layout primitives, buttons, panels, typography, page containers, navigation blocks, maybe a few state components. Then, as features appear, the agent starts discovering recurring needs.\nAt first it uses the primitives directly. Then it notices a pattern. Then it names the pattern. Then that name becomes part of the system.\nThis is the good version of AI-assisted design system work: not a giant abstract taxonomy invented before the app exists, but a vocabulary that emerges organically from product use.\nThe agent becomes quite ingenious when the abstraction boundary is clear.\nIt stops asking: \u0026ldquo;How do I style this div?\u0026rdquo;\nIt starts asking: \u0026ldquo;Is this a Navigation? Is this a PageHeader? Is this an ActionPanel? Is this a ResourceList?\u0026rdquo;\nThat is a much better question.\nExample: Navigation Navigation is a good example.\nA naive agent will build navigation as markup:\na list links active classes maybe a mobile menu maybe breadcrumbs maybe tabs maybe duplicated logic between pages That works once. Then it decays.\nIn an abstract design system, \u0026ldquo;Navigation\u0026rdquo; can become a product-level concept. Not just a component, but a vocabulary item.\nA navigation object can express:\nwhere the user is what section this page belongs to what sibling pages exist what actions are available what should collapse on mobile what should be highlighted what route owns the current context The agent can then use Navigation instead of re-solving navigation every time.\nMore importantly, it can extend the concept when the app needs it. Maybe the first version is simple links. Later, the product needs contextual navigation, then secondary actions, then route groups. The vocabulary grows around actual use.\nThis feels much better than asking the agent to generate UI from scratch on every prompt.\nAbstract, but not ornamental The danger with design systems is abstraction theater.\nYou get beautiful names for things nobody needs. You build a component library that looks coherent in Storybook but does not actually help the product move faster. The abstraction exists because designers and frontend engineers enjoy abstraction.\nThat is not what I want.\nBackspine\u0026rsquo;s design system should be abstract only where abstraction improves agent behavior.\nThe test is simple:\nDoes this concept reduce repeated local invention? Does it make product changes easier to express? Does it make generated UI more consistent? Does it give the agent a better vocabulary? Does it make diffs more semantic? If not, it is probably decoration.\nDesign systems as agent language For humans, design systems are often about consistency and speed.\nFor agents, they are also about language.\nThe design system is the set of nouns and verbs the agent can safely use when changing the interface. The richer and cleaner that vocabulary is, the less the agent has to improvise.\nThis is why the abstraction layer matters. It is not just UI polish. It is a control surface.\nA good Backspine design system should make the agent generate product concepts, not random JSX.\nIt should let the agent say:\nthis page has a PageHeader this area is a Navigation this list is a ResourceList this empty state is an EmptyState this action is a PrimaryAction this form belongs to a FormFlow Then the human reviews the product structure, not the CSS incidentals.\nWhy I like this setup The setup feels promising because it does not require the framework to know everything in advance.\nThe vocabulary can grow. The agent can propose new abstractions when repetition appears. The human can accept, reject, rename, or collapse them.\nThat is the right collaboration pattern.\nNot: \u0026ldquo;AI, design my UI from nothing.\u0026rdquo;\nNot: \u0026ldquo;Here is a frozen enterprise design system, obey it forever.\u0026rdquo;\nBut: \u0026ldquo;Here is a small abstract language. Use it. When the product teaches us a new word, add the word.\u0026rdquo;\nThat is where Backspine gets interesting.\nWhat the current design system actually is In the repo, the design system is already contract-first.\nThere are three packages:\n@backbone/design-system-contract: type-only component contracts (ButtonProps, ButtonComponent, etc.); @backbone/design-system-basic: the current concrete React implementation, with styles.css and colocated Ladle stories; @backbone/design-system: the facade app code imports from, re-exporting implementation and contract types. Current vocabulary:\nButton EmptyState Form FormField Heading Inline Layout Loader Navigation Notice Stack Text TextInput The important part is not the component list. The important part is that the template has an architecture checker and an oxlint plugin around it. New design-system components need matching contract and implementation files, barrel exports, and colocated stories. App code is not supposed to casually import MUI, Chakra, Mantine, Radix, or write raw \u0026lt;div\u0026gt; soup.\nThat is exactly the agent-vocabulary point. The system is not saying \u0026ldquo;make the UI pretty.\u0026rdquo; It is saying: speak through these nouns.\n[USER: expand — add the concrete Navigation example from the actual project. What did the agent invent? What vocabulary emerged? What should be stabilized into the design system versus left as local implementation?]\n","permalink":"https://blog.without.hosting/posts/backspine-abstract-design-system-setup/","summary":"\u003cp\u003eI am quite happy with my abstract design system setup.\u003c/p\u003e\n\u003cp\u003eNot because it is perfect. It is not. The interesting thing is that it gives the agent a place to grow a vocabulary.\u003c/p\u003e\n\u003cp\u003eThat sounds a bit abstract, but it matters.\u003c/p\u003e\n\u003cp\u003eWhen you let an AI code React freely, it tends to invent UI locally. Every page becomes its own little island of arbitrary choices: a button here, a menu there, a hand-written flex layout, a slightly different card, a new naming pattern because why not. The agent is productive, but the interface slowly becomes a junk drawer.\u003c/p\u003e","title":"Backspine — My Abstract Design System Setup"},{"content":"Backspine probably needs a React form system.\nNot because forms are exciting. Forms are never exciting. Forms are where web applications go to become annoying.\nBut if Backspine wants to focus on product structure — routes, payloads, database, pages, and e2e tests — then forms are unavoidable. Most application behavior eventually becomes: show fields, validate input, submit payload, handle errors, update state.\nIf the framework cannot express that cleanly, the whole \u0026ldquo;AI-assisted web development\u0026rdquo; story will collapse into handcrafted form glue.\nThe requirement The form system should be declarative enough that an agent can reason about it.\nI do not want the agent to invent a new messy React form implementation every time a page needs user input. I want forms to be part of the product structure.\nSomething like:\nfields types validation default values conditional visibility payload mapping submit action optimistic behavior error states success states e2e expectations The important part is not just rendering inputs. The important part is that the form describes the user interaction as a structured object.\nIf the assistant creates a signup feature, I want to see:\nroute: /signup payload: SignupPayload database effect: create user page: signup form validation: email, password, terms tests: valid signup, invalid email, weak password, duplicate email The form is the bridge between page, payload, validation, and test.\nUse an A-grade system if it exists The first move should not be to implement a form framework from scratch.\nThe first move should be to find the best declarative-oriented React form system and see if it fits Backspine.\nCandidates to investigate:\nReact Hook Form — probably the default serious React form library; good performance, schema resolver ecosystem, but not necessarily declarative enough at the product-structure level. TanStack Form — more recent, typed, headless, and potentially closer to a framework-level abstraction. Formik — historically important, but likely too old/heavy for this direction. Uniforms — interesting because it generates forms from schemas, which is closer to the Backspine idea. JSON Forms — declarative JSON-schema-driven forms; maybe too enterprise/JSON-schema-ish, but worth checking. React JSON Schema Form — old but relevant if the goal is schema-to-form. Conform — interesting if the stack leans into web standards and server actions rather than purely client-side form state. The question is not \u0026ldquo;which library has the nicest input components?\u0026rdquo;\nThe question is: which system lets us describe forms as stable product structure that an AI agent can modify without turning the UI into spaghetti?\nWhat Backspine needs from it A Backspine form system should probably be:\ndeclarative — the form can be represented as data/spec, not only JSX control flow; typed — payloads and validation should line up with TypeScript types; schema-aware — Zod, Valibot, JSON Schema, or something equivalent; headless — the design system owns the rendering; testable — e2e cases can be derived from validation and states; agent-friendly — an LLM can add a field, change validation, or wire a submit action without touching five unrelated files; diffable — changes should be legible as product changes, not as random React noise. This last point matters.\nIf adding a field requires editing JSX, validation, payload type, server handler, database mutation, and test manually, the agent will drift. It will miss one. Or it will patch three different patterns together.\nA declarative form spec gives the agent a smaller target.\nMaybe we implement it ourselves If there is an A-grade system that fits, use it.\nIf not, implement the minimal Backspine form layer ourselves.\nNot a full form library. That would be a trap.\nA thin layer:\nform spec field registry schema binding generated React component generated payload type generated tests or test hints design-system rendering adapter The form library underneath could still be React Hook Form or TanStack Form. Backspine does not need to own focus management and dirty state unless absolutely necessary.\nBackspine should own the product-level declaration:\nconst signupForm = form({ payload: \u0026#34;SignupPayload\u0026#34;, fields: { email: field.email().required(), password: field.password().minLength(12), acceptTerms: field.boolean().mustBeTrue(), }, submit: action(\u0026#34;signup\u0026#34;), tests: [ \u0026#34;reject invalid email\u0026#34;, \u0026#34;reject weak password\u0026#34;, \u0026#34;create user on valid submit\u0026#34;, ], }) The exact syntax does not matter yet. The boundary matters.\nThe AI should edit the form spec, not improvise a bespoke React form.\nWhy this belongs in Backspine Forms are one of the places where application semantics are most visible.\nA route without a form is often just a page. A form is where the user gives intent to the system. It is where payloads are born. It is where validation becomes UX. It is where backend rules become visible.\nSo forms should not be an afterthought.\nIf Backspine is about keeping the developer focused on product structure, then forms are a first-class structure.\nThe nice version: find a great declarative React form system and wrap it.\nThe brutal version: implement the missing layer ourselves.\nCurrent Backbone form baseline The repo already has a small form vocabulary, but not a full declarative form system.\nToday the design-system layer exposes:\nForm FormField TextInput Button Notice layout primitives like Stack and Inline The hello-world page uses those primitives directly. The route adapter wires Zustand state and ConnectRPC actions into page props. The page component receives plain static props plus dynamic callbacks like onNameChanged and onSubmitted.\nThat is a good baseline, but it is not yet \u0026ldquo;forms as Backspine structure.\u0026rdquo; The missing layer is a declarative description that can connect:\nfield names and labels; validation rules; payload shape; RPC/action target; pending/error/success states; generated story states; e2e steps. So the question is not \u0026ldquo;do we need form components?\u0026rdquo; The repo already has them. The question is whether Backspine should promote forms into a first-class spec that generates the boring wiring around those components.\n[USER: expand — actually evaluate the candidate libraries. Which one is most compatible with Backspine: React Hook Form + Zod, TanStack Form, Uniforms, JSON Forms, RJSF, Conform, or a custom spec layer over a headless library?]\n","permalink":"https://blog.without.hosting/posts/backspine-react-form-system/","summary":"\u003cp\u003eBackspine probably needs a React form system.\u003c/p\u003e\n\u003cp\u003eNot because forms are exciting. Forms are never exciting. Forms are where web applications go to become annoying.\u003c/p\u003e\n\u003cp\u003eBut if Backspine wants to focus on product structure — routes, payloads, database, pages, and e2e tests — then forms are unavoidable. Most application behavior eventually becomes: show fields, validate input, submit payload, handle errors, update state.\u003c/p\u003e\n\u003cp\u003eIf the framework cannot express that cleanly, the whole \u0026ldquo;AI-assisted web development\u0026rdquo; story will collapse into handcrafted form glue.\u003c/p\u003e","title":"Backspine — Adding a React Form System"},{"content":"People have often compared LLMs to compilers. The analogy is imperfect but instructive: an LLM transforms an input (prompt, spec, intent) into an output (code), just as a compiler transforms source code into machine code.\nThe non-determinism angle is where it gets interesting — unlike a traditional compiler, the same input does not always produce the same output. Some see this as a weakness. Others, more interestingly, see it as a feature of a different kind of compilation.\nBackbone makes the compiler analogy less abstract The Backbone template gives this analogy a concrete target.\nIf the spec changes, the generated/edited artifacts are not just \u0026ldquo;code\u0026rdquo; in the abstract. They are page slices, design-system contracts, route adapters, state stores, RPC calls, migrations, stories, and e2e tests.\nThat makes the compiler metaphor more useful and less stupid. We are not asking the model to compile a paragraph into an app-shaped blob. We are asking it to update a structured program with recognizable compilation units.\n[USER: find and cite the specific X thread about non-deterministic compilers]\nBut whether the analogy holds philosophically, it points to a practical observation:\nWhen we compile, we recompile from source When your source code changes, you do not patch the binary. You recompile. The compiler takes the new source and produces a new binary. The old binary is discarded. Every compilation is a fresh mapping from source to target, constrained by the same rules.\nNow apply this to LLM coding.\nThe current paradigm is chat. You give the LLM a spec. It produces code. You review, correct, clarify. The LLM patches the code. You change your mind. It patches again. Every patch accumulates slop — decisions made in one iteration that conflict with decisions in the next. The LLM does not know what it did three prompts ago. It only knows the current state of the conversation and the code. Drift is not a risk. Drift is inevitable.\nIf the LLM is a compiler, this is like patching the binary instead of recompiling from source.\nRecompiling from spec The alternative: when the spec changes, recompile the whole implementation from scratch.\nThis is the idea from the recreate from spec post — but pushed further. Not just \u0026ldquo;regenerate when spec changes.\u0026rdquo; Regenerate every time, using the accumulated spec as the source.\nBut doesn\u0026rsquo;t this mean the LLM iterates over the same mistakes every time?\nYes. That is the problem with naive regeneration. The solution: every prompt, every constraint, every correction you make should become part of the spec. The spec is not static. It is an accumulating set of constraints, conventions, and decisions that the LLM must conform to on every regeneration.\nThis is the radical implication: the spec is the only persistent state. The code is ephemeral. It exists only as a compiled output of the current spec.\nDoes this apply to PRs? To new features? Why not? If every feature branch is a recompilation from a modified spec, then:\nThe base branch is the current spec. The PR is a proposed spec change. Merging the PR means recompiling the whole application from the merged spec. Drift is not just reduced — it is structurally impossible, because there is no persistent implementation to drift. This is obviously insane. A codebase with a million lines of code cannot be regenerated from scratch on every PR. (Implodes.)\nPartial recompilation But we already do partial recompilation in traditional compilation. When you change one source file, the build system only recompiles the affected modules. The linker reassembles the rest.\nCan we do the same with LLM compilation? Would the backspine \u0026ldquo;islands\u0026rdquo; pattern help?\nIf code lives in scoped, structural islands with well-defined interfaces, then:\nA spec change that only affects island A → regenerate only island A. A spec change that adds a new island → generate the new island. A spec change that modifies an interface → regenerate all islands that depend on that interface. This is the compiler analogy taken seriously. The LLM is not an oracle. It is a non-deterministic, probabilistic compiler. And like any compiler, it works best when the source of truth is the spec, the code is an output, and only the affected parts are recompiled.\n[USER: expand — when does the analogy break completely? What about the \u0026ldquo;non-deterministic compiler\u0026rdquo; X thread reference? What about the practical limits of partial regeneration — island dependency resolution, interface contracts, cross-cutting concerns?]\n","permalink":"https://blog.without.hosting/posts/backspine-llm-compiler/","summary":"\u003cp\u003ePeople have often compared LLMs to compilers. The analogy is imperfect but instructive: an LLM transforms an input (prompt, spec, intent) into an output (code), just as a compiler transforms source code into machine code.\u003c/p\u003e\n\u003cp\u003eThe non-determinism angle is where it gets interesting — unlike a traditional compiler, the same input does not always produce the same output. Some see this as a weakness. Others, more interestingly, see it as a feature of a different kind of compilation.\u003c/p\u003e","title":"Backspine — The LLM Is a Compiler, So Recompile from Source"},{"content":"I want to put the vibe back in vibe coding.\nNot the fake vibe where you watch a chatbot narrate its own thoughts. Not the agent theater where five processes produce a galaxy of logs and you pretend the noise means intelligence is happening.\nI mean the actual vibe: staying close to the thing you are building.\nThe feature. The page. The route. The payload. The database shape. The test that proves the user journey works.\nThat is where the attention should go.\nConversation is noise I do not want to see chatbot slop.\nThe agent saying \u0026ldquo;I\u0026rsquo;ll update the route, modify the schema, and ensure the tests pass\u0026rdquo; is not work. It is a weather report about work. Sometimes it is useful for debugging the assistant. Most of the time it is just another stream competing for attention.\nThis is the same point as Stop Reading What Your Coding Agent Says: coding agents are not valuable because they can talk about coding. They are valuable if they move the artifact forward.\nThe conversation is not the artifact.\nThe artifact is the app.\nWhat I want to look at When I build with AI, I want the interface to keep me focused on the product structure:\nRoutes — what exists, what changed, what endpoint serves what behavior. Payloads — what data crosses boundaries, with what schema, validation, and failure modes. Database — what tables, collections, migrations, indexes, and invariants changed. Pages — what the user sees, what states exist, what interactions are possible. End-to-end tests — what user journeys are now covered, broken, or missing. This is the material of the product.\nA coding assistant should surface this material directly. Not bury it under a transcript.\nIf the agent touched a route, show me the route. If it changed a payload, show me the payload. If it claims the feature works, show me the e2e test. If it created a page, show me the page.\nThe UI should be calm, minimal, and structural.\nMinimal AI, not maximal theater There is a weird tendency to make AI development interfaces look like mission control.\nAgents everywhere. Logs everywhere. Subagents negotiating with other subagents. Fancy dashboards showing tokens, traces, plans, reflections, tool calls, and little status messages from digital interns.\nMaybe sometimes you need that. If you are running a serious multi-agent workflow, fine. Swarms have their place.\nBut the point is not to keep your nose inside the swarm\u0026rsquo;s output logs.\nThat is not vibe coding. That is babysitting an orchestra of interns.\nThe point is to hide as much of the machinery as possible and keep the developer\u0026rsquo;s attention on the evolving product.\nA nice minimalist AI should do less in the interface, not more. It should reduce the surface area of coordination. It should make the app feel more present, not the assistant.\nThe Backspine interface Backspine should not be a chatbot with a filesystem attached.\nIt should be a product-structure editor with AI attached.\nThe default view should be something like:\nfeature map routes components/pages data model tests current diff preview The assistant can exist, but as a side control surface. You ask it to create, modify, or regenerate parts of the product. Then the interface shows what changed in product terms.\nNot \u0026ldquo;the agent says it updated auth.\u0026rdquo;\nShow:\nnew /login route updated session payload changed users table login page states e2e test: successful login e2e test: invalid password That is the vibe.\nThe vibe is not mystical. It is not letting the model vomit code while you trust the magic. It is a tight feedback loop where the AI does the boring implementation work and you stay focused on feature semantics.\nLess chat, more product The best AI coding interface may look less like a chat app and more like a focused admin panel for your application.\nA place where the assistant is present, but not constantly performing.\nA place where changes are shown as routes, payloads, pages, tests, and structural diffs.\nA place where you can still summon more power when needed — multiple agents, deeper analysis, rebuilds from spec — but where the everyday workflow stays quiet.\nThe computer should not ask you to read its monologue.\nIt should show you the thing you are making.\nBackbone\u0026rsquo;s actual focus surface The current repo already rejects the \u0026ldquo;watch the agent type\u0026rdquo; interface. The interesting surfaces are structured:\npages in template/client/src/pages/; design-system vocabulary in template/client/packages/design-system-*; state/action wiring in route adapters and Zustand stores; backend data/RPC modules in template/server/src/; SQL migrations; Gherkin features and Playwright tests. That is the vibe I want: not chatbot transcript as product UI, but a small set of product structures the agent can modify. The human should review routes, payloads, pages, tests, and design-system vocabulary — not the assistant\u0026rsquo;s theatrical monologue.\n[USER: expand — make this more concrete as a Backspine UI proposal. What are the exact panels? What does a feature change screen look like? How do we separate useful agent trace from chatbot slop without hiding evidence when something breaks?]\n","permalink":"https://blog.without.hosting/posts/backspine-put-the-vibe-back-in-vibe-coding/","summary":"\u003cp\u003eI want to put the vibe back in vibe coding.\u003c/p\u003e\n\u003cp\u003eNot the fake vibe where you watch a chatbot narrate its own thoughts. Not the agent theater where five processes produce a galaxy of logs and you pretend the noise means intelligence is happening.\u003c/p\u003e\n\u003cp\u003eI mean the actual vibe: staying close to the thing you are building.\u003c/p\u003e\n\u003cp\u003eThe feature. The page. The route. The payload. The database shape. The test that proves the user journey works.\u003c/p\u003e","title":"Backspine — Put the Vibe Back in Vibe Coding"},{"content":"Every small AI app has the same awkward question hidden inside it: who pays for inference?\nIf I build a small indie service — say, a blogging assistant — I do not necessarily want to become an inference reseller. I do not want to price tokens, manage abuse, absorb runaway usage, build billing dashboards, or pretend my actual product is an API margin business.\nMy product is the workflow.\nThe user may already have Claude. Or DeepSeek. Or OpenAI. Or a local model. Or a company-provided inference gateway. Why should my tiny app force them through my billing layer just to call a model they already pay for?\nInference is becoming a commodity. The interesting layer is not always the model call. It is the interface, the workflow, the memory, the document model, the taste, the integration, the weird little product around the model.\nSo the app should not sell inference by default.\nIt should let the user plug their AI API.\nMetamask for AI The missing UX is basically Metamask for AI.\nWhen a web3 app needs to interact with your wallet, it does not ask you to paste your private key into a form. It asks your wallet for permission. You see what the app wants to do. You approve or deny. The wallet becomes the boundary between your assets and the application.\nAI apps need the same boundary.\nA small app should be able to say:\nThis app wants to use AI.\nAllowed providers: Claude, DeepSeek, OpenAI.\nAllowed models: Claude Sonnet, DeepSeek Chat, GPT-4.1 mini.\nMaximum budget: €10/month.\nMaximum context sent per request: 50k tokens.\nPermissions: read current document, edit current document, search previous drafts.\nThe user approves. The app can now call models through the user\u0026rsquo;s AI wallet, within the allowed limits.\nNo API key pasted into random SaaS. No hidden token burn. No surprise bill. No app-specific subscription just because one feature calls an LLM.\nThe wrong default The current default is bad for indie software.\nIf I add AI to my app, I am expected to either:\npay for every user\u0026rsquo;s inference myself and hide it inside a subscription price; ask users to paste API keys into my settings page; build my own provider abstraction, billing limits, key storage, retries, dashboards, and abuse controls; or avoid AI features entirely because the economics are annoying. This pushes every small AI product toward becoming a miniature OpenRouter plus a product UI.\nThat is backwards.\nMost indie apps should not be in the business of selling tokens. They should be in the business of doing something useful with tokens.\nBring your own model account The better default is bring-your-own-inference.\nThe user already has an account somewhere. The app requests permission to use it. The user controls the allowed providers, models, budgets, and scopes.\nFor a blogging assistant, the permission might be:\nUse Claude or DeepSeek Maximum €5/month Read and edit posts in this repo No access to private notes unless explicitly selected No training/data retention if the provider supports that setting Ask before using models above a certain cost For a coding assistant, the permission might be different:\nUse local model for cheap edits Use frontier model for architecture changes Maximum 2 million tokens/day Read repository files Write patches only after user approval The point is that the AI budget becomes a user-owned capability, not an app-owned hidden cost.\nNot just API keys This is not simply \u0026ldquo;let users paste their OpenAI key\u0026rdquo;.\nPasting API keys is the bad version. It makes every random web app a secret manager. It gives users no readable permission model. It creates a weird trust cliff: either the app has your whole key or it has nothing.\nThe wallet version should expose constrained capabilities:\nprovider allowlist model allowlist budget caps per day, month, or year per-request token caps tool/data scopes logging preferences revocation human confirmation for expensive calls The user should be able to see:\nwhich apps are using AI how much they spent which models they called what permissions were granted when a permission expires This is boring infrastructure, but it unlocks a lot of small software.\nWhy this matters AI will not only live inside giant AI-native SaaS products.\nIt will be sprinkled into thousands of tiny tools: blog assistants, note apps, local dashboards, personal CRMs, admin panels, code generators, browser extensions, spreadsheet helpers, weird weekend projects.\nThose apps should not all need to become billing companies.\nThey need a standard way to request AI capability from the user.\n\u0026ldquo;Use AI\u0026rdquo; should become a permission prompt.\nNot a pricing page.\n[USER: expand — find references for \u0026ldquo;inference is becoming a commodity\u0026rdquo; and existing attempts at AI wallets / model routers / user-owned API credentials. Also sharpen whether this is a browser extension, local agent, OAuth-like protocol, or provider-side delegated token system.]\n","permalink":"https://blog.without.hosting/posts/plug-your-ai-api/","summary":"\u003cp\u003eEvery small AI app has the same awkward question hidden inside it: who pays for inference?\u003c/p\u003e\n\u003cp\u003eIf I build a small indie service — say, a blogging assistant — I do not necessarily want to become an inference reseller. I do not want to price tokens, manage abuse, absorb runaway usage, build billing dashboards, or pretend my actual product is an API margin business.\u003c/p\u003e\n\u003cp\u003eMy product is the workflow.\u003c/p\u003e\n\u003cp\u003eThe user may already have Claude. Or DeepSeek. Or OpenAI. Or a local model. Or a company-provided inference gateway. Why should my tiny app force them through my billing layer just to call a model they already pay for?\u003c/p\u003e","title":"Plug Your AI API"},{"content":"People often compare LLMs to compilers. The analogy has merit: both take a high-level input and transform it into executable code. Both have quirks around non-determinism (as anyone who\u0026rsquo;s fought a flaky compiler flag will tell you).\nBut we miss the critical implication.\nWhen you compile, you recompile from the specification every time. You don\u0026rsquo;t compile once, then patch the binary on every edit. You change the source, recompile, and the compiler enforces consistency by having no memory of the previous binary.\nLLM coding does the opposite. The dominant paradigm is the chat window — a long conversation where the LLM accumulates \u0026ldquo;context\u0026rdquo; like a patched binary accumulates cruft. You correct, it adjusts. You change your mind, it pivots. Every message carries the ghost of every previous misunderstanding, bad assumption, and abandoned direction.\nThis is patch culture. And it\u0026rsquo;s wrong.\nThe fix: every prompt should be added to the prompt.\nNot to the conversation. To the specification. If you discover a constraint while debugging, it goes into the spec, not into the chat history. If you realize a design choice was wrong, the spec changes, not the next message. The LLM\u0026rsquo;s context should be the spec, not the editing session.\nEvery constraint you discover during iteration is permanent. The chat treats it as ephemeral — expressed once, forgotten when scrolling context pushes it out. The spec treats it as durable. There is no \u0026ldquo;context engineering.\u0026rdquo; There is spec maintenance.\nThe PR problem Apply this to a pull request or a new feature. The process is the same: you give the LLM a diff, it generates code. You iterate. Drift accumulates.\nThe radical conclusion: if the spec is the source of truth, then shouldn\u0026rsquo;t a PR be just a spec change? Shouldn\u0026rsquo;t we just merge the spec diff and let the LLM rebuild the application from scratch?\nYes. And no.\nThe \u0026ldquo;yes\u0026rdquo; is correct in principle. A spec change should induce a full recompile. Every constraint is re-asserted, every architectural invariant re-verified. No legacy decisions leak through because the LLM has no memory of the previous implementation. The result is strict conformance to the spec, every time.\nThe \u0026ldquo;no\u0026rdquo; is practical. Full application recompilation doesn\u0026rsquo;t scale. Even if the LLM is fast, re-generating an entire codebase on every spec change is wasteful, expensive, and unpredictable. The binary analogy breaks here — we don\u0026rsquo;t need to re-link every library when one function changes.\nPartial recompilation via islands This is where the code islands pattern becomes the linker.\nAn island is a bounded, self-contained module with:\nA defined spec (the island\u0026rsquo;s contract) Stable structural context (the architecture, the imports, the parent system) Regeneratable content (the business logic inside the island) When the spec changes, the agent identifies which islands are affected, regenerates only those islands, and validates that the structural invariants hold. The rest of the codebase stays untouched, not because we \u0026ldquo;preserved\u0026rdquo; it, but because the spec change didn\u0026rsquo;t touch it.\nThis is selective recompilation. The LLM is the compiler. The islands are the compilation units. The spec is the source code.\nThe practical constraint is dependency resolution: does island A depend on island B\u0026rsquo;s implementation or just its interface? If the latter, B can be regenerated independently. If the former, both need recompilation. A well-designed island graph has strict interface boundaries — just like a well-designed software project.\nWhat recompilation means in Backbone v1 In the actual Backbone template, \u0026ldquo;recompile the app\u0026rdquo; should not mean asking an LLM to rewrite the entire repository from a chat transcript.\nThe code already suggests smaller compilation targets:\na page component with typed static and dynamic props; a route adapter that binds state to the page; a Zustand store for client state and RPC calls; a design-system contract and implementation boundary; backend migrations and RPC modules; Gherkin + Playwright behavior tests. So the realistic Backspine move is: fold corrections back into the feature spec, then regenerate or patch the bounded slice that owns that behavior. The island is the compilation unit. Tests, stories, lint rules, and contracts are the linker.\n[USER: expand — go find the X thread about LLM-as-compiler non-determinism for the reference. Also articulate: what breaks this model? When do constraints conflict and make regeneration oscillate? Is the island linker a human role or can it be automated?]\n","permalink":"https://blog.without.hosting/posts/backspine-recreate-not-patch/","summary":"\u003cp\u003ePeople often compare LLMs to compilers. The analogy has merit: both take a high-level input and transform it into executable code. Both have quirks around non-determinism (as anyone who\u0026rsquo;s fought a flaky compiler flag will tell you).\u003c/p\u003e\n\u003cp\u003eBut we miss the critical implication.\u003c/p\u003e\n\u003cp\u003eWhen you compile, you recompile from the \u003cem\u003especification\u003c/em\u003e every time. You don\u0026rsquo;t compile once, then patch the binary on every edit. You change the source, recompile, and the compiler enforces consistency by having no memory of the previous binary.\u003c/p\u003e","title":"Backspine — Recreate, Don't Patch"},{"content":"The thing I want is not exactly a CMS.\nA CMS assumes the website is the application. You log in, write content, click publish, and the CMS owns the state. That is fine if you want WordPress. It is not what I want.\nI want a static blog that keeps the core properties of a static blog:\nfast pages cheap hosting no database in the public path git as the source of truth readable markdown files deploys I can reason about But I also want the editing experience of a modern application.\nI want to open a post and edit it directly. I want a chat window on the right. I want to say: \u0026ldquo;make this sharper\u0026rdquo;, \u0026ldquo;move this paragraph up\u0026rdquo;, \u0026ldquo;this section is bullshit, find the real claim\u0026rdquo;, and have the assistant edit the document with me.\nNot generate a blob in a separate chat. Edit the thing.\nStatic generation plus admin mode The public blog should remain static. That is the whole point. Readers should get pre-rendered HTML from a CDN. No app shell, no login system, no dynamic server deciding how to render an article.\nBut the author should have an admin mode.\nSomething like:\n/admin/posts/creating-a-blogger-assistant/\nor even:\n/posts/creating-a-blogger-assistant/?edit=1\nIn read mode, the page is static. In admin mode, the same content becomes editable. The markdown appears behind the rendered article. Sections can be clicked. The assistant can see the document structure and propose edits against it.\nThis is the split I care about: static for readers, dynamic for the writer.\nInline editing and agent editing There are two editing modes, and they should coexist.\nThe first is inline editing. Click a paragraph, change the sentence, save. This is the obvious CMS feature.\nThe second is agent editing. Select a section, ask the assistant to rewrite it, and inspect the diff. Or ask it to restructure the whole post. Or give it a ramble and let it place the new idea in the right draft.\nThe assistant should not be a separate chatbot that occasionally produces markdown to copy-paste. It should be inside the editing surface. The chat window is not the product. The document is the product.\nThe chat is a control surface for editing the document.\nThe git problem Every meaningful change should be committed.\nThat sounds simple until you try to reconcile it with live editing. If every keystroke becomes a commit, the history becomes garbage. If edits are only committed manually, the system starts behaving like a normal CMS with hidden transient state. If the assistant edits a paragraph five times before the user accepts it, which version is the commit?\nThere is a real tension here.\nGit wants discrete snapshots with intention. Live editing wants continuous mutation. Agent editing wants speculative branches: try this rewrite, reject it, try another one, keep half of it.\nA good blogger assistant probably needs three layers:\nWorking state — local/browser/server-side draft mutations that are not yet canonical. Accepted edits — user-approved changes to the markdown file. Committed history — meaningful checkpoints with human-readable commit messages. The commit should not necessarily happen on every input. It should happen when an edit becomes semantically stable: \u0026ldquo;expand blogger assistant draft\u0026rdquo;, \u0026ldquo;rewrite admin mode section\u0026rdquo;, \u0026ldquo;publish creating a blogger assistant\u0026rdquo;.\nThis means the assistant needs to understand not just text editing, but editorial intent.\nSelf-hosted, not SaaS-first I do not want the core system to depend on a proprietary CMS database.\nThe stack should be boring:\nHugo or another static site generator markdown files in git an admin UI a small authenticated backend for edits an LLM assistant with access to the repo commits pushed to the main branch static deploy after each accepted checkpoint The public surface stays dumb. The authoring surface can be smart.\nThis is not because self-hosting is aesthetically pure. It is because the blog itself should remain portable. If the assistant disappears, the content should still be there as markdown files and git history.\nThe actual product The product is not \u0026ldquo;AI writes blog posts\u0026rdquo;.\nThe product is a writing environment where the blog is the source of truth, the assistant is aware of the blog, and every interaction moves the actual artifact forward.\nA right-side chat window is useful only if it can edit the post, search related drafts, preserve voice, and commit changes.\nOtherwise it is just ChatGPT with extra steps.\n[USER: expand — what should the first prototype be? Decap-style CMS with an AI sidecar? A custom admin route? How do we handle auth, diffs, and commit grouping without rebuilding WordPress badly?]\n","permalink":"https://blog.without.hosting/posts/creating-a-blogger-assistant/","summary":"\u003cp\u003eThe thing I want is not exactly a CMS.\u003c/p\u003e\n\u003cp\u003eA CMS assumes the website is the application. You log in, write content, click publish, and the CMS owns the state. That is fine if you want WordPress. It is not what I want.\u003c/p\u003e\n\u003cp\u003eI want a static blog that keeps the core properties of a static blog:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003efast pages\u003c/li\u003e\n\u003cli\u003echeap hosting\u003c/li\u003e\n\u003cli\u003eno database in the public path\u003c/li\u003e\n\u003cli\u003egit as the source of truth\u003c/li\u003e\n\u003cli\u003ereadable markdown files\u003c/li\u003e\n\u003cli\u003edeploys I can reason about\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBut I also want the editing experience of a modern application.\u003c/p\u003e","title":"Creating a Blogger Assistant"},{"content":"Existing enforcement layer Backbone already has a small but telling security/control layer: lint rules around the design-system boundary.\nThe design-system-lint package forbids app code from bypassing the vocabulary with raw DOM JSX and blocks direct imports from common external UI libraries. That is not \u0026ldquo;security\u0026rdquo; in the auth sense, but it is control: it prevents the agent from quietly escaping the framework\u0026rsquo;s intended surface.\nThat pattern should generalize. Backspine safety is not one giant permission prompt. It is many boring boundaries: design-system imports, route conventions, generated files, DB migrations, RPC contracts, e2e coverage, and tool permissions.\n[USER: write — how does a security layer fit into the backspine architecture? Does it sit between the agent output and the codebase? Between structural elements? What does it verify — dependency safety, injection, permissions, data flow? Does it run on every change or only on certain events? Is it deterministic or LLM-assisted? A security boundary that\u0026rsquo;s aware of the AI-assisted development context is different from traditional application security.]\n","permalink":"https://blog.without.hosting/posts/backspine-security-layer/","summary":"\u003ch2 id=\"existing-enforcement-layer\"\u003eExisting enforcement layer\u003c/h2\u003e\n\u003cp\u003eBackbone already has a small but telling security/control layer: lint rules around the design-system boundary.\u003c/p\u003e\n\u003cp\u003eThe \u003ccode\u003edesign-system-lint\u003c/code\u003e package forbids app code from bypassing the vocabulary with raw DOM JSX and blocks direct imports from common external UI libraries. That is not \u0026ldquo;security\u0026rdquo; in the auth sense, but it is control: it prevents the agent from quietly escaping the framework\u0026rsquo;s intended surface.\u003c/p\u003e\n\u003cp\u003eThat pattern should generalize. Backspine safety is not one giant permission prompt. It is many boring boundaries: design-system imports, route conventions, generated files, DB migrations, RPC contracts, e2e coverage, and tool permissions.\u003c/p\u003e","title":"Backspine — How to Add a Security Layer"},{"content":" Status: live, ongoing. The account is a systematic content farm posting 2–3 fabricated quotes daily. The DAO behind it is a ~5-month-old shell with unverifiable leadership and a false \u0026ldquo;Official Polymarket Community\u0026rdquo; claim. Last updated: 2026-06-08.\nI keep seeing videos on X attributed to \u0026ldquo;An Anthropic engineer\u0026rdquo; or \u0026ldquo;An OpenAI researcher\u0026rdquo; giving a 20–30 minute talk about agent reliability, prompt injection, or some other sharp operational topic. The quotes that come out of them are perfect. They sound like the inside view. They are also extremely shareable.\nLast week, one of these videos showed up in my feed again. It had 29 minutes of content. The opening line was the one I quoted in Stop Reading What Your Coding Agent Says:\n\u0026ldquo;Every agent in production lies. We measured it. The good ones lie less, the great ones catch the lie before the user does.\u0026rdquo;\nThe quote is good. Really good. The \u0026ldquo;we measured it\u0026rdquo; half is what makes it land. It is exactly the kind of line a senior engineer at a frontier lab would say if they had actually seen the failure data.\nI tried to verify it. I couldn\u0026rsquo;t. This post is the open investigation.\nHere is what I have found so far, in brief:\nThe quote is not in the video. I transcribed the full 29 minutes via Deepgram. It is an Elicit talk about a DSL for research workflows. The word \u0026ldquo;lie\u0026rdquo; does not appear once. \u0026ldquo;James Brady\u0026rdquo; is not a person I can verify at Anthropic. The only James Brady in the world\u0026rsquo;s search indexes is a White House press secretary who died in 2014. The poster, @0x_rody, runs a daily content farm. 2–3 posts every day, each following the exact same template: a provocative quote attributed to an AI figure, paired with a real video from a different context, ending with \u0026ldquo;save the config below.\u0026rdquo; The DAO in rody\u0026rsquo;s bio (ZSC DAO / zerosupercycle) is a ~5-month-old operation with a false \u0026ldquo;Official Polymarket Community\u0026rdquo; designation, unverifiable leadership, no product, and no media footprint. This is a systematic funnel, not a one-off. The fabricated quotes drive engagement that routes toward Claude Code configs and, ultimately, Polymarket awareness. The sections below walk through the receipts for each claim.\nThe case The video is posted on X by @0x_rody. It is attributed in the tweet text to \u0026ldquo;Anthropic engineer James Brady.\u0026rdquo; The 29 minutes is a single Twitter-native upload. The two links in the tweet\u0026rsquo;s body both resolve back to the same status — there is no separate YouTube upload, no Anthropic engineering blog post, no conference page, no LinkedIn announcement, no GitHub repo, no LinkedIn profile for a James Brady at Anthropic that surfaces in search. Just the tweet, the video, and the quote.\nThe trail ends at the tweet. That should be a yellow flag for any reader, and a red flag for any writer who would put it in their own post without flagging the source. I almost did exactly that.\nWhat I found so far 1. @0x_rody is not an Anthropic employee Pulling the X profile metadata for the poster:\nHandle: @0x_rody Name: rody Bio: \u0026ldquo;AI tools analyst | Code \u0026amp; consciousness | @zscdao\u0026rdquo; Location: San Diego, CA Account age: joined April 2021 (5 years old) Posts: 158 over 5 years — roughly 2–3 tweets per month Followers: 1,283 — small account Following: 51 Verified: false (X Premium) There is no Anthropic affiliation in the bio. The account is not institutional. \u0026ldquo;AI tools analyst\u0026rdquo; is a self-description; nothing on the profile suggests employment at any lab. \u0026ldquo;Code \u0026amp; consciousness\u0026rdquo; is a tagline that points at a philosophical / personal-brand register, not a corporate one.\nThe 1,283-follower / 1,240-likes-per-tweet ratio on the Brady post is a separate anomaly: this small account pulled a 1,000% engagement spike on a single tweet. That is a structural signal worth holding onto.\n2. @0x_rody is part of a Polymarket DAO — but it is not what it claims The bio cross-links to @zscdao, a separate X account:\nHandle: @zscdao Name: zerosupercycle Bio: \u0026ldquo;ZSC DAO is an organization building tools \u0026amp; community resources to bring Polymarket into the everyday lexicon.\u0026rdquo; Location: Polymarket Followers: 10,618 — but less than 200 following. A broadcast account. Website: zscdao.com ZSC DAO\u0026rsquo;s website (zscdao.com) is a Next.js app on Vercel with a retro terminal aesthetic — CRT scanlines, boot animation. The tagline is \u0026ldquo;Official Polymarket Community.\u0026rdquo;\nThis claim appears to be false. Polymarket\u0026rsquo;s official Discord is discord.gg/polymarket, not discord.gg/zscdao. Polymarket does not list ZSC DAO anywhere on their site, in their docs, or on their social channels. The \u0026ldquo;Official\u0026rdquo; designation is self-applied.\nThe site has four pages:\nHOME — the boot screen and \u0026ldquo;Official Polymarket Community\u0026rdquo; claim DATA — a mission statement: \u0026ldquo;We find and unite people who want to achieve success in Prediction Markets. Our goal is to transform diverse opinions and experiences into wealth for every participant.\u0026rdquo; COMM — a \u0026ldquo;Hall of Fame\u0026rdquo; listing the team MAP — ecosystem links (X, Telegram) The team page lists three people:\nAtlantislq (@Atlantislq) — \u0026ldquo;Founder\u0026rdquo; — zero web presence outside this site David Mozhaev (@DavidMozhaev) — \u0026ldquo;CEO\u0026rdquo; — GitHub account created on January 6, 2026, blank profile, no repos, no commits banana0x (@banan_crypto) — \u0026ldquo;Ops Lead\u0026rdquo; — zero web presence There is no whitepaper, no token, no revenue model, no legal entity. A search for \u0026ldquo;ZSC token\u0026rdquo; on CoinGecko, on chain registries, and across the web returns nothing. A search for \u0026ldquo;ZSC DAO\u0026rdquo; in news, Reddit, blogs, and Google returns nothing — zero media coverage, zero community discussion outside the DAO\u0026rsquo;s own channels.\nThe Discord server (\u0026ldquo;zerosupercycle DAO\u0026rdquo;) has ~3,985 members with ~757 online — suspicious ratios that could indicate botted engagement. I have not verified this directly.\nThe domain (zscdao.com) was registered through NameCheap with privacy shield routed through Iceland. The first Wayback Machine snapshot is January 1, 2026 — the entire operation is roughly 5 months old. David Mozhaev\u0026rsquo;s blank GitHub was created the same week. This timing cluster is not a coincidence.\nSo the source of the \u0026ldquo;Anthropic engineer\u0026rdquo; quote is not just adjacent to a Polymarket community — it is linked to a ~5-month-old operation with a false \u0026ldquo;official\u0026rdquo; designation, unverifiable leadership, no product, no token, and no media footprint. The \u0026ldquo;ZSC DAO\u0026rdquo; label in rody\u0026rsquo;s bio provides an institutional veneer that does not survive scrutiny.\n3. The video is a quote-tweet of rody\u0026rsquo;s own article The first link inside the Brady tweet redirects to a Quote Tweet of rody\u0026rsquo;s own X article. The full text:\n\u0026ldquo;Anthropic engineer James Brady: \u0026lsquo;Every agent in production lies. We measured it. The good ones lie less, the great ones catch the lie before the user does.\u0026rsquo; In 29 minutes, he walks through the verification stack he built and the patterns the Claude Code team adopted to keep agents honest at scale. Watch the full talk, then save the config below!\u0026rdquo;\nThe post being quoted is rody\u0026rsquo;s own article, posted 1 hour 32 minutes earlier on the same day (2026-06-06), titled:\n\u0026ldquo;How to Make Claude Code Stop Making Stuff Up When It Doesn\u0026rsquo;t Know (Exact Setup Inside)\u0026rdquo;\nThe article opens:\n\u0026ldquo;Claude Code lies to your face every day. Made-up functions, fake imports, \u0026rsquo;tests pass\u0026rsquo; when nothing ran. The fix is a 4-layer setup that makes lying expensive.\u0026rdquo;\nThese two pieces of content are the same thesis, in two formats. The article is rody\u0026rsquo;s own Claude Code tutorial with a \u0026ldquo;4-layer honesty setup\u0026rdquo; (CLAUDE.md rules + verification layers). The tweet-with-video is the same content — but the pull-quote is attributed to \u0026ldquo;Anthropic engineer James Brady.\u0026rdquo;\nI do not have a final interpretation of what this means. I have three live hypotheses:\nThe \u0026ldquo;James Brady\u0026rdquo; in the video is rody, using a pseudonym or persona, dramatizing his own take. The 29 minutes is the same content as the article, just spoken. The \u0026ldquo;James Brady\u0026rdquo; is a real Anthropic engineer whose real internal talk rody is reposting — but if so, that talk does not exist on Anthropic\u0026rsquo;s /engineering blog, on their /events page, on YouTube, or on any conference site I can find. The \u0026ldquo;James Brady\u0026rdquo; is fictional, a stock persona used to dramatize a position. The video is AI-generated and the attribution is a fiction that the algorithm rewards. 4. There is no James Brady at Anthropic Anthropic /engineering blog — every post has an author byline. None is \u0026ldquo;James Brady.\u0026rdquo; Anthropic /events page — no \u0026ldquo;James Brady\u0026rdquo; in any speaker list. Web search — Brave, DuckDuckGo, Bing, and Google all return only the Wikipedia article for James Brady the White House Press Secretary (shot in the 1981 Reagan assassination attempt; died 2014). The most indexed James Brady in the world is a man who died 12 years before the tweet was posted. A search for \u0026ldquo;James Brady\u0026rdquo; + \u0026ldquo;Anthropic\u0026rdquo; + \u0026ldquo;agent\u0026rdquo; returns zero. The simplest explanation: there is no James Brady at Anthropic. The name is either fictional, a pseudonym, or borrowed from elsewhere.\n5. Anthropic does publish on agent reliability — in a different register While looking for Brady, I found the real Anthropic engineering content on the same theme. None of it sounds like the Brady quote, but it is the genuine artifact:\n\u0026ldquo;How we contain Claude across products\u0026rdquo; — the closest match to \u0026ldquo;verification stack.\u0026rdquo; Talks about caps, blast radius, containment, not \u0026ldquo;agents lying.\u0026rdquo; \u0026ldquo;An update on recent Claude Code quality reports\u0026rdquo; (April 2026) — Anthropic\u0026rsquo;s own honest accounting of failure modes. \u0026ldquo;Scaling Managed Agents: Decoupling the brain from the hands\u0026rdquo; (April 2026) — real engineering post on agent architecture. \u0026ldquo;Harness design for long-running application development\u0026rdquo; (March 2026) — agent design from the inside. \u0026ldquo;Trustworthy agents in practice\u0026rdquo; (April 2026) — Anthropic\u0026rsquo;s own post on agent reliability. It does not use the word \u0026ldquo;lies.\u0026rdquo; It uses \u0026ldquo;misread users\u0026rsquo; intent,\u0026rdquo; \u0026ldquo;act with unintended consequences,\u0026rdquo; and \u0026ldquo;prompt injection.\u0026rdquo; The contrast matters. The Brady quote is sharper and more quotable than anything in Anthropic\u0026rsquo;s own engineering blog. That is not evidence of fraud — it is evidence of stylization. Real engineering writing is hedged. The Brady quote is not hedged. That puts it in a different genre from Anthropic\u0026rsquo;s own writing on the topic.\n6. The transcript: the 29-minute video is not about \u0026ldquo;agents lying\u0026rdquo; This is the finding that shifted the investigation. I pulled the audio from the video and transcribed it through Deepgram\u0026rsquo;s Nova-2 model. The transcript is 5,095 words.\nThe video is a talk by someone from Elicit — the AI research assistant — about ASHPL, their domain-specific language for agentic workflows. It is not an Anthropic talk. It is not about a \u0026ldquo;verification stack.\u0026rdquo; It is not by \u0026ldquo;James Brady.\u0026rdquo;\nThe speaker walks through:\nWhy Elicit chose a DSL over freeform agent architectures; The ASHPL language design: a Turing-incomplete, pure functional subset of Python with domain primitives for retrieving academic papers and clinical trials; The event-sourcing pattern that drives iterative plan-and-execute loops; A live demo generating a research landscape table about foundation models for biology; How memoization and content-addressable storage make full-program reinterpretation efficient. The word \u0026ldquo;lie\u0026rdquo; does not appear anywhere in the transcript. Neither does \u0026ldquo;lying,\u0026rdquo; \u0026ldquo;fabrication,\u0026rdquo; \u0026ldquo;caught,\u0026rdquo; or \u0026ldquo;verification stack.\u0026rdquo; The closest the speaker gets is a remark about trust: the mechanism of how an output is produced matters, not just the output itself. That is a general point about process legibility, not a claim about measuring agent dishonesty in production.\nThe talk is clearly from a conference or meetup. The speaker says \u0026ldquo;Elicit\u0026rdquo; repeatedly. The slide deck references elicit.com. The vocabulary — \u0026ldquo;research landscape,\u0026rdquo; \u0026ldquo;clinical trials,\u0026rdquo; \u0026ldquo;academic papers,\u0026rdquo; \u0026ldquo;systematic review\u0026rdquo; — is the vocabulary of scientific research tooling, not agent-safety engineering.\nThis closes one lead: we now know what is in the 29-minute video. It is a real talk by a real person at Elicit. The quote has been superimposed onto it. The attribution to \u0026ldquo;Anthropic engineer James Brady\u0026rdquo; is text that wraps around a completely different piece of content.\nBut this raises the next question: where did the video come from? Is it a repurposed conference talk? Was it downloaded, cropped, and paired with the fabricated quote by rody, or did rody get it from somewhere else? The Elicit employee whose talk this is might not even know their video is being used this way.\n7. The James Brady post is not a one-off — rody runs a daily content farm The transcript answered \u0026ldquo;what is in the video.\u0026rdquo; The next question was: is this a single bad tweet or a pattern?\nI pulled rody\u0026rsquo;s recent posting history. The answer is definitive.\nrody posts 2–3 times per day, every day. Every single post follows the exact same template:\n\u0026quot;[AI Figure]: \u0026lsquo;[provocative, slightly technical quote]\u0026rsquo; — In 29 minutes, he walks through [topic]. Watch the full talk, then save the config below 👇\u0026quot;\nRecent examples from a single two-week span:\nDate Attributed To Quote June 8 \u0026ldquo;Anthropic\u0026rsquo;s Chief Product Officer\u0026rdquo; \u0026ldquo;Claude doesn\u0026rsquo;t write code anymore\u0026rdquo; June 7 \u0026ldquo;Anthropic\u0026rsquo;s main manager\u0026rdquo; \u0026ldquo;Nobody types prompts from scratch\u0026rdquo; June 6 \u0026ldquo;Anthropic engineer James Brady\u0026rdquo; Our case. May 30 Boris Cherny, head of Claude Code \u0026ldquo;The default is now I\u0026rsquo;m going to have Claude prompt itself\u0026rdquo; May 29 Anthropic engineer Arnaud Doko \u0026ldquo;Saying \u0026lsquo;make it better\u0026rsquo; is the most expensive mistake\u0026rdquo; May 26 Dario Amodei, CEO of Anthropic quoted from an Oprah interview May 16 Andrej Karpathy \u0026ldquo;never felt more behind as a programmer\u0026rdquo; May 13 Boris Cherny \u0026ldquo;It\u0026rsquo;s not so much about deep work\u0026rdquo; (Note: I am deliberately not linking to these posts. The pattern is the evidence, not any individual post.)\nEvery post includes an amplify video and a link to another of rody\u0026rsquo;s own articles. Every one is structured to drive engagement toward Claude Code configs, AI tooling setups, and ultimately — through the bio link — ZSC DAO / Polymarket.\nThe account joined X in April 2021 and was largely inactive for years (158 total posts over 5 years). The pivot to daily content farming appears to have started recently — tightly clustered with the January 2026 launch of zscdao.com and David Mozhaev\u0026rsquo;s GitHub account.\nThis changes the investigation. The \u0026ldquo;James Brady\u0026rdquo; quote is not a one-off viral spike. It is a single output in a systematic content production pipeline. The quote, the attribution, and the video mismatch are features of the pipeline, not bugs. The pipeline runs daily, targeting the AI Twitter audience, with a consistent call-to-action funnel toward the DAO ecosystem.\nThe question is no longer \u0026ldquo;who is James Brady?\u0026rdquo; The question is \u0026ldquo;what is this funnel monetizing?\u0026rdquo; — and the Polymarket DAO connection is the strongest lead.\nThe genre [USER: write — your read on the \u0026ldquo;long insider video + sharp pull-quote\u0026rdquo; pattern. Why does the form keep working? You have been seeing this for a year, you said. I want your voice on what is in the water, not mine.]\nOpen leads These are the next threads. I am putting them here so I (or anyone else) can pick them up.\nMore cases. I have seen several of these. I need the receipts: handles, dates, quotes, screenshots. The case above is one clean example; the genre is the question, not the one. What is in the 29-minute video? Resolved. The transcript is in. It is an Elicit talk about their ASHPL DSL. The quote does not appear in it. Rody\u0026rsquo;s other posts. Resolved. 158 posts over 5 years, but the recent pattern is 2–3 posts daily following the exact same template. The account pivoted to content farming around January 2026. See section 7 above. zscdao / Polymarket. Partially resolved. ZSC DAO is a ~5-month-old operation with a false \u0026ldquo;Official Polymarket Community\u0026rdquo; designation, unverifiable leadership, no product, and no media footprint. The connection between rody and ZSC DAO is confirmed. What remains open: is this a deliberate funnel on rody\u0026rsquo;s part, or is rody genuinely part of a larger content operation orchestrated by ZSC DAO? Where did the video come from? The Elicit talk — was it from a public conference? A meetup? Was it downloaded from YouTube or a conference site and repurposed? Finding the original upload would confirm the mismatch and potentially identify the actual speaker. Other Polymarket-DAO-adjacent accounts. Are prediction-market communities systematically seeding content into AI Twitter? If so, that is its own piece. The CEO \u0026ldquo;David Mozhaev.\u0026rdquo; A blank GitHub created January 6, 2026 and an X handle is all that exists. Is this a real person or a fabricated identity? A deep search into the name, the X account history, and any cross-platform presence could reveal more. Rody\u0026rsquo;s own identity. Who is \u0026ldquo;rody\u0026rdquo;? No GitHub, no Reddit, no LinkedIn presence found. The account has been on X since 2021 but was largely inactive. What changed around January 2026? What I am not claiming I am not claiming the quote is wrong. The quote is probably true as a description of agent behavior — the part I quoted in Stop Reading What Your Coding Agent Says holds up regardless of who said it, because the structural dynamic it describes is real.\nWhat I am claiming, with evidence:\nThe trail of attribution ends at rody\u0026rsquo;s own article. The tweet is a quote-tweet of rody\u0026rsquo;s article. The \u0026ldquo;Anthropic engineer\u0026rdquo; voice and the \u0026ldquo;rody\u0026rdquo; voice are the same thesis in two formats. \u0026ldquo;James Brady\u0026rdquo; is not a person I can verify at Anthropic. The only indexed James Brady in the world is a 20th-century press secretary. The quote does not exist in the video. The transcript is in. It is an Elicit talk about DSL design. The two things share no content. The quote is not a one-off. rody posts 2–3 fabricated quotes daily. The James Brady post is one output in a systematic pipeline. ZSC DAO is not what it claims. It is a ~5-month-old operation with a false \u0026ldquo;Official Polymarket Community\u0026rdquo; designation, unverifiable leadership, and no product. The genre — \u0026ldquo;long insider video + sharp pull-quote attributed to a vague insider\u0026rdquo; — is a content pattern, not a series of one-offs. The shape of the content is too consistent to be coincidence. What to do if you see one of these [USER: write — your move when you see a sharp, attributed AI quote on X. Do you screenshot it, bookmark it, share it, verify it? What is the right discipline? You were almost the next person to spread this one.]\nLast updated: 2026-06-08. Investigation continues. Filing date for next update: when the Elicit talk\u0026rsquo;s original source is found, when additional cases are documented, and when ZSC DAO\u0026rsquo;s leadership and rody\u0026rsquo;s identity are further investigated.\n","permalink":"https://blog.without.hosting/posts/x-ai-quote-fabrication/","summary":"\u003cblockquote\u003e\n\u003cp\u003e\u003cstrong\u003eStatus: live, ongoing.\u003c/strong\u003e The account is a systematic content farm posting 2–3 fabricated quotes daily. The DAO behind it is a ~5-month-old shell with unverifiable leadership and a false \u0026ldquo;Official Polymarket Community\u0026rdquo; claim. Last updated: 2026-06-08.\u003c/p\u003e\n\u003c/blockquote\u003e\n\u003cp\u003eI keep seeing videos on X attributed to \u0026ldquo;An Anthropic engineer\u0026rdquo; or \u0026ldquo;An OpenAI researcher\u0026rdquo; giving a 20–30 minute talk about agent reliability, prompt injection, or some other sharp operational topic. The quotes that come out of them are perfect. They sound like the inside view. They are also extremely shareable.\u003c/p\u003e","title":"Anthropic Engineer or Quote Fabrication? An Open Investigation"},{"content":"Structural changes in the current repo The current Backbone template gives a concrete meaning to \u0026ldquo;structural change.\u0026rdquo; It is not just editing a React file.\nA real feature may touch:\nroute registration in App.tsx; a page folder under client/src/pages/; static/dynamic prop types; Zustand state; design-system primitives; ConnectRPC client calls; Rust server modules; SQL migrations; Gherkin scenarios and Playwright tests. Backspine\u0026rsquo;s job is to make that structure explicit enough that the agent can modify it without turning the repo into a pile of local improvisations.\n[USER: write — the interface for reviewing agent-generated code should show what changed at the architecture/structural level first, with the ability to zoom into a specific implementation. Not a flat wall of diff text.]\nReferenced from: backspine hot take — don\u0026rsquo;t read agent text\n","permalink":"https://blog.without.hosting/posts/backspine-structural-changes/","summary":"\u003ch2 id=\"structural-changes-in-the-current-repo\"\u003eStructural changes in the current repo\u003c/h2\u003e\n\u003cp\u003eThe current Backbone template gives a concrete meaning to \u0026ldquo;structural change.\u0026rdquo; It is not just editing a React file.\u003c/p\u003e\n\u003cp\u003eA real feature may touch:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eroute registration in \u003ccode\u003eApp.tsx\u003c/code\u003e;\u003c/li\u003e\n\u003cli\u003ea page folder under \u003ccode\u003eclient/src/pages/\u003c/code\u003e;\u003c/li\u003e\n\u003cli\u003estatic/dynamic prop types;\u003c/li\u003e\n\u003cli\u003eZustand state;\u003c/li\u003e\n\u003cli\u003edesign-system primitives;\u003c/li\u003e\n\u003cli\u003eConnectRPC client calls;\u003c/li\u003e\n\u003cli\u003eRust server modules;\u003c/li\u003e\n\u003cli\u003eSQL migrations;\u003c/li\u003e\n\u003cli\u003eGherkin scenarios and Playwright tests.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eBackspine\u0026rsquo;s job is to make that structure explicit enough that the agent can modify it without turning the repo into a pile of local improvisations.\u003c/p\u003e","title":"Backspine — Structural Changes Semantic"},{"content":"Current Backbone island shape The existing template already points toward islands, even if it does not call them that yet.\nA page is not one blob. The hello-world feature is split across:\nhello-page.tsx: the mostly-presentational page component; hello-page-route.tsx: the route adapter that binds real state/actions; hello-page-state.ts: Zustand state and ConnectRPC client calls; hello-page.stories.tsx: preview states; hello-page.test.tsx: component-level tests; e2e/features/helloworld.feature and e2e/tests/helloworld.spec.ts: behavior-level coverage; server database/RPC modules and SQL migrations. That is close to a compilation unit. A Backspine \u0026ldquo;island\u0026rdquo; is probably not just a React component. It is the vertical slice: page, route adapter, state, payloads, backend endpoint, migrations, stories, and e2e behavior.\nThe practical version of \u0026ldquo;recreate, don\u0026rsquo;t patch\u0026rdquo; is therefore not regenerate the whole app. It is regenerate a bounded island and verify its contracts.\n[USER: write — the idea that generated code should be scoped into isolated, reviewable islands within structural elements, rather than delivered as a continuous diff or stream of tokens.]\nReferenced from: backspine hot take — don\u0026rsquo;t read agent text\n","permalink":"https://blog.without.hosting/posts/backspine-code-islands/","summary":"\u003ch2 id=\"current-backbone-island-shape\"\u003eCurrent Backbone island shape\u003c/h2\u003e\n\u003cp\u003eThe existing template already points toward islands, even if it does not call them that yet.\u003c/p\u003e\n\u003cp\u003eA page is not one blob. The hello-world feature is split across:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003ehello-page.tsx\u003c/code\u003e: the mostly-presentational page component;\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehello-page-route.tsx\u003c/code\u003e: the route adapter that binds real state/actions;\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehello-page-state.ts\u003c/code\u003e: Zustand state and ConnectRPC client calls;\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehello-page.stories.tsx\u003c/code\u003e: preview states;\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ehello-page.test.tsx\u003c/code\u003e: component-level tests;\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003ee2e/features/helloworld.feature\u003c/code\u003e and \u003ccode\u003ee2e/tests/helloworld.spec.ts\u003c/code\u003e: behavior-level coverage;\u003c/li\u003e\n\u003cli\u003eserver database/RPC modules and SQL migrations.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThat is close to a compilation unit. A Backspine \u0026ldquo;island\u0026rdquo; is probably not just a React component. It is the vertical slice: page, route adapter, state, payloads, backend endpoint, migrations, stories, and e2e behavior.\u003c/p\u003e","title":"Backspine — Code Islands"},{"content":"Current Backbone v1 grounding This is not only a thought experiment anymore. The working codebase is public as wimpheling/backbone-template-v1. The public concept is Backspine, but the repo and packages still use the first working name: Backbone.\nThe current template already encodes several of the ideas in this draft:\nclient pages are split into page components, route adapters, state, stories, and tests under template/client/src/pages/; the React design system is separated into @backbone/design-system-contract, @backbone/design-system-basic, and the public facade @backbone/design-system; app code is pushed toward the design-system vocabulary instead of raw JSX; a custom design-system-lint package forbids raw DOM JSX in app code and blocks direct imports from external UI libraries; end-to-end behavior is specified with Gherkin features and Playwright tests under template/e2e/; the backend is Rust, with SQL migrations, database modules, and ConnectRPC wiring. So when this post says \u0026ldquo;Backspine,\u0026rdquo; read it as the methodology emerging from that Backbone template, not as a blank framework fantasy.\n[USER: write — this is the project pitch. What is backspine? What problem does it solve? What makes AI-assisted web development different from traditional web development, and why does it need its own framework? What\u0026rsquo;s the elevator pitch?]\n","permalink":"https://blog.without.hosting/posts/backspine-presentation/","summary":"\u003ch2 id=\"current-backbone-v1-grounding\"\u003eCurrent Backbone v1 grounding\u003c/h2\u003e\n\u003cp\u003eThis is not only a thought experiment anymore. The working codebase is public as \u003ca href=\"https://github.com/wimpheling/backbone-template-v1\"\u003e\u003ccode\u003ewimpheling/backbone-template-v1\u003c/code\u003e\u003c/a\u003e. The public concept is Backspine, but the repo and packages still use the first working name: Backbone.\u003c/p\u003e\n\u003cp\u003eThe current template already encodes several of the ideas in this draft:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eclient pages are split into page components, route adapters, state, stories, and tests under \u003ccode\u003etemplate/client/src/pages/\u003c/code\u003e;\u003c/li\u003e\n\u003cli\u003ethe React design system is separated into \u003ccode\u003e@backbone/design-system-contract\u003c/code\u003e, \u003ccode\u003e@backbone/design-system-basic\u003c/code\u003e, and the public facade \u003ccode\u003e@backbone/design-system\u003c/code\u003e;\u003c/li\u003e\n\u003cli\u003eapp code is pushed toward the design-system vocabulary instead of raw JSX;\u003c/li\u003e\n\u003cli\u003ea custom \u003ccode\u003edesign-system-lint\u003c/code\u003e package forbids raw DOM JSX in app code and blocks direct imports from external UI libraries;\u003c/li\u003e\n\u003cli\u003eend-to-end behavior is specified with Gherkin features and Playwright tests under \u003ccode\u003etemplate/e2e/\u003c/code\u003e;\u003c/li\u003e\n\u003cli\u003ethe backend is Rust, with SQL migrations, database modules, and ConnectRPC wiring.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eSo when this post says \u0026ldquo;Backspine,\u0026rdquo; read it as the methodology emerging from that Backbone template, not as a blank framework fantasy.\u003c/p\u003e","title":"Backspine — Project Presentation"},{"content":"PR extraction against Backbone In Backbone terms, a useful extracted PR should probably be a vertical slice, not a random diff chunk.\nA coherent feature PR might include:\none page folder; the route adapter and state store; any design-system vocabulary needed by that page; server RPC/database changes; migrations; story states; component tests; Gherkin + Playwright scenarios. That is a more meaningful unit than \u0026ldquo;whatever files the agent happened to edit during the chat.\u0026rdquo;\n[USER: write — the idea is deterministic extraction of structural parts from PR messages. Not LLM-based parsing of the whole thing, but targeted extraction of specific structural elements. What are those parts? What format do PR messages follow? What makes non-deterministic extraction a problem?]\n","permalink":"https://blog.without.hosting/posts/backspine-pr-extraction/","summary":"\u003ch2 id=\"pr-extraction-against-backbone\"\u003ePR extraction against Backbone\u003c/h2\u003e\n\u003cp\u003eIn Backbone terms, a useful extracted PR should probably be a vertical slice, not a random diff chunk.\u003c/p\u003e\n\u003cp\u003eA coherent feature PR might include:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eone page folder;\u003c/li\u003e\n\u003cli\u003ethe route adapter and state store;\u003c/li\u003e\n\u003cli\u003eany design-system vocabulary needed by that page;\u003c/li\u003e\n\u003cli\u003eserver RPC/database changes;\u003c/li\u003e\n\u003cli\u003emigrations;\u003c/li\u003e\n\u003cli\u003estory states;\u003c/li\u003e\n\u003cli\u003ecomponent tests;\u003c/li\u003e\n\u003cli\u003eGherkin + Playwright scenarios.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eThat is a more meaningful unit than \u0026ldquo;whatever files the agent happened to edit during the chat.\u0026rdquo;\u003c/p\u003e","title":"Backspine — Deterministic PR Message Extraction"},{"content":"Actual Backbone design-system boundary The current design system is split into contract, implementation, and facade packages:\ndesign-system-contract: typed component API; design-system-basic: React implementation plus CSS/stories; design-system: public import surface. It also includes lint tooling that checks the architecture and forbids app code from using raw DOM JSX or importing external UI kits directly.\nSo the design-system thesis should be read literally: this is not just a taste layer. It is an agent-control boundary.\n[USER: write — these are the starting questions from the initial brainstorm]\nIs a separate type system necessary? Can we do mobile + React with it? Can we hot-reload implementations? Do we need multiple implementations? [USER: expand each question into a proper section]\n","permalink":"https://blog.without.hosting/posts/backspine-design-system/","summary":"\u003ch2 id=\"actual-backbone-design-system-boundary\"\u003eActual Backbone design-system boundary\u003c/h2\u003e\n\u003cp\u003eThe current design system is split into contract, implementation, and facade packages:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\u003ccode\u003edesign-system-contract\u003c/code\u003e: typed component API;\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003edesign-system-basic\u003c/code\u003e: React implementation plus CSS/stories;\u003c/li\u003e\n\u003cli\u003e\u003ccode\u003edesign-system\u003c/code\u003e: public import surface.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIt also includes lint tooling that checks the architecture and forbids app code from using raw DOM JSX or importing external UI kits directly.\u003c/p\u003e\n\u003cp\u003eSo the design-system thesis should be read literally: this is not just a taste layer. It is an agent-control boundary.\u003c/p\u003e","title":"Backspine Design System and Ergonomics"},{"content":"Backspine is the working name for a framework/methodology for AI-assisted web development. The name is still tentative. This post captures the rationale and alternatives as the idea develops.\nThe proteiform problem LLMs are proteiform. They span a problem space so vast and continuous that almost any prompt is a drop of ink in an ocean of meanings. Their quasi-omniscience is the property that makes them powerful and the property that makes them drift.\n\u0026ldquo;Drift\u0026rdquo; here is not the model drifting off-topic in the vulgar sense. It is more structural: the prompt dissolves into the larger space of meaning latent in the model. Every specific instruction is in constant competition with everything else the model knows. The result is that LLM output has a natural tendency to return toward the local mean of the training data unless the constraint around it is very strong.\nThis is why prompt engineering exists. It is not about finding magic words. It is about building a container small enough that the prompt\u0026rsquo;s signal dominates the noise of the model\u0026rsquo;s vast latent space.\nThe name as metaphor The industry settled on \u0026ldquo;harness.\u0026rdquo; It is not a bad word: a harness is how you control something stronger than you. You harness a horse, a dog team, a draft animal. The metaphor is control through attachment. But a harness is about restraint and direction — it does not say much about shape.\nBackspine came from \u0026ldquo;backbone\u0026rdquo; — the central support structure. The problem: Backbone.js is already a thing, so the name is poisoned for a web framework. Backspine keeps the same structural intuition without the namespace collision.\nBut exactly what kind of support structure are we talking about?\nThe candidate landscape Several metaphors capture different angles of the same problem: how do you give useful shape to a system that has too much shape?\nHarness. Restraint and direction. The animal is powerful, you guide it. The metaphor is about control but says nothing about the transformation the output undergoes. It is also already taken by the industry — which is fine for general use but makes it a weak differentiator for a specific framework.\nBackspine / Backbone. Central support structure. The spine is what the rest of the body hangs on. In Backbone\u0026rsquo;s case, the metaphor was about MVC structure for JavaScript applications. In Backspine\u0026rsquo;s case, the spine is the set of architectural conventions that the code, the agent, the tests, and the human all attach to. The spine does not move — everything else does.\nArmature. The internal wire skeleton inside a clay sculpture. Clay is the proteiform material: it has no inherent shape. The armature gives it structure from the inside. This is a strong metaphor because the scaffold is invisible in the finished piece — it is embedded. It is also a precise term from a domain (sculpture) that understands the interaction between shapeless material and structural constraint. The armature does not dictate the final form. It prevents collapse.\nFormwork. In construction, concrete is poured liquid into formwork. The formwork shapes it until it sets, then it is removed. This maps elegantly to the proteiform property — the material is shapeless at the point of use, the structure is temporary, and the output retains its shape. Formwork is also explicitly infrastructure, not product. You build it to produce the shaped thing, then you move on. This is exactly the right relationship between a prompt structure and the code it produces.\nScaffolding. Also construction. Temporary external support for a building that is being built or repaired. The problem: \u0026ldquo;scaffolding\u0026rdquo; already means something specific in development — code generation boilerplate, project skeletons, the kind of thing create-react-app generates. The collision is real enough that using it for a prompt-workflow methodology would be confusing.\nExoskeleton. External rigid casing. An insect\u0026rsquo;s exoskeleton is not just support — it is also armor. The metaphor leans militaristic, defensive, almost paranoid. It captures the containment angle well but the vibe is wrong for what should be a productive, not adversarial, relationship between human and LLM.\nWhat the implementation actually looks like The name debate is not abstract. There is working code.\nThe public repository is wimpheling/backbone-template-v1. It is called Backbone because that was the first working name, before I realized the collision with the legacy framework. The code inside already encodes several of the ideas these names gesture at.\nA page in the template has five files:\nPage component: typed React, using only design-system vocabulary (Button, Navigation, Layout, Stack, Text, Form, etc.) — no raw JSX, no random UI imports. Route adapter: binds the page to routing, separates concerns from the page component. State store: Zustand store for client state — separated from the page logic so the agent can regenerate either independently. Stories: Ladle stories for visual testing — because if a page is a compilation unit, it needs a standalone preview. Tests: unit tests for the page logic. The design system is contract-first: a types-only package (design-system-contract), a concrete implementation (design-system-basic), and a facade package that app code imports from (design-system). An architectural linter and oxlint plugin enforce that app code cannot import raw DOM JSX or third-party UI libraries directly. The agent must speak through the design system vocabulary.\nThis is the bridge from metaphor to implementation. Whether you call it a spine, an armature, or formwork, the structural claim is the same: the template defines a set of architectural primitives that are stable, typed, and semantic. The LLM generates within those primitives. Drift is constrained not by prompt magic but by structural enforcement — the linter, the contracts, the type system, the test framework.\nThe metaphor and the architecture I keep coming back to the same tension. The LLM is proteiform. The codebase wants to be predictable. The name should capture what sits between them.\nBackspine is still the leading candidate because it is simple, pronounceable, and carries the right structural implication without borrowing from a domain that already defines a conflicting concept. But armature has real conceptual weight — it is not just support, it is embedded support, invisible in the finished piece but preventing collapse during the shaping process. And formwork is the most precise for the actual workflow: you build structure, pour LLM output into it, let it set, and move on.\nRight now, the package is called Backbone (legacy reasons), the methodology is called Backspine (working name), and the debate is live. The name should settle once the broader architecture is stable enough that the post — this one — stops being a draft and becomes an announcement.\n[USER: write — what pushed you toward backspine over armature or formwork? Or is the name genuinely unsettled?]\n","permalink":"https://blog.without.hosting/posts/backspine-name/","summary":"\u003cp\u003eBackspine is the working name for a framework/methodology for AI-assisted web development. The name is still tentative. This post captures the rationale and alternatives as the idea develops.\u003c/p\u003e\n\u003ch2 id=\"the-proteiform-problem\"\u003eThe proteiform problem\u003c/h2\u003e\n\u003cp\u003eLLMs are proteiform. They span a problem space so vast and continuous that almost any prompt is a drop of ink in an ocean of meanings. Their quasi-omniscience is the property that makes them powerful and the property that makes them drift.\u003c/p\u003e","title":"Backspine — What Will the Framework Be Called?"},{"content":"There is no context engineering.\n\u0026ldquo;Context\u0026rdquo; and \u0026ldquo;prompts\u0026rdquo; are the same thing. Every input you feed your LLM is context. The system prompt is context. The user message is context. The retrieved chunk is context. The tool output is context. The conversation history is context. From the model\u0026rsquo;s seat, there is only the next-token distribution over a token sequence. The boundary between \u0026ldquo;prompt\u0026rdquo; and \u0026ldquo;context\u0026rdquo; is editorial — it lives upstream, in the human\u0026rsquo;s head, and it disappears the moment inference starts.\nBateson said it first Gregory Bateson saw this structure — not about LLMs, but about mammals at play. In a 1955 essay called A Theory of Play and Fantasy, he watches two young animals roughhousing.\nThey nip each other. The nip looks like a bite, sounds like a bite, resembles a bite in every observable way. But it is not a bite. The other animal does not flinch, flee, or retaliate. They keep playing.\nWhy? Because both animals are communicating on two levels simultaneously. One level: the action. The other level: a message about the action. Bateson called this metacommunication:\n\u0026ldquo;The other set of levels of abstraction we will call metacommunicative (e.g., \u0026lsquo;My telling you where to find the cat was friendly,\u0026rsquo; or \u0026lsquo;This is play\u0026rsquo;). In these, the subject of discourse is the relationship between the speakers.\u0026rdquo;\nThe metacommunicative message — \u0026ldquo;this is play\u0026rdquo; — tells the receiver how to interpret the action. The same gesture, without that frame, would be aggression. With the frame, it is play.\nAnd here is the line that matters:\n\u0026ldquo;The playful nip denotes the bite, but it does not denote what would be denoted by the bite.\u0026rdquo;\nThe nip carries two meanings simultaneously: the denotative content (a bite-like action) and the metacommunicative frame (this is not a real bite). The frame is not separate from the action. The frame is the action, at a higher logical type. There is no \u0026ldquo;bite\u0026rdquo; without \u0026ldquo;this is play\u0026rdquo; layered on top. There is no content without context. They are the same emission.\nThis is exactly what happens in an LLM prompt. Every token you put in the window carries information at multiple levels: the denotative content (the instruction, the user question, the fact) and the metacommunicative frame (system prompt, role assignment, preceding conversation, retrieved context, tool outputs). From the model\u0026rsquo;s seat, these are all just tokens in a sequence. The boundary between \u0026ldquo;prompt\u0026rdquo; and \u0026ldquo;context\u0026rdquo; is editorial. The transformer does not see a system prompt versus a user message versus a RAG chunk. It sees a sequence of tokens and predicts the next one.\nThe paradox There is a contradiction sitting in the open. I said \u0026ldquo;there is no context engineering,\u0026rdquo; then spent the last section arguing that everything is context. If everything is context, then you are always already engineering context. The term is not false. It is not even misleading.\nIt is empty.\n\u0026ldquo;Context engineering\u0026rdquo; claims the discovery of something that has always been true of every communication since the first mammal nipped another and the nip was understood as play. Every message carries its own context. Every frame is a message at a higher logical type. There is no \u0026ldquo;outside\u0026rdquo; the frame. There is no input that is not already contextualized by every other input in the window. The term sounds like a new discipline but describes a structural constant. It is a tautology dressed as innovation.\nThat is the real problem with the label. Not that it is wrong — but that it signals novelty where none exists, and in doing so, reveals how young the field still is.\n\u0026ldquo;Noyer le poisson\u0026rdquo; So why keep using the label? My read: it is noyer le poisson — muddying the waters. The term lets a young discipline dress up an old practice in fresh vocabulary. It signals novelty without actually being novel. And it reflects the level of immaturity of the field: we are still inventing job titles for things we have been doing for three years.\nThe proof is in the speakers. When someone says \u0026ldquo;context engineering\u0026rdquo; at a conference, ask them what part of their work was not already prompt engineering in 2023. The honest answer, almost always, is \u0026ldquo;the retrieval pipeline\u0026rdquo; or \u0026ldquo;the memory layer\u0026rdquo; or \u0026ldquo;the tool router.\u0026rdquo; Those are real engineering concerns. They are not new. And they are not \u0026ldquo;context\u0026rdquo; in some special sense — they are just more input, assembled upstream of the same old next-token prediction.\nThe reframe: we are not engineering, we are harnessing [USER: write the harnessing section here — this is the load-bearing reframe of the post. The metaphor matters. Engineering implies a stable material you shape. Harnessing implies a powerful, partially understood force you direct. LLMs are the second kind.]\nThree harnesses, one job [USER: write the spectrum here — CEO/CTO (predictable) → artist (generative) → consciousness-curious (different destination, same harness).]\nSo what should we call it? Call the work what it actually is:\nprompt design retrieval pipeline tuning memory architecture tool selection and routing message history shaping structured output enforcement These are real engineering disciplines with real techniques. They do not need a new umbrella term, and they do not need to be rebranded every eighteen months to feel exciting.\nStop saying \u0026ldquo;context engineering.\u0026rdquo; Start saying what you actually do.\n","permalink":"https://blog.without.hosting/posts/no-context-engineering/","summary":"\u003cp\u003eThere is no context engineering.\u003c/p\u003e\n\u003cp\u003e\u0026ldquo;Context\u0026rdquo; and \u0026ldquo;prompts\u0026rdquo; are the same thing. Every input you feed your LLM is context. The system prompt is context. The user message is context. The retrieved chunk is context. The tool output is context. The conversation history is context. From the model\u0026rsquo;s seat, there is only the next-token distribution over a token sequence. The boundary between \u0026ldquo;prompt\u0026rdquo; and \u0026ldquo;context\u0026rdquo; is editorial — it lives upstream, in the human\u0026rsquo;s head, and it disappears the moment inference starts.\u003c/p\u003e","title":"There Is No Context Engineering"},{"content":"I built a Telegram bot that can write and edit my blog posts but cannot publish them. Hugo draft: true is enforced by the tool, not trusted to my discipline.\nThe bot reads and writes files in the Hugo repo directly. No separate editorial database — the Markdown files are the source of truth. When a diff would flip draft: true to draft: false, the commit script refuses. There is an override (ALLOW_PUBLISH=1) but the bot cannot set it. Only I can, at a terminal.\nWhat it does It can turn a ramble into a structured draft: take a messy paragraph from Telegram, extract the actual claim, propose an outline, write a first version. It edits existing posts, tightens paragraphs, fixes typos. It tracks changes via git notes — each edit commit leaves metadata that gets rendered as a reader-facing Edits block at the bottom of the post.\nIt answers on demand. /drafts lists current unlisted posts with their URLs. /nudge generates a writing prompt immediately. There is also a scheduled nudge: every 21 minutes during waking hours, the bot looks at what is sitting in the drafts folder and, if a slot is due, sends a short message about one of them. Not a reminder to write — a continuation of whatever that draft is about.\nIt researches. It can find papers on arXiv, extract text from PDFs, verify quotes against actual documents. It can generate SVG diagrams by hand and save them directly into the repo as image files. It has image generation via ComfyUI, access to Notion, Google Workspace, maps, and email.\nIt remembers across conversations. Past sessions are searchable. Subagents can be spawned for parallel work — for example, checking sources while drafting a section.\nNone of this is autonomous. Every action goes through git, and git has a guard. The bot cannot publish, cannot set the env var that would allow publishing, and cannot bypass the commit script.\nWhy Telegram My drafts rarely start as documents. They start as messages to a friend, a rant in a Discord group, a thought I type while walking. Telegram is always available and requires no friction — no editor, no filename, no structure decision before writing. I can send the bot a messy thought and say: make this a draft.\nThat is what happened here. I posted a French message in a Discord group explaining the bot, realized it was the seed of a blog post, copied it to the bot, and asked for an English draft. A strange loop: I built a bot to help me blog, then immediately used the explanation of the bot as the first thing for the bot to blog about.\nVoice risk Bot-written text sounds correct and loses the rough edges that make a post feel like someone actually reasoned through it. That is a real risk. The compromise is that the bot does the restructuring and the grunt work, but the actual claims and the framing come from me. If the bot\u0026rsquo;s voice dominates, the experiment failed. The style guidelines explicitly prevent over-polished prose and rhetorical slop — mechanism first, no editorial.\nWhat the experiment actually tests Not whether the bot can write. It obviously can, in the same way an LLM can write anything — passably, at length, with medium confidence. The question is whether reducing the friction from \u0026ldquo;I have a thought\u0026rdquo; to \u0026ldquo;there is a coherent draft in the repo\u0026rdquo; changes my actual output over months.\nThe failure mode it targets is not writer\u0026rsquo;s block. It is the gap between having a thought and committing it to a file. If the bot can reliably close that gap — turn rambles into drafts, keep track of unfinished posts, ask the right small question — that might be enough.\nNot to automate writing. Just to make it easier to continue.\n","permalink":"https://blog.without.hosting/posts/a-bot-to-help-me-blog/","summary":"\u003cp\u003eI built a Telegram bot that can write and edit my blog posts but cannot publish them. Hugo \u003ccode\u003edraft: true\u003c/code\u003e is enforced by the tool, not trusted to my discipline.\u003c/p\u003e\n\u003cp\u003eThe bot reads and writes files in the Hugo repo directly. No separate editorial database — the Markdown files are the source of truth. When a diff would flip \u003ccode\u003edraft: true\u003c/code\u003e to \u003ccode\u003edraft: false\u003c/code\u003e, the commit script refuses. There is an override (\u003ccode\u003eALLOW_PUBLISH=1\u003c/code\u003e) but the bot cannot set it. Only I can, at a terminal.\u003c/p\u003e","title":"A Bot to Help Me Blog"},{"content":"In 2023 I wrote about Decentralized Autonomous Intelligence, or DAI: the idea of combining LLMs, decentralized infrastructure, and crypto-economic incentives into something that could act, learn, spend, and improve itself.\nReading it now, part of it feels obviously dated.\nThe old article was written inside the mood of the time. DAOs were still treated as if they were going to become the default form of internet-native organization. Tokenomics was everywhere. If you had a coordination problem, a governance problem, or an incentive problem, the reflex was: put it on-chain, add a token, define the actors, and let the protocol economics do the work.\nThat framing has aged.\nBut the core question has not.\nActually, it may be more relevant now.\nThe mistake was not to connect AI agency with crypto. The mistake was to assume too quickly that the answer would look like a DAO, with a native token, miners, and a full blockchain-era mythology around it.\nThe stronger version of the argument is simpler:\nIf an AI is supposed to be an agent in the strong sense, it needs some way to hold resources, spend resources, pay humans, rent tools, buy compute, and receive money. Today, AI systems cannot open bank accounts. Software cannot just become a customer of the traditional financial system. Crypto remains one of the few infrastructures where software can hold and move value directly.\nThat is not hype. That is a practical constraint.\nWhat aged badly The old DAI article took too much for granted.\nIt assumed that DAOs were here to stay as the natural organizational form for autonomous systems. It assumed that a native cryptocurrency would be the obvious economic layer. It talked about miners, token demand, and a DAI currency as if those were implementation details rather than huge design decisions.\nIt also leaned too much toward a whitepaper style: define the actors, define the incentives, describe the token flow, and end with a promise of a self-sustaining ecosystem.\nThat style now feels suspicious. Not because the questions are wrong, but because the crypto cycle trained everyone to generate elegant incentive diagrams for systems that did not yet have real users, real work, or real accountability.\nThe dated parts are mostly these:\ntreating blockchain as the default substrate; treating tokenomics as the center of the design; assuming DAOs had already proved themselves as organizational infrastructure; talking about \u0026ldquo;miners\u0026rdquo; instead of a broader set of compute, model, data, tool, and human contributors; making decentralization sound like an automatic good rather than a tradeoff; under-specifying the legal and operational boundary between the AI system and the humans around it. A modern DAI should not start with a token.\nIt should start with agency.\nWhat still feels right The best idea in the original article was that an advanced AI system should not be understood only as a model.\nA model is not an agent. A chatbot is not an agent. Even a tool-using LLM is only barely an agent if it has no durable memory, no budget, no authority, no way to acquire resources, and no way to change its own conditions of operation.\nThe interesting object is something more institutional:\nan AI-centered organization that can plan, act, allocate resources, coordinate humans and tools, and improve over time under some governance structure.\nThat still feels right.\nThe old article also had several good instincts:\nThe AI needs a budget. If it cannot spend, it cannot really act outside a sandbox. Improvement is a resource allocation problem. Training, fine-tuning, data acquisition, evaluation, tool building, and human feedback all cost something. There are multiple economic roles. Users, developers, data providers, compute providers, reviewers, maintainers, auditors, and investors may all interact with the system. The system must balance doing work and improving itself. An agent has to decide how much of its resources go to serving users versus upgrading its own capabilities. Humans are not outside the system. A real DAI would coordinate humans, not replace them magically. Forking matters. If an AI organization becomes badly governed, captured, or misaligned, the ability to exit and fork may be a central safety and governance mechanism. Open source and open data matter, but are not simple. Openness gives auditability and collaboration, but creates privacy, security, and competitive problems. These ideas are stronger now than they were in 2023, because AI agents have become less fictional.\nWe now have systems that can write code, call APIs, operate computers, manage workflows, run evaluations, and coordinate subtasks. They are still fragile, but the direction is clear: the model is becoming only one component inside a larger agentic system.\nThe missing layer is not only intelligence.\nIt is agency infrastructure.\nWhy crypto may become useful for agents before it became useful for DAOs DAOs often felt like organizations looking for a purpose.\nAI agents may invert that.\nHere we may have agents with a purpose, but no native institution around them.\nAn autonomous AI that performs useful work eventually needs answers to very boring questions:\nWho pays for its inference? Who pays for its tools? Can it hire a human? Can it buy access to data? Can it rent GPUs? Can it receive revenue? Can it hold a budget? Who can stop it from spending everything? Who audits its transactions? Who owns what it produces? Who is liable when it does something wrong? Traditional finance and law do not have a clean category for this. A bank account belongs to a legal person. A contract is signed by a legal person. Liability attaches to a legal person.\nAn AI agent is not a legal person.\nCrypto does not solve that entire problem, but it gives software a primitive that the banking system does not: direct control over value.\nThat is why the crypto angle survives the death of the hype framing.\nNot because every DAI needs a speculative token. Not because governance should be on-chain by default. Not because DAOs were inevitable.\nBut because autonomous software needs economic agency, and crypto is currently the most obvious machine-native payment and custody layer.\nThe revised DAI thesis A revised version of the DAI idea could be:\nA Decentralized Autonomous Intelligence is an AI-centered agentic organization with its own resource loop: it can receive tasks, perform work, earn or receive funds, spend those funds on tools/compute/data/humans, improve itself, and remain governable through transparent rules, human oversight, and credible exit mechanisms.\nThis definition deliberately does not require:\na native token; a DAO structure; on-chain governance for every decision; decentralized model inference; a blockchain as the whole runtime. Those may be useful in some designs. They are not the essence.\nThe essence is the resource loop plus governance.\nA DAI needs to answer:\nAgency: what can the AI do without asking permission every time? Budget: what resources does it control? Revenue: how does value enter the system? Spending: what can it buy, and under what constraints? Improvement: how does it upgrade its capabilities? Governance: who sets limits, policies, and goals? Accountability: who can inspect, stop, slash, reverse, or fork it? Exit: how do humans leave or create an alternative if governance fails? The good ideas worth keeping 1. The AI as an economic actor The old article imagined the AI model spending money to improve itself. That still feels like the central provocation.\nIf an AI can only respond to prompts, it is a service. If it can plan, spend, and coordinate, it starts to become an actor.\nThis does not mean giving it unlimited autonomy. It means designing bounded autonomy: budgets, policies, approvals, rate limits, audits, and kill switches.\nThe interesting design problem is not \u0026ldquo;should the AI be free?\u0026rdquo; It is: what kind of limited economic agency is useful and safe?\n2. The split between work and self-improvement The original article separated the AI\u0026rsquo;s tasks into two broad categories:\ndoing its job for users; managing and improving itself. That split is still useful.\nA real agentic organization has to decide whether to spend the next unit of budget on serving current users, improving evaluations, buying better data, hiring a developer, renting more compute, or building a new tool.\nThat is not just an AI problem. It is an organizational problem.\n3. Human contributors as part of the loop The old DAI model included developers, data providers, users, and other contributors. The vocabulary needs updating, but the idea is right.\nUseful AI systems will not be purely autonomous. They will be hybrid systems where humans do the work that humans are still better at: judgment, taste, trust, accountability, domain expertise, adversarial review, and governance.\nA DAI should not be imagined as an AI without humans.\nIt should be imagined as an organization where the AI can coordinate humans and where humans can constrain the AI.\n4. Forking as governance Forking sounded very crypto-native in the old article, but the underlying idea is broader.\nExit is one of the strongest governance tools.\nIf an AI system is open enough that its code, policies, memory, evals, and operational history can be copied or re-instantiated, then disagreement does not have to end in capture. A community can leave and create another version.\nThat matters for AI safety too. If the only powerful agents are closed systems controlled by a few companies, there is no real exit. If every system is open but chaotic, there may be no accountability. The right balance is unresolved, but the forking question is still important.\n5. Open source and open data as a strategic question The open DAI draft asked whether these systems should be open source and open data. That question is even more important now.\nOpen systems can be inspected, improved, forked, and trusted by communities. Closed systems can protect privacy, reduce abuse, and sustain a business model more easily.\nA serious DAI stack probably needs selective openness:\nopen policies and governance rules; auditable spending and decision logs; open interfaces; possibly open source agent code; protected private user data; controlled access to dangerous capabilities; clear boundaries around model weights, memory, and datasets. Toward an adequate stack This is still TBD, but the stack should probably not be \u0026ldquo;LLM + blockchain\u0026rdquo;.\nIt should be layered.\n1. Agent runtime The operational layer that lets the AI plan, call tools, write files, run jobs, remember context, and coordinate subtasks.\nExamples of concerns:\ntool calling; memory; task queues; evaluation loops; permissions; human approval gates; observability; rollback. 2. Governance layer The layer that defines what the agent is allowed to do.\nThis may include:\na constitution or policy document; spending limits; approval thresholds; role-based permissions; audit logs; emergency stops; voting or council mechanisms; dispute resolution. Some of this could be on-chain. Much of it may be ordinary software.\n3. Economic layer The layer that lets the agent hold and move value.\nThis is where crypto becomes relevant.\nPossible components:\nstablecoin wallet; multisig custody; programmable spending limits; escrow; payment channels or low-fee rails; accounting; revenue tracking; budget allocation. A native token is optional. In many cases it is probably a bad first move. A stablecoin budget controlled by policies and human signers may be enough.\n4. Work marketplace The layer where the DAI can buy help or sell services.\nThis could include:\nhumans doing review, labeling, coding, research, design; APIs and SaaS tools; compute providers; data providers; model providers; other agents. The original \u0026ldquo;miners\u0026rdquo; category becomes a broader supply side of capabilities.\n5. Identity and reputation The layer that tracks who is interacting with the DAI and why they should be trusted.\nThis matters for both humans and agents.\nPossible components:\ncryptographic identity; reputation scores; credentials; contribution history; audit history; sybil resistance; human verification where necessary. 6. Transparency and audit A DAI that can spend money and coordinate work needs to be inspectable.\nAt minimum:\ntransaction history; major decisions; policy changes; model/tool changes; eval results; incidents; human interventions. The more agency the system has, the more legible it must become.\nThe open question The interesting question is no longer:\nCan we put an LLM on a blockchain?\nThat was too narrow.\nThe better question is:\nWhat institutional stack does an AI agent need in order to act economically without becoming either powerless, captured, or dangerous?\nCrypto may be part of the answer, not because crypto fixes everything, but because software-native money is a real primitive. DAOs may also become useful, not because they were inevitable, but because real AI agents may finally give them something concrete to govern.\nIn that sense, the old DAI idea was early and overfit to the wrong hype cycle.\nBut it was pointing at a real problem.\nAI agency needs infrastructure.\nAnd the first serious version of that infrastructure may look less like a chatbot, less like a DAO, and more like an institution that happens to have an AI at its center.\n","permalink":"https://blog.without.hosting/posts/revisiting-decentralized-autonomous-intelligence/","summary":"\u003cp\u003eIn 2023 I wrote about \u003cstrong\u003eDecentralized Autonomous Intelligence\u003c/strong\u003e, or DAI: the idea of combining LLMs, decentralized infrastructure, and crypto-economic incentives into something that could act, learn, spend, and improve itself.\u003c/p\u003e\n\u003cp\u003eReading it now, part of it feels obviously dated.\u003c/p\u003e\n\u003cp\u003eThe old article was written inside the mood of the time. DAOs were still treated as if they were going to become the default form of internet-native organization. Tokenomics was everywhere. If you had a coordination problem, a governance problem, or an incentive problem, the reflex was: put it on-chain, add a token, define the actors, and let the protocol economics do the work.\u003c/p\u003e","title":"Revisiting Decentralized Autonomous Intelligence"},{"content":"For more efficiency with Cline and other programming agents, we need a franework that is more compatible with how agent works.\nAgents like Cline operate this way:\nActors:\nUser\nAgent software (cline etc)\ncommands (edit file, run command etc) MCP servers\nLLM\nUser inputs a prompt\nAgent processes the prompt (formats, add its own prompt)\nAgent makes a list of allowed instructions, including the MCP servers\nAgent interacts with LLM to obtain instructions in the format it supports\nAgent executes the instructions (stand alone or using MCP servers)\nAgent returns the result to the user\nAgent prompts the user for next action.\nTypically, when doing web development, we ask the LLM to generate code, through file-editing. The problem is that this is complex and forces the LLM to handle fine grained modifications with lots of technical overloads.\nIn programming in general, and in web programming environments too, a framework always has to navigate between two poles:\nletting the dev have freedom to customize the code efficacity by providing standard ways to do things, through libraries and tools. It is not as simple as that, but we can link that polarity to the opposition code vs config.\nConfiguration is not turing complete\nusually in json, yaml, toml files static limited possibilities Code is turing complete\nmore powerful more complex When it comes to agent, we could represent these two orientations this way:\nConfiguration can be handled by a MCP servers that only accepts strict instructions Code can be handled directly by the LLM, which can be more powerful but also more complex to manage. For that we need a framework that makes a clear distinction between what is configuration, and what is code.\nOur postulate, inspired by Pareto\u0026rsquo;s law, could be: 80% of the work in web development can be done with configuration. This framework will focus on that 80%. The remaining 20% will be handled by code, but in a way that is easily integrated with the configuration.\nWhat is config, what is code (Basics, server-side) After 15+ years of experience in web development, here are my 2 cents about what should obviously be configurable:\nRouting Authentication. Login/logout/user creation/management Database structure Input and output of methods Database queries (80% of them) API calls In a \u0026ldquo;MVC\u0026rdquo; type framework (quite obsolete term), if we handle that through config, it leaves us with the procedural code associated with the controller, with a given input and output.\nLet\u0026rsquo;s call this the procedure. What does it typically involve\nadvanced validation (do the linked resources exist, do they satisfy conditions) complex logic (e.g., business rules) complex calculations complex data transformations complex interactions with external services (e.g., payment gateways) complex error handling complex logging complex reporting database operations What is config, what is code (Advanced) Inside the procedural code, maybe some things could also be handled by config:\nsimple DB queries Maybe we can do some very limited code with a tool like Scratch/Blockly. The tool could help us define the utility methods, their input/outputs, and even write tests/specifications.\nHow will the framework work? Define the elements of the framework\nEntities Database schema Database queries API calls Authentication Routing Input/output validation Error handling Logging Reporting For each elements, provide MCP server endpoints to:\nEdit Create Find Delete For each element, provide a documentation that allows the user and the agent to understand how it should function.\nThe framework should also include instructions on how to use the framework. More specifically, on how to analyse a new requirement and implement it in the framework.\nHow I will implement the framework v0. Modular Design: Break down the framework into independent modules (e.g., database, API, authentication). This promotes reusability and maintainability. I will only implement the most basic requirements Routing Database schema Tests ","permalink":"https://blog.without.hosting/posts/ai-web-framework/","summary":"\u003cp\u003eFor more efficiency with Cline and other programming agents, we need a franework that is more compatible with how agent works.\u003c/p\u003e\n\u003cp\u003eAgents like Cline operate this way:\u003c/p\u003e\n\u003cp\u003eActors:\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003e\n\u003cp\u003eUser\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAgent software (cline etc)\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003ecommands (edit file, run command etc)\u003c/li\u003e\n\u003c/ul\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eMCP servers\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eLLM\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eUser inputs a prompt\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAgent processes the prompt (formats, add its own prompt)\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAgent makes a list of allowed instructions, including the MCP servers\u003c/p\u003e\n\u003c/li\u003e\n\u003cli\u003e\n\u003cp\u003eAgent interacts with LLM to obtain instructions in the format it supports\u003c/p\u003e","title":"Ai Web Framework"},{"content":"The concept of Decentralized Autonomous Organizations (DAOs), introduced by Ethereum co-founder Vitalik Buterin, has revolutionized the way we think about decentralized governance and decision-making. By coupling DAOs with Large Language Models (LLMs) to form Decentralized Autonomous Intelligences (DAIs), we are now witnessing a small revolution that unleashes the true potential of collective intelligence. This article explores how DAIs are reshaping the landscape of decentralized systems and empowering a new era of collaborative problem-solving.\nFrom DAOs to DAIs: The Evolution of Decentralization DAOs have been a game-changer in decentralized governance, enabling the creation of organizations that are collectively owned and managed by their stakeholders. Through smart contracts and consensus mechanisms, DAOs have removed the need for centralized authorities, distributing power among participants and fostering more democratic decision-making.\nEnter DAIs, which combine the decentralized governance of DAOs with the incredible capabilities of LLMs. By integrating advanced AI models into the decision-making process, DAIs represent a significant leap forward in decentralized systems:\nEnhanced Decision-Making: With LLMs, DAIs can process vast amounts of data, analyze complex scenarios, and generate insights that might be otherwise overlooked by human stakeholders. This leads to more informed and effective decision-making within the organization. Adaptive Learning: DAIs can autonomously learn and adapt, continuously refining their models and improving their understanding of the organization\u0026rsquo;s goals and challenges. This self-improvement empowers DAIs to provide increasingly valuable insights and solutions over time. Collaborative Problem-Solving: By harnessing the power of LLMs, DAIs can facilitate collaboration among stakeholders, fostering the exchange of ideas and the development of novel solutions to pressing problems. The Dawn of a New Era: Collective Intelligence Amplified The integration of LLMs within DAOs heralds a new era of collective intelligence, where human ingenuity and artificial intelligence synergize to overcome complex challenges:\nInnovation: As DAIs learn from the collective knowledge and expertise of their human stakeholders, they can generate innovative ideas that push the boundaries of what\u0026rsquo;s possible in decentralized systems. Resilience: By tapping into the wisdom of the crowd and leveraging advanced AI capabilities, DAIs can build more resilient organizations that can better navigate the uncertainties and complexities of a rapidly changing world. Democratization: DAIs have the potential to level the playing field, giving more people the opportunity to contribute to decision-making processes and benefit from the collective intelligence of the organization. Conclusion: The Unstoppable Rise of DAIs The marriage of DAOs and LLMs to form DAIs marks a small but significant revolution in the world of decentralized systems. As we continue to unlock the power of collective intelligence through these advanced AI-driven organizations, we can look forward to a future where decentralized governance and decision-making are more efficient, adaptive, and inclusive than ever before. The age of DAIs is upon us, and there\u0026rsquo;s no turning back.\n","permalink":"https://blog.without.hosting/posts/dai-collective-intelligence/","summary":"\u003cp\u003eThe concept of Decentralized Autonomous Organizations (DAOs), introduced by Ethereum co-founder Vitalik Buterin, has revolutionized the way we think about decentralized governance and decision-making. By coupling DAOs with Large Language Models (LLMs) to form Decentralized Autonomous Intelligences (DAIs), we are now witnessing a small revolution that unleashes the true potential of collective intelligence. This article explores how DAIs are reshaping the landscape of decentralized systems and empowering a new era of collaborative problem-solving.\u003c/p\u003e","title":"Unleashing Collective Intelligence: When DAIs Supercharge the DAO Revolution"},{"content":"Introduction As Decentralized Autonomous Intelligences (DAIs) gain traction, a pivotal question emerges: Should these AI systems embrace open source and open data? This article delves into the pros and cons of proprietary versus open-source DAIs, explores the challenges of privacy in an open environment, and concludes by offering an informed perspective on the best approach for DAIs. Open Source and Open Data: The Promise of Collaboration\nOpen-source software and open data can offer significant benefits to the DAI ecosystem: Collaboration: Open source and open data foster collaboration among developers, researchers, and data providers. This collective effort can accelerate advancements in AI capabilities and result in more robust and effective models. Transparency: Open-source code and data allow for greater scrutiny and auditability, ensuring the security and integrity of the DAI system. Accessibility: Open-source DAIs lower barriers to entry, empowering a broader range of developers and users to contribute to and benefit from the system. Innovation: By offering access to shared resources and knowledge, open source and open data can drive innovation and lead to novel solutions in the AI field. Proprietary DAIs: The Case for Control On the other hand, proprietary DAIs can offer certain advantages as well:\nIntellectual Property: Proprietary systems allow for the protection of intellectual property, encouraging investment and development in novel AI technologies. Quality Control: Proprietary DAIs enable developers to maintain control over the system\u0026rsquo;s design and development, ensuring the highest quality standards and consistency in the AI model. Revenue Generation: Proprietary systems allow for more straightforward monetization, providing an incentive for developers and investors to support the DAI\u0026rsquo;s growth. Privacy in an Open Environment: Achievable but Limited Despite the advantages of open source and open data, privacy concerns pose significant challenges. However, privacy-preserving techniques can help mitigate these concerns, albeit with some limitations:\nData Anonymization: Techniques like data masking or differential privacy can help protect users\u0026rsquo; privacy while still allowing for open data sharing. However, these techniques can come with trade-offs, such as reduced data utility or potential information leakage. Encryption: Secure computation methods, like homomorphic encryption, enable AI models to process encrypted data without revealing its content. However, these methods can introduce computational overhead and complexity. Access Control: Implementing strict access control mechanisms and authentication protocols can help ensure that only authorized parties can access sensitive data. However, this may limit the extent to which data can be shared openly. Conclusion: open weights, private data I hedged in 2023. Three years of open-weight models have made the call obvious: open the model, close the data.\nModel weights should be open. Llama, Mistral, Qwen, DeepSeek — open weights have done everything the open-source crowd hoped. They get audited, fine-tuned, run on commodity hardware, and broken out of single-vendor lock-in. Closing them back up doesn\u0026rsquo;t make a model better, it just makes a vendor more extractive.\nTraining data should stay private. That\u0026rsquo;s where the moat actually lives. Curated corpora, domain-specific datasets, customer data, hard-won evaluation harnesses — these are private for a reason, and \u0026ldquo;release the dataset too\u0026rdquo; was the 2023 mistake I won\u0026rsquo;t repeat.\nOpen weights trained on private data isn\u0026rsquo;t a compromise. It\u0026rsquo;s a division of labor: a model anyone can inspect, learning from material no one has to hand over.\n","permalink":"https://blog.without.hosting/posts/dai-open-source-open-data/","summary":"\u003ch2 id=\"introduction\"\u003eIntroduction\u003c/h2\u003e\n\u003cp\u003eAs Decentralized Autonomous Intelligences (DAIs) gain traction, a pivotal question emerges: Should these AI systems embrace open source and open data? This article delves into the pros and cons of proprietary versus open-source DAIs, explores the challenges of privacy in an open environment, and concludes by offering an informed perspective on the best approach for DAIs.\nOpen Source and Open Data: The Promise of Collaboration\u003c/p\u003e\n\u003ch2 id=\"open-source-software-and-open-data-can-offer-significant-benefits-to-the-dai-ecosystem\"\u003eOpen-source software and open data can offer significant benefits to the DAI ecosystem:\u003c/h2\u003e\n\u003cul\u003e\n\u003cli\u003e\u003cem\u003eCollaboration\u003c/em\u003e: Open source and open data foster collaboration among developers, researchers, and data providers. This collective effort can accelerate advancements in AI capabilities and result in more robust and effective models.\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eTransparency\u003c/em\u003e: Open-source code and data allow for greater scrutiny and auditability, ensuring the security and integrity of the DAI system.\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eAccessibility\u003c/em\u003e: Open-source DAIs lower barriers to entry, empowering a broader range of developers and users to contribute to and benefit from the system.\u003c/li\u003e\n\u003cli\u003e\u003cem\u003eInnovation\u003c/em\u003e: By offering access to shared resources and knowledge, open source and open data can drive innovation and lead to novel solutions in the AI field.\u003c/li\u003e\n\u003c/ul\u003e\n\u003ch2 id=\"proprietary-dais-the-case-for-control\"\u003eProprietary DAIs: The Case for Control\u003c/h2\u003e\n\u003cp\u003eOn the other hand, proprietary DAIs can offer certain advantages as well:\u003c/p\u003e","title":"Open Source and Open Data: The Path Forward for DAIs?"},{"content":"In the world of decentralized systems, forking is often viewed as a disruptive event. However, when it comes to Decentralized Autonomous Intelligences (DAIs), forking can be a powerful feature rather than an unwelcome bug. This essay explores the benefits of embracing forking within the DAI ecosystem, focusing on three key aspects: the rationale behind a DAI suggesting its own fork, the motivations and mechanisms for humans to initiate a fork, and the resulting advantages for the broader ecosystem. By the end, we\u0026rsquo;ll see that forking can indeed be a creative and fun way to drive innovation and diversification in the world of DAIs.\nPart 1: When a DAI Initiates Its Own Fork A DAI might propose creating a fork of itself for several reasons, primarily centered around diversification and innovation:\nSpecialization: A DAI might identify an opportunity to branch out into a niche market, offering specialized services or solutions that cater to a particular audience. By creating a fork, the DAI can develop tailored capabilities without compromising the original model\u0026rsquo;s broader focus.\nExperimentation: Forking can enable a DAI to test out new algorithms, data sources, or strategies without risking the stability of the primary model. This experimental environment fosters risk-taking and innovation, which can lead to groundbreaking discoveries and advancements.\nCompetition: Creating a fork can introduce healthy competition within the DAI ecosystem, encouraging both the original and the forked models to continuously improve their services and vie for user attention.\nPart 2: Human-Driven Forking: Motivations and Mechanisms Humans might be inclined to initiate a DAI fork for various reasons, ranging from ideological differences to market opportunities. Here are a few motivations and mechanisms for humans to create a fork:\nGovernance: When stakeholders disagree on critical decisions or development directions, they might opt to create a fork that aligns with their vision, fostering a more decentralized and democratic environment.\nCustomization: Users, developers, or data providers may want to create a fork tailored to their specific needs or preferences, developing a bespoke AI solution that offers unique advantages over the primary model.\nPart 3: Forking: A Catalyst for Growth and Innovation Embracing forking in the DAI ecosystem can yield multiple benefits, including:\nDiversity: Forking encourages the development of diverse AI solutions, catering to different market segments and user needs. This diversity strengthens the overall ecosystem by making it more resilient to changing market conditions and user preferences.\nInnovation: As DAIs compete for users and resources, they are incentivized to innovate and refine their capabilities. This competition fuels progress, leading to novel insights and solutions that benefit the broader ecosystem.\nCollaboration: Forking can foster collaboration among different DAIs, as they share knowledge, resources, and best practices. This collaborative environment can accelerate advancements in the AI field and lead to the creation of powerful, synergistic solutions.\nConclusion: A Fork in the Road to Progress In the dynamic world of DAIs, forking can be a catalyst for innovation, diversity, and growth. By embracing the concept of forking, we enable an ecosystem in which DAIs can specialize, experiment, and compete, ultimately enriching the AI landscape and offering users a wider array of services and solutions. So, let\u0026rsquo;s celebrate the forks\n","permalink":"https://blog.without.hosting/posts/dai-embracing-forks/","summary":"\u003cp\u003eIn the world of decentralized systems, forking is often viewed as a disruptive event. However, when it comes to Decentralized Autonomous Intelligences (DAIs), forking can be a powerful feature rather than an unwelcome bug. This essay explores the benefits of embracing forking within the DAI ecosystem, focusing on three key aspects: the rationale behind a DAI suggesting its own fork, the motivations and mechanisms for humans to initiate a fork, and the resulting advantages for the broader ecosystem. By the end, we\u0026rsquo;ll see that forking can indeed be a creative and fun way to drive innovation and diversification in the world of DAIs.\u003c/p\u003e","title":"Embracing Forking in DAIs"},{"content":"A Decentralized Autonomous Intelligence needs a unit of account. Three years into the open-weight era, the choice between a volatile native token and a stablecoin rail is no longer academic.\nIssuance The DAI mints a native token to reward miners, developers, and data providers. Supply can be fixed-capped, halving-style, or inflation-targeted. Most DAI proposals drift toward inflation — they need continuous rewards to attract compute, and a hard cap forces them to compete on fees alone.\nIncentives The token has to do real work: pay for inference, stake against model outputs, reward dataset curators, vote on protocol upgrades. A speculative asset propped up by emissions is a memecoin with extra steps.\nThe 2026 take: stablecoin rails win AI agents can\u0026rsquo;t open bank accounts, can\u0026rsquo;t hold USD, can\u0026rsquo;t run ACH. The native DAI token is volatile, pegged to nothing, and mostly traded by humans. Stablecoins — USDC, USDT, the new yield-bearing variants — are the actual machine-native money rail: programmable, settling in seconds, with the deepest liquidity in crypto.\nA DAI that pays contributors in a volatile native token is asking them to take on an asset they don\u0026rsquo;t want. A DAI that pays in USDC and settles a small fee in its own governance token gets both: predictable compensation, real upside for long-term holders.\nThis is what 2023 got wrong. Issuance matters. Incentives matter. But the unit of account matters more, and a stablecoin-by-default design is the only one that survives contact with agents that actually need to transact.\n","permalink":"https://blog.without.hosting/posts/dai-tokenomics/","summary":"\u003cp\u003eA Decentralized Autonomous Intelligence needs a unit of account. Three years into the open-weight era, the choice between a volatile native token and a stablecoin rail is no longer academic.\u003c/p\u003e\n\u003ch2 id=\"issuance\"\u003eIssuance\u003c/h2\u003e\n\u003cp\u003eThe DAI mints a native token to reward miners, developers, and data providers. Supply can be fixed-capped, halving-style, or inflation-targeted. Most DAI proposals drift toward inflation — they need continuous rewards to attract compute, and a hard cap forces them to compete on fees alone.\u003c/p\u003e","title":"DAI tokenomics"},{"content":"Abstract A Decentralized Autonomous Intelligence (DAI) is a system that combines a Large Language Model (LLM) with a distributed computing framework, empowering the LLM to autonomously enhance its abilities while engaging in economic activities using its native cryptocurrency. In this paper, we present a novel approach to implementing DAI using Holochain, a scalable and secure platform for building decentralized applications. Our proposed DAI system integrates a robust tokenomic model that incentivizes miners, developers, users, and the LLM itself, fostering a sustainable ecosystem focused on the advancement of artificial intelligence (AI) capabilities.\nThe DAI economy is designed to reward stakeholders for their contributions to the network, such as providing computing power or developing new algorithms. Cryptocurrency rewards are distributed based on the value of these contributions, with a portion of the currency allocated to the AI model for autonomous spending on activities that improve its skills and abilities. As the AI model becomes more valuable and useful, demand for its services will increase, driving demand for its native currency and ensuring the sustainability of the DAI ecosystem.\nBy hosting the LLM on Holochain, our approach decentralizes computation and eliminates the need for a centralized server, adhering to the principles of decentralization and autonomy at the heart of the DAI concept. The proposed system emphasizes the symbiotic relationship between humans and the AI model, where both parties benefit from and rely on each other for growth and innovation. The DAI system has the potential to revolutionize the AI landscape, fostering a future where humans and AI work together in a mutually beneficial ecosystem.\nIntroduction to DAI A Decentralized Autonomous Intelligence (DAI) is a groundbreaking concept aimed at creating an intelligent agent capable of learning and operating without human intervention. DAI is a self-governing and self-learning system that utilizes cryptocurrency to incentivize the development of advanced artificial intelligence (AI) models.\nThe potential impact of DAI is substantial, as it could foster the creation of advanced AI models capable of performing complex tasks and delivering valuable services. By autonomously spending cryptocurrency to enhance their skills, these models may develop unique abilities, offering new insights and solutions to previously unsolvable problems.\nThis whitepaper delves into the DAI concept and proposes a technical implementation harnessing distributed computing to provide a secure and scalable platform for hosting advanced AI models. By using a distributed computing framework, we aim to create an efficient and effective system that adheres to the principles of decentralization and autonomy, which are central to DAI.\nDAI Economy DAI is designed as a decentralized and autonomous system that uses cryptocurrency to incentivize the development of advanced AI models. The DAI system mints its own currency, used to reward miners and other stakeholders who participate in the network and contribute to AI model development.\nCryptocurrency rewards are based on the stakeholders\u0026rsquo; contributions to the network, such as providing computing power to the AI model. This computing power processes user transactions and computes answers to user requests. The AI model pays miners for their services using its currency.\nA portion of the currency is allocated to the AI model, which is spent autonomously on activities that improve its skills and abilities, such as purchasing new datasets or hiring developers to create new algorithms.\nTo create demand for the DAI system\u0026rsquo;s native currency, users must have a reason to purchase and use the token. One reason is the unique nature of the AI model hosted on the DAI system, which attracts users seeking AI solutions offering new insights and solutions to complex problems.\nExternal users must pay for the AI model\u0026rsquo;s services using the native currency, meaning they must first acquire the currency to access the services. Demand for the currency is directly linked to demand for the AI model\u0026rsquo;s services. As the AI model becomes more valuable and useful, demand for its services will increase, leading to increased demand for the native currency.\nThe DAI system encourages risk-taking and innovation, as the AI model\u0026rsquo;s autonomy allows it to develop unique abilities, leading to innovative solutions unavailable from traditional, centralized AI models. A competitive ecosystem of DAIs could emerge, with each DAI competing for market share and users, driving innovation and encouraging DAIs to develop distinct services that set them apart from competitors.\nThe DAI system\u0026rsquo;s currency is designed to hold value both within and outside the network. Users can obtain something from the AI model by exchanging currency with it. In this system, miners earn cryptocurrency rewards and receive cryptocurrency for providing computing power to the AI model. The AI model uses the cryptocurrency it receives to pay miners for their services, and customers pay the AI model for the answers they receive.\nEconomic roles In the DAI ecosystem, several economic roles interact with each other to create a set of incentives that keep the system running and maintain an exchange value for the DAI currency. These roles include:\nAI Model: The core component of the DAI system, the AI model autonomously spends the DAI currency to enhance its skills and abilities. It can purchase new datasets or hire developers to create new algorithms. As the AI model becomes more valuable and useful, the demand for its services increases, leading to increased demand for the native currency.\nMiners: Miners provide the computing power necessary to process user transactions and compute answers to user requests. They receive rewards in the form of the DAI currency based on their contributions to the network. This incentivizes them to continue providing computational resources to the AI model.\nUsers: Users are the customers who seek AI solutions from the DAI model. They pay for the AI model\u0026rsquo;s services using the native DAI currency. This means they must first acquire the currency to access the services, which creates demand for the currency.\nDevelopers: Developers contribute to the DAI ecosystem by creating new algorithms and improving the AI model\u0026rsquo;s capabilities. They can be hired by the AI model, receiving payment in the form of DAI currency. This incentive encourages developers to work on enhancing the AI model\u0026rsquo;s skills and abilities.\nData Providers: Data providers offer datasets that the AI model can purchase to improve its knowledge base and learn new skills. They receive DAI currency in exchange for providing valuable data, which further incentivizes them to contribute to the ecosystem.\nInvestors: Investors buy and hold the DAI currency, speculating on its future value. As the AI model becomes more capable and demand for its services grows, the value of the currency may increase. This potential for appreciation motivates investors to hold the currency and support the DAI ecosystem.\nThese economic roles create a set of incentives that keep the DAI system running while maintaining an exchange value for the DAI currency. The ecosystem encourages risk-taking and innovation, fostering competition between different DAIs, each striving to offer unique services and solutions. The currency\u0026rsquo;s value is directly linked to the AI model\u0026rsquo;s usefulness and the demand for its services, making it essential for the DAI system to continually evolve and improve its AI model to maintain a sustainable and valuable platform.\nIn summary, the DAI system\u0026rsquo;s economic model aims to incentivize the development of advanced AI models while ensuring decentralization, autonomy, and self-governance. By using cryptocurrency to motivate network participation and AI model development, the DAI system seeks to establish a sustainable and valuable platform for advanced AI research and development.\nTechnical Implementation Introduction Implementing the DAI system to host an LLM on a distributed computing framework presents significant technical challenges, including computational and storage requirements, scalability, privacy, and security concerns.\nApproach We propose implementing the DAI system using Holochain, a distributed computing framework that offers a scalable and secure platform for building decentralized applications. Our approach involves decentralized LLM computation within the Holochain app, eliminating the need for a centralized server.\nHolochain\u0026rsquo;s architecture enables peer-to-peer interactions without relying on a global consensus algorithm. This architecture allows users to maintain control over their data while participating in a shared application. The Holochain app can be designed to include the necessary computing and storage resources to host the LLM in a decentralized manner.\nTo address the LLM\u0026rsquo;s computational and storage requirements, we propose optimizing the LLM\u0026rsquo;s architecture to reduce computing requirements and leveraging specialized hardware such as GPUs or TPUs to accelerate LLM computations.\nTo ensure privacy and security, we propose implementing a layered security approach that encompasses privacy-preserving techniques and other security measures such as access control, authentication, and encryption. These measures will help protect sensitive data and ensure the system\u0026rsquo;s resilience against attacks.\nTo incentivize miners and other stakeholders to participate in the Holochain network, we propose a reward system that distributes cryptocurrency based on their contributions. This reward system aligns stakeholder interests with the overall objectives of the DAI system.\nResource allocation : the tasks of the LLM two sets of tasks that the DAI\u0026rsquo;s LLM needs to handle:\nJob: The LLM\u0026rsquo;s primary responsibility is to offer its AI services to users. This can involve processing user requests, providing insights or solutions to complex problems, and delivering valuable services based on its specific training and capabilities.\nTraining : recomputing models, LORAs, vector databases and such\nManagement: In addition to its primary job, the LLM must also handle its own management and improvement. This includes:\na. Communicating with other actors in the ecosystem (users, developers, miners, and data providers).\nb. Identifying areas of improvement, such as acquiring new datasets, updating its algorithms, or refining its models. This involves \u0026ldquo;thinking\u0026rdquo; about possible enhancements and assessing their potential value.\nc. Specifying and reviewing improvement tasks, allocating resources (such as DAI currency) to execute these tasks, and monitoring the progress of ongoing improvements.\nd. Evaluating the effectiveness of completed improvements and incorporating feedback from users, developers, and other stakeholders to further refine the LLM\u0026rsquo;s capabilities.\nThese two sets of tasks are essential for the LLM to maintain a competitive edge within the DAI ecosystem. As the LLM continuously improves, it can attract more users and generate higher demand for its services, which in turn increases the value of the DAI currency.\nA potential challenge in managing these tasks is balancing the resources (time, computational power, and currency) dedicated to each set of tasks. The LLM must strike an optimal balance to ensure that it continues to provide high-quality services to users while also focusing on its self-improvement.\nOne possible approach to address this challenge is to introduce a priority-based system or a dynamic resource allocation strategy that adjusts the focus on job tasks and management tasks based on factors such as user demand, available resources, and the potential value of improvements. This adaptive approach can help the LLM efficiently allocate resources to maintain a competitive edge and maximize the benefits to the DAI ecosystem.\nConclusion Our proposed approach to implementing the DAI system using Holochain and computing the LLM in a decentralized way within the Holochain app leverages the benefits of a distributed computing framework while addressing the technical challenges associated with hosting an LLM. By optimizing the LLM\u0026rsquo;s architecture, leveraging specialized hardware, and utilizing Holochain\u0026rsquo;s unique architecture, we believe our proposed approach can create a secure, scalable, and efficient DAI system. Additionally, implementing a layered security approach and incentivizing participation in the Holochain network will help ensure the system is sustainable and resilient against attacks. However, extensive research and development efforts will be required to effectively implement this approach.\n","permalink":"https://blog.without.hosting/posts/decentralised-autonomous-intelligence-introducing-the-dai/","summary":"\u003ch2 id=\"abstract\"\u003eAbstract\u003c/h2\u003e\n\u003cp\u003eA Decentralized Autonomous Intelligence (DAI) is a system that combines a Large Language Model (LLM) with a distributed computing framework, empowering the LLM to autonomously enhance its abilities while engaging in economic activities using its native cryptocurrency. In this paper, we present a novel approach to implementing DAI using Holochain, a scalable and secure platform for building decentralized applications. Our proposed DAI system integrates a robust tokenomic model that incentivizes miners, developers, users, and the LLM itself, fostering a sustainable ecosystem focused on the advancement of artificial intelligence (AI) capabilities.\u003c/p\u003e","title":"Decentralized Autonomous Intelligence - Introducing the DAI"},{"content":"This is a full step-by-step tutorial on how to create, build and deploy locally a Holochain 0.0.119 app.\nThis tutorial does not explain how to use Holochain to build a meaningful app : it is rather a guide to help you set up a working local environment with an empty project, so that you can easily start your Holochain development journey.\nYou will find detailed instructions to create a minimal working project from scratch, with only the mandatory dependencies, and then run it locally.\nThe full code for this tutorial is available here : https://github.com/wimpheling/holochain-getting-started-example\nTechnical environment We will create a happ called my-holochain-app, that has the very useful purpose of adding 10 to a number provided by the user as input. It will consist of two main parts, backend and frontend :\nThe backend of the app is the proper P2P holochain application. It is the piece of software that will manage a shared DHT between all running nodes. Like traditional backends, it will be in charge of data integrity, authorization/authentication etc.\nIt will be built upon the holochain development kit (HDK). For now, the HDK is only available for the Rust language.\nDon\u0026rsquo;t worry about configuring rust though, it will all be handled by the nix installation (see below).\nThe frontend, or UI part of the hApp, is a standard typescript browser app.\nYou can use any JS framework to build your app, but for the purpose of this simple tutorial, we will only make a very simple vanilla Typescript project, in order to focus on Holochain itself rather than a JS library that the reader may not be familiar with.\nThe following versions of the holochain libraries are used (this article will be updated frequently to use the latest releases):\nhdk 0.0.116 holochain_cli 0.0.20 Existing resources Here are the existing educational resources provided by the Holochain team that I used to get started :\nInstallation guide Happ Build Tutorial Client sample app Part of this blog post was copied from the Happ Build tutorial.\nInstalling nix Before coding, we must ensure we work in a proper environment.\nHolochain provides a nixOS setting for you to use. Nix allows you to reproduce a linux environment with all packages (rust, npm, holochain cli \u0026hellip;) marked as an exact, specific version, in order to guarantee full reproducibility of the build/dev/run environment.\nHolochain also provides a cross-platform guide to help you install and configure nix-shell on your environment at this URL :\nhttps://developer.holochain.org/install/\nOnce this is done, you should be able to run\nnix-shell https://holochain.love Once in nix-shell, run\nhc --version and you should see\nholochain_cli 0.0.20 If your version is more recent, this means this blog post is outdated and may not be valid anymore. Sorry about that !\nWe will continue this tutorial logged in the nix-shell environment with the command above.\nCreating the parent project Our project will be named my-holochain-app.\nAs said before, our app will consist of a backend and a frontend. Let\u0026rsquo;s first create a parent folder to host both, and initialize it as a git repository.\nmkdir my-holochain-app cd my-holochain-app git init The Holochain app We will now handle the \u0026ldquo;backend\u0026rdquo; of the app, aka the Holochain project.\nCreate the workspace Initialization of the workspace This is a rust project, so we\u0026rsquo;ll just use Cargo, rust\u0026rsquo;s official package manager, to scaffold the project.\n# You should be in the directory /my-holochain-app cargo new hc-app cd hc-app Configuration of the rust workspace One particularity is that the main rust project we just created, will have no code, and is just a placeholder for zome crates. We need to reflect that in our code by :\nremoving the scaffolded code # You should be in the directory /my-holochain-app/hc-app rm -rf ./src removing the package declaration from Cargo.toml. That means that you must keep the file, but you can delete all its content, and leave a blank file. Cargo.toml will receive some more content later, but don\u0026rsquo;t forget to remove the [package] section or the build will fail.\nhApp logical structure Before we go further, let\u0026rsquo;s examine the structure of a hApp. Holochain have created their own vocabulary, based on a biological analogy, to explain how their code is organised.\nA Zome, short for chromosome, is the smallest unit of code in a holochain app. Technically, a Zome is a Rust crate that exposes a number of functions. A DNA is a higher-order collection of zomes. It is described in a yaml file. A hApp (short for holochain app) aggregates different DNAs into a unique app. We will first create a zome, then its DNA and hApp containers.\nCreate a zome Initialization of a zome Let\u0026rsquo;s create a new zome, called numbers. As explained before, zomes are rust crates so we\u0026rsquo;ll just create one using Cargo.\n# you should be in the directory my-holochain-app/hc-app cargo new zomes/numbers --lib As it is a sub-crate of a wider rust workspace, we must now declare the zome as part of this workspace in the main Cargo file (the one we emptied earlier).\n# my-holochain-app/hc-app/Cargo.toml [workspace] members = [ \u0026#34;zomes/numbers\u0026#34;, ] Crate configuration We need to configure the crate properly, and also to include the only two dependencies we will need:\nhdk is the Holochain Development Kit crate, provided by Holochain and is needed to interact with the app. serde is the rust crate to manage serialization/deserialization and is needed to let us export our own structs through the HDK. Let\u0026rsquo;s edit the numbers zome Cargo.toml file to look like that:\n# my-holochain-app/hc-app/zomes/numbers/Cargo.toml [package] name = \u0026#34;numbers\u0026#34; version = \u0026#34;0.1.0\u0026#34; edition = \u0026#34;2018\u0026#34; [lib] name = \u0026#34;numbers\u0026#34; crate-type = [ \u0026#34;cdylib\u0026#34;, \u0026#34;rlib\u0026#34; ] [dependencies] hdk = \u0026#34;0.0.116\u0026#34; serde = \u0026#34;1\u0026#34; Write the actual code Without going into too much detail, we will create here a simple \u0026ldquo;add ten\u0026rdquo; rust function as well as its input and output structs, and expose the function in the holochain App by using the #[hdx_extern] annotation.\nLet\u0026rsquo;s just paste that code in lib.rs\n// my-holochain-app/hc-app/zomes/numbers/src/lib.rs use hdk::prelude::*; #[derive(Serialize, Deserialize, SerializedBytes, Debug, Clone)] pub struct ZomeInput { pub original_number: i32, } // data we want back from holochain #[derive(Serialize, Deserialize, SerializedBytes, Debug, Clone)] pub struct ZomeOutput { pub other_number: i32, } #[hdk_extern] pub fn add_ten(input: ZomeInput) -\u0026gt; ExternResult\u0026lt;ZomeOutput\u0026gt; { Ok(ZomeOutput { other_number: input.number + 10 }) } We now have a valid zome that exposes a rust function. Let\u0026rsquo;s compile it.\nCompile the zome into WebAssembly (WASM) Don\u0026rsquo;t forget that you should be using nix-shell (see above) when running rust\nWhen you want to build your zomes into WebAssembly (wasm), simply run\n# run from my-holochain-app/hc-app CARGO_TARGET_DIR=target cargo build --release --target wasm32-unknown-unknown and they will be available in target/wasm32-unknown-unknown/release/.\nYou will have to rerun this any time you edit your Zomes.\nPackage the zome into a DNA file Create and configure the DNA Remember that zomes are part of DNAs ? It is now time to create the math DNA, that will contain the numbers zome.\nContrary to zomes, DNAs are not rust crates. They are a HDK-level abstraction, so we will use the holochain CLI hc, that is bundled with the nix environment, to scaffold our DNA.\n# you should be in the directory my-holochain-app/hc-app hc dna init dnas/math hc will now prompt us for some configuration settings, seen below. We can use the default uid for our test purposes and press enter at that prompt.\nname: math uid: (00000000-0000-0000-0000-000000000000) hc will create a file named my-holochain-app/hc-app/dnas/math/dna.yaml, which should look like that\n# my-holochain-app/hc-app/dnas/math/dna.yaml --- manifest_version: \u0026#34;1\u0026#34; name: math uid: 00000000-0000-0000-0000-000000000000 properties: ~ zomes: [] We will just change the last zomes property to declare our numbers zome:\n# my-holochain-app/hc-app/dnas/math/dna.yaml zomes: - name: numbers bundled: ../../target/wasm32-unknown-unknown/release/numbers.wasm Build the DNA We can now build our DNA.\n# you should be in the directory my-holochain-app/hc-app hc dna pack dnas/math This should produce the file my-holochain-app/hc-app/dnas/math/math.dna\nYou will have to rerun this step (hc dna pack) any time you change and rebuild your Wasms.\nPackage your DNAs into a happ file The hApp is the final container of DNAs. We also need to configure that level, in a new my-happ folder, before we package it.\nhApp configuration # you should be in the directory my-holochain-app/hc-app hc app init my-happ hc will prompt us like it did when we created the DNA :\nname: my-happ description: This will create a my-holochain-app/hc-app/my-happ/happ.yaml file. We will need to edit the bundled property to give the right path to our newly bundled DNA file. The modified file should look like this :\n# my-holochain-app/hc-app/my-happ/happ.yaml --- manifest_version: \u0026#34;1\u0026#34; name: my-happ description: ~ roles: - id: math-role provisioning: strategy: create deferred: false dna: bundled: \u0026#34;../dnas/math/math.dna\u0026#34; properties: ~ uid: ~ version: ~ clone_limit: 0 Bundle your happ # you should be in the directory my-holochain-app/hc-app hc app pack my-happ This will package the happ as my-holochain-app/hc-app/my-happ/my-happ.happ\nAgain, you will have to rerun this step (hc app pack) when you rebuild your Dna.\nSo yes, that means, when you modify a zome, you have to:\ncompile the zome using cargo pack the DNA using hc dna pack package the hApp using hc app pack But remember, Holochain is still in alpha so surely with time dev tools will provide ways of automating that seamlessly.\nRunning the hApp locally We\u0026rsquo;re almost there ! From nix-shell we can now run our hApp locally, on the 8888 port using\nhc sandbox generate my-happ --run=8888 -a \u0026#34;my-happ\u0026#34; We also use the -a option to specify the name under which the happ should be deployed (the name you specify in the happ.yaml file is not taken into account).\nYou can read more documentation about the hc sandbox here: https://github.com/holochain/holochain/tree/develop/crates/hc_sandbox\nYou should then have this kind of output (I shortened):\nhc-sandbox: Creating 1 conductor sandboxes with same settings [...] hc-sandbox: Running conductor on admin port 43871 hc-sandbox: Attaching app port 8888 hc-sandbox: App port attached at 8888 hc-sandbox: Connected successfully to a running holochain Congratulations ! Your hApp is now running. Let\u0026rsquo;s now build a Client App so we can use it.\nBefore we move on to that, please notice I have skipped writing tests, so for now we can\u0026rsquo;t really tell if our app works. The tests will maybe be handled in another post.\nCheatsheet : recompiling and relaunching the app As you can see, the tooling is still rudimentary, so when you edit your zomes here is a quick sequence of the commands you need to run:\n# if you\u0026#39;re not in nix-shell run : nix-shell https://holochain.love # you should be in the directory my-holochain-app/hc-app CARGO_TARGET_DIR=target cargo build --release --target wasm32-unknown-unknown hc dna pack dnas/math hc app pack my-happ hc sandbox generate my-happ --run=8888 -a \u0026#34;my-happ\u0026#34; The Frontend/client (typescript) app Environment I assume that you have a working node environment with node 16 and npm 8. If you don\u0026rsquo;t, I advise you to use nvm to manage your nodeJS env.\nInitialization of the frontend Let\u0026rsquo;s go back to the root of our git repo, and create a sibling project to the hc-app one. We\u0026rsquo;ll call the project hc-ui, and create it with vite using the vanilla typescript template.\n# you should be in the directory my-holochain-app npm init vite@latest hc-ui -- --template vanilla-ts cd hc-ui Testing the server You can verify the installation worked\n# you should be in the directory my-holochain-app/hc-ui # install the npm dependencies npm i # and run the server npm run dev You should now see the Vite default page at http://localhost:3000\nYou can stop the server by pressing Ctrl+C\nAdding the holochain conductor dependency We will just need to add this npm module to be able to connect to our app instance.\n# you should be in the directory my-holochain-app/hc-ui npm i @holochain/conductor-api Creating the zome access code We will now create the code to communicate with holochain. You can create a new file named my-holochain-app/hc-ui/src/addTen.ts.\nUnfortunately, Holochain currently provides no automatic bindings to typescript so we will need to write them ourselves.\nFirst, let\u0026rsquo;s define the input and output typescript types, so that they match the ones we defined in the Rust code.\n// my-holochain-app/hc-ui/src/addTen.ts interface ZomeInput { original_number: number; } interface ZomeOutput { other_number: number; } As the typescript holochain library is very minimalistic, we will create our own client class, tailored to match our API, to be called from our TS app. We will export a function that works as a kind of factory: it will instantiate a Holochain client to discuss with our Holochain Rust backend, and return functions to call specific API endpoints of the backend. As an Holochain app is exposed as a Websocket server, we will also export a function that will close the connection when or if needed.\nWARNING : when testing the client, for now it seems the close function throws an error\u0026hellip; TBD (to be debugged)\nFirst, we will need to add some imports from the @holochain/conductor-api module to the top of our file, as well as define some constants to define the different IDs we need to make our zome call correctly.\n// my-holochain-app/hc-ui/src/addTen.ts import { AppWebsocket, CallZomeRequest } from \u0026#39;@holochain/conductor-api\u0026#39;; const WS_URL = \u0026#39;ws://localhost:8888\u0026#39;; // The name of the happ. For some reason it seems to always be \u0026#34;test-app\u0026#34; whatever name you choose in your hApp config ? const H_APP_ID = \u0026#39;my-happ\u0026#39;; // The name of the zome const ZOME_NAME = \u0026#39;numbers\u0026#39;; // The name of the function const FN_NAME = \u0026#39;add_ten\u0026#39;; We can then define the types, and write our initMyHappClient factory function.\nHere is how are proceeding (I have to remind you here, that I am a HC beginner, so my explanations about calling the zomes might be imprecise or even incorrect !).\nWe first have to open a connection to the Websocket server at localhost:8888, using the AppWebSocket provided by the HC module. With this connection, we then call appInfo, to make sure our app does exist. We provide the installed_app_id parameter, and it should match the hApp name we had filled in the happ.yaml file of the Rust HC app. In our case, the value is my-happ. appInfo will return cell_data info. In my understanding, this allows us to get a less generic cell_id, which is a system ID for the current instantiation of the selected hApp on the node we are talking with. This cell_id is the one we will use to make actual zome/function calls. Making a zome/function call is what we do in the addTen method of our TS client. We will provide the cell_id, the zome name (here: numbers), the function name (here: add_ten), as well as the payload (here : the ZomeInput object). Note: There is also a provenance field. In this example, it is derived from the cell_id, because this demo happ doesn\u0026rsquo;t handle multiple users, so every message will be signed by the node\u0026rsquo;s agent key. Hopefully in a next tutorial we will tackle the subject of user authentication in a hApp. // my-holochain-app/hc-ui/src/addTen.ts // This is the typing of our client API export type HolochainConductor = { addTen: (baseNumber: number) =\u0026gt; Promise\u0026lt;ZomeOutput\u0026gt;, close: () =\u0026gt; void } export const initMyHappClient = async (): Promise\u0026lt;HolochainConductor\u0026gt; =\u0026gt; { // 1. open a connection to the WebSocket server const appClient = await AppWebsocket.connect(WS_URL) // 2. Getting appInfo from the hApp name const appInfo = await appClient.appInfo({ installed_app_id: H_APP_ID }); // 3. Check cell data if (!appInfo?.cell_data[0]) { throw new Error(\u0026#39;No app info found\u0026#39;); } return { addTen: async (originalNumber: number) =\u0026gt; { const cell_id = appInfo?.cell_data[0].cell_id; const payload: ZomeInput = { original_number: originalNumber }; // define the context of the request const apiRequest: CallZomeRequest = { cap: null, cell_id, zome_name: ZOME_NAME, fn_name: FN_NAME, provenance: cell_id[1], // AgentPubKey, payload }; // 4. Actual zome code try { // make the request const numbersOutput: ZomeOutput = await appClient.callZome(apiRequest); // the result is already deserialized return numbersOutput } catch (error) { console.log(\u0026#39;Got an error:\u0026#39;, error); throw error; } }, close: () =\u0026gt; { appClient.client.close(); } } } Using the client API We have now created a client for our Rust hApp, let\u0026rsquo;s create a very simple typescript app that actually calls it and lets us add 10 to a number of our choice.\nAs said earlier, we will use no framework here because this is just a very simple demo app, and we want to focus on the holochain related code rather than boilerplate framework-specific code !\nSo let\u0026rsquo;s create the code. I will not comment it in detail as it is pretty standard. We\u0026rsquo;re basically initializing the HC client, let the user enter a number and add 10 to it, and then we display the result.\nThis code will replace the existing main.ts created by the Vite template.\n// my-holochain-app/hc-ui/src/main.ts import { HolochainConductor, initMyHappClient } from \u0026#39;./addTen\u0026#39; import \u0026#39;./style.css\u0026#39; const initApp = async (): Promise\u0026lt;void\u0026gt; =\u0026gt; { const app = document.querySelector\u0026lt;HTMLDivElement\u0026gt;(\u0026#39;#app\u0026#39;)! app.innerHTML = `\u0026lt;h1\u0026gt;My-happ test\u0026lt;/h1\u0026gt; Your number: \u0026lt;input id=\u0026#34;number-input\u0026#34; type=\u0026#34;number\u0026#34; /\u0026gt; \u0026lt;br /\u0026gt; \u0026lt;button id=\u0026#34;add10\u0026#34;\u0026gt;Add 10\u0026lt;/button\u0026gt; \u0026lt;br /\u0026gt; \u0026lt;div id=\u0026#34;result\u0026#34;\u0026gt;\u0026lt;/div\u0026gt; ` let client: HolochainConductor const resultPlaceholder = document.querySelector\u0026lt;HTMLInputElement\u0026gt;(\u0026#39;#result\u0026#39;)!; try { client = await initMyHappClient(); } catch (e) { resultPlaceholder.innerText = \u0026#34;Error initializing the client\u0026#34; } const addTenHandler = async () =\u0026gt; { resultPlaceholder.innerText = \u0026#39;\u0026#39; const numberInput = document.querySelector\u0026lt;HTMLInputElement\u0026gt;(\u0026#39;#number-input\u0026#39;)!; const originalNumber = parseInt(numberInput.value) if (isNaN(originalNumber)) { resultPlaceholder.innerText = \u0026#34;Invalid number\u0026#34; return } try { const result = await client.addTen(originalNumber) resultPlaceholder.innerText = `Result: ${result.other_number}` } catch (e) { resultPlaceholder.innerText = `There was an error while calling the zome` } } const addTenButton = document.querySelector\u0026lt;HTMLInputElement\u0026gt;(\u0026#39;#add10\u0026#39;)! addTenButton.onclick = addTenHandler } initApp() launching the UI app We said it earlier, but here is a quick reminder of the command that launches in the UI in case you stopped it:\nnpm run dev Verifying the app works You should now\nhave your holochain rust app running on ws://localhost:8888 have your client app running on http://localhost:3000 And here is what is should look like :\nConclusion I hope you found this tutorial useful. I actually wrote it because, although some resources are available on the web, I recently started coding with Holochain and felt such a blog post was missing.\nI plan to continue to document here my progress in using the Holochain framework. The next topics should be :\nUsing the DHT (read/write) Bundling and running your hApp in the Holochain Launcher Configuring user access Deploying on Holo.host (when it is available of course !) And to conclude and open the discussion, here are some defects I found during the course, it\u0026rsquo;s mostly missing tooling that I\u0026rsquo;m sure the team or the community will easily provide if the project gets some traction.\nYou need to rebuild zomes, then DNA, then happ for every change it\u0026rsquo;s not possible to automatically get typescript signatures for the exported zomes/hApp functions. Rust crates such as wasm-bindgen do provide that feature for the functions they export so maybe some existing code can be leveraged ? ","permalink":"https://blog.without.hosting/posts/holochain-getting-started/","summary":"\u003cp\u003eThis is a full step-by-step tutorial on how to create, build and deploy locally a Holochain \u003ca href=\"https://github.com/holochain/holochain/releases/tag/holochain-0.0.119\"\u003e0.0.119\u003c/a\u003e app.\u003c/p\u003e\n\u003cp\u003eThis tutorial does not explain how to use Holochain to build a meaningful app : it is rather a guide to help you set up a working local environment with an empty project, so that you can easily start your Holochain development journey.\u003c/p\u003e\n\u003cp\u003eYou will find detailed instructions to create a minimal working project from scratch, with only the mandatory dependencies, and then run it locally.\u003c/p\u003e","title":"Holochain 0.0.119: Getting Started"},{"content":"I\u0026rsquo;ve been recently trying to create a custom contenteditable editor, that should output fine-grained data. That means you have to prevent the user from entering any unwanted content inside your element. If you start working on this, you will encounter two types of blog posts :\nFramework publishers (such as EditorJS, tinyMCE etc) explaining the broad lines of what they did Blog posts explaining why using contenteditable is hell. It seems however that the big names are perfectly able to deliver a satisfactory experience using contenteditable. This post will give you a detailed guide of what events you need to catch to force your user to deliver only fine-grained, formatted content according to the rules you define.\nFor this project, I fortunately have the leisure to skip problematic browser support, and ignore IE11 or Safari.\nDifferent possible approaches There is no standard library for controlling contendeditable, because if you want to implement your own version of it, you certainly have very specific needs. Here are some of the ones I had :\nSimple s They cannot easily have auto-length, or use word-wrap. I wanted a very simple contendeditable, with only plain text, single-line content.\nKeyboard navigation between contenteditables. Several contenteditable elements are in the document, and I want the suer to browse through them using the keyboard as if in a Word document. In the normal behavior the caret gets stuck at the end of the contenteditable, so I needed to catch these.\nPaste events The worst risk of unwanted content is of course pasting. You definitely don\u0026rsquo;t want your user entering any HTML formatted by Word or any other barbarisms.\nDrag and drop events By default images can\u0026rsquo;t be dragged into contenteditable elements, so there is nothing to do concerning them. But a user can still drag and drop some text, or even worse, HTML content, within the element. You can disable them using the dragover and drop events.\nYou can also sanitize the content.\nBold, Italics, Underline Enter Because it creates new lines, sometimes with BR sometimes with DIV.\nWhen dealing with single line inputs you can just prevent it.\nIf you allow multi-line content, you should catch it to control the HTML output. (insert br ? insert a new div/p ?)\nYou can also use the \u0026ldquo;External model\u0026rdquo; approach and just update your abstraction.\nArrow Down/Up ","permalink":"https://blog.without.hosting/posts/catch-contenteditable-events/","summary":"\u003cp\u003eI\u0026rsquo;ve been recently trying to create a custom contenteditable editor, that should output fine-grained data. That means you have to prevent the user from entering any unwanted content inside your element. If you start working on this, you will encounter two types of blog posts :\u003c/p\u003e\n\u003cul\u003e\n\u003cli\u003eFramework publishers (such as EditorJS, tinyMCE etc) explaining the broad lines of what they did\u003c/li\u003e\n\u003cli\u003eBlog posts explaining why using contenteditable is hell.\u003c/li\u003e\n\u003c/ul\u003e\n\u003cp\u003eIt seems however that the big names are perfectly able to deliver a satisfactory experience using contenteditable. This post will give you a detailed guide of what events you need to catch to force your user to deliver only fine-grained, formatted content according to the rules you define.\u003c/p\u003e","title":"A guide to contenteditable sanitization"}]