DEV Community: Daniel Nwaneri

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.

my ai coding session burns more power than the average nigerian gets all day.

Daniel Nwaneri — Mon, 13 Jul 2026 08:35:28 +0000

I run Claude Code most of my day. agent loops firing all day, one after another. the usage screen tells me I'm at 26% of my weekly limit. it doesn't tell me what that 26% weighs anywhere else. it feels free.

It isn't.

A single chat reply costs about 0.3 watt-hours — the energy an LED bulb burns in under two minutes. Simon P. Couch measured actual Claude Code sessions and got a median of 41 Wh — 130x a plain message. Simon Willison put his own daily habit at the equivalent of 4,400 typical queries. His comparison: a dishwasher, or a fridge running 24 hours.

KAIST measured agents specifically this year not chat, agents that reason and act across steps. A 70 billion parameter agent — a model roughly the size of what real commercial products run on, not a toy — averaged 348.41 Wh per query. 136.5x a normal query. Scaled up, researchers project close to 200 gigawatts globally just for agents deciding what to do next. A gigawatt is what a small country's whole grid can push out at once.

One dev. One agent open all day. Willison's own number: 1 to 1.5 kWh on a heavy day. Not a lab estimate. His actual habit.

Average Nigerian: 165 kWh a year. 0.45 kWh a day. Lights, a phone charge, a fan through the heat. That's the whole ration.

I'm writing this from Port Harcourt. Friday, I was on a video call with a product manager at Cloudflare — he was walking me through a demo, asking what I thought. It started raining. The light went. The internet went with it, mid-sentence, no goodbye. That's the wire I'm on, talking to someone at a company whose servers never blink.

Building the reconciliation agent for the hackathon that same week, I caught myself mid-build — one stretch, maybe a few minutes, and the token count had already crossed 10k. I wasn't even done. That's one exchange, one agent, one afternoon, running on the grid that dropped a call over rain.

That night I googled it. how much one of these sessions actually costs, in power, not dollars. the number that came back stopped me mid-scroll.

One coding session. One dev. More power than an entire day of an entire person's life, in the country I'm typing this from.

Gartner: global data centers hit 565 terawatt-hours (TWh) this year — the unit whole countries use to measure their power grids. AI-optimized servers alone not data centers overall, just the AI slice — went from 95 TWh in 2025 to 175 TWh in 2026. An 84% jump. One segment. One year.

Nigeria: 40.7 TWh a year, total, country-wide. Less than half of installed capacity reliably reaches anyone.

AI-dedicated servers alone will burn more than four times what my entire country produces. This year.

It's not coming off Nigeria's grid. Different continent, different wire. Nobody dims Port Harcourt to run my prompt.

Cheap for a dev paying $20 a month for Claude Pro. Cheap for a hyperscaler burning gigawatts to keep a chatbot responsive. Nowhere near cheap for the 61% of Nigerians who had grid access in 2022 or the rest who never did.

I needed the work done. I'm not apologizing for the sessions.

I am done pretending they cost nothing.

Every agent loop you fire off casually costs more than someone else's entire day, somewhere, always. You just don't see the meter.

I saw mine. It didn't look like a coding tool anymore.

I'm half sick writing this. And some of you reading it will paste it into an LLM to draft a smart-sounding reply for the comments. That's the loop. That's the whole joke, and it isn't funny.

I Built a Monitor for Servers. Then Pointed It at Myself.

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

This is a submission for Weekend Challenge: Passion Edition

What I Built

I'm in Port Harcourt. This World Cup, kickoffs have landed at 1am, 2am, sometimes later — late enough that a match the tournament calendar dates one day is already the next day where I am. I watched Argentina beat Switzerland 3-1 in the quarterfinal that way: officially a July 11 fixture, already July 12 in Port Harcourt by kickoff. Fell asleep around 4am, up for work a few hours after that.

This is the first World Cup hosted in North America since I've been following closely, and the timezone math is unforgiving from Port Harcourt.

Four days before this challenge launched, I shipped workers-monitor — a Cloudflare Worker that watches my other Workers for trouble. Cron trigger, hourly. Pulls fleet metrics from Cloudflare's GraphQL Analytics API. A deterministic threshold gate decides if something's actually wrong. Only if the gate trips does it call Claude Haiku to separate signal from noise. Only if Haiku confirms does it send a Telegram alert. A quiet hour makes zero Anthropic calls.

