DEV Community: nebulakes

My Wise Buddy and I #2: Deciding Less, Twice

nebulakes — Sun, 02 Aug 2026 21:59:14 +0000

My Wise Buddy and I #2: Deciding Less, Twice

I have an ordinary office job in the food industry — mostly planning work, no engineering — and I build this AI project in the hours around it. I watched AI from the stands for three years and only opened a terminal for the first time this year. This is the week I found out that my main contribution to my own project had quietly become: being the bottleneck.

The sentence I had been reading wrong

"The human is the bottleneck." I'd read that line many times and, honestly, took it as a complaint shaped like a compliment. Look how much depends on me.

Then I looked at where my hours actually went. Reading long AI answers closely. Then either approving something I didn't fully understand, or asking a follow-up question that produced another long answer to read closely. I wasn't steering anything. I was proofreading.

The thing that clicked: "the human is the bottleneck" is a diagnosis, not a prescription. Removing myself isn't the fix, and neither is reading faster. The fix is to split decisions into two piles.

Pile 1 — only I can answer this. What problem are we solving. What is the goal. What counts as success, and how do we verify it. Who reviews. Where is the irreversible boundary — the thing that must never happen without me. These deserve dense, slow conversation, and they deserve it early.

Pile 2 — everything derived from pile 1. Usually in a domain I don't know, and usually with no meaningful effect on the outcome. The AI decides, proceeds, and records what it decided.

Naming the two piles took ten minutes. The hard part is that the border between them drifts — always toward pile 1, because asking me feels safe to the model and feels like control to me. So the border needed its own supervision. Two reviewers:

An autonomy gate. Given the plan as it stands right now, is it safe to run without a human in the loop? Pass, and the autonomous stretch begins.
A conversation-depth check. In the conversation stretch, is the AI asking me things it could have decided itself, or looked up in a file? Is it escalating detail that doesn't need me?

I turned this into a global rule the same day. Its shape:

Two axes for every decision point: risk (if this is wrong, is the final effect irreversible?) and authority/information (does this need something only I know, or something only I can authorize?).
Four routes out of that judgment: AI decides / verify against source material / ask the human / safe stop. The fourth is the one I keep forgetting exists — low confidence plus high impact means stop and report, not guess and proceed.
Two phases: an agreement phase, then an autonomous phase, with the gate between them.
A calibration loop, which is the part I'm least likely to have gotten right on my own, because it doesn't trust my judgment about my judgment. The border isn't set by feel; it's moved by two measured rates. Autonomous-reversal rate: how often I overturn decisions the AI made alone — high means pull that area back into conversation. Unnecessary-question rate: how often it asked me something it could have resolved — high means push that area toward autonomy.

A second idea fell out of the same morning: three notes per project. A fact note (what is true, with sources). A decision note (why we chose this, and — the field that matters — who decided: me, or the AI alone, plus a later verdict: held, overturned, discarded). A prompt note (the history of the conversation). Counting "decisions the AI made" tells you nothing useful. Decisions the AI made × later overturned gives you a concrete signal about where to review or narrow autonomy.

Then I built the whole thing twice

Here's the uncomfortable part. That rule was written by the session I'd been working in all morning — the one that had watched every mess that produced the idea. Which is precisely the session you should not let grade its own homework.

So that afternoon I handed the same prompt to a fresh top-tier session with no context at all. Clean room. Then I put the two versions side by side and merged them.

I expected one to win. Instead, reading both, what I found split by layer.

In this comparison, the context-holding session was stronger on the core. The precision of the gate's pass conditions. The data model — including that decision-maker taxonomy. The hygiene rules about what not to copy where. It reads like it was written by someone who had been burned in specific places, because it was.

The clean-room version added instrumentation, enforcement, and automation — four things the other version simply didn't have. A written contract that makes each gate judgment auditable as a document diff. The quantitative calibration loop (those two rates). A JSONL export turning the decision log into training material. A reminder hook that fires right before the AI asks me a question.

