DEV Community: Diana Novas

Why Vibe Coders Burn Token Limits (And How We Run AI Agents at 10x Speed)

Diana Novas — Tue, 03 Nov 2026 06:44:46 +0000

Every week in developer chats, I see the exact same complaint. People who got hooked on vibe coding complain that they run out of token limits even on the most expensive tiers, so they end up paying for two or three AI subscriptions at once. Their workflow for working with AI coding agents always sounds identical: "I dropped a prompt, the agent is building something, I'll go grab coffee and check on it later."

As a developer with 15 years of experience, I find that approach naive. I pay $200 a month for the Gemini Ultra plan. I work with models and agents every single day across multiple active projects in parallel, yet I have never once hit my usage ceiling. By the end of each week, I still have more than 50% of my weekly quota untouched, even though I ship code five to ten times faster than when I wrote everything by hand.

The secret is simple. In my baseline workflow, a model almost never writes code blind for more than 10 minutes at a time.

Why Unprepared Long Autonomous Sessions Burn Tokens for Nothing

When someone without an engineering background asks a model out of the gate to "build the whole service" or "analyze user reviews and fix everything," the model starts wandering. It reads irrelevant files, guesses at intent, trips over its own bugs, tries to patch around them, and burns hundreds of thousands of tokens in half an hour rewriting the exact same module in circles.

Of course, you can let an agent run autonomously for much longer than 10 minutes. But to do that safely, you have to dissect the task first: document every edge case, break the work into explicit subtasks, and equip the agent with clear skills and instructions defining how it should act and make decisions in each scenario.

It works just like running a company. If you hire 30 employees, toss a vague goal at them, and walk away leaving the business to run itself, nothing good will come of it. That is almost guaranteed. On the other hand, if you give every person clear playbooks and operating rules, verify that they actually understood them, and set up clean processes, you need far less day-to-day micromanagement. More importantly, your team makes far fewer mistakes that cost the company real money.

Working with AI coding agents produces predictable results only when you build on that operational foundation and understand how the system fits together.

An experienced engineer follows a specific order of operations. First, you design the database schema and domain entities. Or you work in the opposite direction: define the domain entities and their relationships first, and then design the tables and indexes around them. Only after that foundation is locked in do you layer the business service logic on top.

I do not think vibe-coded scripts are always terrible or useless. Most of the time, they solve the user's immediate problem. Modern models can even audit security and code quality well if you ask them to run a review. The real trap for vibe coders lies elsewhere: without an engineering foundation, you simply do not know which questions to ask the model or where the system will crack under real load.

A founder today can easily assemble a working prototype alone. That is great for testing a business hypothesis. Still, once the product attracts paying customers and real revenue, the business will need a technical specialist. Someone has to take responsibility for the architecture and data integrity, regardless of whether a human programmer or a cloud neural network typed the original lines of code.

Treating AI Agents Like a Real Dev Team: Rules, Skills, and Checkpoints

Just a year ago, I could still read every single line of code a model produced. Today, at current development speeds, reviewing every line by eye is physically exhausting. The role of a senior engineer has shifted: you act as an orchestrator who directs agents, runs fast visual architecture checks, and automates verification.

If you watch how modern frontier models like Gemini, Claude, or OpenAI reason through a problem, they behave remarkably like human developers. Six months ago, you had to constantly clean up small bugs behind them, and their UI layouts regularly broke margins and alignment. Today, they assemble visual layouts cleanly and reason at the level of a solid mid-level developer. I no longer spend hours digging through unfamiliar API docs or writing glue code by hand because AI handles that routine work.

Still, no team of mid-level developers will ship a reliable system without engineering standards. The exact same rule applies to agents. They need strict guidelines, documented workflows, and specialized skill files for each domain.

To avoid cleaning up mountains of throwaway code later, I run everything through checkpoints, the same way I have always worked with junior and mid-level engineers:

First, we break the task down into short, concrete stages together.
I set a strict gate: "Draft the architecture plan first and send it to me for review. If anything in the logic looks ambiguous, do not guess. Ask me questions first."
Only after we agree on the blueprint does the agent get the green light for a focused 10-minute coding sprint.

