DEV Community: Mladen Stepanić

Vibe Designing

Mladen Stepanić — Sun, 19 Apr 2026 19:45:11 +0000

Since Karpathy coined the term vibe coding, some of my non-coding friends have been showing me their work and teasing me that they can now do everything I can. Anthropic just dropped Claude Design. Now it's my turn.

Shelfcritter, the polygon

I've been building Shelfcritter - a book management app - on and off for a while. It's not really about the books. It's my polygon for testing different agents and workflows, letting AI drive parts of the codebase without losing the plot. And it works, mostly. You can add a book, track what you've read, the basics. But every time I opened the thing, I'd wince. The look and feel was off. Here is how it used to look:

So when Claude Design dropped, I knew exactly where it was going first.

Five minutes and 25% of my weekly Design quota

I didn't bother with the tutorial. The UI is intuitive enough that I just started: took a couple of screenshots of the parts that bugged me most, dumped them in, listed the pain points, and asked for two things - a design system and a redesigned flow for adding new books.

Watching it reason was the fun bit. It picked up friction points from the screenshots without my help, then came back with a couple of sharp clarifying questions. I answered. Five minutes later (and about 25% of my weekly Design quota on a Max x5 plan) I had a clickable prototype I actually wanted to use.

Getting the design into the app was the next question. Claude Design has a pile of export options, but for me the obvious move was Claude Code. The handoff is dead simple: Claude Design hands you a prompt with a link, your Claude Code instance fetches it and reads through the design tokens and component hierarchy on its own. No copy-pasting CSS variables. No reverse-engineering spacing from screenshots.

A few prompts later I had a stack of Beads issues, and my parallel-agents workflow did its thing. Shelfcritter ended up with proper typography and a sense of calm to it. A real library theme. Not production-ready yet, but a couple hours in, it was close.

How Shelfcritter got AI Digest

A bit less than two months ago I started running a daily AI digest. The premise was small: keep some friends informed about what's actually moving in the AI world, and test out Cowork for automation while I was at it (I'm too much of a chicken to give OpenClaw all the permissions it wants - in theory it could spend all my money or get in a fight with my boss). The digest was the first idea that came to mind when I went looking for something to put Cowork through its paces, and it stuck.

It all runs as a Cowork scheduled task. The flow: Cowork gathers the data → Obsidian vault → Discord. It checks the day's releases and the AI news, writes the whole thing into the vault with proper tags, and posts it to the channel my friends actually read (or I hope they do). A single prompt in the repo walks Claude through every step. Most days I don't touch any of it. However, it is ugly and one-dimensional. Like an endless pit of information, going to that channel to be lost forever.

The $100 that pushed me into building an archive

Then Anthropic ran a promotion and I picked up a $100 offer. I decided to go a little wild: a public archive site for every digest I've sent and a future ones, so the Discord posts aren't the only place this stuff lives.

I didn't really write the site. The same Claude Code workflow that redesigned Shelfcritter - Beads issues, parallel agents, reviewing one phase at a time - is what actually built it. I scoped it out, fed the agents one phase, reviewed the diffs, course-corrected, next phase. Eight phases in, the site was there.

The stack is small on purpose: Astro on Vercel for the static build, Neon Postgres with pgvector for hybrid search, Jina for embeddings. The Obsidian vault is the source of truth. I write a digest, push to main, and the rest just happens.

Claude Design, warts and all

It's not all roses though. Claude Design is in what Anthropic calls a "research preview". You and I can call it beta, like normal people. And it shows.

Twice, while I was working on the archive site, it ate the search page. Not errored. Not crashed. Just gone. There's no checkpoint system, so it wasn't coming back. I regenerated it from scratch both times. And since regenerating costs money, it ate that too.

A few times it also flat out ignored my instructions. Probably a skill issue on my end, but the odd bit is that the thing it did instead was often good enough that I told Claude Code to ship that instead. Pro or con? Still undecided.

None of this is a dealbreaker for me. This kind of stuff piles up angry users fast though, and I hope Anthropic patches it before it does.

And yes - it burned through $70 of that $100 credit in a blink of an eye.

Are designers cooked?

Resounding no.