github.com/dannwaneri/workers-monitor

When this challenge's prompt landed — build something inspired by passion — I didn't reach for a new pattern. I reached for the one I'd just proven, and asked what else deserved that kind of restraint. Sleep did.

Nightwatch is the result: same shape, different domain. A gate decides if anything decisive happened; an LLM judges whether it's worth waking up for. Telegram delivers whatever survives both.

The part that's actually the point is the LLM call, and it isn't describing the event. A template can turn JSON into a sentence. What it's doing is judging whether the event still matters — a 4th goal in a 4-0 game and a 90th-minute equalizer are both technically "goal" events, but one is worth breaking sleep for and one isn't. Every notification app on my phone already tells me the score. None of them ask whether I should care.

Demo

Quarterfinals ended July 11. Semifinals start July 14 — a day after this challenge's deadline. There was no live match to point Nightwatch at while I was building it.

So this demo replays the real event feed from Argentina 3-1 Switzerland through the actual deployed pipeline — same gate, same Telegram delivery — rather than capturing a live match in progress. Nine real alerts fired, scoreline computed deterministically in code rather than left to the model to restate, so it tracks the real match exactly: 1-0, 1-1, 2-1, 3-1. Four events came back rated HIGH significance (the 10' opener, the 67' equalizer, the 72' red card, the 112' go-ahead goal in extra time), and five LOW (four routine cards plus the 120+1' insurance goal). I'd rather tell you the real breakdown than round it to something tidier.

[Watch the alerts fire](https://i.imgur.com/EJfqdxC.mp4

Code

github.com/dannwaneri/nightwatch — a new repository, first committed July 12, within this challenge's window.

How I Built It

It pulls from ESPN's undocumented public scoreboard endpoint — site.api.espn.com/apis/site/v2/sports/soccer/fifa.world/scoreboard. No key, no signup. It's unofficial and could change without notice; I built the parser to fail closed per-event rather than crash the whole poll if that happens.

The gate itself: a goal or card has to show up on two consecutive polls before it's confirmed. ESPN's feed occasionally lists something briefly before settling — I didn't want a false "GOAL" alert because I trusted the first read.

One bug worth naming: early on, the running scoreline in each alert came from Haiku's own prose, and Haiku occasionally restated the wrong number even when given the correct one. The fix was structural, not a prompt tweak — the code now computes and prepends the scoreline itself, and strips any score-shaped digits the model tries to add in its own text; the model only ever gets to judge significance and describe what happened. A related fix: the model wasn't given real player names, so it invented one for a goal ("Messi" scored a goal Julián Álvarez actually scored) — fixed by passing ESPN's real athlete data into the prompt instead of letting the model guess.

What's still v1: No auto-discovery of the day's fixtures — you POST /track a match id by hand before kickoff. The sleep-window suppression (don't ping for LOW-significance events between, say, 11pm and 6am) is a hardcoded env var right now, not a config endpoint — it's spec'd but not built. workers-monitor has a real /maintenance endpoint for suppressing alerts during planned deploys; Nightwatch doesn't have its own equivalent yet. No automated test suite; verification was manual, against real ESPN data.

None of that changes what actually happened watching Argentina-Switzerland. I still lost the sleep on that one. The next one, I won't have to choose.

Prize Categories

Not submitting to a prize category this round — no Snowflake, Solana, ElevenLabs, or Google AI in the current build.

Your Hand-Typed Slop Isn't Honest. It's Just Slower.

Daniel Nwaneri — Thu, 09 Jul 2026 07:35:37 +0000

A post on X last week:

"The fact that people can't even reply to posts without AI anymore says a lot more about them than they think."

The replies agreed. Nobody asked the obvious question: says what, exactly?

Here's what I think it says: nothing new.

People have been hollow online since the forum era. "So true!!!" didn't become meaningless when GPT launched. It was meaningless in 2009. Copy-pasted under blog posts. Typed by hand. Fully human. Fully empty.

What changed isn't the emptiness. What changed is the cost to produce it.

That's a different thing.

AI is reportedly writing and reading more of the internet than people are at this point. I haven't chased down the study, but it tracks with what everyone's noticing.

But the conclusion most people draw from that — that authenticity is dying — assumes there was a lot of it before. There wasn't. There was friction. Friction isn't the same as authenticity. It just made the emptiness more expensive to ship.

Autocorrect didn't make people bad texters. It made bad texters faster. The badness was already there.

The tell is whether anyone is actually home behind it. The tool doesn't matter.

Someone typing "this resonated with me 🙏" isn't more present than someone who generated it. They just did more work to say nothing. That's not a virtue.

It does cost something. It costs attention. It costs the willingness to say something specific, something you actually think, something that could be wrong. Most people online weren't paying that cost before AI, and they're not paying it now.

The gap was never intelligence. It was performance. It just wasn't visible when the performance required typing.

Generation got cheap. We never built good filters for the expensive stuff — actual thinking, actual specificity, actual stakes.

Slop has always existed. In dev work, in blog posts, in comments. The skill was always knowing where slop belongs and when to clean it up. Fast parallel experimentation? Slop is fine. Shipping to production without understanding it? That's the problem.

Same principle applies to replies.

Use the tool. Own what comes out.

The people performing outrage about AI replies are doing the same thing. Pattern-matching to a moment. Not thinking it through.

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.

you stopped reading the docs. now you don't understand the systems.

Daniel Nwaneri — Tue, 07 Jul 2026 10:33:25 +0000

I didn't go to a university for computer science. I have a B.Tech in Geophysics.

What I know about software, I built by reading. Documentation, source code, GitHub issues, changelogs, RFC threads that went nowhere, blog posts from 2014 that were half-wrong but made me think. No bootcamp. No structured curriculum. Just me, a browser, and the actual material.

When I was learning Cloudflare Workers, I didn't have a course. I had the Workers docs, the Wrangler changelog, and a broken deployment I had to debug at 1am. I read the binding configuration docs three times before I understood why my KV namespace wasn't resolving. I followed a GitHub issue thread from 2022 to understand a Wrangler behavior that was never in the official docs at all.

That's how I know what I know. Not from a summary. From sitting with the material until something clicked.

I'm watching that process disappear.

we're calling it productivity

The pattern I keep seeing: not "I read the docs and I'm confused about this section" but "give me the code for X." Not "I traced through the source and found this behavior" but "what does this function do."

Understanding is optional now. Just get the output.

We didn't just change how we find answers. We changed what we think the goal is. The goal used to be comprehension. Now it's output. And we're calling the shift efficiency.

It isn't. It's debt.

You can generate a working circuit breaker implementation without understanding what a half-open state is or why it exists. It works in your test environment. It fails in a specific edge case under load six weeks later, and you have nothing to reach for because you never built the mental model. You got the conclusion without the construction. The what without the why.

The why is the only part that matters.

Reading documentation builds a mental model through contact with the actual material — the tradeoffs the API design is managing, the edge cases in a footnote you almost skipped, the why behind the what. The confusion you feel reading a complex RFC is where the learning happens. Friction is where understanding gets built.

When I built Bookmark Brain — a RAG system on 55,000+ of my own X bookmarks — I had to actually understand how Cloudflare Vectorize works under the hood. Not just the API surface. The embedding dimensions, the index behavior, the query distance metrics and what they mean for retrieval quality. I read the HNSW paper. I read source-adjacent documentation. I sat with confusion long enough for it to become comprehension.

That comprehension is now load-bearing in production. If something breaks at 2am, I have a model to reach for.

If I had prompted my way to a working demo, I'd have a demo. I wouldn't have a system I can reason about.

the split already showing in codebases

Who still reads and who doesn't — that's the divide forming. Not senior vs junior, not experienced vs beginner.

It shows in code review. The developer who read the ORM documentation sees in thirty seconds why a query is going to cause N+1 issues. The developer who generated the code can't, because they never built the model that lets you see it.

It shows in architecture. The developer who read the Kafka docs actually understood consumer group behavior, partition assignment, offset management. When the system needs to scale, that developer has something to reach for. The one who learned Kafka from summaries has vocabulary but no structure underneath it.

It shows most brutally in debugging. Debugging is almost entirely a function of your mental model. Without one, you're just changing things and hoping.

AI cannot hold the architecture. It doesn't see the big picture across your codebase. I've watched an AI-generated caching layer get shipped clean, pass every test, and take down production three weeks later because nothing in the code — or in the person who merged it — understood what would happen when two requests raced to invalidate the same key. The human in the loop has to hold that. Which requires a mental model. Which comes from reading, not prompting.

what we're trading without noticing

I've watched developers ship auth systems they can't reason about. Caching layers they can't explain. Queue implementations that work until they don't, and when they don't, there's nothing to reach for except opening a new chat window.

That's not a tool problem. That's a reading problem.

Same tool, two developers. One uses it to understand — asks why the code works, what the tradeoffs are, what breaks under load. One uses it to avoid understanding — takes the output, ships it, moves on. Completely different results six months later when the system needs to change.

That's the line. Not whether you use AI. Whether you're using it to understand or to avoid understanding.

The developers I watch compound over time aren't moving fastest. They're the ones who still read. The actual changelog. The actual query planning documentation. The actual source when something doesn't make sense. They're building a compounding mental model that prompting cannot replicate.

The ones who stopped reading are building something too. API surface knowledge and output patterns, without structural understanding underneath. It doesn't show until the system needs to change.

for self-taught developers specifically

Documentation made self-taught viable. Open-source code you could read. Stack Overflow threads with timestamps, disagreements, edits that showed how understanding evolved. Blog posts from engineers explaining not just what they did but why.

That curriculum is still there. I still use it. I just don't know how many people coming up behind me are.

I built what I've built by reading things that confused me until they didn't. That's not a talent. It's a practice. One I watch developers trade away every day for the feeling of moving faster, without noticing that what they're trading is the actual skill.

The mental model you build from reading documentation at 1am, frustrated, reading the same section three times — that's not a tax on your productivity. That's the thing that makes you irreplaceable when the system breaks.

When you skip it, you skip the thinking. And you won't know you skipped it until you're in production with nothing to reach for.

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.

Why AI Still Can't Write Well and Which Half of That Problem Is Actually Yours

Daniel Nwaneri — Mon, 06 Jul 2026 07:28:29 +0000

I built a 36-pattern checklist to catch AI writing tells in my own drafts, calibrated against everything I've published. So when a theory about why AI can't write well went semi-viral last week, I read it the way I read a bug report: I wanted to know if the explanation actually matched the failure I was seeing in my own tool's flagged patterns, or if it just sounded right.

One of the theories didn't match. It's wrong, and it's the kind of wrong that spreads because it sounds technical enough to not get checked.

The claim: inference-time optimizations — the tricks labs use to make models respond faster — are why creative writing sounds worse than it used to. Specifically, speculative decoding.

Quick version of what that is, because the claim only sounds plausible if you don't know this part. Instead of one big model generating a response token by token, you pair it with a small, fast "draft" model. The small model guesses several words ahead; the big model checks the guesses in parallel and keeps the ones it agrees with. It's a shortcut for speed. The claim going around is that this shortcut quietly degrades writing quality.

It doesn't. Speculative decoding is built to be lossless by design — the output distribution is mathematically identical to what the big model would've produced generating alone, word by word. There's no quality trade happening anywhere in the math. What's real is narrower: creative writing benefits less from the speedup, because high-temperature prose has more genuine surprise in it, so the small model's guesses get rejected more often. One inference-benchmarking writeup put creative-fiction guess-acceptance around 50-65%, versus 75-85% for code — not a peer-reviewed number, but it lines up with how the technique works. That's a story about how much faster your writing gets served, not about how good it is.

Quantization — shrinking a model's precision to save memory — can genuinely hurt output quality. Real, separate lever. But it's not the same thing as speculative decoding, and I watched people conflate the two for a full afternoon before anyone pushed back.

The part that actually holds up isn't the part people were arguing about.

Every major model goes through a training step called RLHF — reinforcement learning from human feedback — where it gets nudged toward responses that human raters rated highly. Sounds fine until you notice what raters actually reward: responses that are pleasant to skim, hard to disagree with. Over enough training, the model doesn't just get better at avoiding bad answers. It narrows toward one "safe" register and stops producing the wider range of responses it was originally capable of. That's called mode collapse, and Kirk et al. measured it directly: RLHF-trained models show meaningfully lower output diversity than the same models before that training step, across every metric in their study.

This is why the "ten drafts, then a panel of models grades and picks the best parts" trick doesn't work, and I know because I've run some version of it myself. If every draft came from a model that already narrowed toward the same safe average, grading and merging those drafts just averages the average. You don't escape mode collapse by voting inside it. You get the same failure, run twice, dressed up as rigor.

Writing has no equivalent to "the code compiles." There's no automatic checkable signal for "this is insightful," so training has nothing to push against except rater preference — and rater preference, in bulk, rewards smooth and safe over sharp and specific. That's the actual bottleneck: the training incentive itself, not the prompt, not the inference trick.

Once you name mode collapse, it's tempting to treat "AI can't write well" as one flat, unsolved problem. It isn't. It splits into two, and I write in the easier half without having fully clocked that until this week.

Nonfiction — technical writing, essays, arguments — has a nameable failure mode: conflicting optimization objectives. The traits that make a model pleasant in consumer chat (warm, hedged) are directly at odds with what good technical writing needs (precise, willing to be blunt). One reward signal, trying to serve two audiences that want different things, so the model gets pulled toward the middle of both and satisfies neither. That's a solvable engineering problem, the same way you'd split an API endpoint that's trying to serve two incompatible callers. Not fully solved, but there's already public evidence of labs shipping partial fixes aimed at exactly this (OpenAI's November 2024 GPT-4o writing update is one example).

Fiction is a different kind of hard, and I don't think it's mine to weigh in on with any authority. A good novel gets built over years of iteration on structure and character, closer to how Pixar's story team reworks a film's plot for years before a single frame gets animated. Published novels only show the finished result. The failed drafts and the years of restructuring never got kept as training data. Even if that data existed, there's limited economic incentive to solve it yet, because "does this novel move a reader emotionally over 300 pages" isn't something you can currently measure the way you can measure "does this code pass its tests."

Update (Jul 7): a sharper version of this argument surfaced after this went up, worth naming honestly. The "no training data for the process" framing has a real hole — finished novels already exist in these training corpora by the millions, so a lack of raw text isn't the bottleneck. Models like GPT-4.5 and Llama 3.1 405B suggest pretraining alone can already produce genuinely strong long-form prose. The likelier story: post-training optimization (RLHF and shrinking parameter counts chasing efficiency) is actively degrading a capability that already existed, not filling a gap that was never there. Doesn't change the nonfiction half of this piece. Does mean the paragraph above needs a rewrite I haven't done yet.

Two different problems, wearing the same complaint. One has a name and a rough fix already shipping somewhere. The other doesn't have a dataset yet, or a business case to build one.

I only write the first kind. Tutorials, arguments built from things I've actually built and broken. That puts me on the solvable side of this line, and for most of the week I was following this argument, I didn't separate that from the harder, maybe-unsolvable half everyone was actually upset about.

"Solvable" doesn't mean "solved," though, and the fix that exists today isn't a model retrain I have access to. It's an editing pass. Which is the actual reason I built that 36-pattern checklist I mentioned at the start — calibrated against my own published work specifically so it can't smooth my sentences toward a generic "good writing" average. There's no average in it to smooth toward. Just my corpus. It doesn't generate the underlying argument for me. Nothing does that yet, and nothing should. What it catches is the RLHF hedge-language creeping back in after a draft is written — the sentence that trails off into a comma and an "-ing" clause instead of just ending, the vague "many people" claim that should name someone instead.

I'm not claiming AI writing is solved. I'm saying I spent a week watching smart people argue about a math claim that turned out to be checkable in about ten minutes, and the actual fix for my half of the problem was something I could run on a draft that same afternoon.

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.

$30 and a Lifetime of Liability

Daniel Nwaneri — Thu, 02 Jul 2026 11:57:19 +0000

co-written with UnitBuilds, who built most of this out loud in the comments of my last piece.

I recently wrote about the $30. someone in cambodia or kenya, paid under $30 to complete a biometric verification step on behalf of a stranger, so a developer somewhere could access an ai model that's geo-blocked where they live.

I framed it as exploitation. it is. but I stopped at the harvesting.

UnitBuilds didn't stop there. over a series of comments, he walked through what happens after the $30 — and it's worse than anything I'd written.

the part the verification step doesn't tell you

when you complete a biometric check — face the camera, look left, look right — you're not just proving you're human. legally, you're authorizing.

not authorizing this one transaction. authorizing the account. anything done with it, by anyone, from that point forward, is yours. that's not a loophole. that's the definition of authentication.

as UnitBuilds put it:

"they can contest in court, but they won't win, by law they can't win, because the very definition of the authentication is that you, as yourself, fully authorize yourself and anyone else by proxy, to use your account to do with, for whatever purposes, assuming full responsibility for it."

the person who took the $30 didn't sign up to be liable for whatever happens next. but the law doesn't have a category for "deceived into authorizing." it has a category for "authorized." and once you're in that category, you're not fighting the bill. you're fighting jailtime.

what "fighting jailtime" actually looks like

UnitBuilds laid out the scenarios plainly:

a bad actor uses the harvested identity to rack up charges, commit fraud, or worse. the account holder — the person who took the $30 — has no idea any of this happened. months later, maybe years later, they get a job offer overseas. they travel. at the border, there's a warrant. for a crime committed using their face, on the other side of the planet, by someone they've never met.

or the company affected sues. the debt is structured for someone earning a developer's salary in a wealthy country. the person actually liable is earning $100 a month.

"imagine that, an entire month's pay gone, on a single ai subscription they never even knew existed, from a bank account they never made. and they don't have the finances to actually fight it in court."

that's UnitBuilds describing namibia specifically — people working full contracts, 8 to 5, for $100 a month. not informal work. not gig work. contracted employment. wiped out by a bill that was never theirs, with no path to contest it, because contesting it costs more than the bill itself.

the version where you don't even get the $30

the scenario above assumes someone got paid. UnitBuilds described a worse one: phishing.

a fake overseas job offer. "all you have to do is submit your id and do the facial verification, and send the code that's sms'd to you." it looks exactly like a routine hiring process. and then:

"that's the last you ever hear of them."

no payment. no awareness that you were ever part of a supply chain. just a verification step that felt normal, and a liability that surfaces however long it takes for someone to misuse it.

this isn't new, it's just wearing new clothes

UnitBuilds has watched this pattern before ai existed. bank impersonation calls — spoofed numbers, confident voices, "confirm your account details" — targeting pensioners who grew up trusting that a call from the bank was actually the bank.

"life-savings gone from pensioners, who have no means of earning it back or fighting the bank for it. some had to choose between food on the table and paying their wifi, losing access to communication with everyone they know, for the sake of not going hungry, because someone scammed them out of 50 years worth of hard work."

whatsapp cloning works the same way — impersonate a relative, get the verification code, clone the account, spread it to the entire contact list, harvest more identities, repeat.

the throughline, in his words:

"it's a system built on accountability, not morality, and the legal system is there to defend the dollar not the person."

in namibia, you go to prison longer for poaching a cow than for murder.

the part that has nothing to do with biometrics

then UnitBuilds introduced something I hadn't considered at all: hardware identity theft.

two forms. the first is shadow proxy networks — malware that quietly routes traffic through your residential gateway, so someone else's activity travels under your ip, your network, your name.

the second is newer and stranger. you buy a windows 11 laptop. secure boot signs the hardware to your microsoft account the moment you log in. from that point, you're the authorized owner of that device — and liable for whatever it does — until you go through the process of manually removing it from your account's device list. format it, sell it, give it away: none of that breaks the link. the new owner is using hardware that's still, in microsoft's records, yours.

"a small little detail they don't tell you when they say it's 'for your data security.'"

the mechanism is identical to the biometric one. ownership and liability bound to an identity that doesn't update when the physical reality changes. the gap between who actually controls something and who's legally responsible for it is where all of this lives — bodies, devices, accounts, doesn't matter. the structure repeats.

the sentence underneath all of it

a developer going by self-correcting systems read the original piece and named the pattern precisely:

"a control that can't see its own downstream doesn't stop the harm, it relocates it."

that's what every layer of this is. kyc doesn't stop fraud — it relocates the verification burden onto someone with no stake in the outcome. secure boot doesn't stop hardware theft — it relocates ownership liability onto whoever's account it happened to be signed into. every fix moves the cost. none of them eliminate it. they just choose, by design or by accident, who absorbs it.

the people who absorb it are consistently the people least equipped to refuse, least equipped to understand what they're agreeing to, and least equipped to fight it once it lands.

UnitBuilds runs Halo Cybersecurity adjacent work and built NMCP, a rust-based mcp implementation. everything quoted here, he gave permission to use directly — his words, not mine, paraphrased into something smaller than what he actually said.

most of what's true in this piece, he wrote first, out loud, in a comment thread.

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine and UnitBuilds'. So is whatever's wrong with them.

Someone Else Pays for Your AI Access

Daniel Nwaneri — Tue, 30 Jun 2026 07:22:16 +0000

you probably didn't think about this when you signed up.

you entered your card details, verified your phone number, maybe uploaded a government ID and took a selfie. friction. annoying. you moved on.

somewhere in cambodia or kenya, someone did the same thing. except they weren't signing up for claude. they were being paid — under $30 — to complete a verification step on behalf of someone they'll never meet, for a service they'll never use, in a supply chain they don't fully understand.

their face is now in a database they didn't choose. it will be used again. not for claude.

every time anthropic tightens access to protect its models, the evasion doesn't stop. it migrates.

geoblocking produced vpn services. phone verification produced sms farms. credit card requirements produced stolen card networks. biometric kyc — live selfies, government id matching — produced agents traveling to lower-income countries to recruit real people willing to complete in-person verification for cash.

the controls and the evasions are a paired system. you can't have one without the other. and the cost of the evasion doesn't stay where the models are. it moves to wherever people are poor enough to trade their biometric data for $30.

the fable shutdown made this visible in a new way.

on june 12, 2026, anthropic disabled fable 5 and mythos 5 for every customer worldwide — not because of an outage, not because of a flaw they found, but because the us government issued an export control directive at 5:21pm Anthropic's official statement and there was no way to segment foreign nationals from us persons in real time. so they turned it off for everyone.

gabriel attal compared it to iran blockading the strait of hormuz AI Frontiers Media. brussels talked. developers in san francisco talked about reliability. nobody talked about cambodia.

the transfer station economy — documented in may 2026 by oxford researcher zilan qian ChinaTalk, May 5 2026 — has been running this supply chain in public for years. github. taobao. telegram. chinese developers accessing claude at 10% of official price through api proxies that sit between them and anthropic's infrastructure.

the three ways the price gets that low:

first, account arbitrage — bulk-registered free credits, unused quotas, carved-up max plans.

second, model swapping — you pay for opus, you get haiku, sometimes you get glm. you can't verify which model answered you.

third, the logs. every prompt, every response, every tool call, every reasoning trace sitting on a proxy operator's server. for a developer using claude code, that's your repository context, your engineering decisions, your verified correct outputs. the markup business is customer acquisition. the logs are the margin.

but the third meal isn't just data extraction. the upstream supply chain that keeps the proxy pool running needs verified accounts. verified accounts need identities. identities increasingly need biometrics. and biometrics, when ai deepfakes get good enough to detect, need real humans.

so agents go to cambodia. agents go to kenya. they find people willing to complete verification for under $30. those faces enter a database. that database doesn't stay in the claude access supply chain.

the chinese developer paying 10% for tokens didn't order this. they're trying to build something with the same tools everyone else has, priced out by geography the same way a developer in lagos is priced out by latency and infrastructure. neither of them sees the person whose face just got harvested in cambodia. neither of them chose the system that makes that harvesting profitable. they're both downstream of a fight they didn't start, between parties who will never absorb the cost themselves.

the worldcoin black market documented this pattern before anyone was paying attention. iris scans harvested in cambodia and kenya, sold for under $30. the same infrastructure. the same geography. the same people absorbing costs they didn't choose.

this isn't new. content moderators in kenya process trauma for platforms they'll never use. data labelers in colombia annotate images for models trained in san francisco. the biometric harvesting is the same supply chain, one layer deeper.

a face verified to bypass anthropic's kyc today can be resold to open a fraudulent bank account tomorrow. it can generate a deepfake. it can be used for blackmail. the original subject in the global south bears the legal and reputational consequences of a transaction that had nothing to do with them.

i build in port harcourt. every api call i make crosses an ocean and costs latency i can't engineer away. i wrote about that recently — the physics problem nobody warned you about.

this is the other side of that piece.

the infrastructure gap isn't just latency. it's who absorbs the externalities of the access war. when two parties fight over who gets to use a model, a third party — somewhere with weaker institutions, fewer legal protections, and more financial pressure to say yes to $30 — pays the cost neither of the original parties wanted to carry.

that's not a side effect.

the controls will keep tightening. fable has been offline for seventeen days. mythos was partially restored on june 27 — only for critical infrastructure organizations the us government specifically approved. general users, developers, international subscribers are still waiting. gpt-5.6 is next in line for the same review process. each new restriction produces a new evasion layer, and each evasion layer reaches further down the economic ladder to find humans willing to be part of the supply chain for cash.

the people performing outrage about ai access — in brussels, in san francisco, in policy papers — are arguing about the front of the supply chain. nobody is arguing about the back.

someone else is paying for your claude access. you won't read about them in the policy papers.

AI helped me research, structure, and edit this piece. The arguments, the examples, and the opinions are mine. So is whatever's wrong with them.