The Two Classic Traps of Modern Models: Over-Engineering and Quick Band-Aids

Even the newest models fall into one of two extremes when you loosen the reins.

The first extreme is trying to anticipate everything under the sun. The model starts piling up complex abstractions and guarding against dozens of hypothetical edge cases that will never happen in production. A simple feature quickly drowns in unnecessary layers.

The second extreme comes from lazy prompting. If you tell a model to "just fix this real quick," it will dutifully hand you a superficial band-aid that hides the symptom while breaking the broader project structure. Conversely, if you state upfront that the solution needs to run reliably for years and respect the existing system architecture, the model produces clean, well-structured code.

That is why I keep an eye on the agent's reasoning trace during those short 10-minute sprints. The moment I see its train of thought veer off course, I stop generation, clarify where the root cause actually lives, and restart the step. That habit saves both hours and tokens.

Why I Moved to a Dual-Mac Setup for Running AI Agents

Adopting this engineer-plus-agents workflow at NovaSynapse gave our small studio the leverage to compete head-to-head in speed and quality with much larger companies. At the same time, working with autonomous agents every day quickly changed my physical desk setup too.

I now work across two Macs full-time. The primary reason is security: I want strict physical isolation so my personal data, private chats, and sensitive credentials never intersect with the environment that AI agents can access. Having a second machine also makes it effortless to offload autonomous agent tasks and heavy background jobs while I focus on architecture on my main MacBook.

At first, jumping between two machines slowed me down. Apple's built-in screen sharing requires both Macs to be signed into the exact same Apple ID, which immediately defeats the purpose of an isolated work environment. Third-party remote desktop tools introduced noticeable input lag, refused to scale cleanly to full screen on smaller displays, swallowed system keyboard shortcuts, and left both computers without a shared clipboard.

To fix those bottlenecks for our own daily work, we built a native macOS utility called MultiMac, which we later released as a standalone product. It links two Macs running different Apple IDs into a unified workspace with true full-screen mode, shared clipboard, and instant hotkey passthrough without touching private data. My second Mac now feels like a direct physical extension of my main MacBook, roughly doubling my daily speed when orchestrating agents.

Frequently Asked Questions About Working with AI Coding Agents

Will vibe coding replace professional software engineers in the next few years?

Prompts alone are already enough to spin up simple prototypes and validate ideas quickly. However, any production system serving real customers and handling real money still requires an engineer who can design the database schema, structure the service layer, and take accountability for system reliability.

How do you stop burning through token limits on cloud AI models?

Stop running long, unprepared sessions where an agent spends half an hour guessing in the dark. Either work in 10-minute iterations with an architecture review gate, or thoroughly decompose the task into subtasks with explicit decision-making skills before launching a longer autonomous run.

How I Built a 4MB iOS App Blocker to Stop Doomscrolling

Diana Novas — Tue, 15 Sep 2026 04:50:08 +0000

The story of how fighting dopamine loops led to building Scroll Brake, why popular competitors demand suspicious permissions, and how to conquer hidden traps in Apple's Screen Time APIs.

Why I Needed an App Blocker in the First Place

I am obsessive about personal productivity. Over the years, I've developed my own system for managing time and daily energy that keeps my schedule structured and gets hard engineering projects shipped.

Yet there are moments when you just pick up your phone on autopilot and start doomscrolling Reels. One short video, a second, a third — the algorithm serves up an endless stream of engaging clips. You thought you were taking a two-minute breather, and suddenly 40 minutes or a full hour has evaporated. Social media algorithms are designed by top engineers to capture human attention at any cost. Each swipe feels slightly more rewarding than the last, trapping your brain in an infinite dopamine loop.

I had zero intention of writing my own app. As a software engineer and founder, my time is scarce, and I prefer using proven off-the-shelf tools. So I went straight to the App Store.

What's Broken with Modern App Blockers

I tested the category leaders — Opal, OneSec, ScreenZen, Refocus, alongside Apple's built-in Screen Time. Almost immediately, I ran into architectural and design patterns that left me bewildered:

The Notification and Privacy Paradox

