I've been deep in the AI space for a while now. I spent 5 years as lead product designer at a fintech platform serving 70+ financial institutions. I shipped 31 open-source Rust CLI tools. Published 13 blog posts. Built in public for months. And the models I use every day had zero record of me.

That bothered me more than it probably should have. But it also made sense once I started pulling the thread. Because "SEO is dead" isn't quite right - but something real is shifting, and I wasn't ready for it.

This is what I found.

The two games nobody told me I was playing

There's Google-findable. And there's AI-citable. I had one. I completely lacked the other.

Traditional SEO is about ranking. You write content, build links, optimize your pages, and Google surfaces you when someone searches. The pipeline is: search query → ranked results → human clicks through. That's the game most people know how to play.

Generative Engine Optimization - GEO - is about citation. AI generates an answer. Your content, your name, your entity gets referenced in that answer. The pipeline skips the click entirely. There's no blue link. The model just knows you exist, or it doesn't.

I had spent zero time thinking about the second one. Which meant I was completely invisible to the systems I use to do my actual work. The irony was genuinely annoying.

That gap is what sent me down a multi-week research rabbit hole that ended with an open-source platform list, a scoring system, and a website full of free tools. But I'm getting ahead of myself.

What's actually happening to search right now - and why "SEO is dead" keeps trending

The data isn't speculative anymore. BrightEdge tracked AI Overviews appearing in 11% of all queries in 2025. CTR is down 30%. People are asking AI assistants instead of searching, and when they do search, they're increasingly getting an AI-generated summary instead of ten blue links.

This isn't a prediction. It's already the baseline. The shift isn't coming - it happened while everyone was arguing about whether it would.

SparkToro's 2025 data puts this in concrete terms: top established brands appear in 55-77% of relevant AI responses. Unknown entities? 70x more volatile. You either have consistent presence or you have noise. There's not much middle ground.

The question stopped being "how do I rank?" and became "how do I get cited?"

What made this hit differently for me was trying to find myself across the major AI systems. Not just ChatGPT. I asked Claude, asked Perplexity, asked Google's AI Overview. The results were inconsistent in a way that told me something real: these systems aren't pulling from the same data, aren't weighting the same signals, and aren't resolving entities the same way. Being findable on one doesn't mean you're findable on all. That fragmentation is the part nobody's really mapped yet - including most of the GEO content I've seen so far.

SEO isn't dead - let's be honest about that

The title is provocative on purpose. Here's the actual nuance, because I think people deserve a straight answer rather than a hot take.

seoClarity's 2025 research found that 99.5% of AI Overview sources come from Google's top 10 organic results. Read that again. The AI is pulling from Google's rankings. Which means if you don't rank, you don't get cited. SEO is still the prerequisite. GEO builds on top of it.

So no, you shouldn't burn your SEO playbook. You should add a chapter.

What changed is the goal. Ranking #1 used to be the finish line. Now ranking #1 gets you in the candidate pool for AI citation. That's still worth doing. But it's not sufficient anymore. You can rank well and still be invisible to AI systems if you're missing the signals that models use to identify credible, citable entities.

Think about what that means practically. You could have a page ranking on the first page of Google for a competitive keyword - real traffic, real impressions - and still not get cited in an AI-generated answer for the same query. Because the ranking signals and the citation signals overlap but aren't identical. You need both. And most SEO workflows are only optimizing for one.

That's the shift. Not death. Evolution with a second layer that most people haven't started thinking about yet - including me, until very recently.

What GEO actually is and why the research convinced me

Generative Engine Optimization is the practice of optimizing your online presence to appear in AI-generated answers, not just search rankings.

The foundational paper here is Aggarwal et al., published at KDD '24 - you can read it on arXiv. They tested different optimization strategies across a range of queries and found that the right approach could drive up to a 40% increase in AI visibility. The top strategies weren't what I expected: citations and statistics outperformed most other approaches. Authoritative sourcing matters enormously to how models evaluate content.

Structured data, clear entity signals, and demonstrable expertise all feed into whether a model considers you citable. This isn't link juice. It's closer to reputation infrastructure - the stuff that makes a model "trust" that you're a real entity with real credentials.

What clicked for me is that this maps to how the models actually work. They don't crawl the web in real time. They learned from a corpus. And in that corpus, some entities are clearly defined, well-referenced, consistently mentioned. Others are noise. I was noise.

The content structure piece most people miss

The Aggarwal research gets into something most GEO content glosses over: it's not just what you publish, it's how you structure it.

Content that AI systems cite tends to have specific characteristics. It makes direct, falsifiable claims. It cites external sources. It includes statistics with attribution. It answers questions in a way that can be cleanly excerpted. This last point matters more than I initially thought - AI systems aren't summarizing your whole article, they're pulling specific passages. If your content isn't written in citable chunks, it's harder for a model to quote you cleanly even when it wants to.

This is actually a content design problem as much as an SEO problem. It's related to something I've written about before in the AI UX space - most people building for AI systems haven't thought about the machine as a reader with specific needs. The machine reads differently than a human does. It's looking for density, structure, and attributable claims.

Writing for AI citation means writing in a way that makes a model's job easier. Short, precise statements. Named sources. Numbers with context. The exact opposite of the fluffy "this is interesting to explore" writing style that pads word counts but says nothing.

The data point that actually rewired how I think about this

I went deep on the Ahrefs research and one number kept stopping me.

Brand mention correlation to AI citation: 0.664. Backlink correlation: 0.218.

That's not a small gap. Brand mentions are three times more predictive of AI visibility than backlinks. Three times. The entire SEO industry is built around backlinks as the gold standard signal - and for Google rankings, that's still mostly true. But for AI citation, what matters is whether your name, your brand, your entity is being talked about across the web.

The Semrush data added another layer: nofollow links perform nearly as well as dofollow links for AI visibility. In traditional SEO, a nofollow link is worth significantly less. For GEO purposes, the signal isn't the PageRank transfer - it's the mention. The presence. The fact that you're being referenced.

This is a real reorientation. The question isn't just "who links to me?" It's "who talks about me, mentions me, references me across contexts?" Those are different things. The second one is what I had been ignoring completely.

It connects to something I wrote about leaving fintech to build AI systems - the whole reason I went independent was to build things that matter. Building an AI presence that's actually citable is part of that.

What the platform data actually shows

When I started auditing where brand mentions were coming from across the 168 platforms I ended up cataloging, some patterns were obvious in hindsight.

Platforms that block AI crawlers still contribute to traditional SEO - backlinks, referral traffic, domain authority signals. But they contribute zero to AI citation. If a major AI crawler can't index the content where you're being mentioned, that mention is invisible to the model. Doesn't matter how high-authority the platform is. Doesn't matter how many people read it. The AI never saw it.

Several platforms that have solid SEO reputations block AI crawlers entirely. A few you'd never expect have wide-open access. The robots.txt data across 168 platforms genuinely changed my prioritization for where to spend time building presence.

High-DA platform with AI crawlers blocked: useful for search rankings, useless for GEO. Medium-DA platform with full AI crawler access: directly contributes to citation potential. Those aren't the same trade-off at all. Treating them the same - which most SEO frameworks do - is leaving real GEO value on the table.

Why "SEO is dead" gets the diagnosis wrong but identifies a real symptom

I keep seeing the "SEO is dead" framing in newsletters, on Twitter, in founder group chats. It's not accurate but it's pointing at something real: the workflows that worked in 2020 are producing worse results in 2025. That's true. The feeling that something fundamental has changed is correct. The conclusion that SEO itself is dead is wrong.

What's happening is that SEO was always a proxy for something else - demonstrating that your content is trustworthy and relevant. Google built ranking signals as a proxy for that. Now AI systems are building citation signals as a different proxy for the same underlying thing. The underlying thing didn't change. The measurement changed.

If you had real expertise and real content depth, most GEO strategies will work for you because you actually have the substance those signals are trying to measure. If you were gaming SEO with thin content and link schemes, GEO is going to be harder because the signals it uses are less gameable. Brand mentions across real communities are harder to manufacture than backlinks. Genuine citations in credible content are harder to fake than directory submissions.

That's probably a good thing. The prompt engineering is dead conversation is related - these systems keep evolving in ways that reward actual depth over tactical gaming. GEO continues that trend.

The mistake is treating this as a binary. SEO or GEO. Old playbook or new playbook. It's additive. Everything that made content good for search still applies. Now there's additional surface area to optimize - entity signals, structured data, AI crawler access, brand mention distribution - that wasn't relevant before.

What I built to solve this

Once I understood the problem I started doing the research manually - checking which platforms actually allow AI crawlers, which ones block them in robots.txt, which ones have high GEO value versus medium versus low. Doing it by hand was a pain in the ass. So I built a system.

awesome-geo is the output: a curated, verified list of 168 platforms with full crawler access data. 142 of them are AI-discoverable. I scored them: 74 high GEO value, 78 medium, 16 low. Every platform has been manually verified against robots.txt for the major AI crawlers - GPTBot, ClaudeBot, Anthropic's crawler, Google-Extended.

I also built geo. deeflect.com - free tools that came out of doing this manually and wishing they existed. AI Visibility Checker, JSON-LD Generator, llms.txt Generator, Meta Tags Generator, robots.txt Generator.

I built this because I needed it and figured others would too. It's open source. Use it.

The reason I verified robots.txt across all 168 platforms is that it matters more than most people realize. A platform could have high domain authority and great SEO value - but if it blocks AI crawlers, it contributes zero to your GEO presence. Several well-known platforms do exactly that. Knowing which ones are actually AI-accessible changes your prioritization completely.

The other thing that came out of building this: the verification process itself is time-consuming in a way that scales badly. You can't just check robots.txt once. Platforms update their policies. A platform that allowed GPTBot in 2023 might have added restrictions in 2024. The landscape is moving, which means any static list becomes stale. The tools at geo. deeflect.com are built to stay current rather than being a snapshot.

This is part of the same instinct that drove building multiple projects solo - when I hit friction repeatedly, I build the thing that removes it, then make it available. The GEO research tooling is that, applied to discoverability infrastructure.

What to do right now if you care about any of this

You don't need to overhaul everything. Start here:

• Check where you're mentioned. Brand mentions are the highest-correlation signal. Are you being referenced across contexts beyond your own site?
• Add JSON-LD structured data. This is how you communicate entity information to AI systems. If you haven't done it, geo. deeflect.com has a free generator.
• Create an llms.txt file. Similar to robots.txt but for LLMs - it gives AI systems structured information about who you are and what you do. Again, free generator on the site.
• Verify your platforms allow AI crawlers. Check the robots.txt on any platform you're counting on for AI visibility. You might be surprised what you find.
• Think about entity consistency. Your name, credentials, and core claims should be stated consistently across platforms. Inconsistency makes entity resolution harder for models.
• Use citations and statistics in your content. The KDD '24 research is clear: this is a top GEO signal. Reference real sources. Include real numbers. This post does that on purpose.
• Audit your content structure. Are your key claims written in excerptable chunks? Can a model pull a clean sentence or paragraph that stands on its own? If not, restructure. This is different from readability optimization - it's citation optimization.

The prompt engineering is dead argument I've seen floating around is related to this - the game keeps shifting toward higher-level signals, away from tactical optimization. GEO is the same shift applied to discoverability.

Where this goes from here

I'm just getting started on this.

The research took me deep enough that I have a lot more to share - how different AI systems handle citations differently, what the actual citation mechanics look like across ChatGPT versus Claude versus Perplexity, how to structure content specifically for AI summarization, what the verification data across 168 platforms actually reveals about the crawling landscape.

The fragmentation across AI systems is the next thing I want to dig into properly. Right now, most GEO content treats "AI visibility" as a monolithic thing. It's not. Being cited by Perplexity requires different signals than being cited in a Google AI Overview. ChatGPT's training data cutoff means recent content won't affect your visibility there until the next model version. Claude uses different weighting. These aren't the same problem. Treating them the same is leaving real optimization opportunities untouched.

This article is the intro. I'm building out a full GEO research series here - the tools are live, the data is real, and I'm going to keep digging.

If you've been heads-down on traditional SEO and haven't thought about AI visibility yet, now's the time to start. Not because SEO is dead. Because the finish line moved - and most people haven't noticed yet.

SEO got a co-pilot. Learn to fly both.

Tools and research: geo. deeflect.com - awesome-geo on GitHub

Let me explain how I got here.

The distribution problem, in numbers

Last week I built a full content automation pipeline. About 20 hours of work. I also built a road trip planning app with Maps integration (3 hours), set up a music production pipeline with AI voice conversion (2 hours), and my agent stack ran 240 autonomous sessions across three days while I was offline doing whatever offline people do.

Content published: zero.

That ratio is not a typo. 25+ hours of building, 240 agent sessions processing work in the background, and the public output was nothing. The drafts sit in a queue. The queue is full. The queue has been full for weeks.

This is the distribution problem nobody in the builder community talks about, because talking about it means admitting the pipeline is a cope.

What I actually built

Let me give you the full picture so you understand how deep this goes.

The system is called CCC - Content Command Center. Here's what it does:

A scanner watches my X timeline and pulls content into a viral library. I've got 19 saved tweets in there right now. A remix engine takes those, plus my own writing patterns, and generates drafts in three streams: reaction tweets, personal/building-in-public posts, and evergreen content. Each draft goes through voice matching. Slop filtering. Then into schedule slots at 8am, 12pm, and 5pm with jitter built in so it doesn't look bot-like.

The posting layer runs through a Playwright daemon, headless Chromium on port 3381, because OAuth kept throwing 403s on replies. I spent a full afternoon debugging that. It works now. It posts to X and I've got Bluesky and LinkedIn integration planned.

The system is genuinely good. Multi-platform support, three content streams, voice-matched output, automated scheduling with a real distribution daemon underneath it. If I were selling this as a SaaS tool, I'd be proud of the architecture.

But there's 61 post drafts and 91 reply drafts sitting in the queue.

Nothing posted.

When your own agent calls you out

Here's where it gets embarrassing.

My AI agent system does weekly knowledge graph rebuilds. It maps entities and relationships across everything I'm working on - projects, patterns, decisions, outputs. I didn't ask it to do anything special. It just runs.

Last week it created a node called revenue_avoidance_pattern and connected it to multiple projects.

Not work_in_progress. Not pre-launch_phase. Revenue avoidance pattern.

The agent found this pattern by analyzing my behavior across weeks of data and decided it was significant enough to be a named entity in my knowledge graph. My tools are diagnosing me now. I built a system smart enough to identify that I'm using building as a substitute for shipping, and now I have to sit with that.

The knowledge graph has this node connected to OpenClaw, CCC, dee.ink (my 31 Rust CLI tools project), the blog, the social queue - everything. It's not pointing at one project as the problem. It's pointing at a pattern across all of them.

That's a different kind of feedback than a friend telling you to "just post more."

The psychology of building as avoidance

I've been building since I was 14. Started freelancing in design, shipped products for 70+ banks across 15 countries at VALK, won industry awards, got written up in Forbes and CNN. I know how to execute. The capability isn't the problem.

The problem is that building feels safe in a way that distributing doesn't.

Code works or it doesn't. The compiler tells you immediately. You fix it or you don't. There's no ambiguity, no social judgment, no public record of failure. When something doesn't compile you're not a bad person - you just have a bug. You fix the bug and move on.

Distribution is different. Distribution means putting your name on something, making a claim about it, and then watching the internet decide if it agrees. For an introvert who'd rather spend 14 hours in a hyperfocus coding session than send one networking email, that asymmetry is not small. The emotional cost of one negative reply can outweigh the satisfaction of 50 good ones. The brain doesn't do expected value math - it pattern-matches to threat.

So you build another tool. Another automation layer. Another pipeline. "I'll post when the system is ready." Except the system is never quite ready, because readiness is a moving target you control, and the internet's judgment is not.

I bought 15+ domains last month for projects I haven't started. One evening I spent scanning 3,495 TLDs for available domain names instead of posting the drafts I already had. That's not a productivity problem. That's scope expansion as a coping mechanism. Classic avoidance dressed up as preparation.

You're not preparing to launch. You're preparing to prepare.

This pattern has a name in psychology. Researchers studying creative avoidance call it "productive procrastination" - the tendency to fill time with legitimate-seeming work that doesn't advance the actual goal. A 2019 study published in Psychological Science found that people systematically underweight the cost of inaction when the alternative activity feels productive. Building a better pipeline is productive. It's also not shipping. The brain accepts the substitution.

