DEV Community: Dragos Roua

Switching from Claude Code to Grok – Same Interface, Different Model

Dragos Roua — Fri, 03 Jul 2026 02:57:34 +0000

At the beginning of June I started a “Claude withdrawal” challenge. The plan was to run MiniMax 3 for a month, to see if I can get the same level of quality, but at 5x less the price. Until then, Claude Code was my main driver, with MiniMax on the backup, for when I was running out of quota, or sometimes for code review. The monthly bill for Claude was $100 on the Max plan, whereas for MiniMax I would pay $20 for the Token plan. All in all, it seemed like an interesting experiment.

Then, half way through the challenge, Grok came into the picture. I got a very interesting offer at $35 for 3 months, then $35/month. But Grok has something neither Claude, nor MiniMax can give me out of the shelf: video and image generations. The only unknown was if switching from Claude Code to Grok will still maintain the same coding power. So I instantly took the offer, and did whatever I had to do to understand if this was the right path.

And here comes the “whatever I had to do”, in plain technical terms.

Switching from Claude Code to Grok – the Actual Steps

The switch itself was interesting because I didn’t want to lose the Claude Code interface. I like the harness. The way it works with my codebase, the commands, the flow. So I used a helper called cliproxyapi. It’s a small proxy that sits between the Claude Code client and whatever model you point it at. You run it locally, tell it to forward requests to Grok’s API instead of Anthropic’s. Then you launch Claude Code the same way you always do, but it talks to Grok under the hood.

Here’s how it goes in practice.

Step 1: Install the proxy. I used brew to install it, I’m on a Mac, and also because I wanted to have it started as a service.

Step 2: Set two environment variables. One is the target API base URL, for Grok that’s something like https://api.x.ai. The other is your API key.

"env": {
    "ANTHROPIC_BASE_URL": "http://localhost:8317",
    "ANTHROPIC_API_KEY": "cliproxy-local-key"
  },

Notice how we use “cliproxy-local-key”, because, and here is where it gets interesting, you log in with xAi OAuth, so you just stay inside Grok standard package, not the one using API tokens. It’s the same with Claude Max, I always logged in with OAuth and kept my usage limits inside the Max plan.

Step 3: Because you have to be logged in via OAuth to xAI, you just use this command before starting cliproxyapi:

cliproxyapi -xai-login

After that you just run

claude

like normal. The proxy intercepts the calls, rewrites the auth headers, and sends everything to Grok. It handles the main chat loop and the tool use stuff too. I’m running it for about a week without any hiccups.

Is It Worth Switching from Claude Code to Grok?

What I get out of this is the same coding experience I had with Claude, maybe better on some things, plus full access to Grok’s image and video generation. And I’m paying $35 instead of $100. Not even that, because the $35 plan will kick in about two and a half months. I already cancelled my Claude and MiniMax subscriptions.

And then there’s this: Grok is less censored. Claude has a lot of guardrails. Some of them make sense, some of them are just annoying when you’re trying to explore an idea or write something that touches on certain topics. Ask it to roleplay something edgy or dig into a controversial angle and it starts hedging or refusing outright. Grok lets you push further. For the kind of work I do, where I’m often asking for unfiltered takes or edge case scenarios, that matters. I don’t want to fight the model just to get it to consider an uncomfortable premise.

The prices in AI keep moving. Five months ago I was at $100. Beginning of June I was at $120 (Claude + MiniMax). Now I’m at $35 but with capabilities I didn’t have in either of the previous setups. The market is still figuring itself out. Providers are competing hard on price because the models are getting better fast and nobody has a permanent moat yet. That works in the user’s favor for now.

But the end goal isn’t to find the cheapest subscription that does everything. The end goal is to run this stuff locally. I’ve already written about running private, local models before. When your tools can be taken away by a policy change, or a regional restriction, or just a company deciding you’re not worth serving anymore, you’re not in control. Local models don’t have that problem. No rate limits. No one watching what you generate. No sudden deprecations.

The gap is closing. Every time the hosted prices drop and the quality goes up, it gets easier to see the path to running something comparable on your own hardware. Not there yet for video generation at the level Grok Imagine does. But the coding side is already viable with some of the open source models, if you’re willing to put in the setup work.

A year ago the gap felt huge. Now it feels like a matter of time and hardware budget.

