DEV Community: Daniel Nwaneri

i used to think in code. now i think in prompts.

Daniel Nwaneri — Wed, 12 Aug 2026 07:57:25 +0000

used to have a habit of thinking in code. it'd be like walking down the street and immediately seeing what kind of code would make the next paragraph.

now it's thinking in prompts. half a recipe for making pasta is in the middle of my brain. i just need to make the prompt to add that.

i learned to code when i was a geophysicist with no computer science education. i was forced to read documentation. i built a lot. it took me years to realize that everyone who had a similar skill set was doing things that made it difficult to be effective. the world was full of idiots. now there are fewer idiots because of an LLM which knows everything. i'm pretty sure i wouldn't have thought it necessary to write code in the first place if someone could do it for me.

no one talks about how to preserve the skills that will make future generations smarter. we're getting worse at thinking deep and dealing with humans because our AI tools don't encourage it.

it's really shameful to think about the fact that now it's more efficient to think about things in terms of "prompt" rather than code.

but this isn't an anti-LLM post. i use it all the time to save time on writing. i'm optimistic that it'll help me be a better programmer. and i've been doing three hackathons at the same time, and i couldn't have done it using only one brain at 100% usage capacity. it makes life so much easier.

being behind is always an unpleasant feeling. i'm on the edge of a bug in the system:

it tells me what the bug is, and suggests a fix.

"what does it look like?" i ask.

the answer has too many technical details. most of them are correct, but i'm too far behind on context.

so i'll let it take care of it. it fixes the bug, commits the changes, and starts a pull request.

"wait a minute… is there a reason for this commit?"

"you're asking me a question before i even got started!"

"this isn't good. i'll check the git log…"

this sounds like an opportunity to build a mental model of what's happening. this is a perfect situation to be an agentless developer. but i can be busy with the next 10 threads. i'd lose a lot of time. maybe that's okay? let's see what the changes look like…

the changes aren't great. it's okay so far. wait a minute… i should double check this change…

oh. okay.

next thread.

this is how we get to where we are today…

i don't expect to switch back from thinking in prompts… i'm optimistic about LLMs! they are helping a lot of people do incredible things! i'm embarrassed that i'm still not doing some things that i can easily delegate with prompts.

OpenAI Just Solved a Problem Open Since 1999. It Still Can't Ask Its Own Question.

Daniel Nwaneri — Wed, 05 Aug 2026 11:39:46 +0000

Four days after I published a piece arguing LLMs can't make the jump, OpenAI announced that an internal model called Astra had solved ten open problems in mathematics and theoretical computer science. One of them had been open since 1999.

I'm not going to pretend that's a comfortable coincidence to sit with. So let's sit with it properly instead of pretending it didn't happen.

The headline result is a non-sofic group. Mikhail Gromov introduced the concept of soficity in 1999 and asked whether every countable group has to be sofic. Twenty-seven years, no mathematician managed to prove or disprove it. Astra built the counterexample. The certificate ships on GitHub in Lean 4, formally verified, "sorry" count zero — meaning no step in the proof was left unproven, no trust in OpenAI required. Total inference cost for all ten results combined: about $2,000.

Thomas Bloom, who curates the Erdős problems catalogue at Manchester, called it big news. Worth knowing: Bloom is the same mathematician who publicly dismantled an earlier false OpenAI math claim last October. His endorsement here isn't a company's own press release getting nodded along. It's the field's most skeptical reader saying this one holds.

So: extraordinary, verified, real. Now the question that actually matters for the piece I wrote.

Valerio Capraro, a mathematician who did his PhD on a problem adjacent to Gromov's conjecture, posted the sharpest version of the distinction I was reaching for and didn't quite land. Astra solved difficult problems inside existing conceptual worlds. Calculus, topology, scheme theory did something different — they didn't answer questions sitting inside a framework, they built frameworks new questions could be asked in.

Non-sofic groups existing or not was always a well-posed question inside group theory as it already stood. Astra found the object. It didn't invent group theory. That's the line: solving hard problems inside a conceptual world is not the same act as inventing the world.

Worth naming plainly, because it cuts the other way against overclaiming too: even a Lean certificate that type-checks doesn't confirm the formal statement actually captures the open problem the way mathematicians understood it. Someone still has to judge whether the formalization is asking the right question. That judgment is exactly the kind of move nobody automated here.

A commenter, Seo, pushed on something I'd been sloppy about. Is "the jump" one mechanism, or several? Einstein's move was importing an outside framework — he read Hume and Mach until he had the nerve to throw out absolute simultaneity. Dirac's move was different. He wasn't handed a wrong answer. Bohr told him Klein had already solved the relativistic electron problem. Dirac went and found a different one anyway, because Klein's didn't fit what he called his darling theory.

Importing something from outside the problem, and rejecting a correct-but-unsatisfying answer on the strength of your own priors, are not obviously the same action. I don't have a clean answer for whether they reduce to one mechanism. I'd rather leave that open than force it, because forcing it is exactly the kind of premature tidiness the whole piece is arguing against.

Here's where it stops being abstract. Sean Goedecke wrote about Terence Tao's public conversation with ChatGPT on a counterexample to the Jacobian Conjecture. Tao's messages are short. The model's outputs, talking to him, are unusually concise — expertise shunts it out of explaining-to-amateurs mode. He pushes back without contradicting directly: "this looks more complex than I was hoping for." And the detail that matters most: Tao makes the leaps himself. He almost never takes the model's suggested next move.

Goedecke's conclusion: the human is the bottleneck, not the model, because the hard part is communicating exactly what kind of solution you want. The information is already in the model. It takes a very smart human to pull it out.

That's my bookmark-time argument, relocated. I've been deciding what's worth saving since 2016, one bookmark at a time, and calling that curation. Tao is doing the same thing in real time, inside a chat window, calling it prompting. Different timescale, same move: supply the frame, let the model fill it.

So the thesis needs updating, not abandoning. Not "LLMs can't jump." Something narrower and, I think, more true. Inside closed, formally verifiable worlds — math, code, games, anything with a Lean checker or a compiler or a scoreboard — the jump is getting crackable by scale and search, and Astra just proved it faster than I expected. Outside those worlds, in anything ambiguous, causally tangled, unverifiable in advance, nobody's shown it yet. Not the actual Einstein case. Not the actual geophysics case. Not the actual "is this bookmark worth keeping" case. And the people getting the most out of these models, Tao included, are the ones still doing that part themselves.