I'm an experienced UI developer. That's what let me steer Claude Design to the result I wanted. I could tell when it was drifting and push back. Sometimes I'd even catch it doing something better than what I'd asked for. Plenty of people will get decent results too. But for anything non-trivial, an experienced designer using Claude Design will still have an edge. They'll obliterate everyone else when it comes to web design.

Web. That's the key bit. I also pointed it at another pet project of mine, a Beads explorer in Swift. The results were nowhere near stellar. It ignored Apple's UX conventions completely, and I couldn't get Claude Code to retrofit them either. I ended up with a fine-looking app full of components built from scratch in places I wanted native ones.

Wanna see the digest site? Head to aidigest.shelfcritter.com.

After the Panic: A Note for Junior Engineers

Mladen Stepanić — Tue, 14 Apr 2026 21:13:34 +0000

The development world as we know it is at a turning point. It's been at a turning point a lot of times since I've started doing this some 16 years ago, and a lot more times before that. But this one time is special, this one time is different: AI threatens to replace us. Get out of Starbucks and learn to use a shovel.

Relax, I'm dramatic on purpose, we're not going anywhere. I'm writing this post mostly for younger folks who I don't envy, because they're in a position where they are threatened by, scared by, and forced into the AI bubble. People are losing their minds over whether AI will make them obsolete, and they're listening to false prophets who are telling them that they should be learning a real craft, a physical skill that won't be touched by AI any time soon. But what's the reality? Reality is that AI is a tool (last time I checked). A powerful tool, and it could be a great asset to a developer who knows what they're doing. If you don't know about the basics, security, user experience, performance... no amount of AI will help you make a good app. That's the truth, and anyone who's telling you otherwise is likely fearmongering to raise their importance, or trying to sell you an AI-powered service or one of their dime-a-dozen courses. These people are not your friends!

I'm not saying you need to avoid AI until it disappears. On the contrary, it's here to stay, just maybe not in the areas AI doom merchants want you to believe it will. You should definitely learn how to work with AI. Large Language Models (LLMs) changed the game for me: I can get to the prototype faster, I can debug faster. I abstracted away boring multi-file edits, tests, and boilerplate, which are generally time consuming. Do I work more? No. Do I output more? Yes, but not as much as my CEO would like me to. The time I save with AI, I spend prompting that very same AI about the stuff I know the least. Brainstorming, asking it to explain its choices, then cross-referencing against documentation and people who actually know what they're talking about. More often than the doom merchants would like to admit, its choices turn out to be overkill or outright wrong. That's how I'm filling the gaps in my infrastructure and backend knowledge.

It's easy to pay $200+ a month and have Claude or any agent write the app for you, but what happens when you get a data breach and you don't understand the code well enough to fix it? When you can't explain to your users what went wrong because the AI made decisions you never questioned? Will you be able to sell your service when everyone can use that same $200+ subscription to build their own, with the same bugs, the same blind spots, and the same confident nonsense baked in? Is that sustainable?

I don't think so.

"But Mythos is coming! ChatGPT 6! $NEXT_BIG_THING! It's going to obsolete us!"

Good. Let it. Add it to the toolset so it can help you learn, not just crunch code faster.

So, what do you actually do?

If you're a junior engineer and the section above made your stomach turn, good, that was the point. Now take a breath.

Keep your ears to the ground on AI. Keep your hands on the fundamentals.

Use whatever agent you can get your hands on and get a feel for it. That's it. That's the whole strategy. Everything below is just me explaining why it works.

Pay attention, don't panic

You should know what the current models can and can't do. Try the tools. Read the release notes. Notice which parts of your job got easier this quarter and which parts got weirder. That's "ears to the ground", it's awareness, not obsession. You don't need to try every new agent framework that trended on Hacker News last Tuesday. Trust me, I lived through JavaScript framework fatigue: the industry always converges on a handful of choices that actually work, and the rest quietly disappear into blog post graveyards. Most of them will be gone by Tuesday after next, and the ones that survive will still be around when you get to them.