Look at that list again. The clean room built the machinery that measures whether the rule works. The session that invented the rule couldn't see that gap — it was the rule. Skin in the game buys precision and charges you perspective.

Final version: the context session's core, plus the clean room's instrumentation layer.

If you'd rather read the thing than my description of it, the merged pack is public: BehindTheBuild — the two rules, the gate checklist, the contract template, the reminder hook, and appendix/COMPARISON.md, which is the actual scorecard between the two versions. Fair warning: I work in Korean, so the pack documents are Korean; the README summarizes each piece in English.

Was doing it twice a waste?

Cost: the same work twice, two contexts, one afternoon. Return: a hypothesis about which layer to trust from which condition — one I can now test on the next rule instead of guessing. So it's a working rule of thumb, not a law:

Draft the core in the session that lived through the problem.
Draft the measurement and enforcement in a session that has never seen it.
Merge them. Don't pick one.

None of this is a new idea. Separating the author from the reviewer is something every team already knows. What surprised me is that it applies to the tool, not just to people. I had assumed more context is strictly better. It isn't. Context is a lens — sharper in the middle, curved at the edges.

And the joke writes itself: I set out to make fewer decisions, and the immediate cost was two extra decisions about how to make fewer decisions. I'd take that trade again.

My Wise Buddy and I #1: Confessions of a Link Hoarder

nebulakes — Sun, 02 Aug 2026 13:58:44 +0000

My Wise Buddy and I #1: Confessions of a Link Hoarder

I'm an ordinary office worker in a decidedly non-tech industry. Not a developer — I don't write software for a living, or as a hobby, or at all. My relationship with code has always been like my relationship with the gym: deep respect, zero attendance.

But I've been quietly obsessed with AI since ChatGPT blew up in 2023. Not building anything — just following it, with the devotion of a sports fan who has never once touched the ball. Newsletters on the commute, social feeds over lunch, YouTube explainers at night. Three years of watching, from the stands, a field that moves faster than anything I've ever seen.

Then, this year, work gave me an unexpected reason to open a terminal: I got to try AI coding agents — Claude Code and Codex — on real tasks. That's when I discovered these tools have changed what someone like me can actually build. This was a dangerous discovery, and this series is about what I'm doing with it.

It begins, as all honest projects should, with an embarrassing confession.

The write-only archive

For years, my entire "knowledge system" has been a single Telegram chat. Just me, forwarding links to myself. A private museum of everything I ever meant to learn.

Every useful thing I found — a YouTube video on agent architectures, a prompt technique, a benchmark screenshot, an article on some new model — went into that one chat. Thousands of messages by now.

Number of times I went back and used any of it: approximately zero. The museum has no visitors. Including the owner.

You probably have a version of this. A bookmarks folder you never open. A watch-later list measured in days of runtime. A notes app with one giant note called "misc." Saving feels productive — every save prints a tiny receipt that says "I'm learning" — but nothing compounds. Information goes in; nothing comes back out.

I call it a write-only archive. And the failure isn't the collecting — collecting is easy, fun, and frankly I'm excellent at it. The failure is that collecting was the only step that ever ran.

What changed

The honest answer: capability, not motivation. Motivation was never the bottleneck — mine has been running at 100% for three years. It just spent all that energy collecting more links.

I always knew the fix in theory — organize the saves, distill them into notes, connect the notes, review them. Every productivity guru says the same thing. But as a manual process, on top of a full-time job, it's a diet plan: correct in every detail, and abandoned within two weeks.

Working with Claude Code and Codex showed me a different shape for the problem. These agents can read files, write files, run scripts, and follow written rules — reliably enough to matter. Which means the boring parts of a knowledge system (filing, formatting, summarizing, cross-linking) don't have to be my habits anymore. They can be someone's job. The someone doesn't have to be human — which is lucky, because the only human available has a well-documented track record.