This June challenge started as a test of MiniMax. It turned into a test of how I actually want to work with these tools. The answer so far is: keep the harness I like, add the capabilities I need, and don’t get too attached to any single provider.

How To Manage AI Cognitive Overload – Lessons After 9 Apps Shipped in 4 Months

Dragos Roua — Fri, 26 Jun 2026 02:53:38 +0000

In the last four months, I managed to ship nine iOS apps. That’s a pace that would have been impossible for me before AI—completing even a single app in 30 days used to be a significant stretch. But while AI has drastically accelerated the production cycle, it has introduced a new problem: AI cognitive overload.

The biggest hurdle in this high-speed environment is constant context switching. Moving between nine different apps, each with its own codebase, logic, and UI patterns, while also managing AI conversations for each of them—that’s a lot of mental weight to carry. The AI never gets tired, but you’re human, and humans do.

To manage AI cognitive overload and keep being productive without burning out, I identified three actions that help me — and I hope they’ll help you too.

1. Increment in Very Small Steps

The temptation with AI is to go big—to hand it a large chunk of work and let it run. That almost always ends badly. The AI drifts, introduces subtle bugs, or solves the wrong problem entirely. By the time you catch all these blunders, you’ve already lost a lot of ground.

Instead, I got used to iterating on small steps and keeping the AI on a short leash. One function, or one screen, or just one bug at a time. I ask for something very specific, verify it works, then move on. The overhead feels counterintuitive when you’re trying to move fast, but the compounding effect of not having to backtrack is enormous. That’s how you actually manage AI cognitive overload — not by thinking less, but by splitting the thinking into small steps, which ends up being the fastest path.

2. Save Often

Frequent checkpoints are compulsory. When you’re working across multiple projects at AI speed, your mental map of where things stand gets blurry quickly. A commit or a save is not just version control—it’s a cognitive anchor. It marks where solid ground is — and it connects with the point above: it must be short, easy to remember, and simple.

When you switch context to a different app and come back three hours later, a recent checkpoint tells you exactly where to re-enter. Without it, you spend 20 minutes just reconstructing what state the project was in. At scale, that reconstruction cost is brutal and it makes AI cognitive overload more expensive than the actual building.

3. Take Frequent Breaks

The AI doesn’t need a break, but then again, you’re human, so you do. This sounds obvious, but it’s easy to ignore when things are moving fast and momentum feels fragile. I need to add just one more feature, fix just one more bug.

A break is not wasted time. It’s when your mental cache clears. When you come back, you see problems differently—you spot things you were too deep in to notice before. The cognitive overload of rapid AI-assisted development is real, and breaks are the only thing that actually resets it. No hack, no productivity tool substitutes for stepping away from the screen.

Keep It Simple

All three of these come down to the same thing: respecting the limits of human attention in a workflow built around a tool that has none. AI doesn’t get overwhelmed. It doesn’t lose track. It doesn’t need to remember where it left off. You do all of those things, and the strategies above are there to protect that human layer.

The bottleneck in AI-assisted development is not the AI. It’s you. Manage that cognitive overload well and the pace becomes sustainable.

Running Local Private AI Models – How And Why

Dragos Roua — Fri, 19 Jun 2026 06:28:44 +0000

Originally published at dragosroua.com.

Last week, Anthropic released Fable 5. Three days later, the US government ordered them to shut it down — for people outside US. Anthropic said they couldn’t filter users by nationality fast enough, so they pulled the plug on the whole thing.

Like any good ol’ miracle, it lasted only 3 days.

That was a very much needed cold shower. When you realize someone can take away your workforce just like that, running local, private AI models, suddenly becomes the number one priority.

Why You Should Run Your Own Local AI Models

In no particular order (because all of them count):

No one can take it away. Local AI models on your machine don’t care about export controls, government directives, or provider board decisions.
No usage limits. No rate limits, no subscription tiers, no “you’ve used your monthly tokens.” Play as much as you want.
Nothing leaves your machine. Your code, your documents, your client data — none of it hits a third-party server. Local AI models are private by default.
Fixed cost. You pay for hardware plus electricity. No surprise price hikes mid-year.
No API dependency. Your workflow doesn’t break when a provider has an outage, deprecates a model, or gets a compliance letter.
You can modify it. Fine-tune, quantize, run on your own data. Build something they can’t sell you. Make your own local, private AI model factory.

What It Actually Costs

I hear you: but I don’t have the money to build a data center in my basement. Fair play. But here’s the thing: you don’t have to.