The people sprinting to learn the agent-of-the-day are running on a treadmill that someone else keeps speeding up. Don't join them. Walk. Pick one agent, get comfortable with it, and stop worrying about the rest. The core concepts carry over: context windows, tool calls, prompts, rules files, how the thing behaves when it's unsure. Switching from one agent to another is a weekend of friction at worst, not a career setback.

Learn the thing underneath

Whatever the AI writes for you sits on top of something older and more stable: HTTP, SQL, a filesystem, a process model, a type system, a cache, a queue. When the AI produces something broken (and it will), your ability to fix it depends entirely on whether you understand the layer it was writing into.

So the unglamorous advice: learn how a request actually travels from a browser to your database and back. Learn what an index is and why your query is slow without one. Learn what happens when two users hit the same endpoint at the same time. Learn why your deploy broke at 2 AM. None of this is going out of style. None of it is getting abstracted away, no matter what the keynote says. And yes, it sounds like a lot, but every hour you put into this now pays off twice over once you pair it with AI.

If you know these things, AI becomes a lever. If you don't, it becomes a very confident liability with your name on the commit.

Choose boring tech that works

Here's the part that won't trend anywhere. The best thing you can build your career on is boring technology, the stuff that's been around long enough to be unexciting. Postgres. A cron job. A plain old background worker. SQLite on a single box, serving more traffic than you'd believe. A monolith that fits in one repo and one head.

Boring tech is boring because it works. It has documentation written by humans who used it in anger. It has failure modes that are known, named, and googleable. It doesn't rename itself every six months. And here's the quiet part: AI is dramatically better at boring tech than it is at the shiny stuff, because there are decades of examples to learn from. Using AI on top of a boring stack is where it actually shines.

Meanwhile, the person who built their whole identity on a framework that launched last spring will spend the next year explaining why nothing works, and why nobody can hire for it.

The job is still the job

Users still need software that solves their problem without asking them to set up ten cloud services, babysit backups, or pray that availability holds. Businesses still need people who can look at a system, understand it end to end, and make a judgment call. AI doesn't do judgment. It does confident averages. Sometimes dangerous ones. Judgment is yours to build, and you build it by doing the work: reading code, breaking things, fixing them, asking why. And breaking things again, just to be sure.

Use AI to skip the parts that were always busywork. Use the time it gives you back to get better at the parts that aren't.

Will our lives change? You bet they will. Which way, that's up to you. You need to decide if you'll chase the agent-of-the-day or you'll actually use AI to produce boring solutions that actually work.

Your call.

I got this figured out for myself. I think I'll still have a lifetime of work fixing vibe-coded messes false prophets will inevitably create. It'll likely be boring but, sometimes, boring is good.

Remote Slop with Claude Code

Mladen Stepanić — Fri, 20 Mar 2026 21:42:38 +0000

In my last post on agentic workflows, I talked about workflow engineering — how the pipeline you design around AI matters more than the AI itself. I built a book inventory app that way. Skills, OpenSpecs, beads, parallel agents in tmux. It worked great.

But there was an asterisk I didn't mention: I was sitting at my desk the whole time.

What happens when you're not?

The Setup

Claude Code recently got a Telegram integration. The idea is simple: you control Claude Code from your phone through a Telegram bot. Same skills, same workflow, same project — different interface. If you've used the plugin system at all, setup is straightforward. Documentation walks you through it, you're chatting with your agent in minutes.

In fact, as of today, Anthropic officially shipped this as Claude Code Channels — a plugin-based feature that lets you push messages from Telegram or Discord into a running Claude Code session on your machine. Your session processes the request with full filesystem, MCP, and git access, then replies through the same chat. It's built on MCP, which means it slots into the existing plugin ecosystem cleanly. I ran my experiment the day it launched, so what you're reading is a day-one field report.

I wanted to test this properly, so I gave it a real task. Not a toy. A refactoring sessions on an existing codebase, the kind of thing I'd normally spend a focused afternoon on. Except today, I wasn't at my desk and I wasn't focused. I was doing something else, checking Telegram between other things.

Buckle up.

The Permission Wall

Immediately: a wall.

Claude Code has a permission system. It asks before it does anything potentially destructive — file writes, shell commands, external calls. At your desk, this is fine. You see the prompt, you approve, you move on.

