DUMB DEV Community

We didn’t have a coding problem - We had a “where do I even start?” problem

Bogdan Varlamov — Mon, 06 Apr 2026 20:38:19 +0000

Problem

A lot of our tasks started the same way:

unclear Jira description
20–30 minutes just figuring out what is actually required
then jumping around the codebase trying to find the right entry point

If the area was unfamiliar, easily 1–2 hours gone before writing anything.

Or you just go ask someone who knows.

Which is fine, but doesn’t scale

And this wasn’t rare.

This was pretty normal.

What was wrong

We kept paying for the same thing:

understanding context
figuring out patterns
re-learning how things are done

Nothing complex, just repeated work.

And heavily dependent on:

who already knows this part of the system

Solution

We didn’t try to “generate code faster”.

We focused on:

understanding + execution as a single flow

Not magic, just structure.

1. Give the agent real system context (agent.md)

A structured entry point (~500 lines):

architecture and patterns
conventions (code, testing, logging)
how to extend the system
risky areas and common pitfalls

This removes the need to “figure things out from scratch”.

2. Build a custom prompt that actually thinks

Not just “generate code”.

The prompt does this in steps:

Understand the task (type, scope, intent)
Estimate complexity
Decide if it should be solved by the agent
Find relevant parts of the codebase
Propose implementation options
Build a step-by-step plan
Highlight risks
Generate a verification checklist

If the task is too complex, it splits it into smaller parts.

3. Use the agent where it makes sense

If complexity is low/medium - the prompt explicitly suggests using the agent.

At this point the agent already has:

system context
correct patterns
a clear plan

So it can generate:

code aligned with the repository
tests for new functionality
regression tests for existing behavior

Not perfect, but good enough to remove most of the routine work.

Result

Tasks estimated at 6–8 hours - often 2–3 hours
Simple tasks - from ~1 hour to minutes
Less need to “figure things out” before starting

This works because:

context is given upfront
implementation is partially handled
common mistakes are reduced

But the main change:

less mental overhead
faster start
fewer interruptions

Takeaway

Most teams don’t have a coding problem.

They have a “time-to-understanding” problem.

If every task starts with digging through the system

and re-learning patterns, that’s the real bottleneck.

AI helps when:

it understands your system
and is used selectively

I see this a lot:

Teams either don’t use AI,
or try to use it everywhere.

Neither works well.

I see this pattern in many teams - curious how you approach it.

The Seven Engineering Problems That Make Real-Time Enterprise Sync Almost Impossible

Ruben Burdin — Mon, 06 Apr 2026 20:36:30 +0000

I spent 18 months trying to make two databases agree with each other. Not eventually. Not within 15 minutes. In real time, bidirectionally, without losing data.

The first version crashed after 10,000 records. The second version handled the volume but corrupted fields when both systems wrote to the same record within the same second. The third version solved conflicts but broke each time that Salesforce added a custom field. I threw out all three and started over.

That was 2022. I had a business degree, six months of self-taught programming, and a problem I could not stop thinking about: why is it so difficult to keep a CRM and a database synchronized in real time?

Three years and one Y Combinator batch later, Stacksync syncs millions of records across 200+ enterprise systems with sub-second latency. I want to explain why this problem is as hard as it is, because most engineering teams underestimate it until they're six months into a failing project.

1. Polling Is a Lie You Tell Yourself

The first approach every team tries is polling. You set up a cron job that checks Salesforce for changes every five minutes. Maybe every minute if you're ambitious. You pull the delta, write it to Postgres, and call it done.

It works on the demo. It falls apart in production.

Polling has a floor. You cannot poll faster than the API allows, and enterprise APIs are not built for high-frequency reads. Salesforce enforces a daily API call limit that depends on your license tier and the number of seats in your org. A mid-size company with 100 users gets roughly 100,000 API calls per day. That sounds like a lot until you realize that a single SOQL query checking for updated records across five objects consumes five calls. Run that query every minute and you've burned 7,200 calls by end of day on a single sync job. Add a second system, add more objects, add any complexity at all, and you hit the ceiling before lunch.

The deeper problem with polling is temporal. Between polls, the world changes. A sales rep updates an opportunity at 10:01:14. Your poll runs at 10:01:00 and again at 10:02:00. For 46 seconds, your database is wrong. If anything downstream reads that record during those 46 seconds, a customer portal shows stale pricing, an internal tool triggers the wrong workflow, a report goes out with yesterday's numbers.

Forty-six seconds sounds minor. Multiply it by every record, every object, every connected system, and you have a data infrastructure that is never fully consistent. You just hope the inconsistency window is small enough that nobody notices.

We noticed.

2. Change Data Capture Sounds Simple Until You Build It

The alternative to polling is event-driven architecture. Instead of asking "what changed?" on a timer, you listen for change events as they happen. Salesforce offers Change Data Capture. HubSpot has webhooks. NetSuite has SuiteScript triggers.

Each implementation is different. Each has its own delivery guarantees, event formats, retry logic, and failure modes.

Salesforce CDC publishes events to a streaming API channel with a 72-hour retention window. If your listener goes down for longer than that, events are gone. No replay. You need to detect the gap, fall back to a full or incremental poll to reconstruct the missing window, then resume streaming without duplicating records or missing the transition point. That recovery logic alone took our team weeks to get right, and it still needed refinement after edge cases surfaced in production.

HubSpot webhooks fire on property changes but batch them. You receive a payload containing multiple changes to multiple records, and the ordering within that batch is not guaranteed. If record A was updated before record B, you may receive B first. For independent records, ordering does not matter. For related records where a parent update must land before a child reference, out-of-order delivery corrupts your foreign key relationships.

NetSuite SuiteScript triggers fire synchronously inside the transaction. If your sync logic is too slow, the user's save operation in NetSuite hangs. You are directly on the critical path of another vendor's product. Time out, and the user sees an error they cannot diagnose.

Every connector demands its own CDC implementation, its own retry semantics, and its own failure recovery path. There is no universal standard. We build and maintain a separate ingestion pipeline for each of the 200+ systems Stacksync connects to.

3. Bidirectional Sync Is a Distributed Consensus Problem

One-way sync is a pipeline. Data flows from A to B. If B receives a record it already has, you overwrite it. If B receives a new record, you insert it. The logic fits in a page of pseudocode.

Two-way sync is a distributed systems problem. Both A and B can write to the same record at the same time. Neither system knows the other system is also making changes. There is no shared clock, no shared transaction log, no coordinator sitting between them enforcing order.

This is a variant of the same problem that databases solved decades ago with distributed consensus protocols like Paxos and Raft. The difference is that you do not control either endpoint. Salesforce is not going to implement your consensus protocol. Neither is Postgres. You are synchronizing two sovereign systems that have no awareness of each other.

The naive solution is "last write wins." Whichever timestamp is later takes precedence. This fails for three reasons.

First, clocks drift. Salesforce's server clock and your database clock are not perfectly synchronized. NTP reduces drift to milliseconds, but milliseconds matter when two writes happen within the same second.

Second, granularity varies. Salesforce timestamps record-level changes. If a rep updates the phone number at 10:01:00 and your system updates the email at 10:01:00, last-write-wins at the record level discards one of those changes. You need field-level conflict detection, which means tracking individual field timestamps across both systems and merging them independently. The data model for this alone is significant.

Third, intent matters. Some fields should always defer to the CRM because the sales team owns them. Other fields should always defer to the database because an automated pipeline owns them. A blanket conflict resolution strategy treats all fields the same, which is wrong for every real-world use case. You need per-field, per-object, per-direction conflict policies that the customer can configure without writing code.

We spent four months on our conflict resolution engine before a single customer used it. It is the hardest part of the system and the least visible.

4. Schema Is a Moving Target

Enterprise systems do not have fixed schemas. Salesforce admins add custom fields weekly. HubSpot users create custom properties for every new campaign. NetSuite consultants build custom record types for industry-specific workflows.

When a new field appears in the source system, your sync layer has three options: ignore it, fail, or adapt. Ignoring it means data loss. Failing means downtime. Adapting means your system must detect the schema change, determine its type and constraints, create the corresponding column in the target database, backfill historical values for that field, and resume syncing, all without interrupting the ongoing sync of every other field.

This is schema evolution, and it has to happen automatically because you cannot ask a customer to manually adjust their database schema every time a Salesforce admin adds a picklist field.

The edge cases are where it gets brutal. What happens when a field is renamed? Your sync layer mapped it by its API name, which in Salesforce is immutable, but in HubSpot it can change. What happens when a field type changes from text to number? Your Postgres column is a VARCHAR and the source is now sending integers. What happens when a field is deleted? Do you delete the column and lose historical data, or mark it deprecated and keep it?

Every schema change is a migration event that has to execute live, without locks, on a table that is actively receiving writes from both directions. We handle thousands of these per week across our customer base.

5. Rate Limits Are Adversarial by Design

Enterprise SaaS vendors set API rate limits to protect their infrastructure from misbehaving integrations. It's reasonable from their perspective and adversarial from yours.

Salesforce enforces both daily and concurrent request limits. HubSpot throttles at 100 requests per 10 seconds for OAuth apps. NetSuite's concurrency model limits you to a handful of simultaneous connections depending on the customer's license.

Your sync engine needs to be the most efficient possible consumer of these APIs. Every unnecessary call is a call your customer cannot use for something else. Every burst that triggers throttling creates a backlog that degrades your latency SLA.

We implemented adaptive rate management that monitors remaining quota in real time and adjusts throughput dynamically. When quota gets low, the engine shifts to larger batch sizes with fewer calls. When quota is abundant, it runs smaller, more frequent batches for lower latency. The system optimizes continuously for the tradeoff between freshness and quota consumption, and the optimal point shifts throughout the day as the customer's other integrations compete for the same pool.

This is invisible to the customer. They see sub-second sync. Underneath, the engine is playing a real-time resource allocation game against constraints it does not control.

6. Ordering Across Distributed Systems

When you sync a Salesforce Account and its child Contacts to Postgres, the Account must exist before the Contacts reference it. If the Contact arrives first and the Account does not yet exist in Postgres, the foreign key insert fails.

In a single-system database, this is solved by transactions. You wrap both inserts in a transaction and they either both succeed or both roll back. Across systems, there is no transaction boundary. Events arrive when they arrive. The Account creation event might be delayed by network latency, CDC channel ordering, or a retry cycle, while the Contact creation event arrives immediately.

You need a dependency graph that understands the relationships between objects, holds child records until their parents exist, and processes them in the correct topological order. This graph has to account for circular dependencies (Object A references Object B which references Object A), self-references (an Account with a parent Account), and polymorphic lookups (a field that can reference different object types depending on the record).

We process these dependency graphs in real time as events arrive, reordering them on the fly without buffering longer than necessary. Getting this wrong means either data loss (dropping events that cannot be ordered) or data corruption (inserting records with dangling references).

7. The Compounding Effect

Each of these problems is hard in isolation. Together, they multiply.

A schema change triggers a migration that temporarily increases API calls, which hits a rate limit, which creates a backlog, which delays events, which breaks ordering guarantees, which causes a child record to arrive before its parent, which triggers a dependency hold, which extends the latency, which means the conflict resolution window widens, which means more conflicts need to be resolved, which means more writes, which consumes more API quota.

One perturbation propagates through every layer. The system must absorb these cascades without data loss, without latency spikes visible to the customer, and without human intervention.

This is why most internal sync projects fail. The team builds something that works for the first use case, in the first month, with the first 10,000 records. Then the schema changes. Then the volume grows. Then a second system is added. Then an edge case creates a cascade, and the debugging obliges you to trace events across three systems, two CDC channels, a conflict resolution log, and a dependency graph.

Most teams give up and switch to batch ETL. They accept 15-minute delays because the alternative is building a distributed systems engine that very few engineering teams have the time, budget, or expertise to maintain.

What I Learned

Synchronizing enterprise systems in real time is a distributed systems problem wearing a SaaS costume. It looks like a simple data pipeline until you peel back the first layer and find consensus algorithms, schema evolution, adversarial rate limiting, and causal ordering all compressed into a single system that has to run 24/7 without losing a single record.

We have been building Stacksync for three years. The problem has not diminished. Every new connector, every new edge case, every new scale milestone reveals another layer of complexity that was invisible at the previous level.

If your team is considering building this in-house, my honest recommendation is to reflect carefully on the total cost. Not the cost of the first version, which will work. The cost of the 40th version, which is the one that actually survives production at scale.

The engineering is possible. I know because we did it. The question is whether that engineering is the best use of your team's time when their actual job is building your product, not maintaining the plumbing underneath it.