Here are four realistic options, as of June 2026 money:

MacBook Pro M4 Max (~$3,000–4,500): 546 GB/s memory bandwidth. Runs 70B models at around 70 tokens/second with 4-bit quantization. Fast enough to feel snappy. This is the “you might already own this” option.

Mac Studio M3 Ultra (~$5,000–10,000): 800 GB/s, up to 512 GB unified memory. Runs DeepSeek R1 — a 671-billion-parameter model — at 17–18 tokens/second. That’s a model that costs real money per token on any API, running locally on your own hardware. This the upper layer for Apple Silicon machines.

Nvidia DGX Spark (~$4,000): Nvidia’s personal AI supercomputer, roughly Mac Mini-sized. 128 GB at 273 GB/s. With TensorRT FP4 optimizations, ~38 tokens/second on 120B-class models. Good if you live in the CUDA ecosystem.

AMD Ryzen AI MAX+ 395 (~$3,000 in a mini PC): 128 GB unified memory, competitive decode speeds, strong on MoE models — Qwen 3 30B A3B runs at 72 tokens/second. The cheapest path to serious local memory.

To recap: the cost for running local, private AI models, on your own hardware is between $3000 and $10,000. Depending on how much you make with your AI setup, you could make back the initial investment in one, two years. From there onwards is pure profit.

The Open Source Models Are Actually Good Now

A year ago, running local AI models meant accepting a real quality gap. That gap is mostly gone. Here are 3 options that are probably covering 90% of the use cases:

Kimi K2 (Moonshot AI): One trillion parameters, 32B active per token. MoE, trained on 15.5 trillion tokens. SWE-bench Verified at 65.8% — better than most closed models on agentic coding tasks. Open weight under a modified MIT license, on HuggingFace.

GLM-5.2 (Zhipu AI): Released June 13, 2026 — two days after the Fable shutdown. One million token context window, which means you can load an entire mid-sized codebase in a single pass. Two thinking modes: High for speed, Max for hard problems. MIT licensed, open weights. No benchmark numbers at launch, which is unusual — but the prior GLM-5 scored 77.8 on SWE-bench Verified, so the baseline is solid.

MiniMax M3 (MiniMax): Released June 1, 2026. 428B total parameters, 23B active per token, one million token context. Ranked #1 out of 90 models on Artificial Analysis’s independent intelligence benchmark. SWE-Bench Pro at 59.0% (vendor-reported). Weights are on HuggingFace, though the license isn’t MIT — commercial use is free if your company makes under $20M/year, otherwise you need written permission. Worth knowing before you ship a product on top of it.

To recap: you get to play with 32B up to 428B parameters on your own machine, at decent speed, with intelligent tool calling. Your own little digital workshop, made entirely off of local, private AI models. It’s also worth adding that the pace of innovation in this area is still breathtaking, so what we talk about now might be obsoleted by even better models in 3 months.

Running Private, Local AI Models Is Not Optional Anymore

The Fable shutdown won’t be the last one. Governments are figuring out that model capabilities are geopolitically sensitive. Providers are figuring out that compliance isn’t optional – and there are already early signs that KYC is coming. Your access to the tools you depend on sits somewhere in the middle — renegotiable at any time, by people who aren’t you, and who probably don’t have the same goals with you.

Running your own local AI models isn’t paranoia. It’s actually a symptom of awareness: the world is moving fast, so you need to stay on top of it. We are on the verge of turning the users of commercial AI into the actual product – you, your train of thoughts, your data will be sold. In the same way this happened with social media.

If you’re ok with that, no problem. But if you care about your privacy, your algorithmic reality choice, and your sovereignty, then, by all means, start building your own local, private AI model factory.

Your future self will thank you.

I Stopped Prompting My Agents, I Write Agentic Loops Instead - Here's Why

Dragos Roua — Fri, 12 Jun 2026 02:19:20 +0000

Originally published at dragosroua.com.

There's a line from Boris Cherny, the head of Claude Code, that's been quite present in the back of my mind for the past week. Paraphrasing: he doesn't prompt the AI anymore. He writes loops, and the loops do the prompting. His job is to write the loops.

When the person who built the coding agent stops using it the way the rest of us do, that's worth some brain cycles. So I sat with it.

Then I did the least glamorous possible thing with the idea, which is exactly why I'm writing this down.