From Telegram? The bot doesn't forward those permission prompts. Your agent hits a permission check, and it just... stops - silently. You're staring at Telegram wondering why nothing is happening, and the answer is that Claude is staring at your terminal wondering why you're not approving anything.

This is the first thing you'll hit, and there's no elegant workaround. Either you solve the permission problem or you don't use this workflow.

The Context Ceiling

Second problem: context. Opus ships with a 1M token context window, which sounds like a lot. And it is — for a focused session. But "entire day, away from your machine, no way to reset" is a different budget. You can't /clear the session from Telegram. If the conversation gets heavy, you can't start fresh. You're stuck with whatever context you've accumulated.

For a day of casual back-and-forth this turned out to be manageable. But it's something you have to plan around, not something you can ignore.

Biting the Bullet

So I did the thing you're not supposed to do: --dangerously-skip-permissions.

I know. The flag name exists for a reason. But here's my reasoning: I wasn't installing new external dependencies. My Claude Code workflow is already scoped — skills are loaded, the project is defined, the agent knows its boundaries.

And it worked. The permission wall disappeared. The agent could actually run.

Not great, not terrible. I'm still not comfortable disabling guardrails as a general practice. For this specific experiment, with this specific setup, it was a calculated risk. Use at your own discretion. Or better — don't. Anyway, don't blame me if Claude decides your main branch needs to have a different history and you don't have branch protection in place. You've been warned.

Saving Context With Agent Teams

The context problem needed a different solution. If I can't clear the session, I need to use less of it.

This is where the workflow from my previous post paid off. If you haven't read it: I use a pipeline where work gets decomposed into beads — small, focused tasks based on Steve Yegge's beads concept. Each bead is scoped tightly enough that a sub-agent can pick it up and run with it without needing the full conversation history.

So I instructed the main agent to delegate aggressively. The pipeline looked like this:

I describe what I want via Telegram
Main agent runs a spec creator sub-agent which generates an OpenSpec (a structured definition of the change) and makes a draft PR on GitHub
I review the spec from my phone and approve
Spec gets decomposed into beads
Sub-agents pick up beads, implement, commit, and update the PR

The main session barely touched any implementation detail. It just coordinated. By the end of the day, I'd used about 30% of the context window. Granted, I wasn't going crazy with requests — but the pattern held up.

Why Not Claude Code on the Web?

Fair question. Claude Code has a web interface now. I could've used that from my phone. No Telegram bot, no permission hacks.

The answer is boring: my tools. My skills are loaded locally. My workflow is configured. I have Playwright set up for visual verification — I literally had the agent screenshot pages to confirm layout changes actually landed. That's not something you get from the web interface.

When you've invested in a workshop, you want to use it. Even from a distance.

The Slow Loop

Here's the real downside, and it's not about permissions or context.

The feedback loop is slow.

At my desk, I have hot reload. I change something, I see it instantly. From Telegram, the loop is: agent pushes to GitHub → Vercel builds a preview → I check the preview on my phone. That's minutes, not milliseconds. For layout work especially, it's painful. You're doing the development equivalent of texting someone in the next room instead of just talking to them.

I could live with it because I was mostly multitasking — checking in on the agent between other things. But if this were my primary way of working? The latency would get to me.

The Numbers

I had Claude Code analyze the session after the fact and here's what a day of remote agent work actually looks like:

Overview

Metric	Value
Total tool calls	507
Agents spawned	22 across 5 teams
PRs created / merged	5 / 5
Telegram messages	34
Playwright interactions	50
OpenSpec tasks verified	76

Agents

Role	Count
QA	4
Spec Writer	3
Frontend	3
Explorer	3
Backend	1
Reviewers	3
Standalone	9

Features

Feature	Status
Crop inset fix	merged
Remove impressum crop	merged
Scrollable mapping	merged
Reading status	in review
OpenSpec cleanup (3 lists)	76 tasks

507 tool calls, 22 agents, 34 Telegram messages, 5 PRs. From my phone.

The Verdict

At the end of the day, I sat down and did what I always do: reviewed the code myself. Read every change, checked every decision. And it was fine. A few minor optimizations I would've caught in real-time at my desk, but nothing structural. Nothing that made me regret the experiment.