So the project is not "become more disciplined." Three years of evidence says how that one ends. The project is: build a system where AI agents run the pipeline, and I only do the parts that need my judgment.

Meet WIBBY

I named it WIBBY — short for Wise Buddy. Yes, I gave it a name. If you're going to talk to a thing every day, it deserves one — and it changes the relationship: WIBBY isn't software I use, it's a colleague I delegate to. A colleague who works nights, never sighs, and has seen the state of my Telegram chat and stayed anyway.

WIBBY is not an app I'm going to sell. It's a personal knowledge operation with three components:

Plain markdown files as the single source of truth — an Obsidian vault, organized so both a human and an AI can navigate it
AI agents that operate the pipeline — capture, file, distill, connect, resurface
Me as the audit layer — the agents draft, I spot-check samples and decide what ships

The pipeline WIBBY needs to run, sketched at the altitude I understand it today:

Stage	What happens	Who does it
Capture	Saves land in one inbox (yes, Telegram stays — it's where my habit already lives)	Bot
Organize	Each item gets filed into the vault with metadata	Agent
Distill	Long raw saves become short atomic notes in my own words	Agent saves a draft; I spot-check samples afterward
Connect	New notes get linked to related existing notes	Agent proposes
Surface	The system brings things back — briefings, resurfaced ideas	Agent

That last row is the whole point. A knowledge system that never brings anything back is just a write-only archive with nicer furniture.

Three rules I'm starting with

Files over apps. Everything lives in plain markdown on my disk. AI agents are shockingly good at grepping and editing text files, and no vendor can take the vault away from me. Apps come and go; a folder of .md files has no opinion about anyone's business model.
AI operates, human approves. I don't want to do the filing, but I also don't want an AI quietly rewriting my notes while I sleep. The default split: agents handle mechanical steps autonomously, and anything that changes meaning lands as a draft that I audit — a random sample every week, not every note. Trust, but verify — especially when the thing you're trusting types faster than you read.
It must survive neglect. I have a job. Some weeks I'll have zero spare hours, and the system has to keep running — or at least fail loudly — without me. This rule has already earned its place: after a reboot, a Windows Task Scheduler default silently kept part of this stack from coming back, and I only noticed by accident. I wrote that postmortem here. Nothing teaches you the value of "failing loudly" like a system that fails in perfect, dignified silence.

Where this series is going

The plan, loosely: get WIBBY working as a real assistant first — capture to surfacing, running daily on spare-time maintenance. Then push further. My long-shot ambition is to grow this from a personal assistant into something closer to a one-person AI operation — but that's a later chapter, and I'd rather show it than promise it. The internet already has enough grand plans from people whose main asset is a Telegram chat full of links.

If you've ever hoarded knowledge you never used, follow along. This series is me finding out how far an ordinary office worker can get — with a wise buddy doing the heavy lifting.

I booted my laptop after six days away — and Windows Task Scheduler silently refused to revive my AI agent

nebulakes — Fri, 17 Jul 2026 02:36:59 +0000

I booted my laptop after six days away — and Windows Task Scheduler silently refused to revive my AI agent

I run a small personal automation stack on a Windows laptop: a Telegram gateway that captures notes into my knowledge base (the "AI agent" of the title), a nightly batch job, a morning briefing job, and a handful of maintenance tasks. All of them are registered in Windows Task Scheduler.

Work kept me away from this laptop for six days — it sat powered off the whole time. When I finally booted it, I expected the stack to come back up on its own. Instead, the capture bot stayed silent. No crash dump, no error notification, nothing in my own logs. The service hadn't failed — it had simply never been started.

The investigation

Task Scheduler's history showed the launch attempts ending with result code 0x800710E0:

The operator or administrator has refused the request.

That message is spectacularly unhelpful. Nobody had refused anything — I'm the only operator, and I never touched those tasks. It's also a generic code (ERROR_REQUEST_REFUSED), so it doesn't point at any specific condition by itself.

In my case, comparing the task's power conditions against the laptop's battery state gave the answer: the task's own conditions were refusing the launch. And the condition responsible was one I had never consciously set.

The root cause: two defaults nobody reads

When you register a scheduled task — whether through the GUI or PowerShell's Register-ScheduledTask — two settings default to the conservative option:

Setting	Default	Effect
`DisallowStartIfOnBatteries`	`True`	Task will not start while on battery power
`StopIfGoingOnBatteries`	`True`	Running task is killed when AC power is unplugged

These defaults make sense for the original use case: heavy maintenance jobs on office PCs, where you don't want a defrag draining someone's battery.

They make no sense for a laptop that hosts resident services. When I booted mine, it was running on battery — as a laptop usually is when you open it away from a desk. Every scheduled launch was being refused, and no amount of waiting would have changed that: a task whose start condition is never met stays dead indefinitely. Eight of my tasks were in this state — the gateway, the nightly batch, the morning briefing, all of them.

The worst property of this failure mode is the silence. Your own application logs show nothing, because your application never ran. Unless you routinely open Task Scheduler's history pane (who does?), the first signal is a user noticing that something has been dead for days.

The fix

Change the two properties on the existing settings object and save it back:

$task = Get-ScheduledTask -TaskName "my-resident-service"
$task.Settings.DisallowStartIfOnBatteries = $false
$task.Settings.StopIfGoingOnBatteries = $false
Set-ScheduledTask -InputObject $task

A tempting shortcut — building a fresh settings object with New-ScheduledTaskSettingsSet and passing it to Set-ScheduledTask -Settings — is a trap of its own: it replaces the task's entire settings block, silently resetting anything else you had configured (restart policy, execution time limit, StartWhenAvailable, …) back to defaults. Patch the existing object instead.

Note the awkward naming: the properties are negative (DisallowStartIfOnBatteries), so the fix sets them to $false. Double negatives are a great way to misread an audit, so verify after applying:

(Get-ScheduledTask -TaskName "my-resident-service").Settings |
    Select-Object DisallowStartIfOnBatteries, StopIfGoingOnBatteries
# Both should now be False

I applied this to all eight tasks. The next morning, the overnight batch and the morning briefing both ran with exit code 0 — on battery.

One honest caveat: these flags remove the task-level power gate. Windows Battery Saver and idle conditions can still defer some scheduled work, so "flags cleared" is necessary but not a blanket guarantee.

Lessons for anyone running resident services on a laptop

Registration-time checklist, not memory. Any task that must survive on a laptop needs the two battery flags cleared at registration time. I added this to the checklist my automation follows whenever it registers a new task, because I will forget, and so will you.
Silent failures need an independent heartbeat. The service can't report its own absence. Something outside the scheduled task should verify liveness — a check on the log file's last-modified time, a ping to a dead-man's-switch, anything that turns "dead indefinitely" into "noticed within a day."
Scope your fix to the actual failure. These two flags only control start/stop on battery. They do not wake a sleeping machine — -WakeToRun wakes the machine at trigger time, and -StartWhenAvailable handles a missed trigger after it wakes; sleeping through a trigger is a different failure I haven't addressed yet. Knowing precisely what you fixed keeps you from false confidence.
This is a mostly-Windows trap. cron has no built-in power-source gate, and systemd doesn't apply one by default (a unit can opt in via ConditionACPower=). If you're porting automation habits from Linux to a Windows laptop, this class of failure won't be on your radar — it wasn't on mine.

To be fair about the damage: the six-day capture gap was my own doing — the laptop was off, and a backfill I'd built recovered the missed messages from the source. What the flags added was worse in kind: an outage that would have lasted indefinitely after boot, with no error surfaced anywhere, on a machine I believed had come back to life. Diagnosis took about an hour; the fix took two minutes. That ratio — a silent, open-ended failure versus minutes of prevention — is exactly why default settings deserve a place in your threat model.