What a loop actually is

Addy Osmani, a Google engineer with close ties to Gemini AI, has the best definition so far: a loop is a recursive goal. You define a purpose, and the AI iterates until it's complete. You stop being the person who prompts the agent and become the person who designs the system that does the prompting for you.

For about two years, working with a coding agent meant one thing: you wrote a good prompt, shared enough context, read what came back, typed the next thing. The agent was a tool and you were holding it the entire time, one turn after another. Like a sculptor uses the chisel.

A loop hands that holding to a small system that finds the work, hands it out, checks it, writes down what's done, and decides the next thing — and lets that poke the agent instead of you. It's like your job is to create the sculptor now - or, to be more precise, a small army of sculptors.

Finding a test use case

I shipped 9 apps in the last 4 months, to bring my total in the App Store to ten. They cross-promote each other, which means every single one is supposed to have a "By the same dev" section in Settings, linking to the others. That's the perfect candidate for a loop, a tiny problem spanning across multiple codebases.

To make things a bit more interesting, I decided to add something on top of that: a convention. Each app displays a version string in Settings that reads 1.4.2 (28) — semantic version, then the build number in parentheses. When you juggle 6-7 apps every day you kinda lose track of which build does what, so I wanted to make sure all apps display this accurately.

So, with these 2 simple things, I decided to write my first loop.

What I built

In total, the loop I built to solve those 2 problems is fifty lines of Python. It's just a vanilla Python script that reads my app folders, grabs the necessary files (meaning the Settings.swift or SettingsView.swift), then sends them to a model with my two rules in plain English (the prompt), and prints a pass/fail verdict per app.

The most important part is this one (simplified):

for app in APPS: state = collect_state(app) # read the files that matter result = audit(app, state) # ask the model to judge them print("✅" if result["ready"] else "❌", app)

It's not very complicated: it has a folder map to which I can add more apps, my conditions in plain English (have the "By the same dev" section, and make sure the version is there in the specific format), and one small loop that feeds each app to the model and prints what came back.

The five building blocks of a loop (and where mine sits)

But a real loop has way more than that. There are many definitions, because these are a lot of moving parts, but in very simple terms, it's something like this:

Automations — something fires on a schedule and does the discovery for you, so you're not the one going around checking. This is the heartbeat. It's what makes a loop an actual loop instead of one run you did once.

Worktrees — separate checkouts so two agents working in parallel don't overwrite each other's files. The moment you run more than one agent, this is the thing that stops parallel from turning into chaos. In my case, this one wasn't needed, my loop was purely reporting, no code written.

Skills — your project knowledge written down once (a SKILL.md file) so the agent reads it every run instead of guessing. Without it, the loop re-derives your whole project from zero every cycle.

Connectors — the loop reaching your real tools: the issue tracker, the database, Slack, the App Store Connect API. The difference between an agent that says "here's the fix" and a loop that opens the PR itself.

Sub-agents — one agent has the idea, a different one checks it. Having models checking each other's work is usually more effective.

And the sixth thing: memory. The model forgets everything between runs, so the memory has to be on disk.

My audit loop uses exactly one and a half of those five. It's a hand-run automation (block 1, minus the schedule) with my conditions standing in for a skill (block 3, barely). No worktrees, no connectors, no sub-agents, no persistent memory.

But it was a very good learning experience.

What it caught

I ran the script across all my apps and most passed clean. The genuine findings were small and exactly the kind of thing I'd never catch by eye.

One of my oldest apps — the task manager that's been around longest — has been shipping its Settings screen with the marketing version only. No build number. It reads 1.4.2 where every other app reads 1.4.2 (28). A one-line gap sitting there through who knows how many releases, because I'd long since stopped looking at that screen.

A real, useful catch. Also the least dramatic finding imaginable, which is precisely why a loop found it and I didn't.

What it got wrong, and why that's the actual lesson

Most "I built an AI loop!" posts skip this part, so it's the part I want to dwell on. The loop lied to me several times, and every lie taught me something.

It complained about missing data I never sent. An app reported "no Settings screen, can't verify anything." There was a Settings screen. But my file collector was pointed at the wrong path and silently returned nothing, and the model dutifully reported on the nothing it received. A loop is only as honest as the state you feed it, and a script that reads zero files fails quietly — no error, just a confident wrong answer downstream. The fix wasn't smarter prompting; it was printing the size of what I was about to send, so I could see when I was feeding it just empty air.