The very first thing almost all these apps do is ask for push notification and analytics permissions. Why would a tool designed to keep me off my phone need to wake up my display with notifications? As it turned out later while building the app, this wasn't greed—it was an old system constraint in iOS that I'll break down below in the technical section.

Aggressive Paywall Walls

Before you even see the main interface or verify whether the tool solves your problem, you get hit with an aggressive subscription screen. It comes wrapped in a "free trial" clearly designed around the hope that users forget to cancel. As an entrepreneur, I understand the conversion math; as a user, I dislike dark patterns.

The Ineffectiveness of Apple's Default Screen Time

Apple's native Screen Time fails on human psychology. When the standard system overlay pops up, your thumb reflexively taps "Ignore Limit for 15 minutes". There is zero cognitive friction — the action happens entirely on muscle memory.

I had no desire to audit dozens of clones with identical paywalls. I realized building a lightweight, native tool for myself would be both faster and more honest.

Scroll Brake Principles: 4MB, No Trackers, No Subscriptions

At NovaSynapse, we follow the principle “Everything you need. Nothing you don’t.” Software should solve the problem, conserve battery, and respect user boundaries.

That's how Scroll Brake was born:

~4 MB install size: No bloated cross-platform runtimes, no web views, zero third-party tracking SDKs.
100% Privacy-First: No accounts, no database, no remote servers. Everything executes locally on-device using native iOS APIs.
Cognitive friction over brute-force bans: To extend time in social apps, you must engage your prefrontal cortex — by solving a quick math puzzle. That single second of friction shatters autopilot.
Anti-dopamine UX over gamification: After solving the puzzle correctly, I deliberately don't show confetti, fireworks, or congratulatory messages. Feeding the brain cheap dopamine for unlocking social media is absurd. The screen is intentionally kept as boring and quiet as possible: the timer is unlocked, and returning relies on the standard iOS back breadcrumb in the top-left corner (by design, iOS privacy protects which specific app triggered the shield, so the host app cannot auto-redirect you).
Monetization: Up to 3 rules are completely free (I only use one myself: the "Social Networks" category capped at 5 minutes a day). For anyone needing more rules, I added a one-time Lifetime purchase instead of forced subscriptions.

The 4-Day Build Story: AI & Xcode Tools

I built the app with AI using Antigravity and Gemini models (3.1 Pro and Flash).

I've tinkered with mobile development before—building with Flutter and exploring native iOS—but that was before AI coding assistants became widespread. With AI, assembling a focused, lightweight app moved remarkably fast. You still can't just blindly accept generated code: Apple's system extensions are notoriously brittle, so I reviewed every line myself to prevent crashes and memory leaks. But overall, the build went smoothly, taking just 3–4 working days including manual testing on physical devices and older iOS versions:

Icon in 15 minutes: Instead of manually exporting dozens of PNG layers, I used Xcode's Icon Composer developer tool. Vector layers automatically adapt to light, dark, and tinted iOS themes.
App Store Review in < 24 hours: Because the app has zero tracking SDKs and requests no private user data, Apple approved the build for the App Store the very next day.

Engineering Deep-Dive: Hidden Traps in Apple's Screen Time API

Now for the technical meat — working with the trio of ManagedSettings, DeviceActivity, and FamilyControls. If you build an app using Apple's Screen Time API, you will inevitably hit three architectural walls. Here is how I solved them:

Why Competitors Demand Push Notifications (iOS < 26.5 vs iOS 26.5+)

Users frequently complain about app blockers spamming notifications, but developers were long trapped by Apple's extension sandbox.

The Legacy Constraint: When an app is blocked, the system displays the protective overlay — ShieldActionExtension. The user taps an action button like "Extend". But this extension runs in a restricted sandbox where calling UIApplication.shared.open is strictly forbidden at both the compiler and system level. The ShieldActionResponse enum historically only supported .close, .defer, and .none. It was impossible to open the host app directly to present a code or puzzle!
The Industry Hack: The only workaround was firing a local push notification (UNUserNotificationCenter). The user had to pull down Notification Center or tap the banner to open the app. That is precisely why almost every competing blocker requests notification permissions.
My Native Fix in iOS 26.5+: Apple finally added the native response case ShieldActionResponse.openParentalControlsApp. When returned, the system immediately launches the main host app directly to the math puzzle view (MathPuzzleView):

  // ShieldActionExtension.swift
  defaults?.set(true, forKey: "launchedFromShieldAction")
  completionHandler(.openParentalControlsApp)