So here's the honest scorecard:

What works: Your full workflow, from Telegram. Skills, beads, agent teams, even Playwright screenshots. If you've built a good pipeline, it travels.

What doesn't: Permission prompts don't reach you. Context can't be reset. The feedback loop trades seconds for minutes. And you'll probably end up running with --dangerously-skip-permissions, which is exactly as comfortable as it sounds.

Who is this for: Someone who's already set up their Claude Code workflow and wants to keep things moving while away from their desk. Not as a primary dev environment — as an extension of one you already trust.

Would I do it again? Yeah, probably. But I'd plan the work differently. Bigger, well-defined refactorings that don't need rapid visual feedback. The kind of work where you can fire and forget, then review later. Not pixel-pushing. Not exploratory coding. Structured changes through a structured pipeline.

Remote slop? A little. But manageable slop, with a review step at the end. And sometimes that's enough.

Stop Repeating Yourself. Stop Repeating Yourself. No, Seriously — Put It in a Skill.

Mladen Stepanić — Sat, 07 Mar 2026 14:24:11 +0000

In my last post I talked about how the workflow is the work, how designing the pipeline matters more than any individual prompt. I still believe that. But I've now hit the next layer of the onion: what happens when the pipeline itself becomes repetitive?

I've been using Claude Code across five projects. A React + Hono book inventory app, a legacy .NET modernization, a Swift macOS menu bar utility, a Rust audio DAW, and a Rust TUI for task visualization. Different languages, different domains, apparently very similar habits. And I didn't notice until I asked.

The Prompt That Started It

Credit where it's due. Chintan Turakhia posted a tweet, "Run this prompt frequently. You're welcome.", with a screenshot of a Claude Code prompt:

scrape all of my claude sessions on this computer. give me a breakdown
of all the things i do, things that are worth making into skills vs
plugins vs agents vs claude.md

So I did. My version had typos, his didn't, but the idea was the same: ask Claude Code to introspect on itself. Read through every session I'd ever had and find the patterns I couldn't see because I was too close to them.

What Claude Found

Claude spawned three subagents in parallel. One explored my global config and plugin structure. Another crawled across all my repos reading every CLAUDE.md and AGENTS.md file. The third dug into specific project architectures and specs. In about a minute, they'd collectively mapped my entire Claude Code ecosystem.

The findings were equal parts validating and embarrassing.

Validating because I clearly had strong workflows. I'd organically developed a feature planning pipeline, openspec proposal, beads decomposition, worktree, implement, merge, clean up. I had a sophisticated agent team pattern with typed agents and context-aware respawning. I had a review pipeline with dedicated expert agents for security, architecture, and code quality. Real workflows. Stuff that worked.

Embarrassing because I was re-stating the same ground rules in virtually every session. Never use Python, always use Bun, use Claude Code's native tools instead of sed and awk, agents must commit frequently but not step on each other, all features start with an openspec. These rules were scattered across AGENTS.md files in every project, re-stated inline whenever Claude forgot, and occasionally contradicting each other between repos. I was spending real tokens and real time repeating myself to an LLM. The irony of a "workflow engineer" with a messy workshop is not lost on me.

The Pivot

I looked at the analysis and immediately decided to act on it. Same session, no break:

let's do the following:
- add recommended things to global claude.md and remove them from projects
- create a new project in ~/repos/ to host all of the recommended plugins
- implement openspec-and-beads skill
- implement agent-team skill
- write a comprehensive readme doc with implemented skills and a list of todo items

Do not connect any of the new skills, I'll make a github repo and publish them there

This is where the session pivoted from analysis to execution. And here's the thing, this pivot itself followed the pattern Claude had just identified. Analysis, planning, execution. The openspec-and-beads workflow, applied to itself. Recursive in the best possible way.

What Got Built

Claude entered plan mode, loaded two meta-skills, executing-plans and writing-skills, and broke the work into three batches.

First batch was the lowest-hanging fruit: creating a global ~/.claude/CLAUDE.md with all my universal conventions, then surgically removing the duplicated rules from each project's config. Every repo got trimmed to only project-specific information. One file, in one place, read by every future Claude session. No more "never use Python" on repeat.