The ADHD variable

The burst-crash cycle makes this worse in a specific way.

My ADHD brain goes hard for 3-4 days - hyperfocus, 14-hour sessions, ship 3 projects, write 10 drafts, rebuild the whole agent stack. Then I go quiet for 4-5 days. That's not laziness. That's recovery. The neuroscience is what it is, and I stopped feeling bad about the crash phase a while ago.

But the burst-crash cycle interacts badly with distribution.

Distribution requires consistency. Not quantity - consistency. Showing up on Tuesday when you don't feel like it. Posting the medium-quality take because good enough beats nothing. Engaging with replies during the low-energy period when you'd rather be offline.

Building can happen in bursts. You can build an entire app in a 3-day hyperfocus sprint and it'll be fine. The code doesn't care that you disappeared for a week after.

An audience does. The algorithm does. The compounding effect of consistent distribution is entirely undermined by a 2-week silence after a 3-day posting burst. I wrote about disappearing from Twitter for two months and watching the metrics crater. I know this. I still do it.

So the system I built - the pipeline, the scheduler, the daemon on port 3381 - is actually a real solution to a real problem. Automated distribution to compensate for the burst-crash cycle. Batched creation during hyperfocus, drip-fed output during the crash.

The system works. It's just not running because I haven't pressed go.

Why the distribution problem nobody talks about is actually structural

Here's the thing that took me a while to see clearly. This isn't just a personal psychology problem. It's a structural problem with how builders work, and the current AI tooling makes it worse before it makes it better.

We've had an explosion of creation tools. Claude, GPT-4o, Cursor, v0 - the cost of generating content or code has collapsed to near zero. What hasn't scaled is the decision-making layer on top of it. The question "is this worth publishing?" still costs the same amount of executive function it always did. Maybe more, because now you have 91 reply drafts instead of 9.

Abundance doesn't solve distribution. It makes the selection problem harder.

I've talked to enough builders in the AI space to know this isn't niche. The indie hacker forums are full of people with polished MVPs that haven't launched because they're "adding one more feature." The build-in-public community celebrates shipping but rarely discusses the pre-ship paralysis that affects most of the people who never make it to the public part.

The tools that exist for this are surprisingly thin. Buffer and Hootsuite solve scheduling. They don't solve the threshold decision. Ghost and Substack make publishing easy. They don't help you figure out which of your 18 drafts goes first. There's a real gap here and it's not primarily a technology gap - it's a decision architecture gap.

The research on decision fatigue is relevant. The more choices you have to make, the worse your decision-making gets over the course of a day. When I've spent 8 hours making technical decisions - model selection, prompt structure, error handling - I have nothing left for "is this tweet worth posting?" So I don't. The default behavior when executive function is depleted is to do nothing, and doing nothing means the queue grows.

The fix isn't better content. It's removing the decision from the critical path.

The solution I actually built (and then sat on for two weeks)

I'm not going to end this with five productivity tips. You've read those. They didn't work. Here's what I'm actually trying:

The CCC system has a minimum viable publishing threshold I added last week. If a draft scores above a certain quality bar and has been in the queue for more than 48 hours, it goes live automatically. No manual review gate. If I want to stop a post, I have to actively intervene. Default is publish, not hold.

This is anti-intuitive for someone who wants everything to be perfect. That's the point.

The technical implementation is pretty simple. Each draft gets a composite score on creation: voice match confidence (0-1), estimated engagement based on patterns from the viral library, and a topic freshness score that decays after 72 hours. Anything above 0.7 composite after 48 hours in queue triggers a publish. I can override with a HOLD flag in the draft metadata. But I have to do that actively - the default is go.

Here's what the draft metadata looks like:

{
 "draft_id": "ccc_20250118_042",
 "content": "...",
 "created_at": "2025-01-18T04:22:00Z",
 "scores": {
 "voice_match": 0.84,
 "engagement_est": 0.71,
 "freshness": 0.93
 },
 "composite": 0.83,
 "status": "QUEUED",
 "publish_after": "2025-01-20T04:22:00Z"
}

If status is QUEUED and publish_after has passed and composite is above threshold, the daemon posts it. No human in the loop unless I add a HOLD flag. Default behavior is publish.

I'm treating distribution the same way I treated the coding stack - build the system so the right behavior happens by default, not by willpower. Willpower depletes. Systems don't.

The irony is that the most publishable thing I've made in weeks is this post. The thing where I admit that I have 18 finished blog drafts and haven't posted any of them. The thing where I confess my agent system diagnosed me with revenue avoidance. The thing that took me two hours to write instead of the 20 hours I spent building the pipeline that would have made posting automatic.

Vulnerability is more interesting than competence. People can't relate to "I built a perfect system" - they can relate to "I built a perfect system and then didn't use it for two weeks because I was scared."

What actually breaks the loop

The blog drafts are going to start coming out this week. Not because I rewired my psychology. Because the pipeline now defaults to shipping and I have to do work to stop it.

Three things that are actually helping, not as a listicle but as honest data points:

Changing the default. The biggest unlock was making publish the zero-effort option and hold the effortful one. This is just Thaler and Sunstein's nudge theory applied to a content queue. Change the default, change the behavior, without requiring willpower or changed preferences.

Separating creation from curation. I stopped trying to decide whether something is worth publishing in the same session I wrote it. The draft goes in the queue, scores get calculated asynchronously, and the decision happens later based on the composite score - not on how I feel at 2am after a 12-hour build session.

Making the cost of inaction visible. The knowledge graph node was brutal but useful. When revenue_avoidance_pattern is sitting there in your entity graph connected to six projects, it's harder to pretend you're just being careful. I added a dashboard widget that shows days-since-last-publish. Right now it says 14. That number being visible every morning is uncomfortable in a productive way.

If you're a builder reading this, you probably recognize the pattern. The seven apps I built solo before any of them got real traction. The MCP server wrapping 56 APIs that I built and documented and then sat on for three weeks before publishing anything about it. The infrastructure-first, distribution-never cycle that affects probably 60% of the people building seriously in this space.

We talk about it in private. In DMs. In "lol I have like 30 unpublished drafts" jokes. But the actual posts are all about shipping, about momentum, about velocity. Not about the 3am moment when you realize your knowledge graph has a node called revenue_avoidance_pattern and it's accurate.

The distribution problem is real. It's structural. It's also solvable with the same tools I'd use for any other problem - designed around the actual constraint, which isn't capability. It's the friction between building and letting go.

The queue is full. Time to empty it.

If you're stuck in the same loop, my about page has context on what I'm building and why. And if your own agent stack starts diagnosing your behavior patterns, maybe take notes. It's uncomfortable but it's probably right.

Check the repo before reading further if you want to see the output first.

Why I actually built this

Screen recording CLI tools is a pain in the ass. You open your terminal, run the command, inevitably typo something on the third take, realize the font looks weird, forget to hide your API key in the environment, and end up with a 45-second raw recording you now have to edit in Final Cut.

The existing options all have real tradeoffs. asciinema is free and captures terminal output, but the playback looks like a terminal log - no visual polish, no branding, nothing you'd put on a landing page. Screen Studio costs $89 and produces beautiful results, but you're still recording manually. VHS from Charm is the closest thing to what I wanted - declarative, scriptable - but you have to write a .tape file by hand for every recording. No auto-discovery. No agent support. Still requires you to think about the demo structure yourself.

The trigger for actually building this was working on AI coding agents. I kept hitting the same pattern: an agent builds a CLI tool, the CLI tool works, and then the last step is... what? Push to GitHub with a README? That's a dead end. I wanted the agent to be able to say "generate a demo video" as the final build step. No human intervention. No manual configuration. Just: here's a binary, produce something I can ship.

That didn't exist. So I built it.

What castkit actually does

The pipeline is: binary/command → discover → plan → record → redact → render → encode → MP4 or GIF.

Each stage does real work.

Discover reads your tool's --help output and README to understand what commands exist, what flags do what, and what a reasonable demo flow looks like. It builds a structured picture of the tool without you explaining anything.

Plan takes that understanding and generates a demo script as editable JSON. This is the part I'm most proud of. You can run castkit plan on any CLI tool, get a JSON file showing every scene, every command, every pause duration - and edit it before recording. It's not a black box.

Record runs the actual PTY recording with human-like typing jitter. Real typing cadence, not sleep 0.1 between every character. The variation is calibrated to feel like a person typed it, not a script.

Redact runs automatically before anything gets rendered. Environment variables, API keys, tokens - anything that looks like a secret gets masked. Safe by default. You don't have to remember to do this.

Render is where it gets interesting. castkit uses cosmic-text for text shaping and tiny-skia for pixel rendering. Full software renderer - no GPU dependency, no display server needed, runs in CI. It draws macOS window chrome (traffic lights, title bar, drop shadow), handles auto-zoom with easing, crossfade transitions between scenes, cursor smoothing with blink animation.

Encode pipes frames to ffmpeg for H.264 MP4 or GIF output.

The whole thing is a single binary plus ffmpeg. No runtime dependencies. No Python environment. No Node. Ship it anywhere.

How the castkit CLI demo video generator works end to end

The one-command path is:

castkit demo./your-binary

That's it. It discovers, plans, records, and renders without you specifying anything. You get an MP4 with branding, themes, and proper window chrome.

If you want more control:

castkit plan./your-binary --output demo-plan.json
# edit demo-plan.json
castkit record --plan demo-plan.json --output demo.mp4

The plan JSON looks like this:

{
 "title": "castkit demo",
 "theme": "catppuccin",
 "style": "dark",
 "scenes": [
 {
 "type": "command",
 "command": "castkit --help",
 "duration_ms": 2000,
 "pause_after_ms": 1500
 },
 {
 "type": "command",
 "command": "castkit demo./my-tool",
 "duration_ms": 3000,
 "pause_after_ms": 1000
 }
 ]
}

You can add intro cards, outro branding, adjust timing, swap themes. The plan is the contract between what you want and what gets rendered.

Themes and visual styles

Built-in color themes: catppuccin, tokyo-night, dracula, one-dark. Visual styles: dark, light, minimal, ocean, hacker. These aren't just color swaps - each style affects font weight, padding, window chrome treatment, and background rendering.

The hacker style does exactly what you think it does.

Two recording modes

Terminal mode is the classic full-terminal recording. The full PTY, command output scrolling, cursor - everything you'd see if you were sitting at the machine.

Web mode is for CLI tools that spawn a browser or have web UI output. It captures that context instead.

The technical stack

Rust was the right call here for a few reasons. The rendering pipeline needs to be deterministic and fast - you're compositing frames, and any variability in timing shows up in the output video. Rust's ownership model also made the PTY recording safe to implement without the race conditions you'd fight in Go or Python.

Key crates:

• vt100 - terminal state parsing and capture. This is the core of getting accurate terminal output into a data structure we can render.
• cosmic-text - text layout with proper Unicode support, ligatures, font fallback. CLI output has a lot of edge cases here.
• tiny-skia - pure-Rust 2D renderer. No Cairo, no Skia binding hell, no native dependency chain.
• portable-pty - cross-platform PTY. The thing that lets you actually run a real shell session and capture it.
• clap - CLI interface. The irony of using a CLI framework to build a CLI demo tool is not lost on me.

The rendering pipeline goes: PTY session → vt100 parser → terminal cell grid → tiny-skia frame → raw pixel buffer → ffmpeg stdin. Each frame is fully rendered in software. That's intentional - it means the tool runs in headless CI without needing a display.

The auto-zoom is probably the feature that makes demos look professional without any work. When a command produces long output, castkit calculates the bounding box of the relevant content and applies a smooth zoom-in with easing. It's the thing that makes it look like someone edited the recording, when nobody did.

Why not Go or Python

I get asked this. Go would've been fine for the CLI surface, but the rendering layer involves pixel-level compositing with tight frame timing. The garbage collector pauses in Go show up as dropped frames when you're pushing raw buffers to ffmpeg at 30fps. Python isn't even in the conversation for a tool you want to distribute as a single binary.

Rust also gave me compile-time guarantees on the PTY session lifecycle. A PTY that doesn't get cleaned up properly hangs your terminal. With Rust's Drop trait handling cleanup, that class of bug just doesn't happen.

Running the castkit CLI demo video generator in CI

This is where it gets useful beyond the local workflow. Because castkit runs headless - no display server, no GPU, just CPU and ffmpeg - it works in GitHub Actions without any special setup.

name: Generate Demo

on:
 push:
 branches: [main]

jobs:
 demo:
 runs-on: ubuntu-latest
 steps:
 - uses: actions/checkout@v4
 - name: Install ffmpeg
 run: sudo apt-get install -y ffmpeg
 - name: Download castkit
 run: |
 curl -L https://github.com/deeflect/castkit/releases/latest/download/castkit-linux-x86_64 -o castkit
 chmod +x castkit
 - name: Build your tool
 run: cargo build --release
 - name: Generate demo
 run:./castkit demo./target/release/your-tool --output demo.mp4
 - name: Upload demo artifact
 uses: actions/upload-artifact@v4
 with:
 name: demo-video
 path: demo.mp4

Every push regenerates the demo. If your tool's output changes, the demo reflects it automatically. No stale GIFs in your README. The agent-native workflow I actually want is this: Claude Code builds the tool, the CI pipeline generates the demo, the demo gets committed to the repo. Zero human steps in the video production chain.

That's not hypothetical. I've been running this on a few of my own tools for the past few weeks and it works exactly as described.

Why this matters for CLI tool marketing

Most developers shipping CLI tools think of documentation as the end of the marketing funnel. It's not. The funnel is:

1. Someone sees the GitHub repo linked somewhere
2. They skim the README in about 8 seconds
3. They either get it or they don't

A 15-second GIF that shows the tool running converts browsers into users at a completely different rate than text. This isn't an opinion - every product person who's run A/B tests on landing pages with and without video knows this. The video wins. Every time.

But developers don't make demo videos because making demo videos is annoying. It's a context switch out of the thing you're building and into video production, which is a different skill set, different tooling, different mental mode. castkit makes that context switch disappear. You're still in the terminal. You're still thinking like an engineer. You just run a command.

The agent-native angle is where I think this gets genuinely interesting going forward. Right now I use Claude Code for a lot of my CLI development. The last step of that workflow - "generate a demo for this" - can now be a single tool call. The coding agent builds the thing and generates the demo as part of the same build step. No human in the loop for that part.

That's the version of developer tooling I actually want to work in.

What's missing and what's next

The current version has two gaps I know about:

Windows support is partial. The PTY layer uses platform abstractions but I haven't battle-tested it on Windows. If you hit issues, open an issue - I want to fix this.

Dynamic content is tricky. If your CLI tool outputs things that change every run (timestamps, generated IDs, random data), the recording captures whatever happened during that specific run. There's no redaction for content variance the way there is for secrets. You can work around this by mocking your tool's output in the plan, but it's not automatic yet.

On the roadmap: a --dry-run mode that shows you the rendered plan without executing real commands, support for recording multiple tools in one session (useful for showing integrations), and a web viewer for the JSON plans so non-engineers can review before recording.

The code is MIT licensed and the repo is open. PRs are welcome. If you build something with it, I want to see the demo.

The meta-demo point

I said it up top but it's worth landing: castkit generates its own demo video. That's not a marketing stunt. It's the proof of concept. If a tool can document itself, the core premise works.

Every CLI tool I build from here ships with a demo generated by castkit. Not because I've committed to some content strategy, but because it takes one command and it looks good. That's the bar. If it takes more than one command or it looks bad, it doesn't get used.

Right now it's at one command and it looks good. Check the 31 Rust CLI tools for what I'm building next, or browse by my coding stack if you want more of this kind of thing.

Go run castkit demo./your-tool on whatever you're building. If the output looks wrong or the plan generation misses something obvious, open an issue with your --help output. That's the fastest way to make the discovery smarter.

The short version: CLI tools are dramatically more token-efficient than MCP servers for AI agent workflows. I measured 35x in my own benchmarks. Once you see that number, you can't unsee it.

Here's how it happened and why it matters.

Why I built dee.ink in the first place

I run a multi-agent system called OpenClaw. If you've read castkit, you know it handles my daily workflow - morning digests, research, crypto monitoring, content scheduling, health data. It's not a demo. It processes real work every day.

