DEV Community: Michael Amachree

AI didn't make me a worse coder. It made me a worse reviewer.

Michael Amachree — Fri, 21 Aug 2026 22:10:19 +0000

I built a lot of apps last year. I approved most of the code and commits that went into them, and a good portion of it I could not explain.

Not "couldn't explain to a junior." Couldn't explain to myself. The tests were green, the diff looked like something I would have written, and I hit approve. If you had stopped me forty minutes later and asked why that function needed a lock, I would have had to go read it again like it was someone else's code.

Which, in a sense, it was. And because most of these were my own projects, there was no second reviewer downstream of me. I was the entire quality gate — and the gate had quietly stopped reading.

I am not going to pretend this is a novel observation. If you read dev.to you have already seen this post four times this spring, and if you read r/ExperiencedDevs you have seen the thread where someone calls themselves "a tourist in their own codebase" and four hundred people say yeah, same. One in five developers in the 2025 Stack Overflow survey picked "I've become less confident in my own problem-solving" as a top frustration with AI tools. The fear is not underreported. It might be the most reported feeling in software right now.

So this isn't a diagnosis post. The diagnosis is done. What I couldn't find anywhere was an honest answer to the next question: every fix anyone proposes for this has the same shape, and that shape is known to fail. Including the one I spent two weeks designing.

That's what I want to work through, and then I want to ask you something.

What actually decays

The reframe that finally made this click for me came from aviation, and it's about thirty years old.

When researchers tested airline pilots who had trained on manual flight but then spent their careers flying highly automated aircraft, they found something specific. The procedural skills — scanning instruments, hand-flying the aircraft — were rusty but largely intact. The pilots could still fly the plane.