Second batch was openspec integration. Instead of embedding massive documentation inline in every project, each repo got a one-liner pointing to the new skill.

Third batch was the main event: the claude-skills repository with three complete skills.

The openspec-and-beads skill formalized my most-used workflow. Gather project context, scaffold a change proposal with motivation and delta specs, decompose into prioritized beads linked to an epic, track during implementation, archive when done. Before this existed as a skill, I was re-explaining the concept every time I started a new feature. Now its a single invocation.

The agent-team skill captured something more subtle, the coordination patterns for running multiple agents in parallel. The key insight was the "cover agent" pattern: when an agent hits roughly 50% of its context window, you let it finish its current task, create a new bead for the remaining work, and respawn a fresh agent to pick it up. The skill also codifies rules I'd learned the hard way. One agent per file to avoid merge conflicts. Commit at every logical checkpoint. Shut down in reverse dependency order.

The use-bun skill was just a quick reference card. A lookup table for Bun equivalents of common Node/npm patterns. bunx tsc --noEmit instead of npx tsc, Bun.file() instead of fs.readFile. Tiny, but it eliminated a whole class of "how do I do X with Bun again?" questions.

The TDD Override

Here's a moment that stuck with me. The writing-skills meta-skill recommended full TDD for new skills, write tests, watch them fail, implement. Claude's response was pragmatic: this content was already empirically validated across hundreds of messages and 240 sessions. The "tests" had already been run, organically, over weeks of real usage. It proceeded directly to writing the specification.

That felt like a right call. TDD for a skill isn't the same as TDD for code. The validation had already happened in practice. The whole point of this excercise was to capture what was already working, not to discover new behavior. Sometimes the best test suite is "I did this 50 times and it works."

The Structure

The repo ended up looking like this:

~/repos/claude-skills/
├── README.md
├── plugin.json
├── marketplace.json
├── skills/
│   ├── openspec-and-beads/
│   │   └── SKILL.md
│   ├── agent-team/
│   │   └── SKILL.md
│   └── use-bun/
│       └── SKILL.md
└── plugins/
    └── README.md

There was a brief moment of confusion about plugin manifests, plugin.json vs marketplace.json, what each needed, but it resolved quickly. The repo was initialized, committed, and pushed to GitHub in the same session.

What This Actually Means

Your LLM conversations are data. 240 sessions contained patterns I couldn't see because I was living inside them. Having Claude analyze its own session history was like running a profiler on your own workflow, the hot paths become obvious. If you haven't done this yet, do it. Chintan was right.

Global config eliminates an entire class of wasted tokens. Every "never use Python" I typed was burning context and attention. A single CLAUDE.md in ~/.claude/ fixed that permanently. If you're using Claude Code across multiple projects, this is probably the highest-ROI thing you can do right now.

Skills are just formalized habits. I didn't settle on the openspec-and-beads workflow during this session. I'd been doing it for weeks. The skill just wrote down what was already true. If you find yourself explaining the same process to Claude more than twice, it belongs in a skill. Not a prompt, not a CLAUDE.md entry, a skill. The distinction matters because skills carry context, structure, and sequencing that a flat config file can't.

The "cover agent" pattern deserves to be a first-class feature. The idea of monitoring an agent's context utilization and strategically respawning it before it degrades, assigning the remaining work as a new task, is something I'm doing manually. In 2026. While Anthropic ships yet another benchmark blog post. The fact that I have to write a skill to manage context windows because the tool won't do it for me is... a choice. Anthropic, if you're reading this: please steal this idea. I'm begging you.

What's Next

The TODO list from this session is still open. A beads MCP plugin so agents can query and update task status natively instead of shelling out to bd commands. A review pipeline skill for spawning expert agents and turning their findings into follow-up beads. A branch cleanup skill because the merge-delete-remove dance is identical every single time and I'm tired of typing it.

The session that produced all of this took about 22 minutes. Three subagents, a lot of pattern recognition, and a pivot from "hmm, I wonder what I actually do" to shipping a plugin repo on GitHub. Not bad for a Saturday morning.

Workflow Engineering > Prompt Engineering