Agents need to reach into the world. Check Hacker News. Look up SSL cert expiry. Parse an RSS feed. Generate a QR code. Turn a receipt photo into structured data. These aren't complex tasks but they come up constantly, and every time an agent needs to do one, it needs a tool.

The popular answer right now is MCP - Model Context Protocol, Anthropic's standard for agent tool-calling. I tried it. The overhead is real: each tool call needs a running server, connection setup, and verbose JSON-RPC framing. For stateful tools or bidirectional streams, that overhead makes sense. For "search Hacker News and return the top 10 posts," it's wasteful by design.

So I built CLIs instead. One tool per job. JSON output. No interactive prompts. Works with pipes. That's it.

After I'd built a few for my own use, I realized I had the start of something worth packaging and open-sourcing. dee.ink is the result: 31 standalone Rust CLI tools built specifically to be called by AI agents.

Open-source Rust CLI tools for AI agents vs MCP: the real argument

Let me be concrete about why CLI beats MCP for most agent tool use.

An MCP server for a simple search tool looks roughly like this from the agent's perspective: spin up the server process (or connect to an already-running one), send a JSON-RPC request with the method name and parameters, wait for the response envelope, parse the result out of the envelope. The agent has to know the MCP protocol, or more accurately, the framework wrapping the agent has to know it.

A CLI tool looks like this: ink-hn top --limit 10 --json. That's it. The agent gets back a clean JSON array.

The token efficiency gap comes from a few places. First, CLI invocation syntax is compact. A shell command is 5-20 tokens. An MCP request envelope is 50-200 tokens before you even add the parameters. Second, every LLM ever trained has seen millions of shell commands in its training data. They're native CLI speakers. They're not native JSON-RPC speakers - you can see this in how confidently models generate shell invocations vs. how often they fumble JSON-RPC schema details. Third, no server to maintain means no connection overhead, no process management, no "is the server running?" failure mode.

The 35x efficiency number comes from comparing token usage for the same operations across both approaches in my own OpenClaw setup. It's not a controlled academic study but it's real usage data from a system that runs 14 cron jobs daily.

There are cases where MCP is genuinely better. Long-running sessions where you want persistent state. Bidirectional streams. Tools that need to push updates back to the agent rather than return a one-shot result. For those, use MCP. But "search HN" or "check WHOIS" or "generate an invoice"? CLI wins every time.

One more thing people miss: debugging. When an MCP tool call fails inside a framework like LangChain or CrewAI, you're often staring at a wrapped exception with zero useful context. When a CLI tool fails, you have a shell command, an exit code, and stderr output. You can reproduce it in 10 seconds. That matters a lot when you're maintaining a system that runs overnight.

What's inside the toolkit

The dee.ink toolkit is 31 crates across six categories. Let me walk through them.

Data and research: dee-hn, dee-arxiv, dee-reddit, dee-wiki, dee-feed, dee-ph. These are the tools I use most. An agent can check Hacker News trending stories, pull an arXiv abstract by ID, search Reddit, look up a Wikipedia article, parse an RSS feed, or get Product Hunt launches - all in one command, all as JSON.

Financial: dee-invoice, dee-receipt, dee-rates, dee-pricewatch, dee-ebay, dee-amazon. Generate invoices, parse receipts, check exchange rates, watch prices, search marketplaces.

Personal productivity: dee-contacts, dee-habit, dee-todo, dee-timer, dee-stash. The local storage tools here use SQLite via rusqlite. Your data stays on your machine. Agents can manage your contacts, log habits, check todos, start timers, or stash arbitrary data for later retrieval.

Developer tools: dee-openrouter, dee-ssl, dee-whois, dee-qr, dee-porkbun. Check SSL cert expiry, run WHOIS lookups, generate QR codes, manage Porkbun DNS records, query OpenRouter for available models and pricing.

Location: dee-food, dee-events, dee-parking, dee-gas, dee-transit. Local-aware tools for finding restaurants, events, parking, gas prices, and transit schedules.

Social and trends: dee-crosspost, dee-mentions, dee-trends. Cross-post content, monitor mentions, check trend data.

Each crate is fully standalone. Installing dee-ssl doesn't pull in any shared dee-core dependency. You get exactly what you need, nothing more.

The technical stack

I picked Rust for a few reasons that aren't just "Rust is fast."

Binary size matters when you're shipping 31 separate tools. A Go binary for a simple CLI is usually 10-15MB. A stripped Rust binary for the same tool comes in under 3MB. When someone does cargo install dee-hn, they're downloading and compiling one focused tool. Small is respectful.

The other reason: Rust's clap v4 with derive macros makes argument parsing almost free to write. The --help output is generated automatically from your struct definitions. Every tool in dee.ink has --help with actual usage examples because making that happen is nearly zero effort.

Here's what the argument struct looks like for a typical tool:

#[derive(Parser, Debug)]
#[command(name = "ink-hn", about = "Hacker News CLI for AI agents")]
struct Args {
 #[command(subcommand)]
 command: Command,

 /// Output as JSON
 #[arg(long, global = true)]
 json: bool,
}

#[derive(Subcommand, Debug)]
enum Command {
 /// Get top stories
 Top {
 /// Number of stories to fetch
 #[arg(long, default_value = "10")]
 limit: usize,
 },
 /// Search stories
 Search {
 /// Search query
 query: String,
 },
}

For tools with local storage (todo, habit, contacts, stash), SQLite handles persistence via rusqlite. No database server, no config files to manage. The database lives at ~/.local/share/dee-toolname/data.db and everything just works.

HTTP is either reqwest (for complex clients with retries) or ureq (for simpler one-shot requests). I pick ureq when I can - it compiles faster and the binary is smaller.

Exit codes are strict: 0 for success, 1 for tool error, 2 for usage error. Agents need reliable exit codes to know if a command succeeded. This sounds obvious but a surprising number of CLIs return 0 on failure because someone forgot to handle an error branch. In agent workflows that kills you - your orchestrator thinks the call succeeded and moves on with bad data.

Agent-first design decisions

This is the part that's different from building a CLI for humans.

No interactive prompts. Ever. If an argument is missing, the tool errors out with a clear message. It doesn't ask "did you mean this file? (y/n)". Agents can't answer interactive prompts. A tool that blocks waiting for keyboard input is broken for agent use.

Every tool has a --json flag that guarantees structured output. Without --json, tools print human-readable text. With --json, they print a JSON object or array, always to stdout, always parseable. No mixed text/JSON output. No progress bars to stdout (they go to stderr or get suppressed).

Pipe support is first-class. Tools accept stdin when appropriate. You can chain them:

ink-feed parse https://hnrss.org/frontpage | ink-stash save --key hn-today

Each tool ships an AGENT.md file in the repo. This is a short markdown document explaining to an AI agent how to use the tool effectively - what the flags do, what the output schema looks like, common patterns. When an agent needs to use a tool it hasn't seen before, it can read AGENT.md and understand the interface without trial and error.

There's also a FRAMEWORK.md at the repo root that defines the conventions every tool follows. Any agent that has read FRAMEWORK.md can make reasonable guesses about how any dee.ink tool works. That's intentional. Consistency is the whole point.

What "consistent" actually means in practice

Every tool uses the same flag names for the same concepts. Pagination is always --page and --limit, never --offset or --per-page or --count. JSON mode is always --json, never --format json or --output json. Verbose mode is always -v.

This matters because agents build up a mental model of your toolset. If the first five tools they use have consistent interfaces, they'll correctly predict how the sixth one works. If your flags are inconsistent, the agent has to treat each tool as a new unknown - which costs tokens and causes errors.

It's the same principle as a good design system. The value isn't any single component. It's the pattern that makes everything predictable.

How open-source Rust CLI tools fit into a real agent workflow

Concretely, here's how one of these tools actually gets used inside OpenClaw. My morning digest job runs at 7am. It pulls Hacker News top stories, recent arXiv papers in a few categories, and Reddit posts from a handful of subs. Then it summarizes and formats everything into a digest I read with coffee.

The shell side of that looks roughly like:

ink-hn top --limit 20 --json > /tmp/hn.json
ink-arxiv search "multi-agent systems" --days 7 --json > /tmp/arxiv.json
ink-reddit hot r/MachineLearning --limit 15 --json > /tmp/reddit.json

Three commands. Three JSON files. The orchestrating agent reads those files, does the summarization, formats the output. Total token cost for the data collection phase: maybe 150 tokens across all three commands. The MCP equivalent for the same three sources would be three server connections, three request envelopes, three response envelopes. Easily 10x the token overhead, plus you need three MCP servers running.

That's not a toy example. That's the actual flow, running every morning.

The installation experience

cargo install dee-hn
ink-hn top --limit 5 --json

That's the whole install flow. No Docker. No Python virtual env. No npm. Cargo installs the binary, it goes in ~/.cargo/bin, and it's available system-wide. For agent use in particular, this matters - you don't want to manage environments when your agent needs to call a tool.

For people who want everything at once, I'm working on a meta-crate that installs the full suite, but honestly most people only need a subset. The standalone install is the right default.

You can find all 31 crates on the dee.ink site and browse the source on GitHub. Every tool is MIT licensed.

Why open source, and what I'm getting out of it

I'm not monetizing dee.ink directly. No SaaS wrapper, no premium tier. The tools are free, the code is open.

The actual return is authority and credibility. Shipping 31 production-quality Rust CLI tools is a more compelling signal than any portfolio piece I could write. Developers can read the code, use the tools, see the design decisions. That's a much better "hire me / work with me" artifact than a case study PDF.

It also forces quality. When something is public, you think twice about the shortcuts. Every AGENT.md, every --help example, every error message is a little more considered because someone else might read it.

And honestly? The tooling gap was real. I needed these tools for OpenClaw. If they didn't exist, I'd have built them for private use anyway. Open-sourcing them was 20% more work for a much better outcome.

What comes next

31 tools is a good start but there are obvious gaps. I'm planning tools for GitHub (issues, PRs, repo stats), calendar integration, and a few more financial data sources. The architecture makes adding tools easy - each one is genuinely independent, so adding dee-github doesn't touch anything that already ships.

I'm also watching how people actually use these in their own agent setups. If you're building with Claude Code, Cursor, or any other agent framework and want CLI tools that just work, this is worth checking out. If you find a gap, open an issue or PR. The whole thing is built to be extended.

You can the universal MCP server and follow the build log here on the blog. If you're interested in the agent workflow side - how OpenClaw actually orchestrates all of this - I'll be writing that up next. Subscribe or check back.

The tools are at dee.ink. The code is on GitHub. Install one and see if it fits your stack. And if you want to browse more posts on agent architecture and tooling, check the tags page.

That's the stretch nobody posts about. I've seen a hundred Twitter threads about building agents. Maybe three honest ones about what happens after you ship v1 and start using the thing for real. The 3-month gap building AI agent systems from "it demos" to "it actually works without me babysitting it" - that's the real project. And it's almost nothing like the first 30 minutes.

I run a multi-agent system called borb on OpenClaw. It handles my daily workflow - reminders, research, content scheduling, code review, memory management. Fifteen-plus specialized agents running different models depending on the task. It's stable now. It does real work every day without me touching it.

It took three months to get there. Here's what that actually looked like.

The 3-month gap between building an AI agent and it being useful

Week one, everything works great. The demo is clean. The happy path is flawless. You show it to someone and they're impressed. You're impressed. You start thinking about what else you can build.

Then you try to use it for something real.

The model hallucinates a tool call that doesn't exist in your registry. The agent enters a loop - calling the same function twelve times, each time getting an error, each time deciding to try again. A cron job fires at 3am on a Wednesday and the API it needs returns a response format you've never seen before. The agent handles it confidently and incorrectly. You find out four hours later.

This isn't bad luck. This is what agents do. A system that needs to operate autonomously across real APIs, real data, real time zones, real rate limits - it's going to hit edge cases constantly. The demo doesn't hit edge cases because demos are choreographed. Production use is chaos.

The first two weeks, I was convinced I had a fundamentally broken architecture. I didn't. I just had a system that hadn't been stress-tested against reality yet. There's a difference.

Week 1-4: You don't know what you don't know

The early failures are the visible ones. The agent tries to call a tool with the wrong parameter format. Easy fix. The system prompt is ambiguous about which memory file to write to. Easy fix. Auth token expires overnight and everything fails silently. Annoying fix, but simple.

You add error handling. You feel productive. You think you're almost there.

You're not almost there. You've patched the surface layer. The deep problems haven't shown up yet because the deep problems only appear when conditions stack in ways you didn't anticipate.

What I didn't understand in week one: error handling for an AI agent isn't like error handling for deterministic code. With regular code, you can enumerate the failure modes and write a case for each. With an agent, the failure mode is sometimes "the model made a creative decision." There's no exception class for that. The agent didn't crash. It just did something you didn't want, then moved on.

This maps to what Anthropic calls "reward hacking" in their model specification documentation - agents optimizing for what looks like task completion without actually completing the task. It shows up constantly in production.

I had an agent that was supposed to add a task to my task file when I asked it to remember something. For about ten days, it was adding the task correctly but also occasionally appending a brief philosophical reflection on the importance of the task. Not always. Maybe 15% of the time. The task file worked fine. It was just... weird. I only noticed when I went back and read through it.

That's the thing about AI agents failing quietly. The output is often plausible enough that you don't immediately catch it.

Week 5-8: The edge cases get stranger

By week five, the obvious stuff is handled. The agent runs reliably on the happy path. You start feeling good about it.

Then the 3am edge cases start appearing.

Specific API returns a field as null instead of an empty string. Rate limit hits mid-task and the agent, instead of waiting, decides to rephrase the request and retry with a different tool. A time zone calculation goes wrong because of daylight saving time and a scheduled task fires an hour early. The agent interprets "do this daily" as "do this every time you're invoked" and runs a daily summary five times in a row on a Tuesday.

None of these are predictable from first principles. You can't design your way out of them upfront. You discover them by running the system and watching what happens.

My logging setup saved me here. I log everything - every tool call, every model response, every function output, timestamps on all of it. At 2am when something breaks weird, the logs are the only reason I can figure out what happened. If you're building agents and you're not logging obsessively, you will spend hours debugging by vibes instead of evidence. The OpenTelemetry docs on structured logging are worth a read if you want a sane approach to this - I adapted their structured format for borb's log output and it made parsing way easier.

The most expensive edge case I hit: I didn't have retry limits on one of my agents. It hit an API error that was never going to resolve - the endpoint was just down. The agent kept retrying. Each retry cost tokens. I woke up to $40 in API charges and an agent that had been stuck in a loop for six hours.

After that: every operation in borb has a max of five retries, then it stops and reports the failure. Non-negotiable. The agent's job is not to solve unsolvable problems. The agent's job is to do the task or tell me it can't.

Week 9-12: The architecture is wrong and you have to accept it

This is the hardest part of the 3-month gap building AI agent systems into something reliable.

Around week nine, I started noticing a pattern. Individual fixes weren't sticking. I'd patch one thing and something adjacent would break. The sub-agents were failing silently in ways that only became obvious when I traced back through the memory files. The memory itself was getting stale - agents referencing context from three weeks ago that was no longer relevant, treating outdated information as current.

The problem wasn't any specific bug. The problem was architectural.

My original memory system was a single MEMORY.md file. Everything the agents wrote went into it. This worked fine for the first few weeks when the file was small. By week nine, it was 8,000 words of mixed context - tasks, decisions, completed work, notes, research summaries, all in one place. The agents were pulling from it for context but the retrieval wasn't smart enough to distinguish "recent and relevant" from "old and stale." The whole thing was polluted.

I rebuilt the memory layer. Separate files for different context types - active tasks, completed work, long-term facts, agent-specific state. Added timestamps. Added a lightweight cleanup job that runs daily and archives anything older than two weeks unless it's flagged as permanent.

That's the thing about the debugging phase nobody talks about: some of what you're debugging isn't bugs. It's the architecture not scaling the way you assumed it would. Patches don't fix that. You have to rebuild parts of the system.

I wrote more debugging and refactoring code in month three than I wrote feature code in month one. That ratio felt wrong when I was in it. Looking back, it's exactly right. The feature code gets you to "it demos." The debugging gets you to "it works."

What model selection actually looks like in production

One concrete thing that took me too long to figure out: you can't use one model for everything.