I got four days. Most theses don't get tested this fast, or this publicly. I'd rather be corrected in the open than be right by accident.

dev.to's Dashboard Can't Count Its Own Posts

Daniel Nwaneri — Mon, 03 Aug 2026 07:38:53 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

forem is the open source platform behind dev.to itself. I've had it starred and cloned for months and never opened the codebase — it's Rails, and I don't write Ruby. Jess's post was the reason that finally changed.

github.com/forem/forem

Bug Fix or Performance Improvement

#23687 is a one-line report: a user published exactly one post, and the dashboard's "Posts" counter said 2.

Not writing Ruby meant I couldn't guess my way to the fix from vibes. I had to actually trace it — reading DashboardsController, the sidebar partials, and the Article model until the shape of the bug was undeniable, not assumed.

The "Posts" badge in the dashboard sidebar renders @user.articles_count — a counter_culture cache on User that increments for every Article row belonging to that user, full stop. No filter on type, no filter on state:

# app/models/article.rb
counter_culture :user

But the link that badge sits on always opens the same default view: DashboardsController#show with no params. That view only lists non-archived, full-post-type articles:

# app/controllers/dashboards_controller.rb
@articles = target.articles.from_subforem.includes(:organization)
@articles = params[:state] == "status" ? @articles.statuses : @articles.full_posts
@show_archived = params[:filter].to_s.casecmp("archived").zero?

Forem has three article types — full_post, status (a short "Boost" update), and fullscreen_embed — and the counter doesn't distinguish between them, or between archived and active. The badge counts everything. The list under it shows a strict subset. Anyone who's ever posted a status update, or archived a post, sees a number that doesn't match what they can actually click into and see — exactly what got reported in #23687.

I couldn't verify that in Ruby, but I recognized the shape of it instantly once it was laid out: a cached count drifting from what a filtered view actually renders. I've shipped that exact bug in JavaScript. Same failure, different syntax.

Code

github.com/forem/forem/pull/23690

The fix doesn't touch the shared articles_count counter — that cache is read elsewhere for badges and spam heuristics, where "every article this user has ever made" is the correct meaning. Instead, DashboardsController gets a helper scoped to match what the Posts tab actually renders, and both the full-page and AJAX sidebar actions use it instead of the raw cache:

# The "Posts" nav item always links to the default (non-archived, full posts
# only) view of the user's own dashboard, so its indicator should reflect
# that same scope rather than the user's raw articles_count, which also
# includes statuses and archived posts that never show up in that list.
def posts_count_for(user)
  user.articles.from_subforem.full_posts.where(archived: false).count
end

My Improvements

There was no way for me to eyeball this and trust it — I can't read Ruby well enough for that, and there's no Ruby or Postgres on the machine I was working from, so I couldn't run the spec suite locally either. Verification had to happen somewhere else: I wrote regression specs asserting a user with one full post, one status, and one archived post should see a count of exactly 1, pushed the branch, and let Forem's own CI be the judge instead of my own confidence.

CI caught something real on the first run — not in the fix, in my test. create(:article, type_of: "status") failed its own model validation, because status-type articles in Forem aren't allowed to have body markdown, and the factory's default does. I found the pattern already used elsewhere in the suite (body_markdown: "", main_image: nil), fixed the two specs, and pushed again.

That failure is the actual proof this wasn't guesswork dressed up as a fix. If I'd been able to run specs locally I might have caught it before pushing; instead the project's own CI did the job a local run would have.

Same lesson my other two entries kept landing on: The Cloudflare Worker That Ran Perfectly and Still Failed Twice and I Was Filming a Demo of My Monitoring Tool. The Monitor Wasn't Monitoring. — "it compiled" and "it's correct" are different claims, and only one of them is worth trusting.

Everything's green now — 19 successful checks, 1 skipped, 0 failures, including the shard that runs dashboard_spec.rb. The PR is open against forem/forem and waiting on a maintainer review, since third-party fork PRs need one before merge. Not merged yet as of writing this — I'd rather say that plainly than imply otherwise.

Different from my other two entries in one way: I don't write Ruby. Claude found the bug and wrote the fix. I picked the issue and gated everything that left my machine — the fork, the push, the PR, the CLA. Full delegation on the code, not on whether it shipped.

How BrowserAct Fixed the Stale-Selector Failures Breaking My Browser Tasks

Daniel Nwaneri — Fri, 31 Jul 2026 11:06:54 +0000

Disclosure: BrowserAct sponsored this piece. The BrowserAct links below are affiliate-tracked — I get credit if you sign up through them.

I keep hitting the same failure building agent workflows in Claude Code: the agent captures a selector once, the page re-renders with a new build hash, and the next run breaks on an element that's still right there on the screen — just under a different id. BrowserAct is a browser automation platform built for AI agents — real browser control, persistent browser identity, task sessions, verification handling, and human handoff, all behind one CLI. This test is about one narrow slice of that: how it handles a page whose ids and classes change under you, using Claude Code to drive it.

I tested that against a page I built myself, compared directly against raw Playwright.

The problem, concretely

Here's the shape of it. A frontend re-renders with fresh CSS-module or styled-components hashes on every deploy. You write:

const id = await page.locator("button").getAttribute("id");
await page.reload();
await page.locator(`#${id}`).click({ timeout: 3000 });

That works the day you write it. It breaks the next time the build hash changes, and the failure you get is a bare timeout with no explanation:

locator.click: Timeout 3000ms exceeded.

Playwright's own role/text locators fix this specific case — getByRole("button", { name: "Submit" }) survives id/class churn fine, because it never depended on the hash in the first place. That's a real fix, not a workaround. What it doesn't give you is a representation of the page an agent can reason about turn by turn, or a signal that says "the page under you just changed, stop and re-check." That's the gap BrowserAct is actually filling.

The interaction model

BrowserAct doesn't hand Claude Code a selector at all. The loop is: read the current state, choose an action from what's actually there, execute it, reassess.

state  -> indexed list of interactive elements, as of right now
click <index>  -> act on one of them
state  -> read again, because the page may have changed

The index is scoped to that one snapshot. It's not a selector, not a stable id — it's a pointer into "what state just returned," and it expires the moment the page does something a new state call would notice.

Setting up BrowserAct

uv tool install browser-act-cli --python 3.12
browser-act --version
browser-act browser create --name "dom-drift-test" --type chrome --desc "local churn test"
browser-act browser list