It flagged good code as broken. Several apps got dinged for "won't compile, this property has no body." None of it was true. I was truncating each file to save tokens, and the version code I cared about lived at the bottom — so I was decapitating the exact thing I was asking about, then watching the model correctly report that the fragment didn't compile. Lesson: the thing under audit gets read whole. You truncate the supporting evidence, never the thing you're judging.

It gatekept on wording. One app titles its cross-promo section "From the maker of…" instead of "By the same dev." The loop failed it. The section was fine — I'd written my rule too literally and the model obeyed too literally. Fix: tell it to judge intent, not phrasing.

Not one of those was the model being dumb. Every single one was me handing it bad inputs or instructions, and the model faithfully reporting on exactly what I gave it. That's the skill of loop engineering, and it isn't prompting. It's building inputs you can trust and knowing where the loop will be confidently wrong.

The senior-dev instinct, by the way, is the right one. Thirty-five years of shipping software taught me to distrust silent failures, and the reflex that says "this is just a for loop with an API call in it" is correct. That's the feature, not the disappointment. The interesting part was never the loop — it was deciding what to check and learning where to distrust the answer.

Three things the loop still won't do for you

Osmani names these better than I could, and they get sharper as the loop gets better, not easier:

Verification is still on you. A loop running unattended is also a loop making mistakes unattended. "Done" is a claim, not a proof. The whole reason you eventually split the checker sub-agent from the maker is to make the loop's "it's done" mean something — and even then your job is to ship code you confirmed works.

Your understanding rots if you let it. The faster the loop ships code you didn't write, the bigger the gap between what exists and what you actually grasp. A smooth loop just grows that gap faster unless you read what it made.

The comfortable posture is the dangerous one. When the loop runs itself, it's tempting to stop having an opinion and take whatever it hands back. Designing the loop is the cure when you do it with judgment and the accelerant when you do it to avoid thinking. Same action, opposite result. The loop doesn't know the difference. You do.

That's exactly why mine is deliberately read-only. It reports; it doesn't touch a file. The worst it can do is have a wrong opinion in my console. The moment I let it edit code, every one of those false positives above becomes a wrecked Settings screen.

What's next

The obvious next step, which I'm resisting on purpose: let the loop propose the fix, not just report the gap. That's where a checker becomes an agent — and it's where blocks four and five (a connector to act, a sub-agent to verify) finally earn their place. I'll get there, but only behind a hard approval gate, because the false positives above are a perfect catalogue of what goes wrong unattended.

So I'm not uninstalling my IDE. I'm not running ten agents in parallel while I sleep. I took one repetitive chore, wrapped it in the smallest possible loop, and kept a human at the end of it. That's the rung I'm on, and I'd argue it's the right rung for most working developers right now — not because the higher rungs aren't real, but because the discipline you build here is what makes them safe later.

Just start small, understand the implications and iterate. Do one sculptor first and make it carve a great statue. Then you can think about building a full army of sculptors.

Vibe Coding for Senior iOS Developers - 6 Takeaways after Shipping 10 Apps in 4 Months

Dragos Roua — Wed, 27 May 2026 02:59:28 +0000

At the start of February 2026 I had one iOS app live in the App Store. As I write this at the end of May, I have ten, and a sustainable working pattern. Ten apps in roughly four months, built solo, on my Mac plus an iPad when in coffee shops.

In this post I will try to extract the actionable insights from this sprint. It’s a smaller and more focused companion to my longer post on vibe coding iOS apps on my iPad with Claude from my favorite coffee shop, which describes my setup and the actual processes. This one is about things I couldn’t see at the beginning, but which might be useful for someone starting to do the same thing — especially if they already know how to ship software. These are notes on vibe coding for senior developers specifically — not for beginners, not for people learning to code.

Intended Audience

Most vibe coding content out there is written for people who never coded before. That’s a fast growing and legitimate audience, but I’m not addressing it here. Vibe coding for senior developers is a completely different topic, and that’s where I’m heading with this article. Ideally, you’re not using AI to learn how to code – you already did this for years. You’re just delegating something you already know how to do, and the delegation skill is what’s new.

The guidelines below are what I’d send my past self at the start of February. They assume you know the language, the coding platform, and master the basic processes.

1. Use Two Models