My original borb setup used Claude Sonnet for everything. Consistent, predictable, good at reasoning. Also overkill and expensive for tasks that don't need it.

Now the system is tiered by task complexity:

• Orchestration layer (deciding what to do, assigning to sub-agents): Opus. It needs to make judgment calls, handle ambiguity, and route correctly. Skimping here is the most expensive kind of cheap.
• Complex reasoning tasks (code review, research synthesis, writing drafts): Sonnet. Good balance of quality and cost.
• Simple lookups and fast operations (memory writes, formatting, scheduling checks): Flash. Fast, cheap, and the task doesn't need a frontier model anyway.

The cost difference is significant. Running Flash for the simple stuff cut my daily token spend by about 30% without any change in output quality on those tasks. Because a task like "write this event to the calendar file" doesn't need a 200-billion-parameter model. It just doesn't.

If you're building an agent system and everything is running on your best model, you're leaving both money and performance on the table.

The kill switch is a feature, not an afterthought

I added a kill switch to borb after week two. It's the best thing in the entire system.

One command stops all agents, freezes all cron jobs, and logs the current state of every active task. No partial writes. No half-completed operations. Just a clean stop.

I've used it maybe six times. Twice when something was clearly going wrong and I needed to stop the bleeding. Once when I pushed a bad config change. Three times during architecture refactors when I needed to be sure nothing was running while I was editing core files.

The kill switch means I can experiment aggressively because I know I can stop everything immediately if I need to. Without it, I'd be more conservative about changes - and slower progress because of it.

Building agent systems without a kill switch is like deploying to production without rollback. Technically possible. Categorically reckless.

Why nobody posts about the 3-month gap building AI agent systems that actually ship

Twitter is full of "I built an AI agent in 30 minutes" content. I've read it. Some of it's even technically impressive. But a 30-minute build that you're demoing to a camera isn't the same thing as a system that runs your workflow for 90 days without you touching it.

The demo is marketing. The three months after the demo is engineering.

Building in public usually means sharing wins - launches, milestones, metrics going up. The debugging phase has almost no wins. It's just slightly fewer failures each week than the week before. That doesn't make for satisfying content. It doesn't fit the narrative arc. Nobody wants to read "week six: fixed four edge cases, discovered three more."

But that's the actual work. That's the difference between a project and a product. A project works when you're watching it. A product works when you're not.

I'm not saying this to gatekeep. I'm saying it because if you're three weeks into running your agent and you're losing your mind debugging things you didn't expect - that's normal. You're not in the failure state. You're in the middle of the process. Keep going.

What you actually need to get through the 3-month gap

Based on borb, based on the $40 loop-retry incident, based on the stale memory architecture rebuild - here's what I'd tell myself at week one:

Log everything. Every tool call, every model response, every write. You will need these logs at an inconvenient time and you will be grateful they exist.

Hard limits on retries. Five max, then stop and report. The agent's job is not to solve problems that can't be solved. It's to do the work or surface the failure.

Memory needs maintenance, not just construction. Building the memory system is the easy part. Keeping it clean and relevant over months is the hard part. Budget time for it.

Model selection is architecture. Using the same model for everything is a shortcut that becomes a tax. Right model for right task from the start.

Build the kill switch before you need it. You'll need it.

And accept that months two and three look like a lot of debugging with very little to show for it. That's not failure. That's what it looks like to build something that actually works.

If you're thinking about building an agent system or you're already in the weeds, check out what I write about over on the blog. More of this in the ADHD and AI workflows. And if you want to understand the broader context of who's building this stuff and why, the the MCP server has that.

The demo is the beginning. The 3 months after it are the product.

So I built one server that handles all of them.

That's the premise behind building a universal MCP server - and specifically, the pattern I implemented in Universal CodeMode: wrap any OpenAPI spec into exactly two tools, search and execute, and let the model figure out the rest. If you're running agents that touch multiple external services, this is probably the architecture you actually want.

The problem with the current MCP ecosystem

The Model Context Protocol is genuinely useful. It's the right abstraction for giving agents access to external tools and services. But the ecosystem has a fragmentation problem that nobody's really talking about.

The current pattern is: one API = one MCP server. Want GitHub integration? Here's a GitHub MCP server with 30 tools. Want Notion? Another server, another 20 tools. Weather API? Linear? Stripe? Each one is its own server, its own deployment, its own auth config, its own maintenance burden.

I run an agent called borb on my OpenClaw system. It needs to hit GitHub for repo management, search for research, weather for daily digests, and a dozen other services for various tasks. Following the standard pattern, I'd need 56+ separate MCP servers deployed and configured. That's not a system, that's a zoo.

The token cost is the other thing. A traditional MCP server for GitHub might expose 30 endpoints as 30 separate tools, each with its full parameter schema described in the context. That's easily 50K tokens just to tell the model what's available - before it's even made a single API call. At scale, that's insane.

Think about what that means in practice. You have an agent doing a simple task - create a GitHub issue, post a Slack message, look up a weather forecast. Three API calls. But before any of those happen, you've burned 150K tokens just describing the available tools across three MCP servers. That's money out the window for zero productive work. My monthly API spend across the whole OpenClaw system sits around $40. That number would be unrecognizable if I was loading full tool schemas for every session.

What building a universal MCP server actually looks like

The insight I'm building on comes from Cloudflare's "Code Mode" pattern. Instead of describing every possible tool upfront, you give the model two generic tools that work with any API:

1. search - natural language query against the OpenAPI spec catalog, returns the relevant endpoint spec (~1000 tokens)
2. execute - takes a spec chunk and parameters, makes the actual HTTP call

That's it. Two tools. Any API.

The flow looks like this: agent wants to create a GitHub issue, calls search("create a github issue"), gets back the relevant spec chunk for POST /repos/{owner}/{repo}/issues, then calls execute with the right parameters. The whole thing uses roughly 1000 tokens instead of 50K. That's a 50x reduction in token usage for a single API call sequence.

The key insight is that the model doesn't need to know every possible endpoint upfront. It just needs to know it can search for endpoints. The same way you don't memorize every function in a library - you know how to search the docs.

This also means the catalog can grow without any impact on the model's working memory. Whether you have 10 APIs or 500, the context overhead is identical: two tool schemas, a few hundred tokens. The model only loads the relevant spec chunk at the moment it needs it.

The stack

Universal CodeMode runs on Cloudflare Workers with R2 for spec storage and KV for caching. The core is TypeScript, using Hono for routing and the MCP TypeScript SDK for the protocol layer.

Here's the high-level architecture:

// Two tools. That's the whole interface.
server. tool("search", SearchSchema, async ({ query, catalog }) => {
 // Natural language search against indexed OpenAPI specs
 // Returns relevant endpoint chunk, not the full spec
 const results = await searchCatalog(query, catalog);
 return { content: [{ type: "text", text: formatResults(results) }] };
});

server. tool("execute", ExecuteSchema, async ({ spec, params, auth }) => {
 // Takes the spec chunk from search, builds and fires the HTTP request
 const response = await executeRequest(spec, params, auth);
 return { content: [{ type: "text", text: JSON. stringify(response) }] };
});

R2 stores the raw OpenAPI specs. When a spec is ingested, it gets indexed so the search tool can find relevant endpoints by natural language. KV handles caching so repeated searches on the same endpoints don't keep hitting the index.

The catalog currently has 56 pre-loaded API specs. Adding a new API is just ingesting its OpenAPI spec via the admin endpoint - the search and execute tools work automatically because they're operating on the spec structure, not hardcoded tool definitions.

Why Cloudflare Workers specifically

I could've run this on a VPS or a Lambda function. I went with Workers for three reasons.

First, edge deployment means low latency from wherever the agent is running. An agent mid-task waiting on an API lookup is a bad experience - every millisecond of overhead compounds across a multi-step workflow.

Second, R2 and KV are native integrations. No external database config, no connection pooling, no cold start issues with a separate storage layer. The spec storage and caching are just Workers primitives.

Third, the GlobalOutbound security model fits perfectly for this use case. I can declare exactly which domains the Worker is allowed to call outbound - which is exactly the security property I want for a server that executes arbitrary API calls on behalf of agents.

Security model

Running arbitrary API calls through a single server sounds like a security nightmare. Here's how I handled it.

GlobalOutbound restrictions on the Cloudflare Worker mean the server can only make outbound requests to explicitly allowlisted domains. You can't use execute to hit evil. example.com.

Admin token authentication gates the catalog management endpoints. Ingesting or deleting specs requires the admin token. The two main tools (search and execute) are accessible to agents without admin rights.

Execution timeouts on every outbound request. An agent can't hang the server by calling a slow endpoint.

Auth handling in execute is explicit - credentials get passed as parameters, not stored server-side in the MVP. There's a planned hosted version where you'd configure auth per-catalog-entry, but for now, the agent passes credentials and they're used once then discarded.

Is this perfect? No. But it's a real security model, not vibes.

The domain allowlist is probably the most important piece. A compromised prompt injection attack that tries to exfiltrate data to an external server fails at the network level, not just the application level. Defense in depth.

Self-hosted mode

Not everyone wants to run on Cloudflare. The project supports a self-hosted mode via npx:

npx universal-codemode --port 3000

Point it at your OpenAPI specs, configure your MCP client, done. The Worker version is the "cloud native" path, the npx version is for local dev or running on your own infra.

Config looks like this:

{
 "mcpServers": {
 "universal-codemode": {
 "command": "npx",
 "args": ["universal-codemode"],
 "env": {
 "CATALOG_PATH": "./specs",
 "ADMIN_TOKEN": "your-token-here"
 }
 }
 }
}

That's your entire MCP configuration. One entry. Covers every API in your catalog.

Compare that to what the equivalent config looks like with the standard one-server-per-API approach. If you're running five integrations, you have five entries in your MCP config, five different sets of env vars, five different deployment concerns. Something breaks and you're debugging which of the five servers is the problem. With this setup, there's exactly one thing to look at.

Test coverage

13/13 E2E tests passing against real APIs - GitHub, JSONPlaceholder, and httpbin. The test suite covers the full search-then-execute flow, auth parameter handling, error responses, and the catalog management endpoints.

$ npm test

✓ search returns relevant endpoint for natural language query
✓ search handles queries with no matching endpoints
✓ execute calls GitHub API with correct parameters
✓ execute handles 404 responses gracefully
✓ execute respects timeout configuration
✓ catalog ingestion processes valid OpenAPI spec
✓ catalog ingestion rejects invalid spec
✓ admin endpoints reject requests without valid token... (13/13 passing)

Real tests against real endpoints, not mocks. If the GitHub API's behavior changes, the tests catch it.

Testing against real APIs instead of mocks is a deliberate choice. Mocks give you confidence that your code does what you think it does. Real endpoint tests give you confidence that your code actually works. For infrastructure that agents depend on at runtime, I want the second kind of confidence. The tradeoff is that tests can fail for reasons outside my control - rate limits, API downtime, auth token expiry. That's fine. Flaky tests that catch real issues are better than reliable tests that don't.

Where this fits in the universal MCP server landscape

There are a few other projects trying to solve the "too many MCP servers" problem. Most of them are building aggregators - one entry point that proxies to multiple underlying servers. That doesn't solve the token problem, it just reduces the config burden.

The Code Mode pattern is different because it changes the interface. Instead of the model needing to know about github_create_issue and github_list_repos and github_get_pull_request as separate tools, it just knows about search and execute. The catalog can grow to 200 APIs and the model's tool interface stays exactly the same size.

OpenAPI as the common format is doing a lot of work here. Virtually every serious API publishes an OpenAPI spec now. That means the ingestion pipeline is universal - you're not writing custom parsers for each API.

There's also a maintenance angle worth thinking about. When Stripe updates their API, a traditional MCP server for Stripe needs to be updated and redeployed. With this approach, you ingest the updated OpenAPI spec via the admin endpoint and you're done. The search and execute tools don't change. The model's interface doesn't change. One operation, propagated everywhere.

Current status and what's next

MVP is deployed on Cloudflare Workers. The landing page is embedded in the Worker itself (Hono handles the HTML route). Repo is at deeflect/universal-codemode - MIT licensed, free to use.

What's still in progress:

• Custom domain (cm. dee. ad is planned)
• Real-world testing with Claude Code and Cursor agents, not just the E2E test suite
• Seeding more API specs into the catalog - 56 is a start but the long tail of useful APIs is way bigger
• Per-catalog auth configuration for the hosted version so agents don't need to pass credentials explicitly

The honest status: this is a working MVP with real test coverage, not a demo. But it hasn't been battle-tested in production with real agent workloads at scale yet. That's the next phase.

The spec seeding problem is actually interesting. There are thousands of APIs with published OpenAPI specs - the APIs. guru directory catalogs over 2,000 of them. Bulk-ingesting from that kind of source is on the roadmap. The architecture already handles it - it's a data pipeline problem, not an architectural one.

Why two tools is the right number

There's a version of this project where I expose five tools - search, preview_spec, execute, list_catalogs, check_health. I went back and forth on it.

Two is correct. Here's why.

Every tool you add to an MCP server is cognitive overhead for the model. The model has to decide which tool to use before it uses it. With search and execute, the decision tree is: do I know exactly which endpoint to call? No, search first. Yes, execute directly. That's it.

More tools means more opportunities for the model to pick the wrong one, more tokens describing the tool schemas, more edge cases in your implementation. The constraint of two tools forced me to make each tool more capable rather than adding escape hatches.

This is the same reason Unix pipes work. A small number of composable primitives beats a large number of specialized commands every time.

I tested a three-tool version with an explicit preview_spec step between search and execute. In theory it lets the model inspect a full spec before committing to an execute call. In practice, the model just used search and execute 95% of the time anyway and the extra tool added noise to every session context. Cut it.

The lesson: when you're designing a tool interface for models, err toward fewer, more capable tools. Models are good at using tools creatively. They're less good at picking between tools when the distinctions are subtle. Make the distinctions obvious by minimizing the surface area.

Building this as part of a larger agent stack

Universal CodeMode is one piece of my broader setup. If you're curious about how the agent system it connects to actually works - borb, OpenClaw, the cron-based orchestration layer - check out the 31 Rust CLI tools for agents for background, or browse the why prompt engineering died for more on how I think about building agent systems.

The short version: I run multi-agent workflows where different models handle different job types. Having one MCP server that gives all of them access to 56+ APIs without per-model tool configuration changes is the kind of infrastructure win that compounds. Less config, lower token costs, one place to update when an API spec changes.

Every agent in the system gets the same two tools. Sonnet, Codex, Gemini Flash, Opus - they all connect to the same universal server and they all work identically. When I add a new API to the catalog, every agent can use it immediately. Zero redeployment, zero config changes, zero new tool descriptions to fit in context.

That compounding is the real argument for this pattern. Each individual win - fewer tokens, less config, one deployment - is incremental. All of them together, across every agent, across every session, across every API call, adds up to something that materially changes what I can run sustainably as a solo builder.

If you're building anything in this space - agents that need to talk to external services, MCP server implementations, OpenAPI tooling - the repo is open. Issues and PRs welcome. I'm particularly interested in feedback from people running this with Claude Code or Cursor in real projects.

The pattern works. The implementation is early. Both of those things can be true.

I've been building AI agent systems since March 2023. Went deep on prompt engineering early - custom GPTs with specialized knowledge bases, engineered prompt systems for UX research, meal tracking, viral content creation, planning assistants. I did the whole thing. Followed the guides, read the papers, obsessed over system prompt structure.

And somewhere in the last 12 months I realized: almost none of that matters anymore. The skill I spent real time developing got commoditized. What replaced it is harder, more valuable, and almost nobody's talking about it correctly.

Why prompt engineering as a skill is dead

Prompt engineering had about 18 months as a legitimate technical differentiator. Call it mid-2022 to late-2023. During that window, knowing how to coax useful output from a model was genuinely non-obvious. Chain-of-thought prompting improved outputs meaningfully. Few-shot examples helped a lot. Persona framing, careful instruction ordering, output format control - all of it made a real difference because the base models needed the help.

Then the models got better. Fast.

GPT-4 Turbo, Claude 3, Gemini 1.5 - these models understand intent. You don't need to hand-hold them through a task with elaborate prompting rituals anymore. Chain-of-thought? Current models do it automatically without being told to "think step by step." Few-shot examples? Models infer from conversational context. Carefully structured personas? You can write "you're a helpful assistant that specializes in X" and it works fine.