Mladen Stepanić — Sun, 01 Mar 2026 10:42:02 +0000

... it's early 2026. Remember when I said AI is a tool? I still believe that. But I've been using Claude Code for a few months now and I need to update the nuance a bit: AI is a tool, but the way you set up the workshop matters more than the tool itself.

I built a book inventory app. Nothing fancy, it tracks books across households, lets users invite others to share their collections. Hono on the backend, React with Vite on the frontend, Neon Postgres for the database, deployed on Vercel. A boring stack for a boring app. And I mean that as a compliment. Oh, and before you ask - no, it doesn't have any AI-powered features. No "smart recommendations," no "AI-curated reading lists." It's a CRUD app. It stores books. The irony is not lost on me.

But the way I built it? That part wasn't boring at all.

The Codex Chapter

I started with Codex. I had high hopes. Same skills loaded, same setup, same project. Progress was slow. Not because Codex is bad, it's not, but because the ergonomics didn't work for me. Worktrees felt awkward. Parallel agents were running but I couldn't see what they were doing well enough to react in time. I was spending more energy managing the tool than building the app. That said, this could easily be a skill issue on my part. Codex might click better for someone with a different workflow or habits, I'm not here to tell you it's a bad tool. It just wasn't the right fit for how I work.

So I switched to Claude Code. And things exploded.

Same skills. Same project. Different interface. Claude Code's TUI let me see parallel agents running in tmux, let me react fast, let me stay in the flow. Thats it. That's the difference. Not smarter AI, not better models, better ergonomics. If you take one thing from this post: capability is table stakes. The interface determines your productivity.

The Workflow Is the Skill

Here's where it gets interesting. I didn't just open Claude Code and say "build me a book inventory app." That's how you get a mess.

Instead, I designed a pipeline. Every feature goes through the same stages:

First, brainstorming. I use obra's superpowers skill, specifically the brainstorming mode, for the planning phase. It made a noticeable jump in the quality of definitions compared to vanilla planning. The output here isn't code, it's clarity about what I'm building and why.

Then, specification. The planning phase generates an OpenSpec, a structured definition of what needs to be built. Still no code.

Then, decomposition. The spec gets broken into beads (if you haven't seen Steve Yegge's beads repo on GitHub, go look). Each bead is a tight, focused task. This is where the magic starts, because beads keep everything scoped. No context window bloat, no agents wandering off into tangents.

Then, implementation. This is where I hand the OpenSpec and the beads to Claude Code and say: go. Parallel agents in tmux pick up the tasks and run.

The One-Shot That Wasn't

Let me tell you about the household feature. Users living in the same space should have access to all books in that space. And I needed an invitation system so the household creator could invite others.

I kicked off the pipeline. Brainstorming produced a clean definition. OpenSpec captured the full scope. Beads broke it into tasks. I handed it to Claude Code and the parallel agents basically one-shotted the whole thing, household concept and invitations, implemented and working.

Sounds impressive, right?

But was it really a one-shot? The implementation was, sure. But I front-loaded the intelligence into planning, specification, and decomposition. The "shot" landed cleanly because the planning was rigorous. Take away the pipeline and ask Claude Code to "implement household sharing with invitations" cold? You'll get something. Whether you'll get something good is a another question.

This mirrors how experienced developers actually work. Nobody good just starts coding a multi-faceted feature. You think it through, you break it down, then you execute. I just happened to have AI on both sides, doing the thinking and the executing. My job was designing the workflow between them.

Three Layers of "Does It Actually Work?"

I can hear the skeptics: "Sure, AI generated the code. But does it work?"

Fair question. Here's my answer: TDD is in place from the start. Yes, through a skill. Tests exist before implementation, not as an afterthought.

But tests only tell you the logic is correct. So I also use a Playwright skill with Chrome to watch actual end-to-end runs. I see the app doing what it's supposed to do. No manual clicking through screens, no "I think it works." I watch it work.

And then, at the end of each meaningful session, I spawn dedicated reviewer agents, one for frontend, one for backend, one for security. Their findings go into a follow-up PR.

Three layers: TDD catches logic errors. Playwright catches visual and integration errors. Reviewers catch architectural and security issues. None of them manual.