browser list after creation is how you get the browser id you'll pass to every session command — it's not returned anywhere else. I used the chrome browser type (a local, blank browser, immediate to create) rather than stealth, since this test is about selector churn on a page I control, not anti-bot evasion — stealth requires an API key and a billed purchase flow that has nothing to do with what I was testing. Creating a local chrome browser completed immediately with no purchase page involved.

Versions tested: browser-act-cli v1.1.0, Playwright 1.61.1, Python 3.12.13. To reproduce this: the test page is a small Node server that reshuffles element ids, classes, and order on every reload — no third-party site involved — plus the Playwright scripts run against the same page.

Skill source: browser-act/skills. Installation details: docs/installation.md.

browser-act --session domtest browser open <browser-id> http://localhost:8934
browser-act --session domtest state

state returns an indexed list, not a selector:

[1]<button class=item-r8k7gx invalid=false />
        Bravo
[2]<button class=item-cr2ajb invalid=false />
        Charlie
[5]<button id=submit-btn-ckeewz invalid=false />
        Submit

You act on the index (click 5), not the class or id, so the build-hash problem doesn't apply to it — there's no hash in the reference to go stale.

The actual comparison

I built a local test page that reshuffles element ids and item order on every reload, specifically to force this failure. Playwright's role locators, as noted above, survive that fine. The difference isn't that Playwright can't handle churn — it's what happens when you act on a reference that's gone stale anyway, whether from a captured selector or an old snapshot:

Playwright, selector captured once, reused after reload:

FAILED clicking #submit-btn-g9mpcm:
  locator.click: Timeout 3000ms exceeded.

BrowserAct, index captured once, reused after reload:

Error 210603: The snapshot belongs to a different page or tab than the
current one. Run 'browser-act state' again on the current page.

Both refuse to silently click the wrong thing. But BrowserAct's error names the exact cause and the exact fix — re-run state — where Playwright's is a generic timeout you already have to know how to interpret.

The recovery flow, actually run

That error is only useful if what follows it actually works. Here's the full loop, one continuous session, real output, no steps skipped — the error and the successful recovery from it, back to back:

browser-act --session shot1 browser open <browser-id> http://localhost:8934
browser-act --session shot1 state

[5]<button id=submit-btn-5zhwmn invalid=false />
        Submit
load 1

Page changes, and the old reference is used anyway — the error from earlier, live:

browser-act --session shot1 reload
browser-act --session shot1 click 5

Error 210603: The snapshot belongs to a different page or tab than the
current one. Run 'browser-act state' again on the current page.

Re-check, don't retry blind:

browser-act --session shot1 state

[5]<button id=submit-btn-c66evj invalid=false />
        Submit
load 3

The id changed (submit-btn-5zhwmn to submit-btn-c66evj), and the fresh state call caught it. Acting on the new index closes the loop:

browser-act --session shot1 click 5

clicked=5

State, act, hit the error, reassess, act again — completed, in the same session the error happened in.

What BrowserAct Actually Solved

It reduced my dependence on generated ids and CSS classes to zero for anything clickable, and gave Claude Code a predictable recovery path the moment the page changed underneath it: re-run state, act on what's actually there now.

Two real limits, not softened. state only indexes interactive elements — in my test, the list items only got indices once I made them buttons. For plain text or document content, the right tool isn't state at all, it's BrowserAct's content-extraction commands (get markdown, get text <index>) — treating state as a universal page parser is the wrong mental model. And separately: the title field in state's own output lagged behind the actual page content in one of my runs — the visible elements had already changed, title hadn't caught up yet. Worth knowing if you're tempted to key any check off title specifically.

One Check I Still Kept Explicit

BrowserAct solved the selector problem. It didn't remove the need to think about website authentication separately. Three different things are in play here, and it's worth naming them precisely: the browser identity (the chrome browser instance itself), the BrowserAct task session (--session domtest), and the target website's own authentication session.

In an earlier run against the same test page, the website authentication state expired while the BrowserAct task session remained active — state kept responding normally, it just started describing a "please sign in again" page instead of the dashboard. BrowserAct exposed that changed page state clearly enough for Claude Code to decide what to do next: continue, re-authenticate, or hand off to a human. It didn't decide that automatically, and I don't think it should — that's still a call I want made explicitly, not inferred.

Where this leaves it

Claude Code and BrowserAct solved the actual failure mode I set out to test: brittle selector maintenance replaced with a workflow built on current page state, indexed actions, and an explicit recovery step when the ground shifts. That's a narrower claim than "browser automation solved," and it's the one I can actually stand behind.

Try BrowserAct: browseract.ai/Daniel
BrowserAct Skills: github.com/browser-act/skills

(Both links above are affiliate-tracked to my account.)

Why Kimi K3 Still Can't Do What Einstein Did

Daniel Nwaneri — Wed, 29 Jul 2026 09:30:59 +0000

In geophysics you almost never get to see the thing you're studying. You get a seismic trace, a gravity anomaly, a resistivity curve. You don't get the rock. You get the rock's echo, and you have to guess at a structure underground that would produce exactly that echo and no other. Nobody hands you the answer key. You infer the case from the result.

I hadn't thought about that part of my degree in years, until I built Bookmark Brain.

Bookmark Brain is a RAG pipeline trained on my own X bookmarks and likes, saved since 2016. It was around 50,000 the last time I wrote about this. It's 70,000 now. Cron jobs pull in new saves on their own; there's no manual re-curation involved. Ask it something and it retrieves the closest matching saved content, then composes an answer that sounds like me. It works well. Too well, honestly. When I asked it about API design opinions, it sounded more like me than most general-purpose models do when I prompt them to write in my voice.

The reason isn't the model. It's the retrieval layer. My bookmarks are coherent because I spent a decade curating them into a specific worldview. The bot just finds the nearest neighbor and composes a fluent sentence around it. What it can't do is the thing I actually needed a few times while testing it: resolve a contradiction between two things I'd bookmarked years apart. It doesn't reconcile them. It picks whichever one is semantically closer to the question and hands that back.

That's not a bug in my pipeline. That's the whole category of thing retrieval can't do.