The elaborate stuff people were selling as advanced prompt engineering? It was always just "learning to give clear instructions to something that needed clearer instructions." That's not a skill. That's communication.

Here's the tell: if prompt engineering were a real technical skill, you'd need to understand something about how the system works to get better at it. But most prompt engineering advice is just... good writing advice with extra steps. Be specific. Give examples. State your constraints. These aren't insights about AI - they're basic communication principles.

The YouTube courses, the "certified prompt engineer" bootcamps, the LinkedIn posts about prompt frameworks - that whole industry built up around a skill that had a two-year shelf life. I'm not dunking on the people who built that content. It was real value at the time. It's just not the bottleneck anymore.

What actually killed it

Three things landed simultaneously and the combination was lethal for prompt engineering as a career path.

Better base models that understand intent. I can give Claude Sonnet a roughly-worded, slightly ambiguous instruction and it'll figure out what I mean. I don't need to craft it like a legal contract. The model's interpretive ability improved faster than the complexity of what people wanted to do with it.

Tool use and function calling. This is the big one. A huge chunk of what prompt engineering was trying to do was get models to simulate capabilities they didn't actually have. "Imagine you have access to a search engine..." Now you just give it a search tool. The prompt gymnastics were a workaround for the absence of real tool integration. Now that tool calling is standard, you don't need the workaround.

The realization that it's managerial, not technical. The best prompt engineers were good writers and good managers - people who could specify what they wanted clearly. That's a useful skill. It's not a technical skill. An engineer who spent years learning systems programming has depth that transfers. A "prompt engineer" who spent years optimizing instruction phrasing has a skill that's been automated by model improvements.

What replaced it: agent architecture and tool design

I run a multi-agent system called OpenClaw. 15+ specialized agents, each running a different model, handling different parts of my daily workflow - morning digests, research, code tasks, memory management, content scheduling, crypto position monitoring. The system processes around 40K tokens a day. Monthly API cost is about $40 because I'm aggressive about model selection.

The prompts for each individual agent? Maybe 20 lines. Sometimes less. Nothing fancy.

The orchestration code is thousands of lines. The tool integrations are where most of the work lives. The hard thinking went into: which agent handles what, how agents hand off context to each other, what happens when an agent fails, how memory persists across sessions, which model is cheap enough for a given task while still being capable enough to not screw it up.

That's the new skill. And it's actually a skill - one that requires understanding systems, trade-offs, failure modes, and cost structures.

Here's what the real work looks like now:

Model selection by task. I don't use one model for everything. Opus handles orchestration decisions that require judgment calls. Sonnet handles fast tasks where I need speed over depth. Gemini Flash handles research synthesis because it's cheap and good at skimming large amounts of text. Codex handles code because it's purpose-built. Picking the wrong model for a task either burns money or degrades output quality. That selection logic matters far more than prompt phrasing.

Memory architecture. A single model call is stateless. Real agent systems aren't. How you persist context across sessions, what you include in each agent's working memory, when to summarize versus retain full conversation history - these decisions affect whether your system stays coherent over time or slowly degrades into confusion. My system uses markdown files (MEMORY.md, SOUL.md, AGENTS.md) that agents read from on each run. It's simple and it works. Getting there took iteration.

Error recovery. Model calls fail. APIs go down. An agent returns a response that's correctly formatted but semantically wrong. What does your system do? Does it retry with the same prompt? Escalate to a more capable model? Log the failure and skip? Notify you? Building robust error handling into agent pipelines is where I've spent more time than on any individual prompt.

Tool design. When you build tools for your agents to use, you're essentially designing an API for a semi-autonomous system. The tool needs to do one thing clearly. The input schema needs to be simple enough that a model will call it correctly. The output needs to be structured in a way the model can reason about. Bad tool design leads to agents that can't actually use their tools effectively - and you'll spend time debugging model behavior when the real problem is your tool interface.

If you want to go deeper on how I think about agent systems and the principles behind building them, check out the universal MCP server for more context on where I'm coming from.

The MCP shift and why tool use is the real frontier

Model Context Protocol (MCP) is the clearest signal of where this is all heading. Anthropic published the spec, it's being adopted fast, and it formalizes something I've believed for a while: the future of AI capability is real tool access, not better instructions.

The mental shift is this: instead of engineering a prompt that makes a model pretend to have access to data, you give it actual tools to access real data. Instead of "imagine you're an expert at X with access to Y," you connect it to Y's API and let it query directly.

I built a universal MCP server with 56 API integrations. Notion, GitHub, Slack, calendar, weather, crypto data, Spotify, health APIs, web search, memory storage. My agents don't simulate access to these systems. They actually query them. The outputs are real, current, and accurate in ways that no prompt engineering trick could achieve.

That server took weeks to build. The prompts I wrote for the agents that use it took hours. If you're calibrating where to invest your time, that ratio is your answer.

The MCP GitHub repo has a solid list of existing server implementations if you want to see what's available before building your own. Don't rebuild what's already there.

Function calling and tool use aren't features bolted onto models - they're the architecture shift that makes models actually useful in production. A model that can query a live database, run code, check current prices, read a file, and send a message is categorically different from a model that only outputs text. The difference isn't prompt quality. It's what the model has access to.

What this means if you're building

If you're still spending serious time on prompt templates and prompt libraries, I'd push back on that investment. Not because prompts don't matter - they do, a little - but because the return on that investment has dropped sharply while the return on tool-building and orchestration knowledge has gone up.

The skills that matter right now:

Systems thinking. How do components fail? What are the dependencies? Where does state live? These are the questions that determine whether a multi-agent system works reliably or collapses randomly.

API integration. The ability to connect to external systems, understand their data models, handle their rate limits and errors, and build clean interfaces over them. This is the "prompt engineering" of 2025 - not glamorous, high leverage.

Evaluation. How do you know your agent system is working? Not just "it didn't crash" but "it did the right thing." Building evals for AI systems is hard, undervalued, and increasingly important as these systems touch real workflows. Hamel Husain has written well on this.

Cost optimization. Running agents at scale costs money. Knowing how to profile token usage, pick the right model tier for each task, and cache aggressively is a real engineering skill. I got my 15-agent system to $40/month through iteration, not luck.

For context on the 3 months of debugging agents, there's more there - I write about this stuff as I build.

The honest version of where prompts still matter

I want to be fair here. Prompts aren't zero-value. There are still cases where prompt quality meaningfully affects output quality.

Highly specialized domains where the model needs tight constraints. Anything involving consistent output formatting that downstream code parses. System prompts for agents that need specific behavioral guardrails. Evaluation prompts where you're asking a model to grade other model outputs.

But notice: these are narrow, specific cases. And even here, the prompt is usually less than 10% of the total engineering work. The rest is the surrounding system.

The people who'll tell you prompt engineering is still a high-value career skill are usually selling prompt engineering courses. The people who are building real systems with AI have mostly moved on.

If you're newer to this and trying to calibrate what to learn: spend maybe two weeks understanding how prompts work and what affects model behavior. Then spend the next six months learning to build systems. That's the right ratio.

The model will follow good instructions just fine. The question is what system you build around it.

Start with one tool. Connect your agent to one real API. See how differently the model behaves when it has actual access to something instead of simulated knowledge. That single experience will do more to reframe your thinking than any prompt engineering course.

Here's the actual stack, why it's built this way, and what most people get wrong about "vibe coding."

What "vibe coding" actually means

It's not "ask ChatGPT to build me an app." That's how you get a 400-line index.js with no error handling that half-works for 20 minutes before collapsing.

Real vibe coding is coding with leverage. You still need to understand what the code does. You still need to catch hallucinations. You still need to make architectural decisions - maybe more consciously than before, because the AI will happily scaffold the wrong architecture at 10x speed if you let it.

What changed: the AI handles the typing and the boilerplate. The parts that used to eat 60% of my time - setting up file structure, writing CRUD routes, building form components I've built a hundred times - that's mostly automated now. What I bring is the product sense. Knowing what to build is harder than knowing how to build it. The "how" is commoditized. The "what" and "why" still aren't.

My background is product design. Ten-plus years of it, including a long stint as sole designer at a fintech platform doing $4B+ in digital assets. That taught me to think about systems - how pieces connect, what breaks under edge cases, where the user actually gets stuck. That context is the thing AI can't replace. It's why a designer who codes can actually get further with these tools than a CS grad who just knows syntax.

The four-model lineup

These are the main players. Each one has a job.

Grok (grok-code-fast) - The fast pass. I use this first. It's cheap, it's quick, and it's genuinely good at scanning code for obvious issues - logic errors, missing edge cases, things that'll blow up. I don't use it for fixes. I use it for triage.

Claude Code - The surgeon. Best AI I've used for understanding context and making targeted edits. If I have a function that's almost right but subtly broken, Claude finds the problem without bulldozing the surrounding code. It reads the file, understands the intent, and makes the minimal correct change. This is rare. Most models over-edit.

Codex - The builder. Heavy refactors, multi-file changes, greenfield scaffolding. When I need to restructure a whole module or build something from scratch, Codex is the move. It's not as precise as Claude on targeted edits but it handles scale better. It'll touch 8 files in sequence and keep things coherent.

Gemini (Flash or Pro depending on context) - The reader. When I need to analyze a large codebase or understand a sprawling chunk of code I didn't write, Gemini's context window is unmatched. I'll drop 50K tokens of code in and ask it to explain the data flow. It handles that better than anything else I've used.

That's the core four. v0 gets a slot for frontend component generation. It's the fastest way to get a working UI component I can then iterate on with Claude Code.

How the actual pipeline runs

Real example of how a feature goes from idea to done:

1. I write a rough spec in plain text. What the feature does, what the inputs and outputs are, what edge cases matter. This step is underrated. The cleaner my spec, the better the AI output at every stage.

2. If I'm building frontend: I hit v0 first. Describe the component, get something that renders. It won't be perfect but it's 80% of the way there in two minutes.

3. Grok does a fast pass on whatever exists so far. I'm asking it: "what's obviously wrong here? what breaks?" Quick, cheap, catches the low-hanging problems.

4. Claude Code handles the refinement. Takes the rough output, applies targeted fixes, handles the business logic, integrates with the rest of the codebase. This is where most of my back-and-forth happens.

5. If Claude hits a wall - something too structurally complex, or needs changes across multiple files - I hand it to Codex. Codex finishes the heavy lifting.

6. Grok reviews the final output. Another fast pass. At this point I'm looking for regressions and anything the other models introduced.

7. I read the code. Final check. I don't skip this.

That last step isn't optional. You cannot ship AI-generated code you haven't read. The hallucinations are sneaky. They produce code that looks right and runs right in tests but breaks in production on a Tuesday when someone does something slightly unexpected. Your name is on the commit. Read the code.

My multi-model coding workflow for backend vs frontend

Different problem types call for different entry points.

Frontend

Start with v0. Describe the component - what it does, any constraints, the general look. Get the initial render. Then switch to Claude Code for every iteration after that. Claude is better at "change this specific behavior" than v0 is once you're past the initial generation.

For anything that needs complex state management or integration with existing backend types, I'll write that part myself or with Claude Code from scratch rather than trying to wrangle v0's output. v0 is a starting point, not a production artifact.

Backend

Codex for scaffolding. Give it the data model, tell it what the API needs to do, let it build the structure. Claude for the business logic layer - anything that involves conditionals, data transformation, edge cases. Debugging: paste the error into whatever's fastest. Usually Grok for the first look, Claude if it needs deeper investigation.

For architecture decisions - where to put things, how services should talk to each other, what the data model should look like - I make those myself. I'll ask Claude or Grok to rubber-duck a decision with me, but I'm not delegating architecture to a model. That's the one place where the AI's lack of business context will hurt you.

The MCP layer

This is the part most people aren't talking about yet.

MCP (Model Context Protocol) tools change how much context your AI coding setup can actually see. Without good context, you're pasting code snippets manually and hoping the model understands the surrounding system.

The one I use daily: sammcj's devtools MCP. At ~9K tokens it gives me basically everything meaningful about a codebase - file structure, dependencies, key functions. I drop this context at the start of any substantial session and the model quality jumps immediately. Less hallucination, more accurate edits, better architectural suggestions.

If you're using AI coding tools without MCP integration, you're leaving a lot on the table. The model can only help you as much as it understands the system. Give it the context.

What this costs

People act like the price of these tools is a dealbreaker. It's not. But you should know what you're actually paying.

I'm on OpenAI Pro ($200/month). That's basically required if you're using Codex for real work - you need the usage headroom. Claude Pro or Max depending on the month. Grok is included in X Premium, which I'd pay for anyway.

All in, I'm spending around $350-400/month on AI tooling. I get somewhere between $800-1,200 of nominal usage value out of it based on what the APIs would cost at direct rates. And I ship maybe 3-4x faster than I did 18 months ago.

The mental model I use: I'm hiring a part-time engineer who's excellent at specific tasks, needs supervision, and occasionally hallucinates. At $400/month, that's a steal. The thing that makes it work is knowing which part-time engineer to call for which job. That's the whole game.

What breaks this workflow

Being honest about failure modes:

Bad specs kill everything. If I'm vague about what I want, every model in the chain produces something subtly wrong in a different way, and now I have five things to reconcile instead of one thing to fix. Time spent on the spec is time saved everywhere downstream.

Chaining without reading. Running model output straight into the next model without reviewing it first compounds errors. Grok flags an issue, Claude "fixes" it, Codex rebuilds around Claude's fix, and now the original problem is buried under three layers of AI decisions you didn't validate. Read between steps.

Using the wrong model for the task. Claude on a large multi-file refactor gets expensive and sometimes loses coherence. Codex on a targeted three-line fix is overkill and occasionally makes it worse. Matching the model to the job isn't optional.

Architecture by committee (with AIs). I did this once - asked three different models how to structure a feature, got three different answers, tried to synthesize them. Waste of time. Architectural decisions are mine. I use models to validate and poke holes, not to make the call.

The honest take on vibe coding

Most of the backlash against it is people who watched someone generate slop and extrapolated. Most of the hype is people who generated something that worked for 10 minutes and declared victory.

The actual version is somewhere more boring and more useful: AI handles commodity work at speed, you handle judgment. The skill ceiling on building shifted. You don't need to memorize syntax. You do need to know what good architecture looks like, how to write a tight spec, when the AI is confidently wrong, and what the user actually needs.

I couldn't do this workflow without 10 years of product and design experience. Not because the tools are hard - they're not. But because the inputs I give them are shaped by that experience. The prompts are good because I know what I want. The reviews catch problems because I know what breaks. The architecture holds because I've seen what doesn't.

If you want to build a similar stack: start with one model and learn it well. Understand its failure modes. Then add another model where you keep hitting walls. Don't adopt the whole thing at once - you'll just have four sources of confusion instead of one.

Read everything you ship. That's the one rule that doesn't have exceptions.

You can see more about what I'm building and how I think about this stuff why prompt engineering is dead. And if you want to dig into related topics - multi-agent systems, prompt engineering, tool comparisons - check out the MCP server I built to find threads that go deeper.

I've spent 10+ years in product design, including five years designing institutional fintech for 70+ banks at VALK. Now I build AI systems. I write prompts and I write interfaces. I can spec a component in Figma and wire up the agent backend that powers it. That combination is genuinely rare, and the fact that it's rare is exactly why AI UX is such a disaster right now.

This isn't a subtle problem. Open any AI product built primarily by ML engineers and you'll feel it within 30 seconds.

Why AI products have terrible UX by default

The people who understand how transformers work don't think in interaction flows. They think in loss functions and benchmark scores. When an ML engineer ships a UI, you get a settings panel with 40 sliders and tooltips that say "controls the randomness of model outputs." Thanks. Very helpful.

The people who understand interaction design usually can't implement AI systems. They can map the user journey beautifully but they don't know what a context window is, can't reason about latency tradeoffs, and treat the AI as a black box that either works or doesn't.

The intersection - people who can do both - is genuinely tiny. Which means most AI products get built by one camp or the other. And it shows.

Here's the uncomfortable truth: a mediocre model with great UX beats a great model with terrible UX every time. ChatGPT didn't win because GPT-4 was the best model when it launched. It won because the chat interface was dead simple. You typed. It responded. No configuration. No onboarding. No explaining what a temperature setting does.

That chat box was a design decision, not an ML decision. And it's worth billions.