The change that most improved my workflow was running two models in parallel — Claude Code as the primary, MiniMax M2.7 as the backup, accessed through OpenRouter.

The split is:

Claude Code handles architecture, agentic loops, spec interpretation, and anything that needs to hold the whole project in context. Memory files, genesis prompts, testing and versioning approaches.

MiniMax M2.7 is used to do refactors, boilerplate, a second opinion on complicated codebases (treating it like the code review guy in my team), and just a backup when I hit my Claude quota.

Claude Code Max is $100/month, MiniMax 2.7 is $20 on the Token Plan, which is more than enough for a backup model (I reckon I could even use it as the main actor, if I really had to, but it would be tight). Beyond pricing, the main reason for this is continuity. Losing steam midday because Claude Code decided to eat half of my tokens on useless stuff, leaving me naked in the middle of that big feature build, that is something that I find highly demotivating.

This is the simplest of the vibe coding for senior developers guidelines, and the one I’d act on first: at least two models, with a clean separation approach.

2. Optimize At the Root

Most of the friction in my coding sessions eventually traces back to underspecification in the first prompt. Every “actually, also…” in turn eight is usually a sign that turn one wasn’t clear enough.

So I came up with a single genesis prompt that describes the app before any code is written. App name, bundle ID, monetization model, tech stack, architecture, file structure, color palette, IAP product IDs, App Store metadata — all of it in one document. The prompt I use is open-sourced as the iOS App Genesis Mega Prompt. It has 23 sections, and it is basically a general purpose template. It only needs the actual app functionality, something you can define in Claude chat or your agent of choice. Then throw that in the genesis prompt and feed the mix to Claude Code. Most of the time, Claude Code is able to do 95% of the work in the first pass.

The time spent on the genesis prompt has the highest leverage in the project. An hour of careful spec writing avoids a day of mid-session corrections. Don’t assume the model has your work history, your experience, your skills. Feed it good, feed it early.

3. Keep Your Mental Mode Light

Shipping at this pace is hard to sustain if you try to hold every project in your head. There’s simply not enough mental capacity to do so. I learned this the hard way. Eventually, I decided I needed an externalized way to know what mental mode I’m in at any moment.

The framework I use for this is Assess-Decide-Do, a mega prompt built on a methodology I’ve been teaching for fifteen years. The short version: at any moment you’re in one of three modes. You’re assessing (what’s the state, what are the options?), deciding (which option, at what cost?), or doing (executing the chosen option). The common failure is doing all three at once. Multiply this by 10 projects simultaneously and you’re free falling.

When I open a session with an Assess-Decide-Do flavored Claude Code, I know immediately which mode we’re in – and I can steer it in the mental mode I want in that specific moment. “We’re in Assess mode for the next 20 minutes — don’t write code, just model the trade-offs for the IAP layer.” Or: “We’re in Do mode on the breath-sync feature — the spec is locked, just implement, nudge me when you’re done.” The framework does the same thing for the AI that it does for me: it names the correct next action.

That’s what keeping the mental mode light means in practice — not memorizing some ruleset, just overlaying a solid cognitive framework over your processes, so you and the agent are in sync.

4. Shrink Building, Expand Verification Time

With AI doing the coding, the time spent building shrinks. The time spent verifying needs to grow in proportion, and that’s the adjustment most senior developers are slow to make. This shift in where the actual work lives is the part of vibe coding for senior developers practice that catches the most experienced people off guard.

My current ratio is roughly 30% spec, 20% generation, 50% verification. After every major feature build: read the diff carefully, run the build, scan for the specific failure modes this model produces, document everything, and only then move to the next step.

The reason verification matters more than it used to is context drift, which is the main hazard of long sessions. The more code generated inside a session, the more the model’s attention dilutes across what it has already produced. The frequency – and impact – of these issues rises as sessions get longer:

silently breaking something built earlier in the same session
forgetting a constraint from the genesis prompt
regressing on a fix it just made
“improving” a working file in a direction nobody asked for (this kinda drives me crazy, honestly)

In my experience, around the third, fourth hour of an intense session, more time goes to un-doing than to doing, because context drift compounds with every additional generation. What works is: shorter sessions, aggressive commits, fresh contexts started on purpose, thorough documentation of everything that was built so far and review of every generation.

If you came up writing every line by hand, which most, if not all, senior developers out there did anyway, you already built the verification reflex. You just need to redirect it from your own typos to the model’s drift.