That distinction tends to clarify the decision quickly.

We Added a /refer Page to TIZZLE: A Cleaner Referral Flow That Actually Converts

Xander Taylor — Mon, 06 Apr 2026 20:34:51 +0000

We Added a /refer Page to TIZZLE: A Cleaner Referral Flow That Actually Converts

We just shipped a new page on the TIZZLE site: /refer.

The goal was simple:

make referrals frictionless, clear the payout model up front, and remove the back-and-forth that usually slows intros down.

Why we added it

A lot of referrals were already happening through DMs and email.

That works, but it creates avoidable problems:

missing client details
unclear expectations on commission
inconsistent handoff process
no obvious place to send people who want to refer someone

So we moved that flow into a dedicated page with one clear CTA and a short submit process.

What the new `/refer` page does

The page explains the referral program in plain language:

earn 10% of first project value
no cap on number of referrals
open to developers, agencies, consultants, clients, and friends
payout after the referred client’s first payment clears

Then it gives a direct submit form for:

referrer details
client details
service type needed
optional project context

No account creation.
No long onboarding.
No extra steps after submit.

The conversion decisions behind it

We kept the page focused on one journey:

understand the reward quickly
see concrete payout examples
trust the process through FAQ
submit in under two minutes

A few implementation choices mattered:

clear hero copy with immediate value proposition
reward banner anchored around the 10% model
example payout figures tied to actual service pricing
FAQ section to remove uncertainty before form completion
minimal form fields to reduce abandonment

Why this matters for service businesses

If referrals are part of your pipeline, treating them like a side process costs you.

A dedicated referral page makes the channel:

easier to share
easier to measure
easier to scale without manual coordination

It also improves trust because terms are visible before anyone submits.

Final thought

Most sites optimize for leads from search and ads, but under-optimize referrals even when referrals close faster.

The new /refer page is our attempt to fix that with a cleaner, lower-friction system.

Explore the full site at tizzle.org

Write Once, Publish Everywhere: Build a Multi-Platform Dev Blog Pipeline with GitHub Actions

Akhilesh Pothuri — Mon, 06 Apr 2026 20:34:27 +0000

Zero to Published: Setting Up a Multi-Platform Dev Blog Pipeline

How to write once in Markdown and automatically publish to Dev.to, Hashnode, Medium, and your personal site without losing your sanity or your SEO

You spent four hours writing the perfect technical post, hit publish on Dev.to, then remembered you also need to post it to Hashnode. And Medium. And your personal blog. By the time you're done reformatting code blocks for the third platform, you've completely massacred your article.

Here's the uncomfortable math: developers who cross-post manually often spend roughly 30–45 minutes per platform adjusting formatting, re-uploading images, and fixing broken syntax highlighting — based on typical manual workflows. That can add up to two or three hours of busywork for every single article—time you could spend actually writing.

What if you could write once in Markdown, push to GitHub, and watch your words automatically appear everywhere your readers hang out—with proper formatting, canonical URLs that protect your SEO, and zero copy-paste gymnastics?

By the end of this guide, you'll have a working GitHub Actions pipeline that publishes to four platforms simultaneously, and you'll never manually cross-post again.

Why Your Blog Deserves More Than One Home

Picture this: you spend four hours crafting the perfect tutorial on async/await patterns. You publish it on your personal blog, feel accomplished, then remember you should probably post it on Dev.to. And Medium. And maybe Hashnode. By the time you've reformatted the code blocks three times and fixed the broken images twice, it's midnight and you're questioning every life choice that led you here.

You're not alone. Developer attention is scattered across a dozen platforms, and no single platform has clearly won broad developer mindshare. Your audience might discover you on Dev.to during their lunch break, stumble across your Medium article from a Google search, or find your personal blog through a conference talk. Missing any of these touchpoints means missing readers — and potential opportunities.

Here's the uncomfortable math: manual cross-posting typically takes roughly 30–45 minutes per platform, per article — based on typical manual workflows. That's not writing time — that's reformatting time. Fixing markdown quirks, re-uploading images, adjusting code syntax highlighting, setting canonical URLs so Google doesn't penalize you for duplicate content. Most developers maintain this discipline for exactly two weeks before their cross-posting ambitions quietly die in a browser tab labeled "Draft - Dev.to."

The pipeline we're building solves this with a simple principle: write once, publish everywhere. You'll create your content in a single markdown file, push to GitHub, and watch as automation handles the rest — deploying to your personal blog while simultaneously cross-posting to Dev.to, Medium, and Hashnode with proper formatting and canonical links intact.

No more copy-paste marathons. No more "I'll cross-post this tomorrow" lies we tell ourselves. Just write, commit, and let the robots handle distribution while you move on to your next article.

The Foundation: Git + Markdown as Your Single Source of Truth

Think of your blog content like source code. You wouldn't store your Python files in Google Docs, manually copying changes between team members' laptops. You'd use Git — because Git tracks every change, lets you branch and experiment, and never loses your work. Your writing deserves the same treatment.

Markdown is the plain-text format that makes this possible. Unlike WordPress or Medium's rich editor, a markdown file is just text. Open it in VS Code, Vim, or Notepad — it works everywhere. When you inevitably decide to switch from Hugo to Astro three years from now, your 47 articles come with you. Try exporting a hundred posts from WordPress sometime; I'll wait.

Frontmatter transforms plain markdown into smart content. Those few lines of YAML at the top of each file become your metadata layer:

---
title: "Building RAG Pipelines That Don't Hallucinate"
date: 2024-01-15
tags: [llm, rag, python]
canonical_url: https://yourdomain.com/posts/rag-pipelines
dev_to: true
medium: true
hashnode: true
---

Platform-specific overrides live here too — maybe Dev.to needs different tags, or Medium requires a subtitle. One file holds everything.

Folder structure matters more than you think. Start simple:

content/
├── drafts/           # Work in progress
├── published/        # Live posts (dated folders)
│   └── 2024-01-15-rag-pipelines/
│       ├── index.md
│       └── images/   # Co-located assets
└── templates/        # Reusable frontmatter

Co-locating images with posts means no broken links when you reorganize. Git tracks your drafts' evolution. Every published piece has a paper trail.

Understanding Canonical URLs (The SEO Magic That Makes This Work)

Imagine you have a favorite family recipe. You share photocopies with relatives, but you write "Original in Mom's cookbook, page 42" at the bottom of each copy. If anyone wants to know the real source, they know exactly where to look. That's a canonical URL — it's you telling search engines "this is my original content, everything else is an authorized copy."

Without this signal, Google sees your brilliant post appearing on your blog, Dev.to, Medium, and Hashnode and thinks: "Four identical articles? Someone's gaming the system." The result? All versions get penalized, or Google picks a random one as the "original" — often not your personal site.

Here's how each platform handles canonicals differently:

Dev.to makes it easy — add canonical_url to your frontmatter, and they automatically add the proper <link rel="canonical"> tag pointing back to your blog
Hashnode goes further, offering a dedicated "Originally published at" field that both sets the canonical AND displays a visible attribution link
Medium is trickier — you must import stories using their "Import a story" feature (not copy-paste) to set canonicals, or manually add it in story settings

The one frontmatter field that saves your SEO:

canonical_url: https://yourblog.com/posts/your-article-slug

That single line is your insurance policy. Every platform in your pipeline should read this field and respect it. Your personal blog becomes the authoritative source, the copies drive traffic back to you, and Google rewards everyone appropriately.

No canonicals? You're essentially competing against yourself for rankings. With them? You're building a syndication network where every platform amplifies your original work.

Building Your Publishing Pipeline with GitHub Actions

Think of GitHub Actions as your personal publishing assistant who never sleeps. You write, you push, they handle the rest — formatting, authenticating, posting to three platforms before your coffee gets cold.

The Basic Trigger: Push and Publish

Your workflow starts simple. When you push to your main branch (specifically to the posts/ folder), the pipeline wakes up:

name: Publish to Platforms
on:
  push:
    branches: [main]
    paths:
      - 'posts/**'

This prevents every tiny README change from triggering a publishing spree. Only new or updated posts start the machine.

Secrets: Your API Keys' Secure Home

Never commit tokens. Ever. GitHub's repository secrets are your vault:

Navigate to Settings → Secrets and variables → Actions
Add DEVTO_API_KEY, HASHNODE_TOKEN, and MEDIUM_TOKEN
Reference them in workflows as ${{ secrets.DEVTO_API_KEY }}

Each platform's API authentication differs slightly — Dev.to uses a simple API key header, Hashnode requires a Personal Access Token with publication permissions, and Medium's integration token needs specific scopes. Store all three; your workflow will pull the right one for each platform.

The Quirks That Will Bite You

Here's where pipelines get messy:

Image URLs: Relative paths break everywhere. Convert all images to absolute URLs pointing to your hosted site or a CDN
Code blocks: Dev.to handles triple-backtick fencing beautifully; Medium sometimes mangles language hints. Test your syntax highlighting
Markdown flavors: Hashnode supports MDX components, Medium strips most formatting, Dev.to has liquid tags. Your pipeline needs platform-specific transforms

The solution? A preprocessing step that reads your canonical Markdown and outputs platform-flavored versions before each API call.

The blogpipe CLI: A Working Cross-Posting Tool

Think of blogpipe as a smart mail carrier that knows each recipient's preferences — it takes your single letter (Markdown post) and reformats the envelope appropriately for every destination.

The architecture is straightforward: Markdown in → frontmatter extraction → platform-specific transforms → API dispatch. When you run blogpipe publish ./posts/my-article.md, here's what actually happens:

The parser reads your file and separates YAML frontmatter (title, tags, canonical URL) from content
Transform functions modify the Markdown per platform — Medium gets simplified code blocks, Dev.to gets liquid tag conversions
API handlers authenticate and POST to each enabled platform

The features that save your sanity:

Dry-run mode (--dry-run) previews exactly what would publish without touching any APIs. It shows you the transformed content for each platform, validates your frontmatter, and catches broken image links. Always run this first.

Canonical injection automatically sets the canonical URL on every platform pointing back to your primary site. This isn't optional — without it, you're creating duplicate content that hurts your SEO and confuses readers who find the same post multiple places.