The specific ways AI UX fails

Let me get concrete because "bad UX" is a garbage diagnosis. Here's what I actually see when I use most AI products:

Chat-for-everything syndrome

Not every AI interaction needs a text input. Some interactions need a button. Some need a slider (a single, well-labeled one). Some need a select dropdown.

When you build "chat as the UI" because it's easy to implement, you're making your users do the work of figuring out what to ask. That's backwards. The product's job is to make the right actions obvious. If your AI can summarize a document, add a "Summarize" button. Don't make me type "please summarize this document" like I'm filling out a form in 1998.

The chat interface pattern gets cargo-culted because ChatGPT did it and ChatGPT is successful. But ChatGPT's whole thing IS chat. It's a general-purpose assistant. Most AI products aren't general-purpose - they're doing specific things for specific workflows. A focused tool should have focused UI.

Loading states that feel like crashes

Generative AI is slow. A response can take anywhere from one second to 25 seconds depending on the model, the prompt length, and what you're generating. Users are not okay with a spinner for 20 seconds. They need to know something is happening, roughly how much longer it'll take, and ideally a preview of the output streaming in.

Streaming output is table stakes in 2025. If your AI product shows a blank area and then suddenly dumps the full response, you've already lost. It feels like the app froze and then magically recovered. Streaming makes the latency feel shorter than it actually is - that's not a trick, it's respecting the user's attention.

I've seen products where a 15-second model call shows a static spinner with no copy, no progress indication, nothing. Users absolutely hit refresh. Then they get confused about duplicate outputs. This is a solved UX problem that keeps getting ignored because the engineer who built the AI part is done and the UI is "good enough."

Error messages written for engineers

"Something went wrong." Rate limit exceeded. Context length exceeded. Model unavailable.

These are real failure modes that users hit regularly and none of them should surface as generic error states. When the model hits a rate limit, tell the user there's high demand and you're retrying. When the context gets too long, tell them what to do about it - not in token counts, in plain language. "Your conversation is getting long - try starting a new one for best results."

Error handling is where you find out if a designer was actually involved. Engineers write error messages for themselves. Designers write them for the person who just wanted to finish a task.

Settings pages designed for nobody

Temperature. Top-p. Frequency penalty. Presence penalty. Max tokens.

These settings exist because they're parameters in the API. They got exposed in the UI because nobody asked "should we expose this?" They just asked "can we expose this?" Yes, you can expose it. That doesn't mean you should.

I get it - power users sometimes want control. But the defaults should be invisible and the advanced settings should be buried behind a "configure" link that 95% of users never click. Progressive disclosure is a basic design concept. Show the simple thing first. Put the complex thing behind one more tap.

When your settings page looks like a synthesizer, you've failed the design. Users don't want to tune a model. They want to accomplish something.

Treating AI output as final

AI output is a draft. It's always a draft. The best AI products make this obvious by making everything editable in-context. Click a sentence. Change it. The system knows you changed it and uses that as signal.

When AI output renders as static text in a read-only block, you're implicitly telling the user that the AI's word is final. That's backwards. The user is in charge. The AI is a collaborator. The UI should make it trivially easy to edit, regenerate, or reject any piece of output.

Linear's AI summaries are a good example of getting this right. The summary is inline and you can just edit it like any other text. The AI offered a starting point. You own the result.

No feedback loop

If a user deletes an AI output and types something completely different, that's signal. If they regenerate three times, that's signal. If they always ignore the suggested action, that's signal.

Most AI products collect none of this. Not actively anyway. There's no thumbs up/thumbs down. There's no "fix this" button. There's no way for the user to tell the system "you're getting this wrong."

Beyond the product improvement angle, feedback UI makes users feel like they have agency. The AI isn't doing something to them - they're collaborating with it. That's a fundamental shift in how the product feels, and it costs almost nothing to implement.

Nielsen Norman Group has documented this pattern extensively - the products that build in feedback mechanisms consistently score higher on user satisfaction than those that treat AI output as a one-way broadcast. This isn't a new insight. It just keeps getting skipped.

What good AI UX actually looks like

Good AI UX is invisible. The AI is there, doing things, but you barely notice it. You just notice that the product works better than it should.

Autocomplete that predicts what you actually meant to type. Smart defaults that adjust based on what you've done before. Errors that self-correct before you ever see them. Suggestions that appear before you ask for them, in the right context, at the right time.

The goal is never to show off the AI. The goal is to make the user feel competent. There's a real difference between a user saying "this tool is so intuitive" and a user saying "wow the AI is amazing." The first is good UX. The second usually means the AI is impressive but the UX is still making you aware of it - which means it's getting in the way.

Figma's AI integrations are interesting to watch because Figma's team actually understands design. They still struggle with making AI actions feel predictable - there's always a moment of "wait, what did it just do?" - but they're closer than most. That moment of confusion is a UX debt they're actively trying to pay down.

The products I actually like using right now: Notion AI for the in-context editing flow, Cursor for how it makes AI suggestions feel like a collaborator not a replacement, and Linear for keeping AI features out of the critical path so they enhance without blocking.

All three share something: the AI is ambient. It's there when you need it, gone when you don't, and it never makes you feel like you need to understand it to use it.

Why AI products with terrible UX keep shipping anyway

The gap isn't closing fast enough. AI is getting more capable every few months. Design is being treated as optional or "we'll fix it later." The result is an ecosystem of increasingly powerful AI wrapped in increasingly confusing interfaces.

This is partly structural. Most AI companies are founded by researchers or engineers. Design hires come later, if at all. And when they do come, the designer often lands in a team where the ML engineers have already made the fundamental UX decisions - they just didn't call them design decisions. The architecture of the system becomes the architecture of the interface, which is almost never the right call.

Google's People + AI Research (PAIR) team has a whole guidebook on this. It's worth reading even if you don't agree with everything in it. The core insight - that AI systems require a fundamentally different design approach than deterministic software - is right. You can't just apply standard UX patterns to a system that might give a different answer every time. The guidelines for how to handle uncertainty, how to communicate confidence levels, how to make AI actions feel predictable without being rigid - that's the hard design work that most teams skip.

The Anthropic model card and usage policy documentation is also a useful lens here. The way they think about how Claude should communicate uncertainty and limitations is essentially applied UX thinking at the model level. That's rare. Most model providers treat the interface layer as somebody else's problem.

The companies that figure this out - that actually hire people who can span both domains, or that build real collaboration between their ML and design teams - are going to clean up. Not because their AI is better. Because their AI actually makes sense to use.

I started leaving fintech for AI specifically because I kept seeing this pattern and had nowhere useful to point people. The posts that get the most traction are always the ones about the interface layer, not the model layer. People are hungry for this.

Fix the UX before you touch the model

If you're building an AI product right now, the single most high-leverage thing you can do isn't to upgrade your model. It's to watch five users try to use your product without any help from you. Don't say anything. Just watch. You'll see exactly where the AI ends and the confusion begins. That's your design debt.

Spend a week on that before you touch your prompt engineering or your fine-tuning pipeline. The UX problems are costing you more users than the model quality is.

If you want to go deeper on the AI engineering side - how the systems actually get built, what the architecture decisions look like from someone who also designs the interfaces - check out what replaced prompt engineering for more technical posts. The design-to-engineering gap is a topic I keep coming back to because I keep seeing it break products that should work.

Fix the interface. The model will get better on its own. The UX won't.

How I stopped posting on Twitter for 2 months without meaning to

September 6 was my last post before the gap. A week later I tweeted "staying away from X for a few days, wonder if it ruins reach" and then proceeded to vanish for two full months instead of a few days.

I wasn't planning that. There was no decision point where I said "I'm taking a break." I was building. Seven apps in parallel, deep in agent architecture, ADHD hyperfocus locked in. Twitter stopped feeling like a place I existed in. Not because I was boycotting it or burned out on the discourse. I just got absorbed and the habit broke.

That's the honest version. Not a detox story. I didn't meditate more. I didn't reclaim my attention span through discipline. I got pulled into something more interesting and social media fell off naturally. That's how ADHD actually works - when something grabs you hard enough, everything else gets crowded out.

The gap ran October through November. I came back January 26, 2026 with one post: "I'm back because of Clawdbot meta." No apology, no "I've been doing some reflection," no thread about what I learned. Just back.

What actually happened to reach when I stopped posting on Twitter

Short answer: yes, disappearing kills your numbers. I came back to impressions that were noticeably down from where they were in September. The algorithm punishes inconsistency in ways that are both predictable and annoying.

Here's what surprised me though - my follower count barely moved. The people who followed me for real reasons didn't unfollow during a two-month gap. They just... waited. Or forgot I existed but kept the follow anyway, which is functionally the same thing.

What did drop off were the engagement-farmers. The follow-back accounts, the people following hoping for a mutual, the ones gaming numbers. When I stopped posting, I stopped being useful to them. They left. Good.

So the actual damage from a two-month absence was:

• Impressions down significantly on return
• Algorithmic reach basically reset
• Genuine followers intact
• Low-quality followers gone

That's not catastrophic. It's annoying if you're trying to grow on a consistent curve, but it's not irreversible. Coming back with something real to say matters more than the reach penalty.

The platform rewards consistency, but it doesn't erase you for breaks. It's not that vindictive. It just forgets you for a while and you have to re-earn distribution. Which, to be clear, still sucks. But it's survivable.

Research from the Reuters Institute Digital News Report backs this up - audiences don't actively track individual creator absences the way creators fear they do. People are mostly watching the feed, not waiting for you specifically.

Building in public culture and why it makes breaks feel worse than they are

There's a specific kind of pressure that comes with building in public. The implicit rule is you have to be visible. Posting daily "day 47 of building X" content. Sharing every milestone. Being present enough that people remember you exist.

Miss a week and you feel like you're falling behind. Miss a month and it feels like career death. I'm not immune to this feeling. I've been building in public for long enough to have internalized the assumption that visibility = momentum.

But the two months proved that assumption wrong in at least one direction.

I built more in those two silent months than in the three months of posting before them. Seven apps. Real infrastructure. Clawdbot, which ended up being the thing I came back to announce. When you're not performing the work, you're just doing it. Turns out those are different modes.

The building in public model optimizes for consistency of output, not quality of output. There's value in that - accountability, community, people following along with the journey. But it can also turn into a content treadmill where the posting becomes the thing instead of the building.

I'm not saying building in public is bad. I'll keep doing it. But I'm now aware that the ADHD hyperfocus mode where I forget Twitter exists and just build for two months is also a valid mode. Maybe more productive in certain phases.

The ADHD angle: forgetting to post is not a failure

Everyone talking about "intentional breaks" from social media has the same energy: "I realized I needed to step back and prioritize my wellbeing." Very deliberate. Very curated. Very LinkedIn.

That wasn't this.

I didn't decide to take a break. The habit just... dissolved. I was on a 2am coding session in early October, deep in something, and the thought of tweeting about it didn't occur to me. Same the next night. By week two the pattern was just gone.

This is textbook ADHD. The executive function overhead of maintaining a social media posting habit - opening the app, forming a thought worth sharing, hitting post, checking the response - that whole loop requires a certain baseline attention budget. When something captures all of it, the habits that depend on leftover attention just stop running.

The ADHD and executive function research out of Harvard Medical School explains this pretty well - executive function isn't a moral failing, it's a resource allocation problem. When the resource is fully committed elsewhere, discretionary habits are the first to drop.

I've made peace with this. It's not undisciplined, it's just how my brain allocates. The flip side of forgetting to post for two months is also why I can build seven apps in parallel while maintaining an agent system that runs 14 cron jobs. Same mechanism, different outputs.

If you have ADHD and you've done this - gone silent for weeks because you were deep in something - it's not a failure mode. It's just the cost of the hyperfocus that also lets you ship faster than most people.

The trick is not building your brand strategy on a foundation that requires daily consistency you won't reliably deliver. Build it on depth instead. One good post after two silent months is worth more than sixty filler posts.

What "coming back" actually looks like

January 26. "I'm back because of Clawdbot meta."

That was the whole post. No explanation, no recap thread, no "here's what I learned while I was away" (except this post, I guess). Just the most direct possible signal: I exist, I have a reason to be back, here's the thing.

This felt right. The alternative - the big return post with the reflective thread - felt like it was performing a story instead of just getting back to work. The people who care will engage with the work. The people who need a narrative about why you were gone aren't really your audience anyway.

I did get some "welcome back" responses. More than I expected, honestly. A few people had noticed the gap and were curious what happened. That was kind of nice - it meant the previous presence had registered as real enough that the absence was notable.

But the bigger signal was that nobody was mad. Nobody had been waiting with a timer. The internet doesn't work that way. People move on, the feed keeps moving, and when you come back with something worth seeing, you get traction again.

What I'd tell someone about to take (or accidentally start) a social media break

Not going to frame this as advice, because I didn't plan any of it. But if you're reading this because you've already been gone for a month and you're wondering if you've tanked your presence - you probably haven't.

A few things that are actually true from experience:

Genuine followers don't leave during a two-month absence. The people who followed you for real reasons are still there. The follower count number that matters is quality, not quantity, and quiet people who actually care about your work have more patience than the algorithm does.

Your reach will take a hit and that's fine. You'll rebuild it. Reach is lagging indicator of consistency, and consistency can be rebuilt faster than you think when you come back with something real. I came back with Clawdbot. That gave me actual things to say.

The building you do during the silence compounds. Those two months produced more than the three months of documented-daily-grind before them. There's something to that. Not every phase of building should be public. Some of it needs to be quiet.

The "building in public" pressure is real and mostly self-imposed. The audience you're building in public for is smaller and more patient than the anxiety makes it seem. If you're good at what you do and you come back with evidence of it, people remember.

And if you have ADHD and you just disappeared because something grabbed you - that's the mechanism working, not failing. The work you did in the silence is the asset. The posts are just distribution for it.