5. Pivot Toward Marketing Earlier than Feels Natural

When the build compresses, the bottleneck moves forward. Before, the most important question used to be “do I have the app yet?” Now it’s: “does anyone know it exists?”

I now start ASO scaffolds the moment the genesis prompt is locked, before any code is written. App name candidates with keyword research, subtitle variations, screenshot copy, the first three sets of keyword fields for Applyra to A/B against, a one-line pitch for Product Hunt. The app build and the marketing build run more or less in parallel.

Marketing also has its own tooling now. While migrating dragosroua.com from WordPress to Astro I built a small set of Claude Code skills for content work — an SEO metadata batch updater, a CTA injector with placement strategies, and a link analyzer that finds orphan pages. They’re open-sourced.

The point isn’t those specific skills; it’s the principle: the same discipline and approach that ships apps also ships the marketing infrastructure around them. Skills, prompts, and scaffolds for content, ASO, and distribution belong alongside the genesis prompt, not after it.

The senior-developer instinct is to build the thing well and let it speak for itself. With the build time compressed (and going asymptotically to zero, for everyone), that instinct produces apps with no downloads. The scarcer resource is not coding anymore, it’s attention. So, marketing counts.

6. Treat Every App as an Experiment

This portfolio approach – or, as I call it, an “ecosystem of apps” – tends to work if you stay light enough to move on when an app doesn’t produce any meaningful result, basically treating it as an experiment, not as the final product.

In my case, monthly revenue is concentrated in two, three apps: Zen Tales, addTaskManager, MosquiGo. The others earn a few dollars per month, each. If I had focused just on a single one, it would be really just about luck. Hit and miss. But treating each as an experiment gives back very good data every week — about ASO, monetization, category dynamics, and which features users actually pay for. That keeps me lean, and I can pivot to something better very fast.

The right metabolism for senior developers doing vibe coding work is: ship fast, measure honestly, and be ready to either double down or walk away on each app independently. The AI lowered the cost of building, so the cost of abandoning a project dropped too.

My 10 Apps and What Each One Required

Here’s the actual lineup from this 4-month sprint, with the specific coding challenge each one forced me to solve.

addTaskManager — productivity built on the ADD framework. Challenge: CloudKit sync across iOS, iPad, and Mac; a realm-state machine that gates UI based on which mode the user is in, and the Zen Status feature: inferring user’s mental state from the actual data in the app. This is the one app I already had, the vibe coding sprint involved mostly adding features like import from other apps

MosquiGo — ultrasonic mosquito deterrent. Challenge: a frequency engine that runs reliably in the background under AVAudioSession constraints, plus anti-habituation patterns so the sound stays effective over hours of use.

AI Kiddo First Words — kids’ first words in 8 languages. Challenge: full localization including Japanese and Korean, child-safe Text-to-Speech routing, and a UI simple enough that a one year old will actually use it.

Zen Tales — Buddhist stories with AI reflection. Challenge: Text-to-Speech generation stories without bloating the app size, real-time AI reflection with careful cost control, while keeping the UI extra simple

Just 5 Words — pick 5 words, get an AI story and image. Challenge: fully on-device generation via Apple Intelligence Writing Tools and Image Playground. No backend, no API key, no network round-trip.

Light Njoy — your iPhone as an ambient lamp. Challenge: five distinct rendering layouts (aurora bands, radial pulses, liquid meatballs, full glow, grid), AI-generated color palettes from natural language, breath-sync haptics, and a custom .njoy file format for sharing lighting sequences.

Hacking Habits — financial resilience habits, companion to my Gravitational Habits ebook. Challenge: a habit-graph data model, integration with the existing Hacking Habits hub on dragosroua.com, and ADD-driven user flows.

Flight Lens — AI-powered flight intelligence. Challenge: Aviation API global polling, the Pulse anomaly index calculation, Apple Intelligence summarization of flight events, and Travelpayouts integration.

999 Wise Quotes — premium wisdom app, sibling to Zen Tales. Challenge: curating ~999 copyright-clean quotes with primary-source attribution as the Scholar tier moat, three AI actions per quote, same Text-to-Speech challenges as in Zen Tales.

Shape Walk — gamified GPS walking app. Challenge: real-time location tracking with low battery overhead, a shape-matching algorithm that grades how closely a walked path traces a target shape, MapKit overlays, and background location handling.
Different categories, different stacks, different monetization paths. But all built following the guidelines above.