And then there's the fourth layer: me. I do a thorough manual code review after all of this. AI catches a lot, but I still read the code myself. I need to understand what's in my codebase, I need to know why decisions were made, and I need to catch the things that automated tools miss. The subtle logic that's technically correct but wrong for the product, the naming that'll confuse me in three months, the architectural drift that no linter will flag. If you skip this step, you're not building software, you're accumulating code you don't own.

The Cross-Model Twist

Here's something that might raise eyebrows: I've been experimenting with using Codex as my reviewer.

Yes, that Codex. The one I moved away from for building. Turns out, Codex 5.3 with maxed out thinking produces genuinely valuable review feedback. And it makes sense when you think about it, review is a different cognitive task than generation. You're evaluating against criteria, not creating from scratch. Codex's deep thinking mode suits that well. The ergonomics that frustrated me during building don't matter for review because it's single-threaded, focused work.

I'm not loyal to one tool. I'm assembling the best pipeline I can from whatever works. Claude Code plans, specs, decomposes, and implements. Codex reviews. Each playing to its strengths.

What This Actually Means

In my last post I said AI is a tool and that you need to know what you're doing to use it well. I stand by that. But now I'd add: the emerging skill isn't coding, and it isn't prompting either. It's pipeline design.

Knowing which skills to load, when to brainstorm vs. spec vs. decompose, when to run agents in parallel, when to bring in a different model entirely, that's the craft now. The code is the output. The workflow is the work.

Will this change again in six months? Probably. But the principle won't: understand what you're building, design a process that keeps quality high, and use whatever tools make that process smooth. Boring? Maybe. But boring apps that work are what people actually need.

And I still think I'll have a lifetime of work fixing vibe-coded messes. Some things don't change.

AI Won't Take Your Job (But Fear Might)

Mladen Stepanić — Mon, 08 Dec 2025 15:10:50 +0000

... it's the end of 2025. And the development world as we know it is at turning point. It's been at turning point a lot of times since I've started doing this some 16 years ago, and a lot more times before that. But this one time is special, this one time is different: AI threatens to replace us.

Relax, I'm dramatic on purpose, we're not going anywhere. I'm writing this post mostly for younger folks who I don't envy because they're in a position where they are threatened by, scared by, and forced into the AI bubble. People are losing their minds over whether AI will make them obsolete, they're listening to false prophets who are telling them that they should be learning a real craft, a physical skill that won't be touched by AI any time soon. But what's the reality? Reality is that AI is a tool (last time I checked). A powerful tool and it could be a great asset to a developer who knows what they're doing. If you don't know about the basics, security, user experience, performance... no amount of AI will help you make a good app. That's the truth, and anyone who's telling you otherwise is likely fearmongering to raise their importance or to sell you an AI-powered service or one of their dime-a-dozen courses. These people are not your friends!

I'm not saying you need to avoid AI until it disappears. On the contrary, it's here to stay - just maybe not in the areas AI doom merchants want you to believe it will. You should definitely learn how to work with AI. Large Language Models (LLMs) changed the game for me: I can get to the prototype faster, I can debug faster. I abstracted away boring multi-file edits, tests, and boilerplate, which are generally time consuming. Do I work more? No. Do I output more? Yes, but probably not as much as my CEO would like me to. I use it to find myself the time to learn core stuff that I'm missing, stuff that AI maybe knows but is unsure how to apply it (or apply correctly). I'm improving my infrastructure and backend knowledge, I use AI to brainstorm and then have it explain the choices it made. Then I question its choices, which are often either overkill or outright wrong. And this happens more times than any of the doom merchants would like to admit.

I don't think so.

Instead, people will still need well-thought-out software that they can use without a hassle of setting up 10 cloud services, or worrying about backups, availability, or disaster recovery.

Will our lives change?
You bet they will. Which way - that's up to you. You need to decide if you'll chase the agent-of-the-day or you'll use the AI to produce boring solutions that actually work.

Your call.

I got this figured out for myself. I think I'll have a lifetime of work fixing vibe-coded messes false prophets will inevitably create. It'll likely be boring but, sometimes, boring is good.