By targeting iOS 26.5+ as our deployment baseline (IPHONEOS_DEPLOYMENT_TARGET = 26.5), I eliminated push notification hacks entirely.

The Sandbox Ban on Direct Usage Analytics

I frequently get asked: "Why doesn't the app show minute-by-minute app charts in custom analytics?"

The answer: Apple architecturally isolates Screen Time data from the host app.

Access to the DeviceActivityResults array is granted exclusively to DeviceActivityReportExtension, which runs in an isolated system process.
The host app embeds only a visual container view, DeviceActivityReport. It renders out-of-process and projects the rendered view into your app's UI.
Data never leaves the extension sandbox — host apps cannot write this data to SQLite, serialize it into arrays, or transmit it over the network.

Apple's documentation is explicit:

"To protect user privacy, the DeviceActivityReport extension runs in a sandbox, and its data doesn’t leave the extension. Instead, the extension creates and returns views that your app displays."

— Apple Developer Documentation: DeviceActivityReport

Impact on Monitoring: Tracking limits through DeviceActivityCenter works strictly on a threshold subscription model (DeviceActivityEvent.threshold). The system notifies DeviceActivityMonitorExtension only when the threshold is reached (eventDidReachThreshold), without streaming any intermediate usage telemetry.
Why You Return via the Top-Left Breadcrumb: In iOS, host apps have zero access to the bundleIdentifier that triggered the shield. As a result, an app cannot programmatically jump the user back into Instagram or TikTok. You simply tap the system back breadcrumb in the top-left corner of the status bar.

Overcoming Hidden Screen Time API Bugs

During stress testing, I encountered subtle iOS platform bugs that can break any blocker:

Event Caching Bug in DeviceActivityCenter

The Bug: When updating the threshold for an existing DeviceActivityName (during an extension), iOS would fail to trigger on the new threshold.
The Fix: Generate a unique activity name containing a session token DeviceActivityName("limit_<UUID>_<sessionToken>") preceded by an explicit stopMonitoring() call.
Apple Documentation: DeviceActivityCenter.startMonitoring.

deviceActivityCenter.stopMonitoring([previousActivityName])
let newActivity = DeviceActivityName("limit_\(UUID().uuidString)_\(sessionToken)")
try deviceActivityCenter.startMonitoring(newActivity, during: schedule, events: events)

The Next-Day Reset Glitch (Dual-Event Schedule Pattern)

The Bug: If a DeviceActivitySchedule was configured with repeats: true and a user extended their time by 1 minute, the system would apply that same 1-minute threshold the following morning instead of resetting to the full daily limit.
The Fix: Register two distinct events in a single schedule:
1. mainEvent: the standard full daily limit for tomorrow.
2. extEvent: a temporary event with the current date embedded in its identifier, expiring at 23:59 tonight.

OOM Crashes (Code 11) in DeviceActivityReport

The Bug: Placing reactive timers (e.g. ticking second counters in SwiftUI) anywhere near a DeviceActivityReport hierarchy triggered continuous XPC re-evaluations of 7-day usage logs. This caused rapid memory leaks and an instant process termination by iOS with an Out-Of-Memory (OOM) code 11 error.
The Fix: Completely eliminate reactive timers in UI views displaying reports, lock report filter parameters without constant mutations, and refresh data strictly on lifecycle events (onAppear, willEnterForeground).

How I Configured It for Myself

Since launch, Scroll Brake has become my primary defense against fragmented attention.

My personal configuration:

1 Rule: "Social Networks" category blocked.
Base Limit: 5 minutes per day.
Extension: 5 minutes granted per solved math puzzle.
Hard Stop: Maximum 5 extensions per day.

I physically cannot spend more than 25 minutes a day inside social apps. More importantly, my brain knows: watching a shared video requires mental friction. That tiny barrier is enough, 8 times out of 10, to set the phone face-down and get back to real work.