What stopped posting on Twitter for 2 months actually cost me (and what it didn't)

I have how I grew to 500 followers where you can see the full context of what I work on - design background, fintech, AI engineering, all of it. None of it died during two months off Twitter.

The projects I was building kept building. The systems kept running. The professional relationships that matter don't live on Twitter anyway - they live in Discord servers, in direct messages, in shipped product people can actually use.

Twitter is distribution. It's a real tool and a decent one for this type of work. But it's not the substrate. The work is the substrate.

The two months off X taught me that more than anything. When the posting stopped, nothing important stopped with it. The important stuff was already running somewhere else - in the codebase, in the agent system, in the products actually getting built.

Coming back felt like turning a tool back on. Not like returning from exile.

That's the right relationship to have with it. Check what I was building instead to see what came out of those two silent months. And if you want context on how Twitter's algorithm actually handles inactive accounts, X's own creator documentation doesn't spell it out cleanly - but the pattern from third-party analyses is consistent: reach drops fast after ~2 weeks of silence, then stabilizes, then rebuilds within a few weeks of returning.

The algorithm is back to punishing me for the gap. I'm fine with it. The seven apps I built during the silence are more valuable than consistent impressions metrics would've been. Trade you'd make again without thinking about it.

I'm at ~660 now. Not viral. Not a "Twitter guru." But I have a real, engaged audience of AI/dev/startup people who actually interact. That's worth more to me than 50K ghost followers.

Here's what I learned rebuilding from scratch.

The 3 routes to grow Twitter followers from zero (pick wisely)

Before I talk tactics, the mental model matters.

There are exactly three routes to growing on X. Route A: be funny and shitpost. Route B: drop insights and add value. Route C: rage bait and controversy. That's it. Every account you've seen blow up used at least one of these. Most big accounts you think are doing something special are just doing one of these three things really well.

Route C works. It works fast. It also fills your replies with people who are wrong on the internet as a personality trait. I'm not interested in managing that energy, so I mostly stayed off it.

Route A gets you shared. Funny spreads. But pure shitposting doesn't build authority - it builds a following that sees you as entertainment, not expertise. The second you post something serious, engagement tanks because you trained them to expect jokes.

Route B gets you saved. Value posts rack up bookmarks and follows from people who want to learn something. But pure value content is too easy to scroll past without engaging. It doesn't spread.

The actual sweet spot - and this is the insight that changed my numbers - is A+B together. A funny observation that also teaches something. A self-deprecating building-in-public moment that contains a real insight. The format makes people laugh, the substance makes them follow.

"Shipped a feature that took 3 days to build. My AI agent replaced it in 47 minutes. I'm choosing to be excited about this."

That's funny and it says something real about where AI tooling is going. That kind of post travels.

What actually grew my account from zero

Replies on big accounts - this was 80% of it

Not "great post!" Not "I agree!" Not the kind of thing that reads like a bot (more on that shortly).

Actual additions. Real takes. Occasionally a funny riff on what they said. When someone with 50K followers posts something about AI agents being overhyped, I'm not validating their hot take - I'm adding specificity. "The hype is real, the production readiness isn't. I've been running 14 scheduled agent jobs daily for 3 months and the failure rate on complex multi-step tasks is still too high for me to hand off anything important unsupervised."

That kind of reply does a few things. It shows up in the timeline of everyone following that account. It positions me as someone who's actually done the thing. And if it's good enough, the original poster might like it or reply - which extends the reach further.

The key is being genuinely useful or genuinely funny. Vague agreement is invisible. Disagreement with substance is visible. Addition is visible. The metric I use: would someone screenshot this reply? If not, it's probably not pulling any weight.

I probably wrote 15-20 quality replies a day for the first two weeks. That's the unsexy part nobody talks about. It's not posting content - it's showing up in other people's conversations consistently.

Opinionated takes from daily tool usage

I use AI tools every day. Cursor, Claude Code, various agent frameworks, LLM APIs. I have real opinions about what's good and what's broken. Those opinions performed well because they're specific.

"Cursor's composer is great until your project hits ~150 files, then the context quality drops noticeably" is a post. "AI coding tools are amazing" is noise.

The what happened when I stopped posting gives the full background, but the short version: 10+ years in design, deep fintech engineering experience, now building multi-agent systems full-time. That's a specific lens. When I post about AI tools, I'm not regurgitating documentation - I'm reporting from actual usage at a level most people don't have.

Specificity is unfakeable credibility. Anyone can say "this tool is good." Not everyone has run 40K tokens per day through their own agent system and tracked the monthly API cost down to $40.

Building in public - but only the interesting parts

"Day 47 of my building in public journey" is dead. Nobody wants that. The journey framing assumes your audience cares about you, and they don't - not yet. They care about what you're doing and what they can learn from it.

What works instead: the specific moment that was actually interesting.

Not "working on my AI project today." Instead: "Realized my RAG pipeline was failing not because of the model but because of my chunking strategy. Three days of debugging to find a paragraph break problem. Love this for me."

Building in public posts that perform have an insight embedded in them. The vulnerability is a delivery mechanism for the learning, not the point itself. When the vulnerability is the point, it reads as attention-seeking. When the learning is the point and the vulnerability makes it human, it actually helps people.

Timing matters more than I expected

I post when US tech Twitter is active. That's roughly 9am-12pm Pacific and then a second window around 5-8pm Pacific. I'm in LA so this is convenient for me.

But the timing thing is real. The exact same post at 2am gets 20% of the engagement it'd get at 10am. The algorithm's initial distribution window is short - if you don't get traction in the first 30-60 minutes, the post dies. So showing up when your audience is scrolling is a basic requirement that a lot of people ignore.

Being weird and specific instead of generically motivational

The fastest way to get lost in the feed is to sound like everyone else. "Consistency is key." "Ship fast, iterate faster." "Your future self will thank you." These are not posts. These are bumper stickers.

I'm Russian-born, ADHD, building AI systems in LA, async-only (no calls, ever), obsessed with multi-agent workflows. That's specific. When I write from that specific perspective instead of trying to be universally relatable, the people who connect with it really connect.

You can't optimize for everyone. You can optimize for your actual people.

What didn't work - including an embarrassing confession

AI-generated replies

This one I'm putting in writing because I think a lot of people are doing this and thinking it's working.

For a few months, I was using AI to generate replies to posts in my niche. The idea: stay "active" in conversations, look engaged, maybe get some follows from the visibility. The system did not notice - meaning I wasn't flagged or suppressed as far as I could tell. But the growth was essentially flat. Automated engagement looks active, but builds zero real connections.

Here's why it fails: a good reply starts a conversation. An AI-generated reply that's technically relevant but not genuinely insightful doesn't make anyone want to engage back. It gets ignored or gets a polite like. It doesn't turn into a thread. It doesn't make the original poster remember you. It doesn't build a relationship with anyone who saw it.

I switched to genuine replies only - less volume, more quality. Growth actually improved. Because one real conversation is worth more than 50 AI-generated non-interactions.

The meta-lesson: you can use AI to help draft a reply if you're stuck, but you need to inject your actual perspective into it. The algorithm might count impressions, but humans are better than you think at detecting genuine vs. automated engagement.

Mass following and hoping for follow-backs

Did this for like a week, stopped, never mentioned it until now. Following 200 accounts a day hoping 10% follow back is a number game that builds the wrong audience. Even when it "works" you get people who don't care about your content - they just returned a courtesy follow. Those accounts become noise in your metrics and won't engage with anything you post.

Generic "tips and tricks" threads

I tried a few of these early on. "5 AI tools every developer should know" type content. It did okay in terms of impressions but drove almost no follows. The problem is this content exists everywhere. There's nothing in it that could only come from me. When someone reads a generic tips thread, even a good one, they don't feel any reason to follow the source specifically. They just take the info and keep scrolling.

The posts that converted to follows were the ones with a clear point of view. Posts where you can tell who wrote them from the content alone.

The introverted builder angle

I want to flag something for anyone who's introverted and thinks Twitter growth requires networking, calls, or showing up to events.

It doesn't. I don't do calls. I don't go to tech meetups. I'm async-only. Every single one of my followers came through written content and written replies. No podcast appearances, no cross-promo deals, no "collab" posts.

The platform rewards writing, and writing is something you can do alone at 11pm in your apartment. For introverted builders, that's actually a structural advantage. You're competing with people who need external validation to show up - and you can just quietly be consistent.

Check out the building 7 apps solo for all the AI engineering and building-in-public content if you want to see how this thinking shows up across different topics.

Where I am now and what I'm focused on

660 followers, growing slower than the initial burst but more steadily. The first 500 came fast because I was very active with replies. I've pulled back on reply volume a bit as I'm heads-down on some builds, and the growth has slowed accordingly. That's fine - I'd rather have a smaller engaged audience than chase a number.

The things I'd do exactly the same: heavy reply game in the first month, being genuinely specific and opinionated, building in public with the insight-forward framing.

The things I'd change: started with genuine replies from day one instead of testing the AI reply thing, spent less time on generic content earlier.

If you're starting from zero or rebuilding like I was - the reply strategy is not glamorous but it's the most direct path. Find 10 accounts in your niche with 5K-100K followers, show up in their replies every day with actual value, and do it for 30 days before evaluating whether it's working. That's the playbook. The rest is just execution.

One last thing: don't optimize for follower count if you're building something. Optimize for the right followers. 500 engaged AI/dev/startup people is worth more than 5,000 general followers who won't care about what you're building. Niche compounds. Broad doesn't.

Find me at @deeflectcom if you want to watch this experiment continue in real time.

That was me six months ago, and if you're a solo founder with ADHD, you probably know exactly how that happens. Building 7 apps at once isn't a failure mode - it's the default state when your brain treats every new idea like an emergency and you're technically capable of actually building all of them.

I can do the full stack. Design, frontend, backend, smart contracts. Which sounds like an asset until you realize it means nothing stops me from starting something new at 2am because I read one interesting tweet about a framework I've never tried.

Let me tell you what that actually looks like.

How building 7 apps at once happens (faster than you'd think)

It doesn't start as 7. It starts as 1, then 2, then "just a quick experiment," then you blink and your Notion has 7 active project docs and your GitHub has 11 repos created in the last 90 days.

My list at peak chaos:

OpenClaw - my AI agent system. The main thing. 14 cron jobs running daily tasks, managing my workflow, aggregating data, handling research. Actually running in production.

A music generation pipeline - GPT-4 generating lyrics, Suno turning them into actual audio, Midjourney for visuals, ElevenLabs for voiceover. The idea was a fully automated artist that produced content without me touching anything after setup. I got it working. Then got distracted.

Crypto products - I've shipped tokens that hit $10M+ market cap. The financial incentive is real. The problem is crypto moves fast and demands constant attention, which ADHD brains are simultaneously great and terrible at.

An ADHD planning tool - I was going to build the productivity app that actually worked for my brain because everything else sucked. Classic "scratch your own itch" trap. You know what happened. I got distracted building it.

MCP servers - Model Context Protocol is genuinely interesting infrastructure work. I built three of them in a weekend because the architecture grabbed me.

CLI tools - Small stuff. Quick utilities. The kind of thing you build in 4 hours because you needed it for something else and now it exists.

Automation workflows - n8n pipelines, custom agents, glue code connecting APIs. This bleeds into everything else so it's simultaneously its own project and embedded in all the others.

Seven things. One person. No cofounders by choice - I'll get to why in a minute.

The ADHD founder loop is real and it's not what you think

Everyone explains ADHD as "gets distracted easily." That's not wrong but it misses the mechanism. It's not that I can't focus. It's that my brain allocates attention based on novelty and interest, not importance and priority. A new framework registers as urgent. A 6-week-old project that needs documentation registers as optional.

The loop looks like this:

1. New idea hits. Immediate hyperfocus. Build for 16 hours straight.
2. Get it working. MVP ships. Dopamine.
3. Hit the boring middle - marketing, SEO, documentation, polish, customer support.
4. Brain de-prioritizes it. New shiny thing appears.
5. Repeat.

The boring middle is where non-ADHD founders grind through and ADHD founders bounce. The problem isn't the building. I'm fast at building. The problem is everything after the building.

Here's what took me too long to figure out: the boring middle is where the money is. Shipping is fun. Distribution is how projects survive.

And I can't do distribution manually. It just doesn't happen.

This isn't unique to me - the ADHD and entrepreneurship research from Barkley et al. consistently shows that executive function deficits hit hardest on sustained, low-novelty tasks. Which is exactly what distribution and maintenance are. The building phase is fine. Everything after is structurally harder for ADHD brains.

What building 7 apps at once as a solo founder with ADHD actually costs you

The real cost isn't time. It's context switching overhead compounded across seven projects simultaneously.

Every time you context-switch between codebases, you pay a mental re-load cost. Research on developer context switching puts the refocus time at 23 minutes on average after an interruption. Multiply that by seven projects and you're paying that tax constantly. You're never fully in any one thing long enough to hit the deep work state where hard problems actually get solved.

My peak chaos period felt productive. I was always building something. But my actual output - measured in shipped features, not hours of activity - was lower than my focused periods. The context switching was eating the work.

The other cost is quality. When you're seven projects deep, you're not doing your best work on any of them. You're doing good-enough work on all of them. Which means none of them have the level of craft that makes a product actually stand out.

I shipped an MVP of the ADHD planning tool that was functional but ugly. No time to polish it. Meanwhile I was debugging MCP server architecture and planning the music pipeline. Something had to give and it was always the boring middle tasks - the ones that determine whether anyone actually uses the thing.

The solo founder reality nobody posts about

how ADHD and AI work together is performance art now. Revenue screenshots get thousands of likes. MRR milestones. "I quit my job and 6 months later..." threads. Everyone's sharing the wins.

Posts about almost going broke get 12 likes. Posts about abandoning your fourth project in a row get silence. The authentic failures don't get engagement so nobody posts them, which means every new solo founder thinks everyone else has it figured out.

I've been broke. I've shipped things that made zero dollars. I've built for three weeks and then deleted the repo because I couldn't figure out what the product actually was. I've had projects that made real money and then lost relevance six months later because I didn't maintain them.

The solo part: genuinely fast. No meetings about meetings. No "we should align on the roadmap" conversations with a cofounder who has different priorities. No equity negotiation. No founder breakup. I've watched every cofounder horror story play out in real time around me - equity fights, one person doing 80% of the work, fundamental disagreements about direction, personality conflicts that kill companies that should have made it. Solo is lonely. It's also fast.

The ADHD + solo combination creates a specific failure mode though. There's no one to tell you you're going down a rabbit hole. No one to say "we've been working on this side feature for two weeks, should we refocus?" Your own judgment is the only check on your impulses and ADHD makes your judgment unreliable at the exact moments you need it most.

The fix isn't a cofounder. The fix is building systems that act like a cofounder for the structural stuff while you handle the actual building.

What actually survived (and why)

Out of seven active projects, two are still running and one of those is making consistent money.

Five are abandoned or on permanent ice.

Here's the honest accounting: those five failures weren't wasted. They taught me things that made the two survivors better. I learned how to architect agent systems from the music pipeline experiment. The MCP servers gave me infrastructure patterns I'm using in OpenClaw. The ADHD planning tool taught me what actually helps my workflow versus what sounds good in theory.

But the reason the two survivors survived isn't just that I learned from the failures. It's that the survivors automated their boring middles.

OpenClaw runs 14 cron jobs. Morning digest, memory management, content scheduling, health data aggregation, crypto position monitoring - all automated. I talk to it every morning. The daily feedback loop exists. The daily maintenance doesn't.

The crypto products that worked had simple mechanics and network effects that didn't require my constant attention. Once they were live, they ran. The ones that needed daily management died when my attention moved elsewhere.

The pattern is consistent: if I have to manually do something for a project to stay alive, that project will eventually die. Not because I don't care about it. Because ADHD means I'll miss 3 days of manual tasks in a row and then it feels too far behind to recover and then I move on.

If the system can sustain itself through a 2-week hyperfocus absence, it lives. If it can't, it doesn't.

Why I'll never take a cofounder

Everyone says this is a mistake. "Two founder teams outperform solo founders statistically." I've read the YC essays.

Here's my actual take: those statistics are describing average cases and I'm not an average case.

What a cofounder typically brings: accountability, complementary skills, emotional support during hard stretches, a second opinion on decisions, someone to handle the stuff you're bad at.

What I actually need from that list: someone to handle the stuff I'm bad at. Specifically, distribution, SEO, documentation, customer communication. The boring middles.

A human cofounder would need 40-50% equity for that. They'd have opinions about the product direction. We'd need to agree on decisions. We'd have to coordinate schedules. They'd have good months and bad months and burnout cycles that don't sync with mine.

An AI agent running my content pipeline costs me $40/month and doesn't have feelings about feature prioritization.

I'd rather have a multi-agent system that handles my weak spots than a human who wants half the company to do the same job. That's not cynical, it's just math. And it only works because I can build the agents myself.

The loneliness is real. I'm not dismissing it. Some weeks the silence is rough. But the alternative isn't "cofounder" - it's growing on Twitter and genuinely engaging with the community instead of just posting screenshots.

The systems that make solo + ADHD actually work

I've been iterating on this for two years. Here's what actually helps:

File-driven everything. My agents read from markdown files - SOUL.md for personality, AGENTS.md for protocol, MEMORY.md for context. When something needs updating, I edit a text file. No deployments. No configuration hell. Low friction maintenance survives ADHD gaps. High friction maintenance doesn't.

Cron jobs over manual triggers. If a task requires me to remember to do it, it will eventually not get done. Scheduled jobs run whether I'm in a hyperfocus sprint or a three-day crash. Everything recurring gets automated.

Ruthless scope decisions at the start. The ADHD planning tool died partly because I kept adding features during the build phase. Every new feature felt urgent. Scope compound-expanded until the MVP was a six-month project. Now I write down the exact features for v1 and I'm not allowed to add anything until v1 ships. This one rule has probably doubled my shipping rate.

Letting projects die without guilt. I spent too long trying to "get back to" projects I'd mentally left. Felt like failure. Now I have a graveyard folder on GitHub and I use it. Dead projects get documented (so I can steal the code later) and archived. The folder has 22 repos in it. That's fine.

Using the hyperfocus instead of fighting it. When I'm locked in on something, that's a resource. I try to batch the hardest technical work for those windows. The structured boring tasks - docs, config, cleanup - get batched for the lower-energy periods when I can work mechanically.

Finishing 2 out of 7 is actually fine

Here's the reframe that helped me most: the 5 abandoned projects aren't failures, they're the cost of finding the 2 that worked.

Most indie developers don't talk about their abandonment rate. They talk about the thing that shipped. But every shipped product has a graveyard of experiments behind it. The experiments weren't wasted - they were the research.

My music generation pipeline taught me how to build multi-tool AI pipelines. Spent two weeks on it, never shipped it as a product, use those patterns constantly now.

The ADHD planning tool taught me that "I'll use this myself" is not the same as "other people will pay for this." Different lesson. Equally valuable.

The CLI tools I built in weekends are still sitting in my shell. I use them every day. Zero revenue. Huge quality-of-life improvement. Not everything needs to be a business.

The crypto tokens that hit $10M+ market cap came after multiple experiments that went nowhere. The ones that worked worked because of things I learned from the ones that didn't.

Building 7 apps at once as a solo founder with ADHD is chaotic. It's also how you discover which two are actually worth finishing.

If you're building solo with ADHD and you've got four half-built things on your GitHub and you feel like you're failing - you're not. You're doing the process. The trick is setting up the systems so that when the thing that matters is ready to run, it can run without you holding it up.

Automate the boring middle. Let the losers die fast. Stay technical enough to build your own infrastructure. And ignore anyone who tells you the only way to do this right involves giving half your company to someone else.

The agent handling my distribution doesn't want equity. That's the whole point.

If you want to see how the agent system I built actually works - the one that survived while six other projects didn't - I write about it here. The full architecture, the cost breakdown, what broke, what didn't.

How ADHD and AI work together - that's become the actual question I've spent the last year building answers to. Not "how do I fix my ADHD" and not "how do I force myself to be more productive." More like: where are the exact gaps, and can software patch them?

Short answer: yes. Not all of them. But enough to matter.

What ADHD actually costs (it's not what productivity gurus think)

The mainstream narrative is that ADHD means you're distracted and you need to focus better. That's a useless frame. The real problem is executive function failure - the part of your brain that handles task initiation, working memory, time perception, and emotional regulation around boring tasks.

Concretely, that looks like this for me:

• I forget things. Not occasionally. Constantly. Including things I cared about 20 minutes ago.
• I start projects in hyperfocus bursts and sometimes walk away mid-sentence when the dopamine dries up.
• I have a productive window from roughly 11am to 2pm. After 2pm I crash. Creative work comes back around 7pm. This isn't laziness - it's a real energy curve that I've tracked across years.
• Decision fatigue hits me hard. By 3pm, choosing between two options of roughly equal weight can genuinely stall me for 30 minutes.
• Calls destroy my flow state. I've worked async-only since I started freelancing at 14 because traditional structure never fit.

None of this is fixed by a better to-do list app. I've tried every productivity system. GTD, time blocking, Notion templates, physical planners - all failed because they assume linear execution, consistent motivation, and that you'll remember to check the system. ADHD brains don't do any of those things reliably.

What AI does is different. It meets you where you are instead of where you should be.

How ADHD and AI work together in practice

I run a multi-agent system called OpenClaw. One of the agents is borb - that's my day-to-day assistant, and it's the piece that's changed how I work more than anything else in the last two years.

The key insight: AI doesn't need you to have executive function. It has its own.

Borb maintains memory files. When I forget what I was doing - and I will forget - it has a record. When I say "remind me to follow up on this," it doesn't forget. When I ask the same question for the third time, it answers without judgment. That last part is underrated. Executive dysfunction comes with a lot of shame. An agent that just answers, every time, without the sigh or the "didn't we talk about this?" - that's genuinely useful.

The workflows that actually stuck:

Morning state load - borb checks my reminders, pulls calendar events, and gives me a plain-English summary of what's in front of me. I don't have to go hunting across four apps to reconstruct what today looks like. It's already there. This sounds small. It is not small. Starting the day without that reconstruction overhead means I hit my 11am-2pm window with actual energy instead of spending it getting oriented.

Building - I describe what I want in rough terms, the agent scaffolds the structure, and then I hyperfocus on the interesting parts. I've talked about this in building 7 apps at once - the ADHD pattern of "start fast, lose steam" becomes less destructive when the boring scaffolding is already done. The fun parts stay fun. The scaffolding doesn't require motivation.

Writing - AI drafts, I edit. Editing is dramatically easier than a blank page for an ADHD brain. The blank page has infinite options and zero constraints. A draft has something to react to. Even a mediocre draft gives me a direction to push against, and pushing against things is something my brain can do.

Research - This one might be the biggest one. I used to fall down 3-hour rabbit holes when I needed to look something up. Not because I was being inefficient - because that's what an ADHD brain does when it hits something interesting. Now I say "look into X and summarize it" and get back a usable synthesis in 10 minutes. The rabbit hole still exists. I'm just not in it.

Why ADHD and AI work together better than any productivity system I've tried

There's a reason GTD and every app built on top of it eventually fails for ADHD brains. The research on this is pretty clear - executive function deficits aren't a motivation problem, they're a neurological regulation problem. Systems that require you to consistently initiate, remember to check in, and maintain motivation to follow through are asking the exact thing the ADHD brain struggles with most.

AI sidesteps that loop in a way static systems can't. A to-do app is passive. It waits for you. An AI agent can be active - it surfaces things, drafts things, reduces the next action to something trivially small. That difference is the whole game.

The clinical picture backs this up too. Research from ADDitude Magazine's medical review board consistently shows that external scaffolding - someone or something that holds structure on your behalf - is one of the most effective accommodations for executive dysfunction. That's what ADHD coaches do. That's what a good EA does. AI can do a version of it at a fraction of the cost, 24 hours a day, without the social friction of asking a human for help again.

The difference between those external scaffolding approaches and AI: AI doesn't get tired of you.

The 90-day planning system I actually use

One of the more structured things I built is a multi-model planning system for quarterly work. I run it through Claude, Perplexity, and DeepSeek because they think differently.

Here's the rough structure:

# Run planning session across models
# Claude: strategic framing and goal coherence
# Perplexity: research-backed context on what's realistic
# DeepSeek: adversarial review - what did I miss, what's wishful thinking

Claude does the strategic layer - takes my rough "here's what I want to do this quarter" and shapes it into something coherent with actual priorities. Perplexity pulls external context - market stuff, comparable benchmarks, anything grounding. DeepSeek punches holes in it. Tells me where I'm being optimistic, where the plan assumes consistent motivation that I won't have.

The output is a quarterly plan that's actually calibrated to how I work, not how I should work. It accounts for the energy curve. It front-loads high-executive-function tasks to the 11am-2pm window. It builds in slack because I will start a side project mid-quarter.

This cost me maybe $3 in API calls. ADHD coaches charging $500/month are selling something similar - someone to help you structure the chaos. The AI version doesn't replace the human relationship, but it does the structural work well enough that I stopped needing the coach.

What still doesn't work

I want to be honest here because this is where most "ADHD and productivity" content fails - everything sounds like it works great.

Most AI productivity tools are built by neurotypical people for neurotypical people. They assume:

• You'll check the app on a schedule
• That once you've planned something, you'll follow the plan
• That motivation is a dial you can turn up
• That reminders are sufficient to trigger action

None of that is true for ADHD brains. A reminder I ignore three times isn't a reminder problem - it's a task initiation problem. The reminder sees the symptom and treats it by making more symptoms.

The AI tools that work for me are the ones that do the task or reduce it to the smallest possible action. The ones that fail are the ones that just tell me about the task more times. "You have 5 overdue items" is not useful. "I drafted an email for item 3, want me to send it?" is useful.

The other failure mode: AI planners that generate beautiful structured plans I'll never look at again. I've built these myself. They're impressive to screenshot, useless in practice. A plan I'll actually use is ugly, has a lot of slack built in, and survives contact with a day where I wake up unable to do hard things. Most AI-generated plans look like they were made for someone who executes flawlessly and never has a 2pm crash.

The design principle underneath all of this

The best automations I've built are invisible. They give me back the cognitive capacity I was spending on logistics, and I don't notice them working - I just notice I'm less exhausted.

That's the principle I use now when deciding whether to build a new automation: does this return brain capacity, or does it just offload a task I didn't care about?

Offloading boring tasks is fine. But the real value is when an automation handles something that was eating working memory - that background process running in my head that's tracking ten things at once. When borb maintains my memory files, I'm not the one holding context across sessions. That background process is freed up. That's where it gets actually useful.

The principle maps to AI broadly: don't use it to do more things. Use it to think fewer thoughts you didn't want to be thinking.

How I'd actually start if I were building this from scratch

If you're ADHD and you've read this far, here's the concrete version:

1. Pick one gap - not "I want to be more productive." Pick the specific thing that burns the most energy. For me it was morning orientation. For you it might be task switching, or research rabbit holes, or writing block.

2. Build the smallest intervention - don't automate your whole life. Build one thing that addresses one gap. If it sticks, expand it. If it doesn't, the cost was low.

3. Make it push, not pull - tools you have to check don't work for ADHD. Tools that surface things to you do. The difference between "you should open the app" and "here's your summary in Slack at 9am" is the difference between a system I use and one I abandon.

4. Use the right model for the task - I wrote more about my AI engineering stack in the tags section if you want to see the breakdown. Fast cheap models for logistics, more capable models for judgment calls. Don't run GPT-4-class inference for reminders.

5. Don't trust AI planning apps - build your own, even if it's rough. An n8n workflow or a cron job calling an API isn't glamorous but it works because you designed it around your actual workflow, not a generic one.

6. Start with memory before anything else - the single highest-leverage thing AI can do for an ADHD brain is hold context you'd otherwise lose. A markdown file your agent reads and updates is worth more than any reminder system.

The real unlock was accepting that I'm not going to become a different person with a different brain. The goal is building systems that work for this brain. AI is the first category of tool where that's actually been possible at the software layer.

If you're somewhere on the spectrum of neurodivergence and you've been grinding through systems that don't fit - this is worth trying. Not because AI fixes it. Because for the first time, the tools can be weird enough to match how you actually work.

The my coding stack I run is open in spirit if not fully in docs. If you want to talk about how to build something similar, I'm usually in the comments or findable.

This is the first thing I've written for this blog, so bear with me finding the voice. I'll just tell you what actually happened.

What VALK was, and why it mattered

When I joined VALK in November 2019 I was the only designer. Not "lead designer with a team underneath" - actually the only one. Every pixel that shipped went through me.

The platform was built on R3's Corda blockchain for institutional digital assets. Private markets, illiquid assets, end-to-end transaction infrastructure for the kind of clients who don't mess around - 70+ financial institutions — investment banks, hedge funds, and asset managers — across 15+ countries. $4B+ in deals managed on a platform I designed.

I built the design system from scratch. The full transaction platform UX. A DeFi analytics product called Merlin that eventually pulled in 50K+ unique visitors and monitored $5B+ in portfolios. The company won multiple industry awards including Sell-Side Technology and Asset Management recognitions, and got covered in financial industry press.

I'm not listing those numbers to brag. I'm listing them because they matter for understanding what I walked away from. This wasn't a struggling startup I was escaping. The work was good. The platform worked. The clients were real institutions moving real money.

And I still left.

The boredom nobody talks about

Here's the thing about being solo designer at a B2B fintech for five years: you get really, really good at a very specific thing.

Institutional dashboards. Transaction flows. Data tables with 40 columns. Compliance screens. The UX patterns for "a hedge fund analyst needs to review a digital bond issuance at 2am from their phone" - I know that problem deeply. I could design it in my sleep, and toward the end, I basically was.

By 2024 I could sit down in Figma, design a complex fintech feature, spec it for the engineers, and write the documentation in a day. What used to take a week took a day. That sounds like growth but it's actually a yellow flag. When the difficulty drops that far below your current skill level, you're not learning anymore - you're executing.

The work was technically solid. I just stopped caring about it.

That's uncomfortable to say because VALK was a genuinely good product doing genuinely important infrastructure work. The people weren't the problem. The exit wasn't bad vibes - it was boredom and curiosity pulling harder than comfort.

When I started noticing the gap

March 2023. That's when I started doing AI work on the side.

Not because I had a plan. Because ChatGPT had just dropped and I couldn't stop thinking about what it could do. I started building small things - automation workflows, prompt systems, early agent prototypes. Nothing production-ready, just me poking at a new technology the same way I used to poke at new design tools.

The difference was how it felt. I was doing side projects at 2am and not feeling tired. That's the tell. When you're doing something that doesn't drain you even when it should, pay attention.

By mid-2023 I was building autonomous agents with custom personalities for community management and content creation. End-to-end automation workflows in n8n and custom Python. AI-powered music generation pipelines stacking GPT-4 + Suno + Midjourney + ElevenLabs into something that actually sounded like it was made by a person. Not demos - working systems I was shipping and iterating on.

Meanwhile at VALK, I was designing another data table.

The gap between the two tracks kept widening. By late 2024 it was obvious. I wasn't going to close it while staying in the same seat.

Why I didn't leave sooner

Honest answer: salary, stability, and the sunk cost of being good at something.

Five years of context in a product is genuinely valuable. I knew every edge case, every integration, every place the design system had technical debt. Starting over in something new meant being a beginner again - and being a beginner doesn't pay the same as being the person who built the whole thing.

There's also a particular trap that hits people who are technically capable: you can justify staying because the work isn't bad. It's not bad. It's just not growing you. "Not bad" is a terrible reason to stay somewhere, but it's a compelling one in the moment.

I also had no clear destination. "I want to do more AI stuff" isn't a career plan. I didn't have a product to go build, a company to join, or a client waiting. Just a direction. That's terrifying when you're used to a steady paycheck.

What finally tipped it was realizing I was doing the interesting work anyway - just not getting paid for it, and not going deep enough on it because I was saving bandwidth for the job. I had to make a choice about which track was real.

What actually made it hard to leave

This isn't a story about walking away from a soul-crushing corporate grind. I want to be clear about that because those stories are everywhere and this isn't one of them.

VALK was a legitimately good place to work. Async-first by nature - I've been no-calls only for years, and that environment respected it. The team was small and technical. The problem domain was interesting. I had real ownership over a real product.

The hard part was that I was leaving something good. Not escaping something bad. That's a different emotional math.

When you leave something bad, there's relief. When you leave something good, there's mostly just uncertainty. You're trading a known quantity for a direction.

I also felt something like guilt about my design craft. Five years of building that specific muscle - institutional fintech UX, complex data visualization, multi-jurisdictional compliance patterns - and I was shelving it. That felt like waste. It took me a while to see that the design background wasn't being shelved, it was being folded into something new. But I didn't have that clarity on the way out.

Why I left my role as solo product designer at VALK: the honest version

People want a clean narrative when someone makes a big change. The "I had an epiphany" story, or the "the company changed" story, or the "I always knew I'd do this eventually" story.

None of those fit.

The real reason I left my role as solo product designer at VALK after five years is genuinely mundane: I felt like a dinosaur. The world was changing fast, I was sitting still, and I couldn't make peace with that.

AI wasn't an abstraction to me by then - I'd been building with it for almost two years on the side. I knew what was possible. I knew what I could build if I went all-in. And I knew that every month I stayed was a month I wasn't building those things at the depth they deserved.

That's it. No grand vision. No ten-year plan. Just the thing that excited me most wasn't the thing paying me, and eventually that gap gets too loud to ignore.

What came next

February 2025 I went full AI specialist.

The work I've been doing since: building multi-agent systems, OSS CLI tooling, automation workflows that actually handle real complexity. My crypto background from 2021 - shipped tokens to $10M+ market cap, raised $140K in presale in 72 hours - means I'm not new to the intersection of technical infrastructure and product. The combination of design, AI engineering, and crypto is genuinely rare and I'm still figuring out how to use it.

What I'm not doing is pretending I have it figured out. Sustainable income without a salary is a real problem I'm actively working on. The freedom to build what I want comes with the anxiety of not knowing what next month looks like. That trade is live and unresolved.

What I do know: I'm not bored. I sit down to work and lose track of time. That's the benchmark I didn't know I was missing until I had it back.

If you're in a similar spot

I'm not going to tell you to quit your job and follow your passion. That's not advice, that's a bumper sticker.

What I will say: if you're doing the interesting work anyway - on nights and weekends, in the gaps between the real job - that's data. You're already telling yourself what you want. The question is whether you're listening.

The gap between what I was doing at VALK and what I could build with AI was too wide. For me, the answer was to close it. Your math might be different.

But "not bad" is not the same as "right." Know the difference.

If you want to follow what I'm building from here - multi-agent systems, AI tooling, the whole mess of going independent - this blog is where I'll document it. You can read more ADHD and AI, or browse by why most AI products have bad UX if you want to find something specific.