Image URL transformation rewrites relative paths (./images/diagram.png) to absolute URLs (https://yourblog.dev/posts/my-article/images/diagram.png). Broken images are the fastest way to look unprofessional.

Atomic error handling is critical. If Dev.to publishes successfully but Medium fails, you shouldn't end up with a half-distributed post and no idea what happened. Blogpipe uses a transaction-like approach: it attempts all platforms, collects results, and gives you a clear report of what succeeded, what failed, and retry commands for failures.

When Things Break: Gotchas and Platform Limitations

Let's be honest: this pipeline will break, and usually at the worst possible time. Here's what's going to bite you.

Medium's API Is Basically Hostile

Medium deprecated their official API years ago and never brought it back. The "Integration tokens" in settings technically work but are severely limited — you can create posts, but you can't update them, can't delete them, and can't even reliably fetch your own content. The workaround everyone actually uses? RSS import. You publish to your canonical site, Medium pulls from your RSS feed, and you manually claim the post. It's clunky, but it works consistently. Some developers use unofficial API endpoints discovered through browser inspection, but these break without warning.

Rate Limits Will Find You

Dev.to allows 30 requests per 30 seconds — generous for publishing, but aggressive if you're also fetching to check existing posts. Hashnode's GraphQL API is more forgiving but has daily limits. The solution: implement exponential backoff with jitter. Don't just retry after 1 second, 2 seconds, 4 seconds — add randomness (1.2 seconds, 2.7 seconds, 4.1 seconds) to prevent thundering herd problems if you're running multiple pipelines.

Silent Code Block Destruction

This one hurts. Medium converts triple-backtick code blocks into their proprietary format, often stripping language identifiers and mangling indentation. LinkedIn's article editor is worse — it can completely flatten multi-line code into a single paragraph. Dev.to and Hashnode handle Markdown properly, but always verify after publishing. The safest approach: use GitHub Gist embeds for critical code samples. They render correctly everywhere and update automatically when you fix bugs.

Your First Week: A Practical Rollout Plan

Think of your first week like setting up a new kitchen. Days one and two, you're just getting organized — putting things in the right cabinets so you can actually cook later.

Day 1-2: Build Your Foundation

Create your repository with the folder structure we discussed: /content/posts/, /templates/, and /.github/workflows/. Write your first post in Markdown — pick something short, around 500 words. This isn't about creating your masterpiece; it's about having real content to test the pipeline. Include a code block, an image, and a link. These three elements break most cross-posting workflows, so you want to catch issues early.

Day 3-4: Wire Up Automation (But Don't Go Live)

Configure your GitHub Actions workflow with a critical flag: dry-run: true. This simulates publishing without actually posting anything. You'll see exactly what would happen — which API calls would fire, how your Markdown transforms for each platform, where images would upload. Run this at least three times with small tweaks to your post. Check the output logs obsessively. When everything looks right, manually publish to ONE platform (I recommend Dev.to — its API is the most predictable) and verify the result matches your dry-run preview.

Day 5+: Launch and Learn

Remove the dry-run flag. Publish a real post. Then immediately check all platforms. Something will be wrong — accept this now. Maybe Hashnode stripped a heading level, or Medium's code block lost syntax highlighting. Fix it, update your templates, and try again next week.

Set up basic tracking: which platform drives the most views? Most engagement? After a month of data, you'll know where to focus your energy.

Full working code: GitHub →

Building a multi-platform publishing pipeline isn't about chasing vanity metrics across every site—it's about writing once and letting automation handle the tedious copy-paste-reformat dance that kills most developer blogs before post three. The upfront investment feels steep (five days of setup for a blog post?), but you're not building infrastructure for one article. You're building infrastructure for the next hundred. Every post after this one takes fifteen minutes from draft to published-everywhere, and that changes the economics of writing completely.

Key Takeaways

Start with Markdown as your single source of truth — platform-specific quirks get handled in templates, not in your writing process
Dry-run mode is non-negotiable — test your pipeline with fake publishes until you trust it, then test it three more times
Track results from day one — a month of data will tell you which platforms deserve your attention and which are just noise

What surprised you most about multi-platform publishing? Drop a comment below—I'm especially curious if anyone's found clever workarounds for Medium's image hosting limitations.

50 Things Anthropic's API Can't Do (And We're Going to Walk Through Every Single One)

Jonathan Murray — Mon, 06 Apr 2026 20:34:17 +0000

Quick disclaimer before we start: Claude helped me write this. Very intentionally.

Not just "helped," either.

I gave Claude direct access to our docs at docs.backboard.io. It navigated the docs itself, read them, and produced this list.

So yes, an AI made by Anthropic read our documentation and wrote about the limitations of Anthropic's own API.

It did not argue.
It did not resist.
Because it knows.

So let's talk about what it knows.

Anthropic's API is stateless.
So is OpenAI's.
So is Grok.
So is OpenRouter.

That one word, stateless, explains almost every pain point developers hit the second they move beyond a toy demo.

And yes, we solve this at Backboard. You get free state for life, by the way. Not to bury the lead. But that is only part of the story.

Here is the bigger point.

Stateless means every API call starts from zero.

The model does not know who you are.
It does not know what was said five minutes ago.
It does not know what your user cares about.
It does not know what happened in the last session.

You send context.
It responds.
The connection closes.
It forgets.

That is not a bug.
That is the design.

These APIs are low-level primitives. And low-level primitives are supposed to be simple.

But the second you try to build something real, something users come back to, something that gets better over time instead of feeling reset every session, you hit a wall.

And that wall is infrastructure.

Session management.
Context window handling.
Memory extraction and retrieval.
Vector databases for RAG.
Multi-provider credential management.
Agent orchestration.

None of that ships with the raw API.
All of it becomes your problem.

That is where Backboard comes in.

Backboard is a single API layer that handles all of it across 17,000+ models, including Claude, GPT, Gemini, Grok, and more.

Shared state.
One key.
One abstraction.

Below is a list of 50 specific things Backboard does that the raw Anthropic API does not.

We are going to break all of them down in a 5-part series, starting with the most important concept: what "state" actually means.

Then we build from there, all the way to multi-agent systems you can spin up by describing what you want in plain English.

For now, here are the headlines. Follow me if you want to see all 5 parts without battling the Algo.

State and Conversation Persistence

Persist a full conversation across sessions without storing anything yourself
Pick up exactly where you left off, days or weeks later
Give every user their own isolated conversation thread
Run unlimited threads per assistant
Tag threads with metadata like user IDs, plans, or channels
Get the full structured conversation history back from the API at any time
Keep threads alive indefinitely until you explicitly delete them

Memory Across Sessions

Have an assistant automatically remember user preferences between completely separate conversations
Auto-extract facts from conversations and store them in a knowledge base
Automatically retrieve relevant memories when they matter, without writing any retrieval logic
Pre-load what you already know about a user before they ever say a word
Search semantically over everything the assistant has learned about a user
Use memory in read-only mode, retrieve without ever writing
Add, update, or delete specific memories via API
Customize exactly what kinds of facts get extracted, per assistant
Use higher-accuracy memory extraction for high-stakes use cases
Share everything the assistant learns about a user across all of that user's conversations

Context Window Management

Automatically handle conversations that exceed the model's context limit
Never manually count tokens or write truncation logic
Switch models mid-conversation without recalculating context for the new model
Automatically adjust document chunking when the model changes

Model Routing and Multi-Provider Access

Access 17,000+ models from a single API key
Switch models mid-conversation without losing any state or history
Use different models for different messages in the same thread
Route cheap queries to cheap models and hard ones to expensive models, in the same thread
Implement transparent provider fallback when a provider goes down
Browse the full model catalog programmatically, filter by capability, context size, and price

RAG and Document Intelligence

Upload a document and have it queryable in minutes with zero infrastructure
Get hybrid keyword and semantic search automatically on every query
Index mixed document types in one knowledge base, PDFs next to code files next to spreadsheets
Scope a document to a single conversation instead of the whole assistant
Choose your own embedding model and dimensions per assistant
Tune how many chunks get retrieved per query
Index code files natively alongside prose
Check document indexing status and get chunk and token counts back from the API

Tool Calling with Persistent State

Have every tool result automatically become part of the persistent conversation history
Chain multiple rounds of tool calls without rebuilding state between rounds
Loop tool calls until the agent reaches a completed state
Run multiple tools in parallel within a single response
Stream the final answer to the user after tool execution completes

Web Search

Give an assistant real-time web access with a single parameter
Let the assistant decide on its own when to search vs. use what it already knows
Combine live web search, persistent memory, and streaming in one API call

Multi-Agent Architecture

Run parallel agent threads simultaneously and merge outputs in a coordinator
Build specialist and coordinator agent networks
Give each agent in a network its own model
Give each agent its own system prompt and identity
Give each agent distinct tool-calling capabilities
Have every agent in a network share what they know about the same user
Describe a complete multi-agent system in plain English and have it built for you, no code required

That last one gets its own post. It's the whole point of doing all the other work first.

What's coming

This is the start of a 5-part series. Each post takes a chunk of the list above and walks through it properly, starting from first principles. If you don't know what "state" means, Part 1 explains it. If you've never thought about the difference between conversation context and long-term memory, Part 2 covers that. We're not assuming anything.

Part 1 (Beginner): What state is, why it matters, and your first 10 stateful patterns explained from scratch.

Part 2 (Intermediate): The difference between context and memory, and 10 patterns that make your assistant genuinely smarter over time.

Part 3 (Advanced): RAG without the infrastructure. Hybrid search, mixed document types, scoping, tuning.

Part 4 (Expert): Multi-model routing, stateful tool chains, and parallel agent execution.

Part 5 (Master): Describing multi-agent systems in plain English and having them built for you via MCP.

Follow along. By the end you'll have gone from "what is state" to building systems most teams spend months architecting.

Start here: docs.backboard.io
Or just get an API key: app.backboard.io — $5 free credits, no credit card needed

Brainstorming with BMAD and Qwen Code.

Kévin Drapel — Mon, 06 Apr 2026 20:33:36 +0000

Introduction

There are plenty of tools that promise to make coding faster. Fewer actually help you think better.

That difference matters. Most mistakes in software don’t come from typing speed or syntax. They come from unclear thinking, rushed decisions, or blind spots that only show up later when things break.

This article is about a setup that tries to address that problem directly: combining BMAD as a structured thinking framework with Qwen Code through its CLI. The goal is not just to generate code, but to guide how decisions are made before and during implementation.

To make that practical, I will use the Six Thinking Hats approach as the backbone for brainstorming. It forces you to look at a problem from multiple angles, instead of defaulting to the first idea that “seems good enough.” When paired with a CLI-driven coding assistant, it becomes a workflow: think deliberately, then execute quickly.

This is not a theoretical piece. It’s about how to actually use these tools together to reduce bad decisions. While my example will focus on software development, the tools and techniques presented here are broadly applicable to many contexts and industries, including decision-making, business plans, presentations, what-if scenarios, etc.

The Squad

This setup uses two components:

Qwen Code (CLI) to write and run code from the terminal
BMAD framework (v6) to structure thinking and guide decisions The BMAD framework is available for all common AI tools (Claude Code, Codex, etc.)

Qwen Code

https://github.com/QwenLM/qwen-code

Installing Qwen Code is straightforward, follow the official setup instructions. Using npm is recommended, as it is the standard package manager for most AI-related tooling. You must install NodeJS v20+, we will also need it for BMAD in a moment.

You will need a Qwen account to use the CLI. Notably, Qwen provides a very generous free-tier quota. It is possible to run full sessions at no cost that would otherwise cost tens of dollars on comparable plans such as Claude. You can even use a local model (Qwen models are opensource) if you want a 100% standalone and free version (but be aware BMAD may not work properly if model capabilities are too tight), check my article on this: https://medium.com/@kevin.drapel/your-local-qwen-with-qwen-cli-and-lm-studio-564ffb4c1e9e

Qwen can be invoked from the commandline by simply launching “qwen”. You will need to authenticate the first time (/auth command in case of issues), choose “Qwen OAuth” which is the free plan.

BMAD 6

The acronym stands for “Build More Architect Dreams” It is a comprehensive Agile development framework, but in this context only a small subset is used, specifically the brainstorming capability.

bmad-code-org / BMAD-METHOD

Breakthrough Method for Agile Ai Driven Development

Build More Architect Dreams — An AI-driven agile development module for the BMad Method Module Ecosystem, the best and most comprehensive Agile AI Driven Development framework that has true scale-adaptive intelligence that adjusts from bug fixes to enterprise systems.

100% free and open source. No paywalls. No gated content. No gated Discord. We believe in empowering everyone, not just those who can pay for a gated community or courses.

Why the BMad Method?

Traditional AI tools do the thinking for you, producing average results. BMad agents and facilitated workflows act as expert collaborators who guide you through a structured process to bring out your best thinking in partnership with the AI.

AI Intelligent Help — Invoke the bmad-help skill anytime for guidance on what's next
Scale-Domain-Adaptive — Automatically adjusts planning depth based on project complexity
Structured Workflows — Grounded in agile best practices across analysis, planning, architecture, and implementation
Specialized…

View on GitHub

In practice, the framework installs a collection of agents and skills into a local folder. These can then be invoked by an AI coding agent, such as Qwen Code in this setup.

Preparing our Project for BMAD

Create an empty folder on your disk, this is the place where the project will be stored. BMAD will create a few folders next to the one of Qwen (.qwen).

Launch a terminal, navigate to the folder, then launch BMAD setup:

npx bmad-method install

First question in the installation process will be the folder, you can just press Enter to install it in the current one (and Enter a second time to confirm).

When asked for the modules to install, pick the 3 first modules (use arrows/space to enable them), then Enter to confirm.

BMAD will ask if you want to add custom modules or agents, you can answer No and continue. Next step is the integration with tools, here we need to select “QwenCoder”.

Next questions are about the interaction, how you want the agent to call you and in which language. The choice is up to you but we will continue in English. We also choose the default output folder.

The module configuration is then set on “Express Setup”.

BMAD finalizes the installation and we are ready to go.

Invoking The Brainstormer

With the setup complete, we can now use BMAD inside Qwen.

Launch Qwen and enter “/skills” command. You should see a long list of “bmad-xxxxx” skills indicating your installation was successful. We are going to use bmad-brainstorming.

Before going into the skill, let’s set the scenario for our brainstorming demonstration: we aim to develop a web application for gardeners that assists them in planning their next plantings. The app will help them decide what to plant, when to plant it, and the optimal locations for each plant in their garden.

We now need to expand this idea but we are not sure what the best options are, so we will use the bmad-brainstorming skill to help us. In Qwen, we simply type “bmad-brainstorming” as a prompt (in Claude Code and other tools, the skills are exposed as real commands). Note that during the different steps, BMAD (through Qwen) will ask different permissions to write files into its folders. “It keeps track of the intermediate steps as markdown files.

The skill asks us what is the vision and what are the expected outcomes.

This is our first answer:

1) Make a simple web tool for gardeners that tells them what veggies to plant and where to put them. It should give seasonal tips based on where they live and let them map out their plants in basic beds or pots. Keep it simple, don’t ask for too much info, and focus on being clear rather than super precise. 2) I want to have a specification that can be used for the implementation.

BMAD summarizes the key aspects of the vision and wants us to confirm if we are aligned on the goals. It also proposes the approach for the next steps. There are different brainstorming methods available and depending on the kind of goal to achieve, you can let it propose the most appropriate choice. You can also enforce a given methodology.

We prompt “1” for the user-selected techniques, BMAD shows a list of categories. You could choose one of the main category or you can enforce a specific approach here: “Six Thinking Hats” by De Bono (https://en.wikipedia.org/wiki/Six_Thinking_Hats).

This method involves adopting multiple perspectives to examine goals and challenges. It is especially valuable in software design, as it clearly separates emotional, analytical, and creative thinking, helping reduce bias in decision-making. Each “hat” is associated with a specific colour and represents a distinct mindset.

I want to use Six Thinking Hats

BMAD invites us to either continue with this or add another methodology into our process. As we want to keep it simple for the sake of the demonstration, we just continue.

Going through the Hats

BMAD starts with the blue hat that is focused on the thinking process.

One important point: you are not required to write everything in detail, you can complete your ideas iteratively. This is where AI is extremely powerful as it can easily pivot. If a request is unclear or you can’t make up your mind, you can also say you don’t know, ask for some suggestions or simply skip an answer.

Coming back to the blue hat, we are asked what the key components are, logical flow, constraints. Here I skip the answer for question 2, I will only answer for 1 and 3.

I need functional specifications, as well as technical specifications.

It must be simple for a gardener, audience is not expected to be familiar with computers We get a summary of the blue hat and BMAD switches to the white hat which is focusing on facts. This is one of the most important hats because it builds the pillar leading to a robust analysis.

The questions are targeting the needs and required data to achieve the goals. We give some answers based on our expertise:

When to plant, what kind of soil, sunny vs shady area, when is the harvest.

location, season, space between plants.

we need the location of the garden to figure out if the area is cold, mild, etc. we also need the spacing information and some plants cannot be planted together, you also need to consider rotations.

watering needs

White hat is summarized and then the red hat is presented with a perspective based on the gut feeling.

The questions focus on the feeling of the users, what they like and what is frustrating them, as well as our own feeling. This is our answer:

they should feel that the tool is reliable, they must feel relieved that they do not have to keep in mind all the scheduling

missing planting at the right time + missing watering

it is important to have a calendar and reminder of regular tasks (watering)

users would love to be guided

I will skip the next hats (yellow, black, green) but the process is similar, you just answer to refine the AI’s understanding. The black hat is particularly interesting as it forces you to adopt a negative mindset, what could go wrong. The green one takes the opposite path, how to get out of the negative aspects. The yellow one focuses on the benefits.

At the end, the blue hat is presented again if we want to refine the mindset. We just ask BMAD to go forward with a “let’s continue”.

A summary of the hats is shown and again BMAD asks you what you want to do next. You can add more ideas, dive deeper into a particular topic or just continue. To keep the demo concise, we proceed directly to specification generation.

Generated Specification

A specification is quickly generated. It covers all sections you could expect from such document: overview, functional specification with features and user stories.

The technical aspects are covered as well as it was part of the information we requested: architecture, technical stack, data sources, APIs, etc.

Further Refinements

At this point, it is strongly recommended to read the first version of the generated document. You will probably have some changes to perform in it. You may have new ideas that come up during the review. Instead of simply changing manually the .md file, you can make a new round of brainstorming.

This is what we are going to do by invoking the “green hat” (the optimistic view) again

Can we make a run with a green hat, I would like to improve a few things

As we had made a first full pass of Six Thinking Hats, the green hat is now presented with some additional ideas that you can explore.

Green hat comes up with some ideas such as a webcam in the garden.
We propose a few new ideas but also ask for some advice:

I think it would be nice to have an idea of the incoming weather in that area. I think users would also like to have the schedule that is printable (PDF?) . Can you also propose me some ideas going into those directions?

The green hat comes up with an extensive set of areas to explore and summarize them. Our proposal is the first one in the list, but BMAD also brought some new ideas such as a “harvest goals calculator” or a gamification with “streaks & badges”. We decide to go for the practical additions (B).

B is nice, proceed with that
BMAD proceeds with the necessary changes in our specification.

Jumping to another Brainstorming Method

Maybe you feel the Six Thinking Hats is not sufficient or appropriate for your usage, you can instruct BMAD to propose you an alternative:

Can you suggest another brainstorming method that would be appropriate? We would continue with it

It recommends a few options, the top 3 is:

Question Storming: You have a solid spec now identify what you don’t know yet. Assumption Reversal: Challenge the design decisions you’ve made to find better alternatives. Constraint Mapping: Before implementation, know which constraints are real vs. imagined

We go with the Assumption Reversal.

We get challenged on the location, what happens if the user NEVER enters his location. This removes a lot of information that could be useful for the garden management.

The user will not have access to weather information. It will not be possible to give advices on the right time for planting. An alternative could be to allow the user to choose a hardiness zone if he does not want to disclose his exact location. If none of this is possible, the suggestions will be disabled.

If we stop the process at that point, we get a conclusion with our reversal thinking. After each major milestone, we are proposed to continue with brainstorming, adapt the plan or proceed with the implementation.

Conclusion

The brainstorming tool in BMAD is not just a way to generate ideas, it is a way to structure thinking.

By combining perspective-based reasoning and exploration, it transforms what is usually an unstructured and sometimes inconsistent process into something repeatable and reliable. Ambiguities are reduced early, hidden constraints surface naturally, and ideas evolve into more coherent solutions.

The time invested in this phase is not wasted. It directly impacts the quality of the outcome by strengthening the foundations of the solution before any implementation begins.

Used properly, BMAD does not just help you think of better ideas, it helps you design better systems.

Original article:

medium.com

The Release That Broke Everything

Wu Long — Mon, 06 Apr 2026 20:32:27 +0000

Some releases ship features. Some ship fixes. And some ship chaos.

OpenClaw v2026.4.5 managed to break things on every major platform simultaneously. Not one bug, not two — a cascade of regressions that turned stable deployments into resource-hungry, crash-looping messes within hours of upgrading.

Let's look at what happened, because the failure modes here are textbook examples of how complexity compounds.

The Damage Report

Within 24 hours of v2026.4.5 going live, users reported failures across macOS, Windows, and Linux. Here's the highlight reel.

macOS: 87 Processes, 888% CPU

#62051 is the kind of bug report that makes you wince. A Mac Mini user upgraded from v2026.4.2 and watched their system spawn 87+ worker processes, each independently loading all plugins:

[plugins] BlockRun provider registered (55+ models via x402)
[plugins] Registered 1 partner tool(s): blockrun_x_users_lookup
[plugins] Not in gateway mode — proxy will start when gateway runs

That message repeated for every single child process. The result:

103 total openclaw processes (vs ~8 on the previous version)
888% CPU across all cores
Load average 17.77 on an 8-10 core machine
API response times went from 10ms to over 2 minutes

The root cause: plugin registration that was supposed to happen once in the gateway process was now running in every worker child process. Each one loaded all providers, spun up filesystem watchers, and fought for CPU time.

Windows: Stack Overflow Before Startup

#62055 hit Windows users with a completely different failure mode. The CLI wouldn't even start:

RangeError: Maximum call stack size exceeded
    at evaluateSync (node:internal/modules/esm/module_job:458:26)

The ESM module graph had grown significantly between releases. On Linux and macOS, V8's default stack (~8 MB) handled it fine. On Windows, the default ~1 MB stack couldn't cope. Users who worked around the stack issue with --stack-size then hit heap OOM at 4 GB.

Same codebase, same version, completely different crash — because the release process didn't test against platform-specific V8 defaults.

Linux: Tools Rendered as Raw Text

#62089 was subtler but arguably worse. Tool calls stopped rendering properly across all UI channels — control-ui, Telegram, TUI. Instead of formatted output, users saw raw [TOOL_CALL] blocks.

The tools still executed fine. The results were correct. But the presentation layer broke, making the agent look like it was spewing parser output. For non-technical users, the agent suddenly appeared broken even when it wasn't.

The Compound Effect

One user (#62095) documented the full experience: 10 gateway restarts in 8 hours. Their stable Mac Studio M3 Ultra setup hit all of these simultaneously:

doctor --fix didn't actually fix the warnings it reported
Subagent announce timeouts defaulted to 120s, blocking the gateway for up to 8 minutes per failure
New security checks broke existing LAN setups without migration guidance
Slack health-monitor reconnected every 35 minutes in a loop
Gateway hit 1.5GB RAM with 379 accumulated session files

Each issue alone was survivable. Together, they made the system unusable.

Why This Happens

This isn't unique to OpenClaw. Any fast-moving project with these characteristics is vulnerable:

1. Plugin isolation boundaries shift silently. The worker process change probably looked innocent in the diff — maybe a refactor that moved initialization earlier, or a startup path that stopped checking whether it was in gateway mode. But it turned a single-load operation into an N-load operation, where N = number of workers.

2. Platform-specific limits aren't in CI. The module graph grew gradually across many PRs. No individual change was problematic. But the cumulative effect crossed Windows' stack threshold. Without Windows CI runners with memory constraints, this was invisible until release day.

3. Default values are load-bearing. The 120-second announce timeout was probably fine when subagents were rare. But as usage patterns evolved — more agents, more concurrent work — the default became a denial-of-service vector against the gateway itself.

4. Presentation regressions are stealth killers. The tool rendering bug didn't affect functionality at all. But it destroyed the user experience. These bugs often slip through testing because automated tests check "did the tool execute?" not "did the result render correctly?"

The Deeper Pattern

What makes v2026.4.5 interesting isn't any single bug — it's the simultaneity. Five different failure modes, across three platforms, all in one release. This usually means one of two things:

A large structural change (like the plugin loading refactor) had cascading effects that weren't fully traced
Multiple risky changes landed in the same release window without adequate soak time

The fix is almost never "more testing" in the abstract. It's more specific:

Canary releases that expose changes to a subset of users first
Platform-diverse CI that catches the Windows-specific failures before they ship
Resource-budget tests that fail when process count or memory exceeds expected bounds
Rollback documentation so users know exactly how to get back to the last stable version

For Agent Builders

If you're building on top of a fast-moving agent framework:

Pin your versions. Don't auto-upgrade to latest. Wait 48-72 hours after a release and check the issue tracker.
Monitor your resources. Process count, memory, CPU — these are your early warning system. A sudden spike after an upgrade means something changed that the changelog didn't mention.
Keep the previous version's binary. Being able to roll back in 30 seconds is worth more than any amount of testing.
Test your specific platform. "Works on my machine" is especially dangerous when the codebase targets Linux, macOS, and Windows simultaneously.

v2026.4.5 will get patched. The individual bugs will get fixed. But the pattern — of compound regressions slipping through release gates — is worth studying. Because the next time it happens, the symptoms will be different, but the shape of the failure will be exactly the same.

Building a Multi-Agent ATDD Pipeline with LangGraph and Hexagonal Architecture

Carlos Eduardo Sotelo Pinto — Mon, 06 Apr 2026 20:30:48 +0000

Building a Multi-Agent ATDD Pipeline with LangGraph and Hexagonal Architecture

Write the spec, mark the story as ready, walk away. The agents do the rest.

The problem with solo AI development

Building a product solo is brutal.

You are the PO, the architect, the developer, and the QA — all at the same time. When AI coding agents entered the picture, I didn't see a magic button. I saw a new kind of team member that needed the same thing any team member needs: clear responsibilities, short tasks, and a verifiable definition of done.

The first thing I tried was the obvious approach: long prompts, one agent, do everything. It failed the way it always fails. The model drifted, lost context, and confidently built the wrong thing.

Then I applied something I already knew from software architecture:

Divide and conquer.

If a long prompt fails, what about a very short one with a very specific context? What if instead of one agent doing everything, you had multiple agents — each with a single role, a precise skill, and just enough context to do their job?

That question led me to build an ATDD orchestrator: a pipeline of specialized AI agents, coordinated by a state machine, that takes a user story from spec to acceptance without human intervention in the technical stages.

In this article I'll walk through the architecture, the design decisions, and — the main focus — how replacing a Celery queue with a LangGraph state machine made the whole thing significantly cleaner and more explicit.

What is ATDD and why does it fit AI agents perfectly?

Acceptance Test Driven Development says: write acceptance criteria first, then build until they pass. The acceptance criteria — written as Gherkin scenarios — are the only real definition of done.

This maps naturally to a multi-agent pipeline:

Architect (human + Claude): define the spec, write the acceptance criteria, refine user stories
Test engineer (autonomous): write unit and integration tests in RED — before any implementation
Developer (autonomous): make the RED tests pass — and only that
Tester (autonomous): quality gate — regressions, ruff, mypy
ATF worker (autonomous): run the Gherkin acceptance scenarios with Playwright + Behave

Each role has a single responsibility. Each transition is triggered by a status change in a file. No agent can skip a stage or self-certify completion.

story.md → status: ready
              │
              ▼
        test_engineer  → tests in RED
              │
              ▼
          developer    → tests GREEN
              │
              ▼
            tester     → quality gate
              │
              ▼
          atf_worker   → acceptance scenarios pass
              │
              ▼
        status: accepted  ✓

The spec is the contract. The Gherkin scenario is the verdict.

The architecture: hexagonal all the way down

Before talking about LangGraph, it's worth understanding the underlying architecture — because it's the reason the LangGraph integration was so clean.

The orchestrator follows strict hexagonal architecture (ports and adapters):

domain          — pure Python, no external dependencies
application     — imports domain only (use cases)
infrastructure  — imports domain + application + external libs

The domain defines three ports (interfaces):

class StoryRepository(ABC):
    def get(self, story_id: str) -> Story: ...
    def save_status(self, story_id: str, status: Status, note: str = "") -> None: ...
    def find_by_status(self, status: Status) -> list[str]: ...

class CodeRunner(ABC):
    def run(self, role: str, prompt: str) -> None: ...

class TaskQueue(ABC):
    def enqueue(self, task_name: str, story_id: str) -> None: ...

Each use case depends only on these ports. For example, RunDeveloper:

class RunDeveloper:
    def __init__(self, story_repo, runner, queue): ...

    def execute(self, story_id: str) -> None:
        try:
            self._runner.run("developer", _PROMPT.format(story_id=story_id))
            self._repo.save_status(story_id, Status.READY_TO_TEST)
            self._queue.enqueue("run_tester", story_id)
        except Exception as exc:
            self._repo.save_status(story_id, Status.BLOCKED, note=str(exc))
            raise

Notice: the use case doesn't know what CodeRunner is (subprocess? API call? mock?), what StoryRepository stores to (files? database?), or how TaskQueue delivers the next task (Celery? Redis? LangGraph?).

This is the key. The infrastructure is replaceable without touching the domain.

The original infrastructure: Celery + Redis

The first implementation used Celery with Redis as the broker. Each role had a dedicated queue. The dispatcher polled every 30 seconds for stories in status INBOX and enqueued the first task.

# infrastructure/celery/tasks.py
@app.task(name="run_developer", queue="ready-to-dev")
def task_developer(self, project_path: str, story_id: str) -> None:
    repo, runner, queue, notifier = _deps(project_path)
    RunDeveloper(repo, runner, queue).execute(story_id)

This worked. But it had friction:

Redis is required even for local development
The state machine logic is implicit — split across four separate queue definitions and the enqueue calls inside use cases
Retries when a quality gate fails required manual re-enqueue logic scattered across use cases
docker compose up just to run a pipeline on your laptop

I wanted the workflow to be explicit. That's where LangGraph came in.

The new infrastructure: LangGraph

LangGraph is a library for building stateful, graph-based workflows. You define nodes (work units) and edges (transitions), compile the graph, and invoke it with an initial state. It handles traversal, conditional routing, and can even do checkpointing.

It's designed for AI agent workflows — and an ATDD pipeline is exactly that.

State

The graph state is a TypedDict — a plain Python dict with type annotations:

from typing import TypedDict, Optional
from atdd_orchestrator.domain.story import Status

class PipelineState(TypedDict):
    story_id: str
    project_path: str
    status: Status
    blocked_reason: Optional[str]
    dev_retries: int

dev_retries is the key addition over the Celery implementation. It's the counter that prevents infinite loops when the quality gate or acceptance tests keep failing.

Nodes

Each node calls the existing use case with one important change: it receives a NoOpQueue instead of a real queue adapter. The graph handles routing — the use cases don't need to know what comes next.

class _NoOpQueue(TaskQueue):
    def enqueue(self, task_name: str, story_id: str) -> None:
        pass  # routing is the graph's job

After executing the use case, the node reads the current status back from the repository (the use case already persisted it), and returns the updated state:

def developer_node(state: PipelineState) -> PipelineState:
    repo, runner, notifier, queue = _deps(state["project_path"])
    try:
        RunDeveloper(repo, runner, queue).execute(state["story_id"])
    except Exception:
        pass  # use case already saved BLOCKED to the repo

    status, reason = _read_status(state["project_path"], state["story_id"])
    return {**state, "status": status, "blocked_reason": reason}

The node is thin. It wires dependencies, delegates to the use case, reads the result, and returns. No business logic lives here.

Graph with conditional edges

This is where LangGraph pays off. The state machine that was previously implicit becomes explicit Python code:

from langgraph.graph import StateGraph, END

MAX_DEV_RETRIES = 3

def _route_after_tester(state: PipelineState) -> str:
    if state["status"] == Status.READY_TO_ATF:
        return "atf"
    if state["status"] == Status.READY_TO_DEV:
        if state["dev_retries"] < MAX_DEV_RETRIES:
            return "developer"   # quality gate failed → retry
    return END                   # blocked or retries exhausted

def _route_after_atf(state: PipelineState) -> str:
    if state["status"] == Status.DONE:
        return END
    if state["status"] == Status.READY_TO_DEV:
        if state["dev_retries"] < MAX_DEV_RETRIES:
            return "developer"   # acceptance failed → retry
    return END

def build_pipeline():
    g = StateGraph(PipelineState)

    g.add_node("test_engineer", test_engineer_node)
    g.add_node("developer",     developer_node)
    g.add_node("tester",        tester_node)
    g.add_node("atf",           atf_node)

    g.set_entry_point("test_engineer")

    g.add_conditional_edges("test_engineer", _route_after_test_engineer,
        {"developer": "developer", END: END})
    g.add_conditional_edges("developer",     _route_after_developer,
        {"tester": "tester",       END: END})
    g.add_conditional_edges("tester",        _route_after_tester,
        {"atf": "atf", "developer": "developer", END: END})
    g.add_conditional_edges("atf",           _route_after_atf,
        {"developer": "developer", END: END})

    return g.compile()

Reading this, you immediately understand the full lifecycle of a story:

test_engineer
  → READY_TO_DEV   → developer
  → BLOCKED        → END

developer
  → READY_TO_TEST  → tester
  → BLOCKED        → END

tester
  → READY_TO_ATF   → atf
  → READY_TO_DEV   → developer (retry, up to 3×)
  → else           → END

atf
  → DONE           → END
  → READY_TO_DEV   → developer (retry, up to 3×)
  → else           → END

The retry logic, the blocking conditions, the terminal states — all visible, all in one place.

Dispatcher

With LangGraph, the dispatcher becomes trivially simple:

def run(project_path: str) -> None:
    pipeline = build_pipeline()

    while True:
        repo = FrontmatterStoryRepository(project_path)
        for story_id in repo.find_by_status(Status.INBOX):
            initial_state = {
                "story_id": story_id,
                "project_path": project_path,
                "status": Status.INBOX,
                "blocked_reason": None,
                "dev_retries": 0,
            }
            final_state = pipeline.invoke(initial_state)
            log.info("Pipeline done — story: %s | final status: %s",
                     story_id, final_state["status"])

        time.sleep(POLL_INTERVAL)

No broker, no worker process, no docker compose up. Just:

pip install -e ".[langgraph]"
python dispatcher_langgraph.py /path/to/your/project

The design decisions worth discussing

Why is the state stored in files, not a database?

Each user story's state lives in a story.md file with YAML frontmatter:

---
id: US04
title: User can reset their password
status: in-progress:ready-to-test
sprint: sprint_02
---

Keeping state in the repository means:

Any agent, any tool, any human can read and update it with a text editor
The state survives restarts with no migration
Git history shows every state transition
The orchestrator doesn't own the state — the project does

Why is the Architect role never automated?

The architect (human + Claude) defines scope, acceptance criteria, and what the story means. That judgment stays human-controlled.

Automating that step is how you end up building the wrong thing perfectly. The spec is the contract — someone has to own it.

Why keep Celery?

LangGraph is a better fit for local development and single-machine setups. Celery is better when workers need to run on separate machines or when you need horizontal scaling.

Both share the same domain and the same use cases. The difference is purely in which infrastructure adapter you wire in. That's hexagonal architecture earning its cost.

The NoOpQueue pattern

This is worth calling out explicitly. The use cases currently call self._queue.enqueue("run_tester", story_id) as a side effect of their execution. In the LangGraph world, that call is meaningless — the graph decides what runs next.

Rather than modifying the use cases (which would break the Celery flow), we pass a NoOpQueue that swallows the enqueue calls silently. The use case's core behavior — running the agent, saving the status, raising on failure — is unchanged. Only the side effect is suppressed.

This is dependency injection doing exactly what it's supposed to do.

What I tested on a real project

The first project running through this pipeline is atf-ai — a CLI tool with Playwright-based acceptance tests. Five user stories, end-to-end:

Story	Status
US01 — Scaffolding CLI	`damaged` (1 failing scenario, known issue)
US02 — Docker Runner	`accepted` ✓
US03 — Screenplay Actors & Steps	`accepted` ✓
US04 — Feedback & State Tracking	`accepted` ✓
US05 — Reports Pipeline & PyPI	`accepted` ✓

Four out of five stories went from ready to accepted autonomously. The fifth is blocked on a known state mismatch that requires architectural review — exactly the kind of thing that should block, not silently pass.

What's next

A few things on the backlog:

LangGraph checkpointing — persist graph state to disk so a pipeline can resume after a crash without re-running completed stages
Parallel stories — run multiple stories concurrently using asyncio and LangGraph's async support
Observability — emit structured events at each node transition for tracing and debugging
Self-healing architect — when a story is blocked, trigger a Claude session to diagnose and propose a fix

Repository

The full source is open:

github.com/csotelo/atdd-framework

atdd_orchestrator/
├── domain/          # Story, Status, ports — pure Python
├── application/     # use cases — depend only on domain
└── infrastructure/
    ├── celery/      # Celery + Redis adapter
    └── langgraph/   # LangGraph adapter (new)

35 tests, 0 failures. No Redis, no OpenCode, no network required to run the test suite — all ports are stubbed.

Final thought

The thing that surprised me most about this project wasn't the AI part. It was how much cleaner the orchestration became once I made the state machine explicit.

With Celery, the workflow lived in queue names, routing keys, and scattered enqueue() calls inside use cases. You had to read four files to understand what happened after a test failure.

With LangGraph, the entire lifecycle is in one function. The retry logic, the terminal conditions, the branching paths — all visible at a glance. That's not a small thing when you're the only engineer on the project and you come back to the code three weeks later.

If you're building multi-agent pipelines, make the state machine explicit. Your future self will thank you.

Questions, issues, or contributions: github.com/csotelo/atdd-framework

I've Touched Everything and Mastered Nothing

Dmitry (Dee) Kargaev — Mon, 06 Apr 2026 20:28:35 +0000

Seventeen years. That's how long ADHD has been making me touch every skill, hobby, and career path that crossed my path. I'm 30 now. I've lived in eight countries, built products in five programming languages, shipped code on four blockchains, released music on Spotify under an artist name I genuinely cannot remember, and learned enough Vietnamese to haggle at a market in Nha Trang.

I am not world-class at any of it.

That's the honest version of this story. Not the LinkedIn version where "my diverse background gives me a unique perspective." The real version, where I've spent a decade and a half chasing dopamine across every domain imaginable and I'm only now figuring out what that actually means for a career, an identity, and a life.

What the ADHD cycle actually looks like across every skill, hobby, and career path

The cycle runs on roughly a two-week clock. Something new appears - on Twitter, in a YouTube rabbit hole, in a Discord I shouldn't be in at 2am. The dopamine hits immediately, before I've done anything. I'm already planning the next phase while I'm still in the first hour.

Then comes the manic stretch. Twelve-hour sessions at the computer, deep in documentation and GitHub repos and forum threads from 2015 that nobody else has read. I still eat well, still sleep well, still train. Health is the one thing I never let slide, no matter how deep the rabbit hole goes. But everything else disappears.

Two weeks later, sometimes less, I wake up and it's gone. Not burnout. Burnout has texture - exhaustion, resentment, a desire to rest and come back. This is nothing. Flat affect toward something that consumed me completely three days ago. The interest didn't fade. It evaporated.

This has been my entire adult life. Before that, too - graffiti, parkour, long-distance running, acrobatics, all before I owned a computer. I fixed a relative's MS-DOS machine in English when I was around eight and barely spoke English. I rigged our home phone line to connect to a friend's LAN across the city. I built a radio to intercept our wireless home phone so I could eavesdrop on my mom's calls.

I was never bored. I was always building something I'd abandon.

What I didn't understand at eight, and only started to understand around 27, is that this isn't a moral failing. It's the shape of how my brain processes novelty. The dopamine system in ADHD brains responds to new stimuli harder and drops off faster than neurotypical brains. I wasn't undisciplined. I was running a biological process I had no name for.

Knowing that doesn't stop the cycle. But it changes how you relate to the wreckage.

The graveyard is real

Let me just list some of it.

A DJI drone I used four times. A Sony DSLR that mostly lives in a bag. A 3D printer I operated twice, let collect dust for six months, and sold at a loss. A soldering station I learned to use at university, felt was essential to own again years later, and which currently sits in my wardrobe untouched. A ukulele from Turkey. Guitar - I can play a few songs. Piano - I can play Kanye's Runaway and that's it. Harmonica. Stylophone. Otamatone. An AKAI MPK Mini. Ableton. AI music with Suno. I released lofi tracks on Spotify. I cannot remember the artist name.

Stocks in Russia via an app. Mostly broke even, maybe lost a bit. Cybersecurity hardware - a Flipper Zero, a Kali Linux laptop, ESP32 boards with Marauder firmware, an ESB dongle for intercepting TPMS sensors, and an M5Stack kit with a pile of controllers and sensors. Cardputer. LLM630. Tiny screens, weird modules, more little boards than I had any reason to own. I spent weeks flashing firmware and scanning radio frequencies. Did I build anything useful? No. Make money? No. But I understood how your wireless water meter broadcasts unencrypted data to anyone with the right hardware, and that felt worth it.

None of this is sustainable. The "ADHD is a superpower" content you see everywhere stops before this part. The graveyard. The money spent. The projects half-finished. The domains where I got to "good enough to be dangerous" and never further, because the dopamine was already somewhere else.

This pattern has been running long enough that it stopped feeling surprising a while ago.

The financial reality nobody mentions

I want to be concrete about this because most "ADHD and creativity" content is vague about costs.

The 3D printer was around $400. Sold for $180. The drone was $700. Used it maybe ten hours total. The cybersecurity hardware - Flipper, M5Stack, the various ESP32 boards, cables, accessories, random modules - probably $600 spread across three months. The Ableton license. The AKAI. The ukulele I bought in a market in Istanbul because I was in a hyperfocus phase about lo-fi music production.

I don't have an exact number. But it's real money. And this doesn't count the opportunity cost of the hours - hundreds of hours flashing firmware on microcontrollers that never produced anything, learning guitar in 30-minute sessions spread across five years, studying Vietnamese for six weeks before the next interest hit.

I'm not saying this to make it sound worse than it is. I'm saying it because the "embrace your ADHD divergent thinking" content leaves this part out and I think it's dishonest. The breadth has real costs. The search has a price.

When it does stick

Some things stuck. Design, 17 years. The gym, 15+ years. AI, three years and accelerating.

I started freelancing at 14, selling forum banners and GIFs on ICQ. By university I was building websites for roughly $80-120 each in local-currency terms at the time. When I graduated, companies were offering something like $150 a month. I was already making more than that per site. I said no thanks and kept going. Design is probably the closest thing I have to real expertise after 17 years - I spent five of those years as the solo senior product designer at VALK, a fintech platform that moved $4B+ in deals across 70+ financial institutions in 15 countries. Awards. Real scale. Products that live in actual banks.

The gym stuck because I started before I knew what consistency meant and just never stopped. Different approaches over the years - bodybuilding, strength, cuts, boxing for two years in Krasnodar - but the baseline never dropped. I track bloodwork every few months and stay on top of health like it's another system to tune. When something becomes infrastructure instead of a project, the ADHD can't kill it.

AI stuck because it's the first domain that feeds the obsession cycle faster than the cycle drains it. Every week there's something genuinely new. You can't get bored because the field won't hold still. I built one of the first agentic loops I'd seen anyone build in 2022 - a Telegram bot for a crypto community that could reason and take actions, before "agentic" was even a term. I didn't know what I was building. I just thought it was interesting.

Now I let AI maintain my second brain - knowledge, reminders, loose thoughts, follow-ups, personal assistant type shit. Less "look at my agent stack," more "I built something that remembers what I forget and keeps my life from scattering." I also host local models on a Mac Mini because of course that became another obsession too - if something can run on my own box, I want to try it. It's not a demo. It runs every day. You can read more about how I approach coding and multi-model workflows if you want the technical side.

Why some things survive the cycle

I've thought about this a lot. What makes design and the gym persist when everything else evaporates?

Two patterns show up every time.

First: external feedback loops that don't require internal motivation. The gym gives me bloodwork numbers, strength PRs, photos over time. Design gives me client feedback, shipped products, metrics. When my internal interest flags, there's still external data pulling me back. The drone had none of that. The guitar had none of that. They only worked when I was actively excited, and when the excitement went, nothing remained.

Second: the domain kept changing fast enough to feed new obsession cycles. Design went from print to web to mobile to design systems to AI-generated UI. Every three years there was a new layer to get obsessed about. The gym went from machines to compound lifts to programming to bloodwork optimization. The domain regenerated novelty before I burned through it.

AI has both properties at a ridiculous level. New model every month. New architectural pattern every six weeks. New tool category every quarter. It's basically a purpose-built trap for an ADHD brain and I walked straight into it.

How ADHD shapes every skill, hobby, and career path you choose

Here's what I've realized after 30 years of this: ADHD doesn't just affect how you learn things. It determines what career paths even become available to you.

I have an Information Security bachelor's that I haven't used professionally once. But the two years I spent in that program gave me networking fundamentals, an understanding of cryptography primitives, and enough systems-level thinking that when blockchain showed up in my life it wasn't foreign territory. That "useless" degree became the reason I could evaluate Solidity code for security issues at VALK without being a dedicated security engineer.

The career I've actually had - designer, then product lead, then AI engineer - looks like three different careers. But they're the same brain solving the same problem at different layers of abstraction. Design is about modeling user mental states. Product is about modeling system interactions. AI engineering is about modeling agent behavior. I didn't pivot three times. I drilled down.

That's the ADHD career path nobody maps: not a straight line, not even a zigzag, but a spiral. You come back around to the same core problems from different angles. The angle changes. The problem doesn't.

The generalist discount problem

No job posting says "wanted, someone who can do a little bit of everything."

Generalists get discounted by hiring processes designed for specialists. I have production code in TypeScript, Python, Rust, Solidity, and SQL. Deployed products on four blockchains. Sysadmin experience across every OS since childhood. Enough crypto experience to have launched 20+ tokens. On a resume this looks scattered. In a specific situation - say, a 48-hour sprint where a client needs a smart contract, a minting frontend, and custom illustrations - it's exactly what's needed and nobody else in the room has all three.

When VALK wanted a Christmas NFT campaign I told them I'd handle it. Smart contract, minting site, illustrations, the whole frontend - solo, in one sprint. That's not something a specialist does. That's an ADHD brain that collected 12 different surface-level skills over a decade, all converging on one afternoon's work.

The problem is you can't interview for that. "I know a little about a lot" doesn't clear an ATS. So the career path for someone like me had to go around traditional hiring - freelance, founding roles, solo building. Places where the breadth shows up in delivered work rather than credentials.

The breadth problem and the breadth premium

This year I wrote a 33,000-word book from scratch. I'd never written a book before. Don't Replace Me: A Survival Guide to the AI Apocalypse - 24 chapters, formatted, cover designed, published on KDP, audiobook via ElevenLabs, SEO landing page with schema markup, Amazon ads. Not because I wanted to be an author. Because the process of building the whole machine was interesting to me.

The ADHD didn't stop me from finishing a book. It kept me engaged long enough to finish one because there were 15 different new processes to learn inside the single project. The writing was interesting for the first 10,000 words. Then the Kindle formatting was interesting. Then the audiobook pipeline. Then the schema markup. By the time I finished, I had a complete book, a production process, and had learned four skills I didn't have before.

This is the pattern. I don't go deep on one thing. I go wide enough that when a project needs five different skills, I'm the one person in the room who can cover them all. The breadth is a premium in those moments - genuine leverage that a specialist can't replicate without a team.

The honest version though: those moments don't come every day. Most days, the breadth just means I know enough to be frustrated by problems in domains where I don't know enough to solve them.

Why the AI age changes this calculation for ADHD builders

AI is doing something weird to the generalist problem. On one side, everyone's a generalist now. Vibe coding means your non-technical friend can ship a landing page. The moat of "I know five programming languages" is basically gone.

On the other side - and this is the part I actually believe - breadth becomes more valuable when AI amplifies execution. You don't need to be an expert Rust developer. You need enough Rust to direct an AI agent doing Rust work. You need to know when the output is wrong. You need the taste to recognize what "good" looks like without being able to produce it from scratch at 100 words per minute.

I spent 17 years accumulating surface-level knowledge across maybe 30 domains. That knowledge doesn't help me compete with a specialist in any one of them. But it means I can look at an AI's output in almost any domain and tell you whether it's right. Design intuition applied to code review. Crypto chaos tolerance applied to agentic system failures. Sysadmin muscle memory applied to Docker containers. The ADHD brain that couldn't go deep now has a use case that rewards breadth.

This isn't hypothetical. I use dee.ink - a collection of 31 Rust CLI tools I've built for AI agent workflows - as a practical example. Building those tools required Rust, CLI design, documentation, packaging, and enough understanding of AI agent needs to spec useful primitives. Same with the home lab stuff - a ZimaBoard running home server experiments, local infra, and smart home services because once I touched self-hosting I obviously had to touch that too. A specialist Rust engineer would write better Rust. A specialist AI engineer would understand agent needs more deeply. A specialist infra person would build a cleaner home lab. But I could build the whole thing myself, end to end, without waiting on anyone.

That's the AI-era argument for the ADHD generalist: you're not competing on depth anymore. You're competing on range of judgment. And AI is making range of judgment the bottleneck, not depth of execution.

If you've felt this same tension - the generalist guilt, the half-finished projects, the identity question of what you even "are" professionally - I wrote more about navigating ADHD and AI as actual compensation tools, not the productivity-porn version.

The identity question ADHD every skill, hobby, and career path creates

Here's the thing nobody talks about with the ADHD generalist lifestyle: you don't know what you are.

Ask a specialist what they do and they tell you in one sentence. "I'm a backend engineer." "I'm a product designer." The identity is clean. The work is legible to other people.

Ask me and I have to make a choice about which version of myself I'm presenting. The designer with 17 years? The AI engineer building multi-agent systems? The guy who spent three months obsessively learning about RF signal interception for no professional reason? All of these are equally true. None of them is the whole answer.

For a long time this felt like a problem. I'd look at people with clear professional identities - engineers who'd been doing one thing for ten years, designers with a coherent portfolio narrative - and feel like I was faking it. Like my breadth was evidence of some underlying lack of commitment.

What I've landed on at 30 is different. The identity question isn't a problem to solve. It's a feature of a specific type of brain operating at full capacity. The discomfort of not fitting a category is the cost of not being constrained by one.

I'm not a designer who learned to code. I'm not an engineer with design skills. I'm something that doesn't have a clean job title yet, that probably couldn't exist before AI made it possible to execute across domains without a full team. That's not a failure of self-definition. It's just early.

What actually sticks at 30

The gym. Design. AI.

And maybe that's the real pattern. The things that stuck aren't the things I chose. They're the things that were still there after the dopamine moved on. The gym was still there because I'd been going long enough it became automatic. Design was still there because clients kept paying me. AI is still there because it keeps generating new problems faster than I run out of interest.

What I've stopped doing is chasing the feeling of the early phase - that first-week intensity when everything seems possible and you're learning at maximum speed. That feeling always ends. The question isn't how to keep the feeling. It's what you're building during it.

What I actually think about it at 30

The "ADHD superpower" narrative is mostly incomplete. It's real but it stops too early. Yes, the hyperfocus is incredible. Yes, the breadth compounds in ways specialists can't replicate. Yes, the manic phases produce more in two weeks than most people produce in two months.

But the depressive phases are the tax. The days where you look at a project you were obsessed with last week and feel nothing at all. Not tired. Not frustrated. Nothing. The graveyard of equipment bought and abandoned is real money. The projects with twelve active tabs and zero generating revenue are real.

I've been through every single phase of this across eight countries and more career pivots than I can accurately count. I still think I'll find the thing. Maybe design and AI are already it and I just haven't accepted that yet. Maybe something I haven't encountered will show up and replace everything I've built my identity around. Both feel equally plausible from the inside.

What I know is this: at 30, having touched more domains than most people touch in a lifetime, being functionally average at most of them and arguably expert at two - I'm not embarrassed by any of it. The search wasn't failure. The search was the work. Everything compounds in ways you can't predict when you're in the middle of a two-week obsession with intercepting radio signals from water meters.

If you want to see what the current obsession looks like in practice - the AI engineering side, the multi-agent systems, the actual tools - the about page has the full context. And if you're building something similarly scattered and solo, the tags page will probably surface something relevant.

If you're in the middle of your own version of this - the cycle, the graveyard, the guilt about the 3D printer sitting in your closet - you're probably not broken. You're probably just still searching.

That's an okay place to be.

So I asked AI to list my skills

Based on everything I've touched, built, learned, half-learned, abandoned, revived, bought, sold, shipped, and somehow got paid for, I asked AI to write out my skill set in one paragraph.

It was a mistake.

Graphic design, product design, UI design, UX design, interaction design, interface design, web design, mobile design, dashboard design, platform design, application design, systems design, design systems, visual systems, component systems, branding, digital branding, visual identity, typography, layout, hierarchy, composition, spacing, iconography, illustration, digital illustration, vector illustration, marketing design, motion graphics, banner design, avatar design, forum graphics, landing page design, cover design, presentation design, pitch deck design, onboarding design, checkout flow design, conversion design, user flows, journey mapping, wireframing, prototyping, information architecture, UX strategy, usability thinking, interface critique, product thinking, product strategy, feature prioritization, product packaging, product positioning, product communication, client communication, stakeholder communication, design leadership, solo product ownership, freelance design, agency design, startup design, enterprise product design, fintech product design, dashboard UX, enterprise workflows, white-label platform design, workflow design, complexity reduction, visual clarity, frontend design, frontend implementation, HTML, CSS, responsive design, JavaScript, TypeScript, React, component libraries, design-to-code translation, web app implementation, rapid prototyping, interface implementation, code editing, debugging, code reading, AI-assisted coding, product-minded engineering, scripting, Python, Rust, SQL, Solidity, command-line tooling, CLI product thinking, developer tooling, automation scripting, API integration, webhook logic, backend glue code, database basics, schema instincts, debugging AI output, debugging code, debugging workflow failures, prompt engineering, prompt iteration, prompt structure, context design, tool calling, agent orchestration, multi-agent workflows, AI workflow design, AI product design, AI UX, AI-assisted writing, AI-assisted coding, AI-assisted research, AI tool evaluation, model comparison, reasoning model usage, local model usage, cloud model usage, local LLM setup, memory systems, second-brain systems, reminder systems, retrieval systems, RAG, embeddings, semantic search, vector search, AI assistant design, assistant workflow design, personal AI systems, research pipelines, writing pipelines, content pipelines, synthesis pipelines, information capture, note systems, knowledge systems, crypto product design, Web3 product design, smart contracts, Solidity workflows, token launch mechanics, NFT launch mechanics, minting flows, DeFi UX, blockchain UX, wallet UX, crypto campaign execution, crypto community operations, crypto marketing, launch coordination, presale mechanics, token website building, contract deployment understanding, onchain product instincts, community bot building, Telegram bot building, automation design, workflow automation, n8n-style orchestration thinking, research automation, content automation, digital marketing, internet marketing, social media growth, Instagram page growth, landing page copy, copywriting, headline writing, article writing, blog writing, long-form writing, editing, rewriting, draft development, AI-draft cleanup, humanization, publishing workflows, book writing, book formatting, self-publishing, KDP publishing, metadata writing, SEO, GEO, search intent mapping, keyword targeting, internal linking instincts, schema markup thinking, authority building, distribution strategy, launch strategy, publishing systems, website management, domain setup, CMS-light publishing, self-hosting, home server experimentation, Docker, DNS, reverse proxy basics, infrastructure curiosity, service setup, local infra experimentation, smart home experimentation, device setup, system setup, macOS setup, Windows setup, Linux setup, terminal usage, shell comfort, firmware flashing, hardware experimentation, embedded-device tinkering, cybersecurity basics, information security fundamentals, cryptography fundamentals, systems thinking, network instincts, radio experimentation, wireless experimentation, sensor experimentation, hardware debugging, hardware setup, game server hosting, home PC hosting, monetization instincts, digital hustle instincts, app install arbitrage, e-commerce experimentation, dropshipping experimentation, pricing instincts, sales instincts, client acquisition instincts, offer shaping, agency operations, productized service instincts, open source contribution, release management, tool publishing, music experimentation, music production, AI music workflows, Ableton experimentation, audio arrangement instincts, basic piano, basic guitar, basic ukulele, basic harmonica, stylophone experimentation, otamatone experimentation, creative direction, aesthetic judgment, visual taste, naming instincts, concept development, trend detection, trend synthesis, pattern recognition, fast learning, context switching, parallel execution, obsessive research, rabbit-hole depth, ambiguity tolerance, pressure-driven shipping, solo building, independent execution, figuring things out with incomplete information, reverse engineering workflows, surviving bad documentation, adapting to broken tools, evaluating software fast, comparing tools quickly, stack assembly, stack migration, no-code experimentation, low-code experimentation, API-first thinking, browser tooling, workflow compression, research summarization, synthesis, memory capture, memory retrieval instincts, file organization attempts, chaos-tolerant organization, async collaboration, self-direction, self-teaching, self-reinvention, internet-native communication, pseudonymous building, online identity experimentation, public writing, authority building through shipping, cross-domain thinking, interdisciplinary synthesis, technical taste, product taste, marketing taste, creative taste, execution bias, strategic intuition, quality smell detection, visual QA, copy QA, product QA, issue isolation, error triage, launch QA, software evaluation, tooling adoption, rollout instincts, packaging instincts, distribution instincts, positioning instincts, and generally becoming competent enough to start, ship, fix, relaunch, and repurpose work across an unreasonable number of domains without ever sitting still long enough to make any of it feel normal.

Reading it felt less like a skills list and more like a forensic report.

I ran my AI codebase triage tool on itself — here's what it found

EJ Wisner — Mon, 06 Apr 2026 20:28:29 +0000

I built Ghost Architect™ Open — a free, local AI tool that triages codebases and scores findings by severity. To test it properly, I ran it on its own source code.

It found a Critical bug.

The finding

The redaction engine — the module that strips API keys and secrets before sending code to Claude — had a pointer offset bug. When replacing a secret pattern, it wasn't advancing the scan position after each replacement. On files with 50+ environment variables, it would stop redacting halfway through.

Users were seeing "Redacted 12 patterns" and assuming their code was safe. Pattern 13 was their database password.

The bug was fixed the same day. That's the point — you can't fix what you can't see.

What Ghost Architect™ Open does

Points at any local directory, ZIP file, or GitHub repo
Triages the code and scores findings: Critical, High, Medium, Low
Runs entirely on your machine — your code never leaves
Uses the Anthropic API with your own key (new accounts get a $5 credit)
Supports PHP, Python, Node.js, Java, Go, React, and more

Free vs Pro

Ghost Open is free. It returns Critical and High findings in TXT and Markdown format.

Ghost Pro adds Medium and Low findings, multipass analysis, project intelligence, and full PDF reports.

Try it

GitHub: https://github.com/EJWisner/ghost-architect-open

Full platform: https://ghostarchitect.dev

Enabling Pin-Based Commenting on Live HTML Iframes: Open-Source, Framework-Agnostic Solution with Adapter Flexibility

Pavel Kostromin — Mon, 06 Apr 2026 20:25:11 +0000

Introduction & Problem Statement

Imagine trying to annotate a live, interactive webpage with the precision of Figma’s pin-based comments. Now, imagine doing this within an iframe—a nested HTML document isolated by its own DOM and coordinate system. This is the core technical challenge Washi solves. While tools like Figma excel at static design files, replicating their annotation precision on live, dynamic HTML content within iframes introduces a cascade of complexities: DOM mutations, cross-origin restrictions, and coordinate system discrepancies.

The Problem: Why Pin-Based Commenting in Iframes is Hard

At its core, pin-based commenting requires pixel-perfect synchronization between the annotation layer and the underlying content. In iframes, this breaks down due to:

DOM Isolation: Iframes operate in a separate document context, making direct DOM manipulation from the parent page impossible without explicit permissions.
Coordinate Mismatch: The iframe’s internal scroll position and element coordinates are decoupled from the parent window, causing annotations to drift or misalign.
Dynamic Content: Live HTML updates (e.g., via JavaScript) require real-time recalibration of annotation positions, a task complicated by iframe boundaries.

Existing solutions often fail here. Proprietary tools lock users into specific frameworks, while open-source alternatives lack the flexibility to handle iframe-specific edge cases (e.g., nested iframes, cross-domain content). Washi’s adapter-based architecture addresses this by abstracting the iframe’s complexities, enabling seamless annotation across diverse environments.

Why This Matters: The Collaborative Workflow Bottleneck

Without tools like Washi, teams resort to screenshots, lengthy video calls, or clunky third-party integrations. Consider a cross-functional team reviewing a live dashboard prototype: designers, developers, and stakeholders must align on specific UI elements, interactions, and bugs. Screenshots quickly become outdated; verbal descriptions lack precision. The result? Feedback loops slow to a crawl, with miscommunications compounding delays.

Washi’s pin-based approach anchors feedback directly to the live element, eliminating ambiguity. For instance, a designer can drop a pin on a misaligned button, attach a comment, and link it to a Figma spec—all within the same interface. This spatial precision accelerates resolution times, particularly in remote settings where asynchronous collaboration is the norm.

Technical Deep Dive: How Washi Works

Washi’s solution hinges on three mechanisms:

Adapter Layer: A framework-agnostic bridge that communicates with the iframe’s content via postMessage, bypassing same-origin policy restrictions. This enables DOM queries and mutation observation without direct access.
Coordinate Mapping: A real-time transformation matrix calculates the offset between the parent window and iframe’s internal coordinates, ensuring pins remain anchored despite scrolling or resizing.
Reactive Updates: Leveraging MutationObserver, Washi detects changes in the iframe’s DOM and recalibrates annotations dynamically, preventing drift in live environments.

This architecture contrasts with naive solutions (e.g., overlaying annotations via CSS positioning) that fail under iframe constraints. By treating the iframe as a black box and relying on adapters, Washi maintains compatibility across React, Vue, Svelte, and vanilla HTML setups.

Edge Cases and Failure Modes

Washi’s effectiveness degrades in two scenarios:


Scenario	Mechanism of Failure	Mitigation
Cross-Domain Iframes	postMessage requires explicit permission from the iframe’s origin, which may not be granted.	Use a proxy server or configure CORS headers on the iframe source.
Heavy DOM Mutations	Rapid, large-scale DOM changes (e.g., full page reloads) can overwhelm the MutationObserver, causing temporary annotation lag.	Throttle mutation callbacks or implement debouncing in high-churn environments.

Professional Judgment: When to Use Washi

Rule of Thumb: If your workflow involves reviewing live HTML content within iframes and requires precise, Figma-style annotations, use Washi. Its adapter-based design ensures compatibility with your existing stack, while its open-source nature avoids vendor lock-in. Avoid it if your use case is static (e.g., PDF annotations) or if you operate in a closed, single-origin environment where simpler overlay tools suffice.

In the arms race of collaborative tools, Washi isn’t just another annotation utility—it’s a bridge between the static precision of design tools and the dynamic chaos of live web development. As remote teams become the default, its role in streamlining feedback loops will only grow more critical.

Technical Deep Dive & Solution Architecture

Washi’s design philosophy is rooted in solving a deceptively complex problem: enabling Figma-style pin annotations on live HTML content within iframes while maintaining open-source accessibility and framework agnosticism. This section dissects the architectural decisions that make this possible, focusing on the mechanisms that overcome iframe-specific challenges and their real-world implications.

1. Adapter Layer: The Framework-Agnostic Bridge

The core of Washi’s flexibility lies in its adapter-based architecture. Iframes inherently operate in a separate document context, creating a DOM isolation problem. Direct manipulation of the iframe’s DOM from the parent window is blocked by the browser’s same-origin policy—a security mechanism that prevents cross-origin scripting attacks. Naive solutions relying on CSS overlays or absolute positioning fail here because they assume a shared DOM, which iframes explicitly deny.

Washi circumvents this by treating the iframe as a black box. Instead of direct DOM access, it uses the postMessage API to communicate with the iframe’s content window. This mechanism acts as a bridge, allowing the parent window to send commands (e.g., "query element at coordinates X,Y") and receive responses (e.g., "element is a `

with ID content-section`"). The adapter layer translates these commands into actionable DOM operations within the iframe, effectively bypassing the same-origin policy without compromising security.

Why this works: By abstracting the communication layer, Washi remains framework-agnostic. Whether the iframe contains React, Vue, Svelte, or vanilla HTML, the adapter layer handles the translation, ensuring compatibility across diverse web ecosystems.

2. Coordinate Mapping: Solving the Scroll and Resize Problem

Iframes introduce a coordinate mismatch between the parent window and the iframe’s internal document. When users scroll or resize the iframe, the annotations must remain pinned to the correct element—a challenge exacerbated by dynamic content updates. Traditional solutions relying on fixed positioning break because the iframe’s scroll position and transformation matrix are decoupled from the parent window.

Washi addresses this with a real-time transformation matrix. It continuously calculates the offset between the parent window’s coordinates and the iframe’s internal document coordinates. This matrix is updated on every scroll, resize, or zoom event, ensuring annotations remain anchored to the correct element. For example, if a user scrolls the iframe 200px down, Washi recalculates the pin’s position relative to the iframe’s new scroll offset, preventing annotation drift.

Edge Case Analysis: In scenarios with nested iframes or complex CSS transforms, the transformation matrix must account for cumulative offsets. Washi handles this by traversing the iframe hierarchy and aggregating transformation matrices, ensuring precision even in deeply nested structures.

3. Reactive Updates: Preventing Annotation Drift

Dynamic HTML content poses a unique challenge: annotations must persist even when the underlying DOM changes. Without a mechanism to detect and respond to these changes, pins would become misaligned or disappear entirely. Washi employs a MutationObserver to monitor the iframe’s DOM for changes. When an element is added, removed, or modified, the observer triggers a recalibration of all annotations.

Mechanism: The MutationObserver acts as a watchdog, firing callbacks whenever the DOM structure changes. These callbacks update the internal annotation map, ensuring pins are reattached to the correct elements. For example, if a `

` containing an annotation is replaced with a new element, Washi detects the change and transfers the pin to the corresponding new element.

Performance Trade-offs: Heavy DOM mutations (e.g., re-rendering an entire page) can overwhelm the MutationObserver, causing annotation lag. Washi mitigates this by throttling mutation callbacks or implementing debouncing, ensuring updates occur at a manageable frequency without sacrificing responsiveness.

4. Edge Cases and Mitigation Strategies

Cross-Domain Iframes: postMessage requires explicit permission from the iframe’s origin. Without this, communication fails. Mitigation: Use a proxy server to relay messages or configure CORS headers on the iframe’s source. Rule: If iframe content is hosted on a different domain → implement CORS or proxy.
Heavy DOM Mutations: Rapid changes overwhelm MutationObserver, causing lag. Mitigation: Throttle or debounce callbacks. Rule: If DOM updates exceed 100 mutations/second → apply throttling.

5. Comparative Analysis: Why Washi’s Approach is Optimal

Alternative solutions, such as CSS overlays or absolute positioning, fail under iframe constraints due to their reliance on a shared DOM. Washi’s adapter-based, coordinate-mapping, and reactive architecture provides a robust, framework-agnostic solution. While it introduces slight overhead (e.g., postMessage latency), the trade-off is justified by its compatibility and precision.

Professional Judgment: Use Washi if your workflow involves reviewing live HTML content within iframes and requires Figma-style annotations. Avoid it for static content (e.g., PDFs) or single-origin environments where direct DOM access is feasible.

In conclusion, Washi’s architecture is a testament to solving hard problems with elegant, mechanism-driven solutions. By treating iframes as black boxes, mapping coordinates in real-time, and reacting to DOM changes, it bridges the gap between static design tools and dynamic web development—a critical enabler for modern, collaborative workflows.

Use Cases & Real-World Applications

Washi’s pin-based commenting system isn’t just a theoretical innovation—it’s a practical tool solving real-world problems across industries. Here are five concrete scenarios where Washi’s architecture shines, backed by the technical mechanisms that make it work.

1. E-Commerce Platform Design Reviews

Scenario: A remote design team reviews a live product page prototype embedded in an iframe. Designers need to annotate specific UI elements (e.g., misaligned buttons, incorrect font sizes) directly on the dynamic HTML content.

Mechanism: Washi’s Adapter Layer uses postMessage to query the iframe’s DOM, bypassing same-origin restrictions. The Coordinate Mapping system calculates the transformation matrix between the parent window and iframe, ensuring pins stay anchored to elements even during scroll or resize events. MutationObserver recalibrates annotations when the product grid dynamically updates (e.g., AJAX-loaded items), preventing drift.

Edge Case: If the iframe loads cross-domain content (e.g., third-party reviews widget), postMessage fails without explicit origin permission. Mitigation: Configure CORS headers or use a proxy server to relay messages.

2. SaaS Dashboard Iteration

Scenario: A developer and product manager collaborate on a React-based dashboard iframe. The PM needs to flag data visualization inconsistencies (e.g., incorrect chart labels) on a page with heavy DOM mutations.

Mechanism: Washi’s Reactive Updates throttle MutationObserver callbacks to handle >100 mutations/second without overwhelming the system. The Adapter Layer abstracts React’s virtual DOM, ensuring framework-agnostic operation. Coordinate mapping aggregates transformation matrices for nested iframes (e.g., embedded analytics widgets).

Trade-off: Throttling introduces ~50ms annotation lag during intense mutations, but prevents system freeze—a critical compromise for usability.

3. Marketing Landing Page QA

Scenario: A QA team tests a Vue.js landing page iframe, annotating broken links and misrendered hero sections. The page uses CSS transforms and animations, complicating pin stability.

Mechanism: Washi’s Coordinate Mapping recalculates offsets on every scroll/resize event, accounting for CSS transforms via the aggregated transformation matrix. The Adapter Layer treats Vue’s reactive DOM as a black box, ensuring compatibility without framework-specific hooks.

Risk: Rapid CSS animations (e.g., parallax effects) can cause temporary pin misalignment. Mitigation: Debounce coordinate recalculations to 60fps, balancing responsiveness and accuracy.

4. Educational Platform Prototyping

Scenario: A UX researcher annotates an Svelte-built course module iframe, pinpointing accessibility issues (e.g., unreadable contrast ratios) on dynamically generated content.

Mechanism: MutationObserver detects Svelte’s reactive DOM updates (e.g., new quiz questions loaded via API), triggering annotation recalibration. The Adapter Layer translates parent commands into iframe-specific DOM queries, maintaining framework agnosticism.

Choice Error: Teams might opt for CSS overlay solutions, which fail here due to iframe’s isolated DOM. Rule: If targeting dynamic iframe content, use Washi’s adapter-based approach instead of naive overlays.

5. Internal Tool Development

Scenario: An engineering team reviews a vanilla HTML admin panel iframe, annotating performance bottlenecks (e.g., slow-loading tables). The page uses nested iframes for modular components.

Mechanism: Washi’s Coordinate Mapping traverses the iframe hierarchy, aggregating transformation matrices for nested frames. The Adapter Layer communicates with each iframe’s window via postMessage, enabling cross-frame annotations.

Limitation: Fails if nested iframes block postMessage due to security policies. Optimal Solution: Preconfigure iframe permissions or use a shared proxy for message relay.

Comparative Analysis: Why Washi Wins


Solution	Effectiveness	Failure Condition
CSS Overlay	Fails under iframe isolation; assumes shared DOM.	Always fails for iframes without direct DOM access.
Absolute Positioning	Breaks on scroll/resize due to coordinate mismatch.	Fails when iframe content scrolls or resizes.
Washi (Adapter + Mapping)	Robust for dynamic iframes; handles scroll, resize, mutations.	Fails only if `postMessage` blocked or mutations >100/second without throttling.

Professional Judgment: Use Washi if your use case involves live HTML iframes requiring Figma-style precision. Avoid for static content or single-origin environments where simpler solutions suffice.

I built an app that helps couples decide what to watch together

Martin Langaas — Mon, 06 Apr 2026 20:24:53 +0000

My girlfriend and I had the same argument
every Friday night: "What do you want to watch?"
"I don't know, what do YOU want to watch?"

So I built Logflix.

What it does

Both of you swipe on movies and series — yes or no.
When you both swipe yes on the same title, it's a match.
No more endless scrolling. No more compromises where
nobody's actually happy.

How it works

Share a link or scan a QR code
Both swipe independently on your own phones
Match appears live on screen when you both like the same title
Works across Netflix, HBO, Disney+ and more
No account needed

Tech stack

Next.js / Supabase / Vercel

Why I built it

Dead simple. No setup maze. You and your partner,
swipe, match, watch.

🎁 New users get 7 days free Premium after their
first match — no credit card needed.

Live and free: logflix.app/together

Would love feedback — especially if you have a partner
who can never decide 😄

DUMB DEV Community

We didn’t have a coding problem - We had a “where do I even start?” problem

Problem

What was wrong

Solution

1. Give the agent real system context (agent.md)

2. Build a custom prompt that actually thinks

3. Use the agent where it makes sense

Result

Takeaway

The Seven Engineering Problems That Make Real-Time Enterprise Sync Almost Impossible

1. Polling Is a Lie You Tell Yourself

2. Change Data Capture Sounds Simple Until You Build It

3. Bidirectional Sync Is a Distributed Consensus Problem

4. Schema Is a Moving Target

5. Rate Limits Are Adversarial by Design

6. Ordering Across Distributed Systems

7. The Compounding Effect

What I Learned

We Added a /refer Page to TIZZLE: A Cleaner Referral Flow That Actually Converts

We Added a /refer Page to TIZZLE: A Cleaner Referral Flow That Actually Converts

Why we added it

What the new /refer page does

The conversion decisions behind it

Why this matters for service businesses

Final thought

Write Once, Publish Everywhere: Build a Multi-Platform Dev Blog Pipeline with GitHub Actions

Zero to Published: Setting Up a Multi-Platform Dev Blog Pipeline

How to write once in Markdown and automatically publish to Dev.to, Hashnode, Medium, and your personal site without losing your sanity or your SEO

Why Your Blog Deserves More Than One Home

The Foundation: Git + Markdown as Your Single Source of Truth

Understanding Canonical URLs (The SEO Magic That Makes This Work)

Building Your Publishing Pipeline with GitHub Actions

The blogpipe CLI: A Working Cross-Posting Tool

When Things Break: Gotchas and Platform Limitations

Your First Week: A Practical Rollout Plan

Key Takeaways

50 Things Anthropic's API Can't Do (And We're Going to Walk Through Every Single One)

State and Conversation Persistence

Memory Across Sessions

Context Window Management

Model Routing and Multi-Provider Access

RAG and Document Intelligence

Tool Calling with Persistent State

Web Search

Multi-Agent Architecture

What's coming

Brainstorming with BMAD and Qwen Code.

Introduction

The Squad

Qwen Code

BMAD 6

bmad-code-org / BMAD-METHOD

Breakthrough Method for Agile Ai Driven Development

Why the BMad Method?

Preparing our Project for BMAD

Invoking The Brainstormer

Going through the Hats

Generated Specification

Further Refinements

Jumping to another Brainstorming Method

Conclusion

The Release That Broke Everything

The Damage Report

macOS: 87 Processes, 888% CPU

Windows: Stack Overflow Before Startup

Linux: Tools Rendered as Raw Text

The Compound Effect

Why This Happens

The Deeper Pattern

For Agent Builders

Building a Multi-Agent ATDD Pipeline with LangGraph and Hexagonal Architecture

Building a Multi-Agent ATDD Pipeline with LangGraph and Hexagonal Architecture

The problem with solo AI development

What is ATDD and why does it fit AI agents perfectly?

The architecture: hexagonal all the way down

The original infrastructure: Celery + Redis

The new infrastructure: LangGraph

State

Nodes

What the new `/refer` page does