What had cratered were the cognitive skills. Maintaining awareness of where the aircraft actually was. Tracking what the next step should be. Recognizing and handling an instrument failure. (This is Casner et al., 2014; the FAA's response was to recommend that pilots hand-fly for the majority of flights.)

Read that again with your own job substituted in. The typing survives. The model in your head is what goes.

A 2024 review by Brooke Macnamara and colleagues in Cognitive Research extends this to AI assistants specifically, and makes the argument sharper than I would have dared: because AI mimics cognitive work rather than mechanical work, and because cognitive skills decay faster than physical ones, AI-induced skill decay should be worse than the automation decay we already documented in cockpits.

That's the reframe. It isn't that AI makes you slow at writing code. It's that AI is very good at the exact part of the job that used to build your judgment as a side effect, and the judgment does not maintain itself in storage.

Which matters, because look at what the job is now. Reviewing. Catching the thing the model was confident about and wrong about. Knowing what to build. Deciding when the plausible answer is the wrong answer. Every one of those is the cognitive column, not the procedural one. We have automated our way out of the reps that produced the only skills we still get paid for.

You cannot feel this happening

Here's the part that changed how I think about the whole problem. There are three independent findings that all say the same uncomfortable thing: you are structurally unable to self-assess this.

One. Macnamara's review names the mechanism directly. Ordinary skill decay you notice, because you stopped doing the task. AI-induced decay hides, because you didn't stop doing the task — you kept shipping, kept reviewing, kept closing tickets. Only the cognitive engagement stopped. A surgeon still completing successful operations has no signal that their judgment has softened. Neither do you, with a green CI badge.

Two. METR ran a randomized controlled trial in 2025 with sixteen experienced open-source developers on 246 real tasks in their own repositories — projects averaging five years of their own contributions. Developers predicted AI would make them 24% faster. Afterward, they estimated they had been about 20% faster. They were 19% slower.

Sit with that. Not "they were wrong about the tool." They were wrong about their own experience, immediately after having it, on code they knew better than anyone. And the slowdown was worse on tasks where they had high prior experience. Whatever perceptual instrument you'd use to detect this in yourself, that study is the calibration check, and it failed.

Three. The classic testing-effect result from Roediger and Karpicke (2006): students who re-read material rated themselves more confident about remembering it than students who self-tested — and then recalled 40% versus 61% a week later. The re-readers read the passage 14.2 times on average. The testers read it 3.4 times. Re-reading felt like learning and wasn't.

Re-reading a diff until it looks fine is the same operation. It builds confidence and not much else.

So: the decay is invisible by construction, our self-reports are demonstrably inverted, and the review habit we all use produces exactly the false confidence the memory research warns about. Any solution that depends on noticing you have a problem is dead on arrival.

Try this before you read on

Two minutes, on your own code. I'd genuinely like to know what happens.

Open the last commit or PR you shipped that an AI mostly wrote. Don't read it yet.
In a scratch file, write what it does, why it was needed, and what breaks if you delete it.
Now read the diff.

Note where you stalled. Not whether you were "right" — where you stalled.

This has a name in cognitive science: the illusion of explanatory depth (Rozenblit & Keil, 2002). People rate their understanding of how things work as high, are asked to produce an actual causal explanation, and then revise their own rating sharply downward. The effect is much stronger for explanatory knowledge than for facts or procedures — meaning it's strongest for precisely the kind of knowing that code review requires. It's also strongest when the mechanism is visible in front of you, which is a fairly brutal description of reading a diff and feeling like you understand it.

The MIT Media Lab found a version of this last year: participants who wrote essays with an LLM struggled to quote the essay they had finished minutes earlier. Small study, preprint, treat it lightly. But "I shipped this and can't quote it" is a sentence I recognize.

Why I'm not building a skill score

My first instinct was a dashboard. Measure me. Your coding ability: 73% and falling. A number, a trend line, and enough dread to keep me honest.

I'm glad I read the habit-formation literature before writing any code, because that idea is a known failure mode.

A CHI 2016 study looked at Lift (later Coach.me), one of the most popular habit apps of its era. Streaks and reminders did drive repetition — that part works. But they created a dependency: the behavior was attached to the app rather than to the person. Users performed for the streak. And then, inevitably, they stopped opening the app — the same paper notes the wider pattern, that around 74% of users abandon health apps after ten uses — and the behavior went with it. The authors' framing is that these features introduce fragility into exactly the thing they were meant to make durable.

Extrinsic reward crowding out the internal motive is old, well-replicated psychology. A skill score is that trap wearing a developer hat: gamified anxiety. It tells you you're declining, which feels bad, which makes you avoid the tool, which makes the number worse. Week two you uninstall it.

And there's a cleaner objection. A score measures output. Understanding isn't output — it's a capacity, and the only way to observe a capacity is to make someone use it. You cannot report understanding. You can only demonstrate it.

Why the usual advice doesn't work either

This is the part I expect people to argue with, so let me be careful.

Every article on this topic — including the good ones — ends with roughly the same list:

have no-AI days
try it manually for fifteen minutes first
20–30 minutes of unassisted problem-solving daily
close the tool and explain every line out loud
write the architecture yourself

None of this advice is wrong. I think all of it works, when done. But look at the shape of it: every item is discipline-shaped, scheduled, and outside the workflow. It's a separate practice, competing for time, sustained by willpower, with no cue and no consequence for skipping it.

That is structurally the same object as the habit app. It's the pre-app version of the same object. And the reason to expect it to fail is the reason the article gave you in paragraph one: you're being asked to voluntarily add friction to fix a problem you cannot perceive yourself having, using time pressure as the counterweight, in an industry that measures you on what you shipped, never on whether you understood it.

Also — the specific advice to "rotate AI-free days" is trying to solve skill decay with abstinence, and the research doesn't actually support that framing. Which brings me to the useful finding.

The finding that changed the design

In January 2026 Anthropic published a randomized controlled trial (Shen & Tamkin) that is, as far as I can tell, the most directly relevant study that exists. 52 mostly-junior engineers learned Trio, an async Python library none of them knew. Half had an AI assistant; half had docs and web search.

The headline is grim and got all the coverage: the AI group scored 50% on the comprehension quiz versus 67% for the hand-coders — about two letter grades, on concepts they had used minutes earlier. The largest gap was on the debugging questions, which is the precise skill you need to catch bad AI output. The speed advantage was about two minutes and wasn't statistically significant. Same speed. Much less understanding.

But the finding nobody quotes is the one underneath it. The researchers identified six distinct interaction patterns, and three of them preserved learning even with full AI assistance. High scorers averaged 65–86%. Low scorers were under 40%. Same tool, same time budget, double the comprehension.

The three that worked all involved cognitive engagement at the moment of generation:

generate the code, then ask follow-up questions about it
ask for code and an explanation together
ask conceptual questions, then write the code yourself

The three that failed: delegate wholesale, drift into delegation over the session, or use the AI to iteratively fix things without ever understanding them. (Participants in that last group were also slower.)

So the variable is not how much AI you use. It's whether an act of retrieval or explanation happens at the point of use. That's a much smaller intervention than "no-AI Fridays," and unlike willpower, it's the kind of thing software can put in front of you at the right moment.

Microsoft Research and CMU landed in the same place from a different direction at CHI 2025. Surveying 319 knowledge workers across 936 real AI-assisted tasks, they found higher confidence in the AI predicted less critical thinking, while higher confidence in your own ability predicted more. Their design recommendation was for tools that use "proactive prompts" and act as a provocateur rather than an answer machine.

I read that and realized the intervention I wanted had already been specified by people with better data than me. Nobody had built it into the place where the work actually happens.

What I want to build

Not a score. Not an app. A review-time forcing function — something in the hook or MCP layer between the agent and the merge, where I already am.

The agent drafts a change. Before I can rubber-stamp it, it asks me one question:

What does this change do?
What breaks if we remove it?
Where's the edge case this misses?

Then it does the part that makes it more than a journaling prompt: it compares my answer to the actual diff and shows me where my model diverged. Over time the signal isn't a vibe, it's a record — did my explanation match the code? Did I flag the thing that later broke? That's review accuracy and bug-catch rate, which are evidence, not a self-report.

Design constraints, all of them derived from something above rather than from taste:

In-workflow, not an app. Out-of-workflow practices are the failure mode of the entire genre.
One question, ~20 seconds. Anything longer loses to delivery pressure, which is the honest reason none of us do the 20-minute practice.
No score, no streak, no dashboard. Lift, and everything downstream of Lift.
Explanation-shaped, not recall-shaped. The illusion of explanatory depth is where the gap is largest; quizzing trivia would miss it.
Retrieval before review, not after. Roediger & Karpicke — you have to attempt the answer before seeing the material, or you've just re-read the diff with extra steps.

The adjacent shape I keep sketching is spaced repetition over your own codebase — Anki for the repo. "Why does this function exist?" "What would break if you deleted it?" I think it's weaker: it's out-of-workflow again, and it drifts toward recall when the thing that matters is explanation.

Where I think this might be wrong

Three real holes, and I'd rather name them than get talked out of them in the comments.

It might become another rubber stamp. Anything mandatory gets gamed. I'd type "makes the retry idempotent" seventeen times a day without thinking. Every forced-friction tool ever built has hit this wall, and I don't have a good answer beyond "vary the question and only fire on non-trivial diffs," which is a hope, not a design.

Something has to grade the explanation, and that something is an AI. Which means I'd be offloading the assessment of whether I understood something to the same class of system whose output I stopped understanding. I think this is survivable — comparing my prose against a diff is a much narrower task than generating the diff — but I notice the shape of it, and it bothers me.

The friction lands in the wrong place. 66% of developers say their top AI frustration is code that's "almost right, but not quite," and 45% say debugging AI output already takes longer than writing it themselves. Those people are not short on friction. Adding a question to their review might be adding a tax to the exact step that's already the expensive one.

The question

I'm asking because I have a rule against starting things right now — one flagship for 90 days, everything else goes in a parking lot file. This idea is in the parking lot. It comes out only if the reaction here says it should, so this is a real question with a real consequence, not a call to action.

Three things, and short answers are genuinely more useful than long ones:

Did you run the two-minute test above? What happened — did you stall, or was it fine? Just say "stalled" or "fine" if that's all you've got. I especially want to hear "fine," because if most people are fine then I've written 1,800 words about my own bad habits.
What's your actual anti-atrophy practice — not the one you'd recommend, the one you did this week?
Would you install this? And if you think it's a bad idea, say so plainly. "This would annoy me into uninstalling it in a day" is the most useful comment I could get, and it costs you one line.

I've been assuming that because I can feel the erosion, a tool should exist. The research above says pretty clearly that my feelings about my own competence are not evidence. Yours might be worth more than mine.

Sources, if you want to check my work: METR RCT (2025) · Shen & Tamkin, Anthropic (2026) · Macnamara et al., Cognitive Research (2024) · Lee et al., CHI 2025 (PDF) · "Don't Kick the Habit," CHI 2016 · Roediger & Karpicke (2006) · Rozenblit & Keil (2002) · Stack Overflow Developer Survey 2025

The cheapest model on my plan loses every benchmark. It still beats models charging 14x more.

Michael Amachree — Fri, 21 Aug 2026 20:38:31 +0000

The cheapest model I can run on my plan costs $0.14 per million tokens. The one I actually reach for costs $0.44. I put them side by side expecting the cheap one to be close.

It lost all four benchmarks. Coding, reasoning, math, real-world bug-fixing — four for four.

I'm still recommending it. Not because it competes with the good models. Because of what it does to the models in the middle.

The trade, stated plainly

	MiMo-V2.5	Deepseek v4 flash
Input / 1M	$0.14	$0.44
Output / 1M	$0.28	$1.32
Requests per 5h window	30,100	7,600
Coding	56.8	69.1
Reasoning	38.0	51.8
Math	85.0	86.0
Bug-fixing (SWE-Bench)	43.1	49.9

Two numbers matter more than the rest. MiMo gives you roughly four times as many requests before your window empties, at a third of the input price. And it gives up twelve points of coding ability to do it.

That's the whole decision. Not "which model is better" — which resource you're actually short on.

Where my instinct was wrong

I went in believing the cheap models had quietly caught up. The number I expected to find was a two- or three-point gap.

Math cooperated: 85.0 against 86.0. One point. That's noise, and it's a real result — for arithmetic-heavy work the cheap model is simply fine.

Reasoning did not cooperate. 38.0 against 51.8 is a 27% drop, the widest gap of the four. On paper that reads like a rounding difference. In practice it's the difference between a model that follows a four-step refactor and one that loses the thread at step two and confidently ships step three.

So "close enough" was wrong, and it was wrong in the direction that costs you the most: the reasoning gap is exactly the gap you feel when you hand a model something ambiguous.

The comparison I should have run first

The interesting fight was never cheap-versus-best. Look at what sits between them.

Model	Coding	Input / 1M	Requests / 5h
MiMo-V2.5	56.8	$0.14	30,100
Qwen3.7-Plus	55.9	$1.20	4,300
GLM-5.1	55.8	$1.40	880
Qwen3.6 Plus	54.5	$2.00	3,300

The $0.14 model beats all three.

Qwen3.6 Plus charges fourteen times more per input token and codes a point and a half worse. GLM-5.1 charges ten times more, scores a point lower, and burns your quota thirty-four times faster — 880 requests against 30,100.

That's the finding. The floor didn't rise to meet the ceiling. It rose to swallow the middle. Every model priced between one and two dollars is now paying a premium for benchmark scores it doesn't actually have, and the only reason that isn't obvious is that nobody puts price, benchmark, and quota burn in the same row.

Which is the entire reason I built the thing.

Why "cheapest" needs an asterisk

MiMo-V2.5 isn't literally the cheapest model on my plan. There's one below it: Muse spark 1.2 contributor, at $0.10/$0.20, with 45,300 requests per window and a coding score of 72.2 — better than DeepSeek, at a quarter of the price.

That combination doesn't happen by accident. The word contributor is sitting right there in the model name. I don't have documentation explaining the arrangement, so I'm not going to assert one. I'll say this instead: when one model is cheaper, faster-burning, and better than everything around it, the price is buying something other than compute. Treat it as an outlier until you know what.

Set it aside and MiMo-V2.5 is the floor. Hy3 ties it on input price at $0.14 and actually out-codes it slightly at 58.8 — but charges twice as much on output and gives you 4,300 requests instead of 30,100.

What I got wrong building this

The first version of my burn scoring inferred quota cost from price. Cheaper token, slower burn. It seemed obviously true.

It was wrong, and it was wrong in an embarrassing direction: it ranked expensive models as quota-hungry even when the provider gave them generous request allowances, and it flattered cheap models that burn through a window fast. I was measuring the thing I could see instead of the thing I cared about.

The fix was to stop inferring and start reading — the published request counts per window, straight from the docs. That's when the table started disagreeing with my intuitions, which is when it started being useful. The MiMo-versus-middle finding above only exists because burn stopped being a function of price.

There's still a bug I haven't fixed: at the low end, a couple of models render a burn band that disagrees with their own request count. It's on my list. I'd rather say that here than have you find it.

What this doesn't tell you

Benchmarks are a proxy and a coarse one. A twelve-point coding gap is real, but I can't tell you it maps cleanly onto your codebase, your language, or your prompting habits. Some of these scores come from different evaluation suites and get normalized to sit in the same column — that normalization is a judgment call, and it's mine.

Nothing here is hand-curated. Scores, tags, and burn bands are all computed from three upstream sources, so when they update, my conclusions change without my permission. That's the design. It also means I'm occasionally wrong in public.

And I have no historical data. I can tell you what the board looks like right now. I can't tell you what moved.

The part I actually want to argue about

I think most people pick a model once, by reputation, and never revisit it — and then spend the rest of the month rationing requests they didn't need to ration.

The table is free, needs no account, and links every number back to its source: zp.svelte-apps.me · code at github.com/Michael-Obele/zenpick · open an issue if a number looks wrong to you, because sometimes it is.

So: when you're choosing a model, are you short on capability or short on requests? I've been answering that question wrong for months — optimizing for the smartest model I could afford, then quietly avoiding using it. Curious whether anyone else has caught themselves doing the same thing.

I Got Tired of Guessing OpenCode Go Models — So I Built a Live Fit + Burn Dashboard

Michael Amachree — Wed, 29 Jul 2026 05:55:02 +0000

I Got Tired of Guessing OpenCode Go Models — So I Built a Live Fit + Burn Dashboard

zp.svelte-apps.me · open source: github.com/Michael-Obele/zenpick

TL;DR

OpenCode Go is $10/month for 13+ curated open coding models — the first month is $5 anyway (their standard intro offer), and if you sign up through my link we each get an extra $5 credit on top. The hard part isn't the price — it's picking the right one without torching your quota. ZenPick is the focus here: it's a free, open-source dashboard that ranks every Go model by task fit and quota burn so you can decide in 10 seconds. Built with Svelte 5 + SvelteKit.

The decision that actually hurt

OpenCode Go is a strong deal. One subscription, $10/month, 13+ models. DeepSeek, Qwen, Kimi, GLM, MiMo, and more.

But Go usage limits are defined in dollar value, not request counts.

Pick a cheap workhorse and you can run tens of thousands of requests per 5-hour window. Pick a premium reasoning model and you might land under a thousand in the same window.

Same tier, wildly different economics. Pick wrong for a long agentic session and you can burn a large chunk of your monthly quota in an afternoon. Pick too cheap for a hard reasoning task and you waste hours on weak output.

The docs give you a markdown table. Cross-referencing benchmarks, request volume, pricing, and task fit across 13+ models in a table is a bad developer experience.

So I built ZenPick.

Three questions, answered fast

1. Which model fits my task?

Every model gets an algorithmic fit score (0–100) across six scenarios:

Brainstorming — open-ended ideation, long context
Coding — coding benchmarks + tools/speed/uptime fit
Competitive — hard one-shot reasoning
Agentic — long multi-step runs, stability signals
Frontend UI — Design Arena Elo + intelligence + coding
Budget — cheapest option that still ranks

Scores are weighted blends of real signals — Artificial Analysis TrueSkill for coding, Design Arena Elo for UI preference, context and tooling for agentic fit. Missing data doesn't zero a model out of the ranking. The table is never empty, and ordering stays meaningful.

2. How fast will it burn my quota?

Each model gets a thermal burn classification from blended price per million tokens:

❄️ Slow burn (< $1.50) — volume workhorse
🌡️ Moderate ($1.50 – $6.00) — daily driver
🔥 Fast burn (> $6.00) — premium / focused sessions

The table also surfaces request estimates per window so the economics are visible before you start a long run.

3. What does it replace from a closed-source workflow?

Open any row's detail drawer for migration hints — e.g. if you used a frontier Sonnet-class model, which Go model is the closest practical stand-in. Plus pricing, benchmarks, quota estimates, and one-tap model ID copy for your OpenCode config.

What actually shipped

Scenario pills + search. Tap Brainstorming, Coding, Competitive, Agentic, Frontend UI, or Budget. The table re-ranks by fit for that job. Search narrows by name or provider. You can go from "13+ models" to "two agentic options that won't torch quota" in a few seconds.

Sortable model table. Sort by name, benchmarks, price, quota requests, scenario fit, or burn. Scenario filter and sort are independent — e.g. Budget scenario, then sort by coding score.

Model drawer. Click a row for benchmark bars, pricing per 1M tokens, request estimates (5h / week / month), migration hints, Add to compare, and Copy model ID.

Side-by-side compare (up to 4). Open Compare. Each row highlights the winner; ties stay unhighlighted. Benchmarks, pricing, context, speed, burn, scenario fit, tags, and migration sit in one grid.

Ask AI. From compare, jump into Grok, ChatGPT, Claude, or Gemini with a pre-filled prompt that already includes the live ZenPick stats for the selected models. You bring the task; the context is already there.

Quota calculator. Estimate tokens per request for your session pattern and see how request counts shift. Official tables assume fixed patterns; real agent runs often don't.

The build

Stack: Svelte 5 runes · SvelteKit · Tailwind v4 · shadcn-svelte · Bits UI · Bun.

Remote functions for data. Model loading lives as a SvelteKit remote query, not a pile of ad-hoc client fetches. It fetches Go models, modelgrep, and llm-stats in parallel, matches each Go model across sources, runs inference (tags, scenario scores, burn, migration hints), and serves through a 6-hour stale-while-revalidate cache. So you get a fast page and data that isn't days old, without burning your own rate limits.

Multi-source blending, honest and field-specific. You can't naively average every benchmark. Methodologies differ.

Field	Primary	Fallback / blend
Coding	modelgrep AA TrueSkill	llm-stats only if modelgrep missing — no average (different scales)
Reasoning	modelgrep AA TrueSkill	llm-stats only when outlier-safe
Math	GPQA + llm-stats math	Blend when both are 0–1 accuracy-style scores
Design Arena Elo	modelgrep	—

False precision is worse than a clear primary source. The UI prefers honesty over a single "magic number."

Algorithmic scenario scoring. Each scenario has its own weighted blend. The Frontend UI score leans heavy on Design Arena Elo (human preference), with some general intelligence and a touch of coding. If every input is missing, the model gets a neutral floor (0.5) — not zero — so the table stays comparable. The pattern repeats for the other five scenarios with their own field weights.

Svelte 5 runes end-to-end. No legacy $: or export let. UI state uses $state / $derived / $props. Compare selection is a small client store; the compare route keeps ?models= in sync for shareable links.

What I learned

1. Benchmark field names lie. Upstream labels aren't always what they sound like. Verify what a score measures before you put it in a column header. One wrong label trains users to distrust the whole table.

2. Blending requires methodology discipline. Averaging TrueSkill-style ranks with 0–1 composites produces a number that feels precise and is nonsense. Field-specific primary/fallback rules beat "average everything."

3. Continuous fit scores beat tags. v1-style tag filters (coding, tools) go stale and create fake ties. A 0–100 score from live signals is harder to build and much more useful.

4. Stale-while-revalidate is the right default for this dashboard. Nobody needs millisecond-fresh Elo on every paint. They need a fast page and data that isn't days old. 6h TTL + SWR hits both.

5. Compare + Ask AI closes the last mile. A ranked table answers "what's good." A 4-model grid + a pre-filled AI chat answers "for my task, tonight, which two should I try?"

Quick picks (starting points — not guarantees)

Live scores move. Treat this as a compass, then verify in ZenPick:

Use case	Start here
Daily workhorse / high volume	DeepSeek V4 Flash (slow burn, high request density)
Hard reasoning + tough coding	Qwen3.7 Max (premium; use deliberately)
Long agentic sessions	MiMo-V2.5-Pro or Kimi K2.7 Code
Max requests / tight budget	Cheapest strong coding option in the Budget scenario (often MiMo-class)
Frontend / UI generation	Highest Design Arena / Frontend UI fit in the current lineup

If your real sessions disagree with the table, that's useful signal — open an issue.

Try it

🔗 Live: zp.svelte-apps.me
📦 Source: github.com/Michael-Obele/zenpick
📄 About / methodology: zp.svelte-apps.me/about
⚖️ Compare: zp.svelte-apps.me/compare
💰 OpenCode Go — $10/month, 13+ models. First month is $5 standard; my link adds another $5 credit on top (we both get it).

modelgrep and the OpenCode Go model list work without keys; llm-stats enrichment is better with an API key.

Already on GitHub Copilot in VSCode? You can route OpenCode Go through your existing setup with the opencode-go-copilot-provider extension — no separate config dance. (I use it myself; ZenPick picks the model, the extension routes it.)

Honest limitations

Fit scores and burn tiers are derived, not hand-curated editorials.
Benchmarks lag releases; a brand-new Go model may show thin data until upstream catches up.
Request estimates depend on assumed token patterns — use the calculator for your workflow.
ZenPick doesn't replace reading OpenCode Go docs for billing, privacy, and plan rules.

What's your biggest Go pain right now?

Is it picking the right model, budgeting the burn, migrating from a closed-source workflow, or something else entirely?

I'm collecting real stories from people using OpenCode Go to figure out what to build next. Drop a comment with your Tuesday problem — I'll dig into the patterns.

Built with Svelte 5, SvelteKit, Tailwind v4, shadcn-svelte, and Bun.
Data attribution: modelgrep, llm-stats, OpenCode Go — see the About page.

I Built Tech Invoice Forge: an Offline-First Invoice App for Tech Freelancers

Michael Amachree — Fri, 03 Apr 2026 13:03:59 +0000

Most invoicing tools follow the same pattern: create an account, connect to a cloud app, hand over your data, and pay monthly for the privilege of sending a PDF.

That model works for some people. It never felt right for me.

I wanted something simpler: a professional invoicing tool that runs entirely in the browser, stores data locally, works offline, and generates clean PDFs instantly without a backend. That is what Tech Invoice Forge is.

Tech Invoice Forge is a local-first invoice and receipt generator built for tech professionals, freelancers, and small teams who want speed, privacy, and control without subscription friction.

What Tech Invoice Forge does

At its core, Tech Invoice Forge lets you create invoices, preview them live, save them locally, and export them as PDFs or JSON.

The experience is intentionally straightforward:

Fill in sender and client details
Add line items, tax, and discounts
Watch the PDF preview update as you type
Save everything locally in the browser
Download the finished invoice instantly

There is no account to create and no server round trip for the core workflow.

Why build it this way?

I kept running into the same frustration with cloud invoicing software: too much overhead for a simple task.

If all I need is to generate a clean invoice and send it, why should I have to:

create an account
trust a third-party cloud database
wait for server-side rendering
pay for features I do not need
worry about my invoice history living somewhere else

Tech Invoice Forge is my answer to that problem.

The goal was not to make a bloated finance platform. The goal was to make a fast, reliable, privacy-first invoicing tool that feels like a native part of the browser.

What makes it different

Tech Invoice Forge is built around a few ideas that matter a lot in practice.

It works offline by default

All core data lives locally in IndexedDB. That means invoices, client records, and profile details stay on the device unless you choose to move them elsewhere later.

It gives instant feedback

The invoice preview updates as you type, so you can see the final document without waiting for a server response.

It keeps the workflow lightweight

The app includes the essentials without forcing unnecessary complexity:

sender profile management
saved client records
invoice history
multiple templates
currency support
notes and terms
PDF export

It stays out of your way

The app is designed to feel clean and professional, not crowded. You can open it, create an invoice, and get back to work quickly.

A quick tour of the product

The public site is split into a few simple experiences.

The landing page positions the app as a local-first alternative to cloud invoicing tools. It focuses on the promise: no accounts, no backend, no monthly subscription just to create a PDF.

The pricing page makes the product direction explicit. There is a Local Edition for people who want a self-contained workflow, and a Cloud Sync waitlist for users who may eventually want cross-device access and team features.

The invoice editor is where the product matters most. It includes sender details, client details, invoice metadata, line items, discounts, notes, and a live preview panel that shows the rendered result as you work.

The profile area keeps business details and client data organized so creating the next invoice is faster than starting from scratch every time.

The stack behind it

I built Tech Invoice Forge with a modern Svelte stack because the product benefits from being fast and reactive at the UI layer.

The current stack includes:

Svelte 5
SvelteKit 2
Tailwind CSS v4
IndexedDB for local persistence
Valibot for validation
pdfmake for PDF generation
Lucide icons for the interface
Bun for development

That combination fits the product well. The browser handles the entire workflow, and the app stays responsive while the user is entering data and previewing documents.

What I learned building it

The biggest lesson was that local-first software can feel better than cloud software when the problem is narrow and repetitive.

For invoicing, most users do not need a giant platform. They need:

speed
privacy
reliability
good defaults
a clean export path

When you remove the account wall and the backend dependency, the product becomes easier to trust and easier to use.

I also learned that a small set of thoughtful features is usually more valuable than a long list of generic ones. If the preview is instant, the data is local, and the PDF looks professional, the app already solves the core job.

Who this is for

Tech Invoice Forge is a good fit for:

freelancers who want a fast invoice workflow
developers who prefer local-first tools
agencies that want a lightweight billing tool
anyone who does not want their invoice data tied to a cloud account

If you care about privacy, portability, and a low-friction workflow, this kind of app makes a lot of sense.

Closing thoughts

I built Tech Invoice Forge because invoicing should not feel like signing up for another subscription service.

It should feel like opening a tool, doing the work, and getting a clean result immediately.

If that sounds useful, try the live demo and see how it feels in practice.

Live demo: https://tif.svelte-apps.me

GitHub: https://github.com/Michael-Obele/tif

DocShark: a local-first documentation MCP server for AI

Michael Amachree — Thu, 19 Mar 2026 10:39:23 +0000

DocShark: documentation for AI, served locally

Most AI tools are only as good as the documentation they can reach.
When the docs are spread across websites, rendered client-side, or buried behind a maze of pages, the context you get back is often incomplete or stale.

That is the problem DocShark is built to solve.

DocShark is a fast, local-first Model Context Protocol server that scrapes, indexes, and serves documentation from any website. It turns documentation into a local knowledge base that your AI tools can search instantly, without depending on a cloud service or an API key.

Live site:

dsharkd.svelte-apps.me

GitHub: https://github.com/Michael-Obele/docshark

What DocShark does

At a high level, DocShark does four things well:

Crawls documentation websites.
Extracts the useful content and converts it to clean Markdown.
Breaks pages into context-aware chunks.
Makes the result searchable through MCP and the CLI.

The result is a local documentation layer that works with coding agents, desktop clients, and terminal workflows.

Why I built it

There are already tools that can fetch docs, but many of them only work for a narrow source type or rely on heavier infrastructure.

DocShark focuses on a simpler model:

documentation websites, not just GitHub repos
local storage, not a remote index
SQLite FTS5, not a hosted search backend
Bun-first tooling, not a large runtime stack
MCP compatibility, so AI clients can use it directly

That combination makes it useful both for individual developers and for people building agent workflows.

How DocShark compares

Context7 is the obvious comparison point because it also solves the "AI needs current documentation" problem. It is strong when you want a hosted documentation service that injects up-to-date library docs and examples into your prompt.

DocShark takes a different path. It is better when you want to index real documentation websites, keep everything local, avoid API keys and rate limits, and use one tool for both MCP and CLI workflows.

Here is the practical tradeoff:

Tool	Strengths	Limitations	Where DocShark wins
Context7	Fresh version-specific docs, code examples, MCP integration, polished onboarding	Cloud service, API key/rate-limit considerations, focused on supported libraries rather than arbitrary websites	DocShark is better if you want a local-first index for any documentation site and no external dependency
Docfork	Broad library coverage, up-to-date docs, open source, easy access to software library docs	Optimized for library documentation rather than arbitrary rendered documentation sites	DocShark is better for crawling and indexing any docs website, including custom or rendered docs
Deepcon	Strong documentation retrieval for AI workflows, cloud-hosted convenience	More service-oriented than local-first, and it is narrower in how you manage your own source set	DocShark is better if you want to own the index and control exactly what gets crawled and stored
GitMCP / GitHub repo tools	Great for repository-centric docs and code browsing	Best when the source of truth lives in GitHub, not when the docs are published on a separate site	DocShark is better for public docs sites, rendered pages, and documentation that is not tied to one repo
Per-library MCP servers	Very targeted, often simple to set up for one project	They do not scale well when you need to switch between many libraries	DocShark is better as a single general-purpose server for multiple sources

If you want the shortest summary: Context7 is a strong hosted documentation service, but DocShark is the better alternative for local-first workflows, broader website coverage, and users who want to keep the whole documentation layer under their control.

Core features

Any documentation site

DocShark is not limited to source repositories. It can crawl public documentation sites and index their rendered content, which makes it useful for modern docs that are built from multiple routes, dynamic pages, or generated content.

Smart extraction

The scraper is designed to pull out the main content and discard the noise. Navigation, sidebars, and other non-essential layout elements are removed so the indexed result is easier for an AI assistant to use.

Semantic chunking

Pages are split by heading structure so the search results preserve context. That matters because a search result is only useful if it still knows where it came from in the document.

SQLite + FTS5 search

DocShark uses SQLite with FTS5 for full-text search, which keeps the entire experience local and fast.

That gives you:

instant keyword search
offline access once content is indexed
no external search provider
no dependency on cloud APIs

JS-rendered site support

Many docs sites are not simple static HTML pages.
DocShark supports rendered documentation sites, so it can work with sites that rely on JavaScript for content delivery.

Polite crawling

The crawler respects site structure and includes rate limiting and robots-aware behavior so it is safer to use against public documentation sites.

MCP server + CLI

DocShark exposes the same knowledge base through both an MCP server and a Bun-first CLI. That gives you two ways to work:

agent integrations for AI tools
direct terminal commands for indexing, searching, and maintenance

The workflow

Using DocShark usually looks like this:

1. Add a documentation site

Point DocShark at a docs URL to begin crawling:

bunx docshark add https://svelte.dev/docs

2. Search the indexed content

Once the content is indexed, you can search for the exact topic you need.

bunx docshark search "query syntax"

3. Connect your AI tool

Because DocShark speaks MCP, you can connect it to compatible clients and let the assistant query your documentation library directly.

{
  "mcpServers": {
    "docshark": {
      "command": "bunx",
      "args": ["-y", "docshark", "start", "--stdio"]
    }
  }
}

CLI features

DocShark includes a practical set of commands for day-to-day use:

Command	What it does
`start`	Runs the MCP server in HTTP or STDIO mode
`add`	Adds a new documentation source and starts crawling
`rename`	Renames an existing library without changing content
`search`	Searches the indexed documentation
`list`	Lists indexed libraries and their status
`refresh`	Re-crawls an existing library
`remove`	Deletes a library and its indexed content
`get`	Returns the full markdown content for a page
`info`	Shows details and indexed pages for a library
`update`	Checks for or installs a newer Bun release

That command surface makes the project useful even if you never connect it to an AI client.

MCP tools

On the protocol side, DocShark exposes a compact but useful toolset:

manage_library to add, rename, refresh, inspect, or remove a library
search_docs to search across indexed content
list_libraries to inspect what is available
get_doc_page to retrieve a full page in markdown form

Those tools are designed to map naturally to how people actually work with documentation.

What is inside the stack

DocShark keeps the stack intentionally small:

Bun for runtime and CLI execution
SQLite for persistence
FTS5 for search
Readability.js for extracting the main content
Turndown with GFM support for Markdown conversion
Valibot for validation
CAC for the CLI parser and command dispatch
TMCP for the protocol server
A shared library service that powers both the CLI and MCP server

The current MCP surface is intentionally compact:

manage_library for add, rename, refresh, inspect, and remove workflows
search_docs for ranked search
list_libraries for discovery
get_doc_page for full-page retrieval

That choice keeps the project local, fast, and easier to reason about than a larger server stack.

Who it is for

DocShark is a good fit if you:

use AI coding assistants regularly
want documentation access inside your editor or terminal
work with documentation sites that are not simple markdown repos
prefer local tools over hosted indexing services
want one general-purpose MCP server instead of many per-library integrations

Try it out

If you want to see the project in action, open the live site and source repo above.

Star DocShark on GitHub

Closing thought

DocShark is a small idea with a practical goal: make documentation available where AI tools already work, without handing your context over to a cloud service.

If you spend time jumping between docs tabs, terminal commands, and assistant prompts, it is the kind of tool that quietly removes friction from the whole workflow.

What Your AI Chat History Says About Your Love Life (A Valentine’s Roast)

Michael Amachree — Sat, 14 Feb 2026 22:40:34 +0000

It’s Valentine’s Day. The air is filled with the scent of roses, expensive chocolates, and the faint ozone smell of servers overheating.

While everyone else is out having candlelit dinners, some of us are right here, staring at a blinking cursor, asking a Large Language Model why our CSS grid isn't centering. But have you ever stopped to think that your relationship with your AI might be a mirror for your actual romantic life?

I took a look at the most common "AI conversation archetypes" among developers. Find your chat style below, and accept your diagnosis.

1. The "Fix This Immediately" Typer

The Logs:

"Error: undefined is not a function. Fix it."
"Still broken. Try again."
"Why did you import a library I don't have? REFOCUS."

The Diagnosis: The Toxic Ex.
You don't want a partner; you want a miracle worker who can read your mind without you communicating your needs. You provide zero context, demand immediate results, and threaten to switch to a different model the second things get difficult. In relationships, you’re probably the one who says "I'm fine" when you are absolutely, cataclysmically not fine, and then gets mad when your partner doesn't guess why.

Prescription: touch grass (or at least add a "please").

2. The Over-Explainer

The Logs:

"Hi! Hope you're having a good processing cycle. So, I have this React component—it's a button, but not just any button, it represents the existential dread of the user. I want it to be blue, but like, a sad blue? Here is the entire history of the project since 2019 for context..."

The Diagnosis: The Stage 5 Clinger.
You pour your heart out. You treat every prompt like a first date where you simply must explain your entire childhood trauma before the appetizers arrive. You crave deep connection and context, but you’re mostly just exhausting the token limit. In love, you’re sending 14-paragraph texts at 2 AM asking "What are we?" after one coffee date.

Prescription: Learn to summarize. Your AI (and your date) doesn't need to know about the legacy code from three years ago.

3. The "Just Copy-Paste" trust fall

The Logs:

"Write me a full auth system in Go."
(User copies code without reading it)
(User deploys to production)
(Production crashes)
"Why did you do this to me??"

The Diagnosis: The Hopeless Romantic.
You fall in love fast and hard. You trust blindly. You see a snippet of code that looks vaguely correct, and you’re already planning the wedding (deployment). You ignore all the red flags (security vulnerabilities) because you just want it to work so bad. When it inevitably breaks your heart, you blame the universe instead of your lack of unit tests.

Prescription: Code review is a love language. Use it.

4. The Gaslighter

The Logs:

"Are you sure that's the syntax? Pretty sure it's not."
"I think you're hallucinating. That library doesn't exist."
(AI apologizes)
"Actually, wait, you were right. But you should have been more confident."

The Diagnosis: The "It’s Complicated."
You enjoy the power dynamic. You like testing boundaries. You don't actually want the answer; you want to see if you can trick the other party into slipping up. This is a relationship built on intellectual one-upmanship. It’s exhausting, it’s petty, and frankly, it’s why you’re spending Valentine's Day arguing with a non-sentient neural network about the efficacy of var vs let.

Prescription: Admit when you're wrong. It’s sexy.

5. The "Prompt Engineer" Perfectionist

The Logs:

"Act as a senior Rust engineer with 20 years of experience, a PhD in CompSci, and a penchant for dry humor. Analyze this function using the Socratic method..."

The Diagnosis: The Checklist Dater.
You have a list of requirements for a partner that is longer than a webpack config file. You don't want a connection; you want a customized build. You spend more time tweaking your dating profile (prompt) than actually going on dates (coding). You are paralyzed by the idea that there might be a slightly better optimization out there.

Prescription: Sometimes npm install is good enough. Perfect is the enemy of "shipped."

So, who is your Valentine?

Whether you're treating your AI like a therapist, a junior dev, or a magical oracle, remember: at least the AI replies instantly and never judges you for eating pizza over the sink at 3 AM.

Happy Valentine's Day, devs. May your commits be clean, your tests pass, and your deployment pipelines remain green. ❤️

Day 12: The Grand Finale & New App Launch! (Countdown Timer)

Michael Amachree — Wed, 31 Dec 2025 19:41:28 +0000

🎄 Day 12 of 12 Days of Svelte Apps 🎄

We made it! To celebrate the finale, we are launching a brand new mini-app today.

🎁 Presenting: The Countdown Timer

🔗 Start counting: https://svelte-apps.me/apps/countdown-timer

Why we love countdowns

Did you know the first crowd countdown (in Times Square/NYC) only started in 1979? It's a surprisingly modern tradition.

We love them because they mark a "genesis moment"—when time resets and anything feels possible.

Features

This new app lets you:

Set a target date and time
See a live, ticking breakdown of Days, Hours, Minutes, and Seconds
Enjoy a distraction-free, beautiful interface

Thank You!

Thank you for following along with this 12-day series. We've explored everything from budget trackers to text summarizers.

The Svelte MiniApps collection is open source and growing. If you want to contribute in 2025, come join us on GitHub!

Happy Holidays and a Happy New Year! 🥂

Day 11: New Year, New Security (Password Generator)

Michael Amachree — Wed, 31 Dec 2025 19:40:03 +0000

It’s Day 11 of 12 Days of Svelte Apps 🎄

As we approach the New Year, it's the perfect time for a "Digital Deep Clean".

Verify your backups, unsubscribe from spam, and update your weak passwords.

Fact: "123456", "password", and "admin" are still the most leaked passwords in 2024.

Today's app: Random Password Generator.

🔗 Generate a key: https://svelte-apps.me/apps/random-password-generator
💻 View the code: https://github.com/Michael-Obele/Svelte-MiniApps/tree/main/src/routes/apps/(app)/random-password-generator

Why use this over a server-side tool?

Privacy.

This app runs entirely in your browser. The passwords generated never leave your device. There is no API call involved in the generation logic.

Features

Length Control: Go beyond 8 characters. Try 20+.
Character Sets: Toggle symbols, numbers, upper/lowercase.
One-click Copy: Grab it and paste it into your password manager.

Start 2025 secure.

Day 10: Visualize Your 2024 Code Journey (GitHub Tracker)

Michael Amachree — Wed, 31 Dec 2025 19:38:57 +0000

It’s Day 10 of 12 Days of Svelte Apps 🎄

The end of the year is a time for reflection. For developers, that often means looking at our contribution graphs.

Today's app is the GitHub Contribution Tracker, a tool to visualize and celebrate your open source activity.

🔗 Create your summary: https://svelte-apps.me/apps/github-contribution-tracker
💻 View the code: https://github.com/Michael-Obele/Svelte-MiniApps/tree/main/src/routes/apps/(app)/github-contribution-tracker

More Than Green Squares

While GitHub's profile graph is iconic, sometimes you want focused data:

What was my longest streak?
How many total contributions did I make?
Which repos got the most love?

Built with SvelteKit

This app demonstrates fetching data from the GitHub GraphQL API server-side and rendering visual components with Svelte. It handles authentication and data visualization seamlessly.

Share your stats in the comments! 👇

Day 9: Smart Holiday Shopping & Travel (Currency Converter)

Michael Amachree — Wed, 31 Dec 2025 19:37:37 +0000

It’s Day 9 of 12 Days of Svelte Apps 🎄

Shopping globally for gifts? Planning a winter getaway?

Don't guess with your money. Today's app is the Currency Converter.

🔗 Try it live: https://svelte-apps.me/apps/currency-converter
💻 View the code: https://github.com/Michael-Obele/Svelte-MiniApps/tree/main/src/routes/apps/(app)/currency-converter

real-time Rates

We hook into live exchange rate APIs to ensure you're getting current data, not last month's numbers.

Features

150+ Currencies: From AUD to ZAR.
Instant Calculation: Reactivity in Svelte makes conversions feel immediate.
Reverse Mode: Easily swap source and target currencies.

Save your budget this holiday season by knowing exactly what you're spending.

Day 8: Recipe Conversions Without the Panic (Unit Converter)

Michael Amachree — Wed, 31 Dec 2025 17:55:11 +0000

It’s Day 8 of 12 Days of Svelte Apps 🎄

Holiday cooking is fun… right up until the recipe switches units on you.

cups vs milliliters
ounces vs grams
Fahrenheit vs Celsius

So today’s mini-app is the Unit Converter — a clean, fast converter you can keep open while you cook.

🔗 Try it live: https://svelte-apps.me/apps/unit-converter
💻 View the code: https://github.com/Michael-Obele/Svelte-MiniApps/tree/main/src/routes/apps/(app)/unit-converter

What it does

The UI is intentionally simple:

Pick a unit category (Volume, Temperature, Mass, etc.)
Enter a value
Choose “From” and “To” units
Get a formatted result instantly

It also includes a Swap button so you can flip the direction quickly, and a Clear action to reset the input.

What makes it feel good to use

Results are formatted cleanly (so you don’t get unreadable long decimals)
It handles "same unit" conversions gracefully
It supports a wide set of categories beyond cooking too (length, area, time, angle, data, energy, force, power, pressure)

A few holiday-friendly conversions to try

Oven temperature

If your recipe says 350°F but you’re using a °C oven, pick Temperature and convert.

Cups to milliliters

For recipes written in US cups, pick Volume and convert to mL for a measuring jug.

Ounces to grams

For baking (where precision matters), converting to grams can make measuring a lot easier.

If you try it, post a conversion you used today (or a recipe you’re making) and tag me.

Day 7: Holiday Word of the Day (English Dictionary App)

Michael Amachree — Wed, 31 Dec 2025 17:42:56 +0000

It’s Day 7 of 12 Days of Svelte Apps 🎄

If you want a tiny holiday habit that takes less than a minute, try this:

Pick one word you heard today and look it up.

Maybe it’s from a carol, a Christmas movie, a family recipe, or a caption you’re writing.

Today’s mini-app is the English Dictionary App — a clean word lookup tool that focuses on the stuff you actually want:

clear definitions
pronunciation (including audio when available)
synonyms and antonyms
examples and word origin (when provided)

🔗 Try it live: https://svelte-apps.me/apps/dictionary-app
💻 View the code: https://github.com/Michael-Obele/Svelte-MiniApps/tree/main/src/routes/apps/(app)/dictionary-app

What you get from one search

Type a word and hit Find Meaning.

The results are organized so you can skim quickly:

the word + phonetic spelling
pronunciation buttons (tap to play)
meanings grouped by part of speech (noun/verb/etc.)
numbered definitions (with examples when available)
a small set of synonyms/antonyms (deduped and kept readable)

There’s also a Cached indicator when results come from cache — a nice detail when you’re searching the same word again.

Holiday words to try (starter pack)

merriment
tinsel
solstice
carol
yule

Why this is a great micro-app

It’s not trying to be a full language-learning platform. It’s a quick lookup tool with:

a friendly empty state
a solid loading experience (skeleton UI)
a clear error state when a word isn’t found

If you try it, reply with your holiday word of the day.