A 2014 blog post by Amni Rusli, "Irreplaceable Us," made roughly this same argument, minus the RAG pipeline. Machines work within given parameters, she wrote — feed them data and code and they'll optimize inside that space forever. What they can't do is leap into a different pond of parameters entirely and haul something back. She used Einstein and Dirac as her examples. Einstein reading Hume and Mach until he had the nerve to throw out absolute simultaneity. Dirac telling Bohr that Klein had already solved the relativistic electron problem and going looking for a different answer anyway, because the existing one didn't fit his "darling" theory.

Twelve years later, in January, Google DeepMind published a paper making the same claim with the informality stripped out. Tom Zahavy's "LLMs Can't Jump" starts from a diagram Einstein actually drew, in a letter to Maurice Solovine: sense experience jumping to a system of axioms, then deduction working forward from there. Peirce had a name for the gap in that jump, and the paper borrows it. Deduction: rule plus case gives you a result, the only mode that guarantees truth. Induction: case plus result gives you a rule, which is close to what training an LLM on a trillion documents actually is. Abduction: rule plus a surprising result gives you a new case, or a new rule, to explain it. That's the geophysics move. That's resolving the contradiction in my own bookmarks. That's the one nobody has automated.

The paper's argument for why scaling doesn't fix this is data scarcity. General relativity wasn't induced from a mountain of prior experimental results, because there wasn't one. The axioms can't have been deduced either, since deduction only runs forward from premises someone already has. Something else produced the premises. That something is the jump, and it's still missing.

Then Kimi K3 shipped. 2.8 trillion parameters, the largest open-weight model ever released, benchmarking close behind Fable 5 and GPT-5.6 Sol on coding and agentic tasks. Moonshot's own claim is 2.5x the intelligence per unit of compute over their last generation. None of that changes the argument. A bigger training set makes induction better and deduction more reliable over longer chains. It doesn't add a third capability that wasn't there before. Feed a model more of the internet and you get a more convincing compositor, not a different kind of thing.

I said this to a commenter under my original bot post, before I'd read the DeepMind paper: a model trained on Newtonian physics at sufficient scale would produce better Newtonian predictions, not special relativity. Turns out that's the whole thesis, just arrived at from a different direction — one from watching my own retrieval logs, one from a formal read of Peirce.

Which brings me back to my own bookmarks.

What actually happened at bookmark-time, every time I decided a tweet was worth saving, was a small version of the jump. This connects to that. This contradicts what I believed last year. Keep it. I've been doing that since 2016 — a decade of small jumps, one save at a time. Bookmark Brain inherited the residue of all of them. It never makes one itself.

That's the part that should worry people more than the benchmark charts do. Not that the model can't out-think Einstein. That most of what gets paid for isn't the jump either.

I write the essay, but I bookmark the argument first. That's where I'm putting the hours now — not in the composing, which the model will keep getting better at, but in the deciding what's worth saving. The jump doesn't scale. Mine, at least, still has to happen one bookmark at a time.

I Was Filming a Demo of My Monitoring Tool. The Monitor Wasn't Monitoring.

Daniel Nwaneri — Mon, 27 Jul 2026 08:40:19 +0000

This is a submission for DEV's Summer Bug Smash: Smash Stories powered by Sentry.

The project

workers-monitor is a Cloudflare Worker I run to watch a small fleet of
my own Workers. Hourly cron, deterministic threshold gate, Claude Haiku
judgement only if the gate trips, Telegram alert if Haiku confirms
something's actually wrong. A quiet hour makes zero LLM calls.

github.com/dannwaneri/workers-monitor

It pages me on Telegram when something's wrong with the fleet it
watches. What it didn't have, until recently, was an equivalent safety
net for itself — if workers-monitor broke, nobody got told. So I added
Sentry: automatic error capture, and Sentry.withMonitor() around the
hourly run so a dead cron trigger would be caught immediately instead of
silently waiting up to 24 hours for the next daily heartbeat to go quiet.

I deployed it. A cron tick ran clean. I moved on, fairly pleased with
myself.

The bug

A few days later I sat down to record a demo video of the Sentry
integration — screen capture, narration, the whole thing, for a separate
part of this challenge. Simple plan: open the Sentry dashboard, show the
captured errors, show the cron monitor's check-in, done.

I opened the Monitors page to get the screenshot.

There was nothing there. Just Sentry's own auto-created generic "Error
Monitor" — no workers-monitor-hourly-poll, no Cron-type entry
whatsoever, despite the code having run successfully, every hour, for
days. I'd been carrying around a completely false belief: that deploying
Sentry.withMonitor() and watching it execute without error meant it was
monitoring. It wasn't. It never had been.

Sentry.withMonitor("workers-monitor-hourly-poll", () => run(event, env))

Nothing about this throws. It compiles. It deploys. The wrapped function
runs exactly as intended, every hour, on schedule. And it still wasn't
doing the one thing it existed to do.

How I found it

By accident, honestly. Not through review, not through testing — I found
it because I was trying to film proof that something worked, and the
proof wasn't there. If I hadn't been making a video, I might not have
looked at that specific dashboard page for weeks.

The fix

withMonitor's check-in has nowhere to attach without a schedule —
Sentry needs to know what "on time" even means for this monitor before it
will create a Cron Monitor entity to check in against. Without that
config, the call silently has no monitor to report to.

Sentry.withMonitor(
  "workers-monitor-hourly-poll",
  () => run(event, env),
  {
    schedule: { type: "crontab", value: "0 * * * *" }, // matches the real cron trigger
    checkinMargin: 5,
    maxRuntime: 5,
    timezone: "UTC",
  },
)

One config object. I deployed it, then made myself actually wait for a
real hourly tick — not a local test, the genuine production cron —
before I let myself believe it was fixed. workers-monitor-hourly-poll
showed up as a real Cron monitor afterward, "Every hour" schedule and
all.

Why this one mattered to fix

Because it's the same lie twice, if I'm honest about it. I built a
monitoring tool because I don't trust systems to tell me the truth about
their own state unprompted. Then I shipped a piece of that exact tool
without applying the same skepticism to itself. "It ran without throwing"
is not evidence of "it's doing its job" — I know that, I'd have said it
confidently to anyone who asked — and I still fell for the gap between
those two claims on my own code, in the one project whose entire purpose
is not falling for that gap.

See it

https://youtu.be/dSvSOw0fy-E

Real Sentry dashboard, the actual moment the cron monitor showed up after
the fix — not a re-enactment.

What I'd do differently next time