Closing Thoughts

These are my notes from a specific four-month sprint. I’m not sure if it qualifies as a final method. The model landscape will change for sure. The tooling will change. Some of these guidelines may be obsolete by the end of the year.

But I hope this 6-point approach will survive:

writing tight specs
two-model setup (main + backup/verifier)
mental modes management (ADD)
heavy verification
marketing early (or in parallel)
every app is an experiment

If you’re a senior developer thinking about doing something similar, my take is the work hasn’t gotten easier — it just moved. The value you add now sits in the spec, the verification, and the distribution, which is where most of us were not very experienced to begin with.

That’s the honest summary of vibe coding for senior developers practice four months in: same craft, different shape.

Can LLMs Really Understand How You Think? (Spoiler: No, But It Doesn’t Matter)

Dragos Roua — Mon, 24 Nov 2025 08:25:11 +0000

A few years ago I created a a framework called Assess-Decide-Do (ADD) to map how humans actually move through work—evaluating options, committing to decisions, executing tasks. Just three realms, with the goal of keeping a constant flow between them.

Last week I integrated it into Claude as an “operating system” layer.

What Changed

The LLM now tracks which cognitive phase I’m in. I can ask “Where are we in ADD?” and get: “Currently executing in Do.” For Claude Code users, there’s a persistent status bar:

[ADD Flow: 🔴 Assess | Exploring implementation options]

It updates automatically as the model detects behavioral shifts. At session end, you get a recap: realm transitions, time distribution, overall flow assessment.

Does the AI Actually Understand Me?

No. And this distinction matters more than it might seem.

LLMs predict plausible tokens. They don’t model your goals, don’t track your intentions, don’t “get” you. They have no orientation, no internal map of what you’re trying to accomplish. When Claude responds helpfully, it’s just navigating its probability space, not understanding.

The ADD mega-prompt doesn’t change this fundamental limitation. What it does is give the model a structure to pattern-match against. When I write exploratory, open-ended language, the model recognizes Assess patterns. When I shift to definitive, commitment-oriented language, it detects Decide. Action-focused, sequential language signals Do.

The model isn’t understanding my cognitive state. It’s mirroring it back through language recognition—which, it turns out, is exactly what LLMs are good at.

But Mirroring Might Be Enough

Here’s the surprise: the support we get from accurate mirroring is remarkably close to what we’d want from actual understanding.

When I’m in Assess mode—evaluating, brainstorming, daydreaming—the model doesn’t push me toward premature decisions. It recognizes the linguistic patterns of exploration and stays in that space with me. No friction. No “so what’s your conclusion?” pressure.

That permission alone changes the interaction quality dramatically.

After a week of 6-7 hour daily sessions, I create more. I stay in flow longer. I feel more relaxed. Not because Claude “gets” me, but because the tool responds appropriately to my current mental state based purely on how I’m expressing myself.

We don’t need AI consciousness. We need AI that fits our cognition. Language-based mirroring delivers that fit without requiring the impossible.

Human Amplification versus Human Replacement

We can frame AI as human replacement—matching creativity, autonomy, maybe consciousness—or as amplification: leveraging knowledge while remaining fundamentally a tool.

I’m betting on amplification. Not because it’s philosophically satisfying, but because it’s working right now. The ADD integration proves you can get meaningful cognitive support from pure pattern-matching. No understanding required.

World models might change everything. Prominent voices are calling the end of the LLM era. Maybe. But “right around the corner” has a way of staying around the corner, and I’d rather build with what works today.

Miscellaneous (but maybe useful) stuff

I’ve been building things on the internet since the late 90s—coded, launched companies, wrote over a million words on productivity. The ADD framework came from decades of noticing how I actually work versus how productivity systems told me to work.
The integration works with Claude, Gemini, Grok, and Kimi (Claude’s implementation is most refined). Mega-prompt and setup instructions: 👉 GitHub repo
If you want to go deeper than the mega-prompt, I built addTaskManager, an iOS app implementing ADD as a full task management system.
For the philosophical foundations behind ADD—why three realms, how they map to cognitive states, the theory underneath—I write about this on my blog: 👉 dragosroua.com

When you remove the friction between your thinking and your tools, what changes? I’m curious what this community’s experience is—whether you’ve tried cognitive frameworks with LLMs, or built your own approaches. Let’s discuss in the comments.