Treat "I deployed it and it didn't error" as a hypothesis, not a
conclusion — for every feature, not just the ones I already suspect are
fragile. The KV read bug I fixed earlier in this project (a separate
entry, if you're comparing notes) came from a structured spec review.
This one came from dumb luck — I happened to need a screenshot. I'd
rather it come from the habit than the accident next time.

PR

github.com/dannwaneri/workers-monitor/pull/3

One file changed, 14 insertions, 1 deletion — the isolated fix, nothing
else riding along with it.

The Cloudflare Worker That Ran Perfectly and Still Failed Twice

Daniel Nwaneri — Mon, 27 Jul 2026 08:40:07 +0000

This is a submission for DEV's Summer Bug Smash: Clear the Lineup powered by Sentry.

Project Overview

workers-monitor is a Cloudflare Worker that watches a small fleet of my
own Workers. Hourly cron, pulls fleet metrics from Cloudflare's GraphQL
Analytics API, runs a deterministic threshold gate, and only calls Claude
Haiku to judge signal-vs-noise if the gate trips. If Haiku confirms
something's actually wrong, it sends a Telegram alert. A quiet hour makes
zero LLM calls.

github.com/dannwaneri/workers-monitor

https://youtu.be/APot7n2wYB8

Real alert history from the deployed Worker — the daily heartbeat, and
scrolled back, the genuine incidents this system has actually caught.

This submission covers two bugs, found days apart, that turn out to be
the same failure mode wearing different clothes: code that compiles,
deploys cleanly, and runs without throwing — and still doesn't do the one
thing it was written for. "No error" is not the same claim as "working
correctly," and both bugs below only exist because that distinction got
missed once.

Bug Fix or Performance Improvement

Bug 1: the maintenance window's fail-open gap

workers-monitor has a maintenance-window feature — POST a start/end
time and it suppresses Telegram alerts during a planned deploy, without
stopping the gate or the logging. The function that reads that window had
one non-negotiable rule, written as a comment directly above it:

Malformed data fails OPEN (returns null → no suppression) — a broken
window read must never accidentally silence a real incident.

The code didn't actually satisfy that comment:

async function readMaintenanceWindow(env: Env): Promise<MaintenanceWindow | null> {
  const raw = await env.STATE.get(MAINTENANCE_KEY);
  if (!raw) return null;
  try {
    const w = JSON.parse(raw) as MaintenanceWindow;
    if (Number.isNaN(Date.parse(w.start)) || Number.isNaN(Date.parse(w.end))) {
      throw new Error("unparseable start/end timestamps");
    }
    return w;
  } catch (err) {
    console.error(/* ... */);
    return null;
  }
}

Only JSON.parse and the timestamp validation sit inside the try block
— await env.STATE.get(...) on the line above does not. A genuine KV
read failure (a real outage, not bad data) throws an exception nothing in
this function catches. It propagates out of readMaintenanceWindow, out
of the run() function that calls it, and aborts the entire hourly run —
not just alert suppression, but the deterministic gate, the Haiku
judgement call, and the structured logging for that hour, all of it,
silently skipped. Every KV blip during that window meant a full hour of
zero fleet visibility, not just a missed alert.

I found this via a structured review of the diff against the original
spec's acceptance criteria, not a live incident. One criterion was almost
word-for-word the comment above the function — the review caught that the
code only satisfied half of that sentence.

Between the two bugs: closing the class of gap, not just the instance

Fixing bug 1 raised an obvious follow-up question: what happens when
workers-monitor itself breaks, not the fleet it watches? Nothing —
console.error into wrangler tail, unread unless I happened to be
watching. So I wired in Sentry: Sentry.withSentry() around the handler
for automatic error capture, an explicit Sentry.captureException() on
the deliberately-swallowed exception in the scheduled handler's own
catch, and Sentry.withMonitor() around the hourly run() call so a
dead cron trigger gets caught immediately instead of waiting up to 24
hours for the next Telegram heartbeat to go silent.

I deployed it, watched a cron tick complete without error, and considered
cron monitoring done.

Bug 2: the cron monitor that was never actually monitoring

It wasn't done. While recording a demo video of the Sentry integration —
for a separate piece of this challenge — I opened the Monitors dashboard
to screenshot the cron check-in, and there wasn't one. Only Sentry's own
auto-created generic "Error Monitor," nothing for workers-monitor-hourly-poll
at all, despite the code executing successfully every hour for days.

Sentry.withMonitor("workers-monitor-hourly-poll", () => run(event, env))

This isn't wrong syntax. It compiles, deploys, executes the wrapped
function fine. But the check-in has nowhere to attach without a schedule
— Sentry needs to know what "on time" means for this monitor before it
will create a Cron Monitor entity to check in against. Without that
config, the call silently has no monitor to report to. No error, no
warning, just nothing showing up. Exactly the same shape as bug 1: code
that runs clean and still isn't doing its job.

Code

github.com/dannwaneri/workers-monitor/pull/1 — the fail-open fix, isolated, 12 insertions / 1 deletion.

github.com/dannwaneri/workers-monitor/pull/3 — the cron monitor fix, isolated, 14 insertions / 1 deletion.

// Bug 1 fix — env.STATE.get() gets its own try/catch, separate from the
// existing one around JSON.parse:
async function readMaintenanceWindow(env: Env): Promise<MaintenanceWindow | null> {
  let raw: string | null;
  try {
    raw = await env.STATE.get(MAINTENANCE_KEY);
  } catch (err) {
    console.error(JSON.stringify({
      event: "maintenance_window_read_error",
      error: err instanceof Error ? err.message : String(err),
    }));
    return null;
  }
  if (!raw) return null;
  try {
    const w = JSON.parse(raw) as MaintenanceWindow;
    if (Number.isNaN(Date.parse(w.start)) || Number.isNaN(Date.parse(w.end))) {
      throw new Error("unparseable start/end timestamps");
    }
    return w;
  } catch (err) {
    console.error(/* ... */);
    return null;
  }
}

// Bug 2 fix — the missing monitorConfig, matching the real deployed schedule:
Sentry.withMonitor(
  "workers-monitor-hourly-poll",
  () => run(event, env),
  {
    schedule: { type: "crontab", value: "0 * * * *" }, // matches wrangler.jsonc's trigger
    checkinMargin: 5, // minutes late before considered missed
    maxRuntime: 5,    // minutes before considered timed out
    timezone: "UTC",  // Cloudflare cron triggers always run in UTC
  },
)

My Improvements

Neither fix is large. What connects them is how each was actually
verified, not assumed:

For bug 1, I ran a two-part review before trusting the diff: does it
satisfy every Given/When/Then acceptance criterion from the original
spec, and separately, does it resolve every assumption flagged during
design, including ones nobody had explicitly revisited. That second check
is what surfaced it — the acceptance criterion for KV-failure behavior
was already written down before the code existed, and the implementation
simply didn't fully match its own spec.

For bug 2, the same discipline applied to my own claim: I'd told myself
"deployed, ran without error, cron monitoring is working." I checked the
Monitors dashboard before the fix (empty — confirmed the bug was real,
not a hunch), deployed the fix, waited for a genuine production cron
tick — not a local test, not a manual trigger — and only considered it
done once workers-monitor-hourly-poll actually appeared as a registered
Cron monitor with an "Every hour" schedule.

The broader lesson, true of both bugs: "the code deployed and nothing
crashed" is a dramatically weaker claim than "the thing I built does what
I said it does." Those two can look identical from a terminal and be
completely different in reality.

Best Use of Sentry

Both Error Monitoring and Cron Monitoring are used here, and bug 2 is
specifically about making the Cron Monitoring half actually work as
intended, not just installed:

Automatic error capture, verified against real output — Sentry.withSentry() wraps the handler, instrumenting fetch and scheduled. Deploying a temporary route that threw an intentional error confirmed the capture path end to end — and surfaced something I didn't expect: alongside the intentional error, Sentry also caught a second, unrelated TypeError: Cannot read properties of undefined (reading 'scriptName'), thrown from inside the SDK's own fetch wrapper on the same request. Not my bug — Seer's root-cause analysis traced it to the SDK reading scriptName off a Cloudflare execution-context field that wasn't populated for a curl-originated request — but it's the kind of thing you only catch by generating a real event and reading what actually came back, not by trusting that withSentry() compiled and calling it done.
Explicit capture on the swallowed exception — the scheduled handler already had a deliberate top-level try/catch so one bad run doesn't crash the Worker. That's exactly the case withSentry's automatic uncaught-exception capture can't see, since the exception is caught before it ever becomes "uncaught" — so the catch block also calls Sentry.captureException(err) directly.
Cron monitoring, now actually registering — after the bug 2 fix, workers-monitor-hourly-poll shows up as a real Cron monitor with an "Every hour" schedule. If the trigger stops firing entirely, Sentry now catches that immediately, instead of the previous 24-hour blind spot (the daily Telegram heartbeat was the only prior proof-of-life).

Verified, not assumed, on both fronts: for error capture, I deployed
a temporary route that threw an intentional error, confirmed it was
captured in the Sentry dashboard, then removed the route before opening
the PR. For cron monitoring, the Monitors dashboard was checked empty
before the fix and populated after a real hourly tick — not a claim, a
before/after I watched happen.

https://youtu.be/dSvSOw0fy-E

The resolved issues, the real stack trace, and the moment the cron
monitor actually registered — the same evidence, on screen.

The Only AI Tell That Doesn't Need a Detector

Daniel Nwaneri — Wed, 22 Jul 2026 13:36:22 +0000

Paul Graham posted a test this week that has nothing to do with sentence structure. Slop gives itself away, he said, when the diction doesn't match the idea, when something completely ordinary gets delivered with the excitement of someone announcing a discovery.

That's a different axis than everything else I've been reading about detection this month. Pangram scores a pattern: token by token, sentence by sentence, does the shape of this text statistically resemble a machine's output. Sloan, the human version I ran into on DEV.to, did the same thing by ear instead of by classifier, GPTZero as a second opinion. Both are measuring the same thing: surface. PG's test measures a relationship. What's actually being said, against how much weight the delivery is putting behind saying it.

Run my own flagged pieces through it and they'd pass clean. What got them flagged wasn't excitement outrunning substance, it was named data points and short paragraphs doing real argumentative work, plainly. Pangram's classifier and PG's ear would disagree with each other on the same writing. That's worth sitting with. The tool built to formalize the intuition doesn't actually agree with the intuition once you test them against the same text.

Pascal's comment on the last piece fits here too. Rephrasing his own English for flow, after 6 to 20 hours of writing the argument himself, isn't a case of ordinary ideas dressed up as brilliant ones. It's someone's real thinking, translated. Nothing in that process produces the register mismatch PG is describing. A classifier flagged it anyway, at 97% confidence, on a post from 2017.

The other thing PG's test doesn't need is a platform. Chris Best's whole pitch for shipping Pangram into Substack is that reader intuition doesn't scale, you need a tool doing this at the volume a feed operates at. PG is quietly arguing the opposite: the tell was always available to anyone reading carefully, you just have to know what you're listening for. That's closer to Josh Puckett's complaint in "In Defense of Writing," that readers already discount slop on sight, than it is to anything Substack shipped this week.

I don't think that makes the tool pointless. Most readers aren't reading carefully, most of the time, and a feed moving fast enough rewards that. But it does mean the two approaches are solving different versions of the problem. One scales an ear. The other replaces it.

I know which one caught real writing and called it fake, and I know which one would have let it through. Diction that matches the idea isn't something a classifier trained on hard negatives is built to notice. It's something you have to actually read for.

Substack's New AI Detector Has the Same Blind Spot DEV.to's Did

Daniel Nwaneri — Wed, 22 Jul 2026 08:28:46 +0000

Substack shipped an AI detector this week. Every post, note, and comment over 100 words can now be scanned through Pangram to see how much of it reads as human or AI. Chris Best's launch post frames it as giving readers a choice: the platform isn't banning AI use, just surfacing it. Worth knowing going in: Pangram's own data already ranks Substack as the cleanest of the platforms it scans, a fraction of LinkedIn's AI-content rate. They're launching transparency tooling from the platform with the least to hide.

I read that and thought: I already know exactly how this goes. I lived it on a smaller scale, with a person instead of a platform integration.

A few months ago I got flagged twice in one day by "Sloan," DEV.to's moderation-warning system. Not a bot quietly scoring posts in the background. A specific community member, reading articles and running them through GPTZero, then sending the same message a blunt classifier would have sent.

The two pieces that got flagged were the ones that generated the most technical discussion I'd published all year. Short paragraphs. Named data points. Rhetorical questions doing real work. The features that make an argument land are the same features that read as "AI-shaped" to anyone calibrated to notice them, human or model.

Write worse, look more human. Write well, get flagged.

That thread also surfaced the part nobody had a clean answer for: the policy creates a dishonesty incentive. Two equally AI-assisted pieces, equally good — the one with a disclosure gets flagged, because now there's something to catch. The one without doesn't. The system was catching transparency, not AI use.

And then Marco showed up in the comments. Forty years in tech, writing in his second language, using AI to make sure his Italian didn't flatten into something stiffer than he meant. Same Sloan message. Same classifier verdict. Nothing to do with what the policy was built for.

Pangram is a real classifier with real engineering behind it: hard negative mining against its own false positives, training data deliberately mirrored so it can't just learn "formal writing = AI." That's more rigor than one guy running GPTZero between article reads. I'll give it that.

But it inherits the same structural problem Sloan had, because it's answering the same narrow question: does this text look AI-shaped. Not: did a human do the thinking. Chris Best's own post admits as much. Pangram can't tell you whether care went into something, only whether the sentences pattern-match to a machine's output.

That gap is where Marco lives. Detectors trained without deliberately mirrored data have a documented habit of flagging non-native English writing, since careful, formal phrasing correlates with both AI output and someone translating in their head before they type — enough of a problem that several major universities have stopped letting instructors use AI detectors at all. Pangram claims their mirror-prompt method fixes it. Maybe. Most of the numbers backing that claim trace back to Pangram or a study Pangram commissioned.

Someone with no stake in the answer already looked. The Atlantic's Matteo Wong traced a recent wave of AI-writing accusations back to Pangram itself, including a horror novel pulled from a major publisher days before its release. His argument wasn't that the tool is broken. It's that a detector that's mostly reliable can be more dangerous than one that's obviously unreliable, because people stop checking. A 99.98% accuracy rate sounds like certainty. Applied across millions of posts, the failures are still real people, still real reputations, just quieter about it.

That's Marco's risk, and mine, in one sentence: the false positive doesn't feel like a statistic when it's your byline.

I write from Port Harcourt, in English, the language I was taught in and think in, using AI as part of an actual workflow: not to generate opinions I don't have, but to get from a rough draft to a clean one without losing the argument along the way. Sloan already showed me what a false positive costs, close enough that I don't need to imagine it. Marco is the version of that risk I can't unsee.

It's also the whole reason I stopped using a generic humanizer and built one calibrated to my own published corpus instead. A tool trained to strip "AI-shaped" patterns from anyone's writing will also strip the parts of your writing that are just yours, an em dash you use structurally, a habit of compressing three examples into two. Voice-humanizer checks against what I actually sound like, not against a mirrored dataset of nobody in particular.

Sloan and Pangram are both answering "does this look like AI." I don't think that's the question that matters. The question is whether someone can be asked "did you know what you were writing about, and do you stand behind it," and answer yes.

I do.

A bug in Qwen3-TTS taught me voice is biometric

Daniel Nwaneri — Tue, 21 Jul 2026 09:01:28 +0000

The trained voice cloning model for my project is 50 megabytes. Anyone with those 50 megabytes can convincingly be me on a phone call.

I did not build the project to prove this point. I built it because every AI voice cloning tool I tried erased my Nigerian accent. ElevenLabs, XTTS, F5-TTS — Western English training data, generic African-accented output. The pipeline that finally worked chains Qwen3-TTS (Alibaba's 1.7B voice cloning model, released January 2026) with a reference clip of my own voice. Runs on free Kaggle GPU. Full write-up at github.com/dannwaneri/naija-voice.

The technical hurdle was small and specific. Qwen3-TTS ships with a hardcoded min_new_tokens=2 at line 2046 of modeling_qwen3_tts.py. The README documents that you can pass Hugging Face generate() kwargs, but this line silently overrides min_new_tokens no matter what you pass. Half the seeds I tried produced mid-sentence truncation because the model was free to emit EOS within a few tokens. Once I patched that line, the pipeline held. Voice consistent across a full minute. Nigerian accent intact.

Issue #55 on the repo has been open since January, filed by a Korean user reporting the same truncation symptom in a different language. Six months, no maintainer response, no root cause identified. I commented with the diagnosis and opened a PR.

That is the surface story.

The .pth file is me

The trained model weights are 50 megabytes. That file, run through the pipeline, produces audio indistinguishable from my voice. It carries my accent. It handles the way I compress vowels. Anyone with those bytes can generate audio of "me" saying anything. A phone call to my bank. A video message to my mother. A confession to a crime.

I did not commit the weights to GitHub. The repo has the code and the notebooks. It does not have the file that IS me. This is the first line of the README:

The trained voice model (models/) is intentionally not published — a voice fingerprint is biometric data and should not be committed to public repositories. If you fork this, generate your own from your own voice.

I wrote that line before I understood what it meant. I understand it now.

Voice is not like a password

You can rotate a password. If your Gmail password leaks, you change it and the leak is contained. The new password does not carry any history of the old one.

You cannot rotate a voice. If someone has a working clone of my voice today, that clone works for the rest of my life. Every phone call I make afterward has to compete with a generated version indistinguishable from the real one. I cannot upload a new voice next Tuesday.

Fingerprints have this same property, but fingerprint capture requires physical proximity. Voice capture requires 60 seconds of clean audio. I have posted 60 seconds of clean audio on the internet. Every podcast host has. Every Twitter Spaces speaker has. Every founder pitching on Loom has.

The threat model is not exotic. It is a scammer with a phone, my mother's number, and 60 seconds of me talking about AI voice cloning on YouTube.

What I do about it

Publishing the weights to a public Hugging Face space would be the standard AI-project move. Star count, forkability, community reach. I am not doing it.

I documented the pipeline and the training procedure. Anyone who wants their own voice can build it. Anyone who wants my voice specifically has to compromise my laptop.

That is a small mitigation. It does not defend against the 60 seconds of audio I have already released. It does not defend against a service that offers cheap voice cloning to anyone with a URL. But it means the artifact I control is not the source of the leak.

If you are building anything voice-related: do not publish the weights of a specific person's voice unless that person has explicitly consented in writing. If you clone your own voice for your own content, keep the weights on hardware you control. If you offer voice cloning as a service, refuse the "clone this pastor" and "clone this politician" requests. One viral misuse case poisons the entire category.

The tooling to clone voices well is now open source, small enough to run on a free GPU, and documented well enough that a solo developer can figure it out in a weekend. The tooling to defend against voice cloning misuse does not exist yet.

That is not a call to arms. It is where we are.

the part of this year I don't put in the commit messages

Daniel Nwaneri — Mon, 20 Jul 2026 10:22:22 +0000

24 hours. That's how long a contract lasted before someone pulled it because I was running Windows, not Mac. Not my work. My OS.

It almost broke me. Not in the dramatic way. In the quiet way — the kind where you keep shipping code during the day and don't tell your family anything at night.

Then came FR8. A fully-funded, three-month residency in Helsinki for young builders. I found it in Hemapriya's Dev Opportunity Radar #2, applied the same day, got a confirmation email. A few days later: "didn't quite align with what we're currently looking for — deep technical, high-conviction bets." I took it well in the replies. Not so well internally.

The Windows contract was the lowest. Finland was close behind it.

I kept showing up for the DEV Challenges anyway. Almost every one that's run since I got back. Won OpenClaw. Lost more than I won — a lot more. Those losses did something the wins didn't: they prepared me. I'm in the Global AI Hackathon this month. And the Africa Deep Tech Challenge. I want to win one. Maybe both.

There was a third one too, closer to home than the other two: the Community Program Manager role at DEV itself. MLH had just acquired DEV and needed someone to run it. Not a writing role. Not a building role. My profile fit because of the platform depth, not despite it.

Rejected on location. Small team, no infrastructure to hire in Nigeria right now. Not my resume. Not my answers. A payroll line I couldn't fix from my side of the application.

This isn't even my original account. I had one back in 2019. Lost it. Found my way back here in November 2025 — eight months, not a year, but it's felt longer.

My family doesn't know any of this. Not the Windows call, not Finland, not the account I lost in 2019. They know I code. They don't know what coding cost this year.

DEV.to is where the people who do know are. Not because I told the whole story to anyone here. Because writing honestly and showing up did what explaining never could.

Somewhere in the middle of all of it, one of those pieces — "Someone Else Pays for Your AI Access" — got picked up in AI Engineer World's Fair Daily Context, swyx's curated daily covering the World's Fair conference in San Francisco. I wrote that piece from my phone in Port Harcourt. My mom doesn't know what Daily Context is or who swyx is, or what any of this means. I still want to find a way to show her.

If you've had a stretch like this — a low point, another one right behind it, and a community that held you without needing the backstory — I see you. I feel you like we're in the same room.

Jess, Ben, the whole DEV team — thank you. You're touching lives in ways I don't think you fully know.

Here's to the next stretch being kinder. And if it isn't, here's to showing up anyway.

Building an AI Agent That Knows When Not to Guess (Qwen + MCP)

Daniel Nwaneri — Wed, 15 Jul 2026 16:23:34 +0000

A payment landed for exactly half an invoice's value. The payer's email matched the customer on file. The reference generated by Paystack — the Stripe-equivalent payment processor across Africa — didn't match anything at all.

Qwen looked at it and came back with 30% confidence and no invoice named.

I built Recona for the Global AI Hackathon Series with Qwen Cloud, deadline July 20, 2026 — an agent that reconciles Paystack payments against open invoices and chases the overdue ones, with no human involved on the easy cases. That transaction wasn't supposed to be the interesting part of the demo. It became the whole point.

What Recona does

If you freelance or run a small business taking payments in Nigeria, money lands with a reference like PMT final tunde, and you spend the evening figuring out which invoice it settles — and which client you forgot to chase. Recona automates both halves. It matches incoming payments against open invoices using Qwen, and it runs a daily collections sweep that drafts and sends increasingly firm reminders as invoices age.

Cloudflare Workers and D1 handle ingestion and orchestration — signature-verified Paystack webhooks, idempotent against duplicate delivery. Alibaba Cloud SAS runs a Dockerized Node service that holds all the Qwen reasoning, deployed separately from the ingestion layer. The reconciler exposes its matching engine both as REST and as MCP tools — match_transaction_to_invoice, draft_payment_reminder — over streamable HTTP. Telegram is the human-in-the-loop surface, because the actual job here is a workflow closing itself, not another dashboard to log into.

The rule I designed around: the model proposes, deterministic code disposes. Auto-closing an invoice requires exact amount, matching currency, and confidence above a threshold — checked in code after Qwen responds, never trusted from the prompt. The LLM reads the messy handwriting. The calculator authorizes the deposit.

What I expected to demo

I had a clean story planned. A client pays half an invoice. Qwen correctly identifies which one it is. My deterministic guard blocks the auto-close anyway, because the amount is wrong. Model is right, code overrules it for safety. Good demo beat.

That's not what happened.

I ran the real transaction through the real system — the actual Cloudflare Worker at recon-ingest.fpl-test.workers.dev, the actual deployed reconciler, the actual Qwen API. I ran it twice: once against the original invoice, once after re-seeding a fresh one at exactly double the payment amount, to rule out a fluke.

Both times, given a payment that matched an invoice's customer email but was exactly half the amount, with a reference that had zero connection to any invoice number, Qwen returned 30% confidence and no committed invoice ID — even though its own reasoning text named the right invoice by ID. It wasn't wrong. It just wouldn't commit to an answer it didn't have enough signal to support.

I had a choice: force the demo video to match the script I'd already written, or let it show what the model actually did. I rewrote the narration to match reality.

Why the honest version is the better demo

I designed against the failure mode I was worried about — a confident wrong answer sliding past my guards. I didn't design as carefully against the opposite one: a system so wrapped in caution that the model's own certainty never becomes a usable signal, and a human ends up reviewing everything regardless of whether the model actually knew the answer.

What I saw sits in between. Qwen reasoned out loud about the correct invoice, declined to assert it, and handed a legible number to the orchestration layer — 30%, here's why. That's exactly the kind of thing you can build policy around. My auto-close gate doesn't have to grade whether the model's guess is right. It just has to trust the confidence number Qwen already computed about itself, and default to a human whenever that number is low.

Don't build your safety layer to catch the model when it's wrong. Build it to treat the model's own uncertainty as a first output, and put your guardrails on that. The alternative requires you to be smarter than the model at judging its own answers. This one just requires the model to be honest about what it doesn't know — and Qwen, in my testing, was.

A junior hire who's always certain is expensive to trust. One who says "I'm 30% sure, and here's why" is the one you can actually build a process around.

Repo: github.com/dannwaneri/recona — MIT licensed. Built for the Global AI Hackathon Series with Qwen Cloud, Track 4: Autopilot Agent.