DEV Community: Jessica Doering

I Tried the Mysterious Ox Alpha Model. Then I Fell Down the Rabbit Hole of Who Actually Made It.

Jessica Doering — Mon, 24 Aug 2026 20:01:56 +0000

A few days ago, a new AI model quietly appeared on OpenRouter.

Its name is Ox Alpha.

Nobody officially knows who made it.

It is listed as stealth/ox-alpha, described as a reasoning model built for coding and sustained agentic work, and it comes with some pretty wild specs, including a 1,048,576-token context window and up to 131,072 output tokens. The developer is simply listed as an anonymous third-party provider.

Rather than throw benchmarks at it, I did what I usually do when I want to get a feel for a coding model.

I told it to make me something.

So I Had Ox Alpha Build a Game

I gave Ox Alpha a game-building task and ended up with Pizza Rush, a little pizza-shop game where customers place orders and you have to build, bake, and serve their pizzas before they lose patience.

You can actually play it here:

pizza.pinkpixel.dev

The game has more going on than I expected from a quick model test.

Customers request pizzas. You start with dough, add ingredients by dragging or tapping them, make sure you remember the sauce and cheese, bake the pizza, and try to pull it from the INFERNO 9000 oven while the oven meter is in the green zone.

Meanwhile, customer patience is ticking down.

Three customers walk out and your pizza empire falls apart.

It also tracks days survived, pizzas served, money earned, and perfect pizzas.

What interested me wasn't that the model could generate HTML, CSS, and JavaScript for a game. Plenty of coding models can do that now.

It was that it assembled several systems into something that felt like an actual small game instead of a decorated page pretending to be one.

There was state.

There were orders.

There was timing.

There were failure conditions.

There was scoring and progression.

There were multiple mechanics interacting with one another.

It was a surprisingly solid first impression.

And then I started wondering what the hell I was actually using.

Nobody Knows Who Made Ox Alpha

Ox Alpha was released as a stealth model, and the provider has deliberately chosen to remain anonymous during the preview.

That immediately turned its release into an internet detective story.

Business Insider reported that developers were already impressed by its coding and long-running agent capabilities, while speculation around its creator bounced between several companies, including Chinese AI lab Z.ai and Microsoft's MAI team.

TechCrunch reported the same uncertainty, with theories changing almost as quickly as people could test the thing.

But the most interesting part of the story isn't simply that nobody knows who made it.

It's how people are trying to figure it out anyway.

You Can Hide a Model's Name. Hiding Its Fingerprints Is Harder.

Researchers started treating Ox Alpha like a black box.

Instead of asking:

"Who made you?"

they started examining characteristics the model cannot easily disguise.

Its tokenizer.

Its reasoning controls.

Its API parameters.

Its error messages.

Its output behavior.

Its tool-calling behavior.

Basically, they started fingerprinting the model.

One public investigation compared Ox Alpha against Z.ai's GLM-5.3 and Xiaomi's MiMo-V2.5 using multiple kinds of black-box testing.

The strongest result came from tokenization.

Across 24 baseline-adjusted tokenizer probes, Ox Alpha matched GLM-5.3 on all 24.

Even stranger, Ox Alpha consistently reported exactly 75 additional prompt tokens on every test, which is consistent with the two systems sharing a tokenizer while Ox Alpha adds a fixed hidden system prompt or template overhead.

MiMo only matched five of the 24 probes.

That doesn't prove Ox Alpha is GLM-5.3.

A compatible tokenizer could also appear in a related model, fine-tune, unreleased checkpoint, distillation, adapter, or intentionally compatible serving system.

But it is considerably stronger evidence than simply saying:

"It feels like GLM."

Then the Other Clues Started Matching Too

The tokenizer isn't the only thing pointing in that direction.

Researchers also found that Ox Alpha and GLM-5.3 expose very similar mandatory reasoning behavior and parameter capabilities.

Attempts to disable reasoning produced matching or highly similar provider behavior.

Deterministic outputs also showed unusually close formatting and response patterns.

For now, what model this actually is still a mystery.

Just one with fingerprints all over the crime scene.

Model Fingerprinting Might Become a Whole Thing

This is the part I find most fascinating.

We usually think of a model's identity as the name attached to the API endpoint.

GPT-whatever.

Claude-whatever.

Gemini-whatever.

GLM-whatever.

But a model also has observable characteristics.

A tokenizer can be a fingerprint.

Error formatting can be a fingerprint.

Parameter validation can be a fingerprint.

Reasoning controls can be a fingerprint.

Tool-call formatting can be a fingerprint.

Unicode handling can be a fingerprint.

Even the number of tokens produced by carefully chosen strings can reveal information about the model family underneath.

That means an anonymous provider can hide the label without necessarily hiding the machinery.

With enough probes, you can start narrowing down what you're talking to without ever seeing the weights, training pipeline, or internal architecture.

It reminds me a little of browser fingerprinting.

Your browser doesn't have to explicitly tell a website exactly what it is if enough tiny behavioral characteristics collectively identify it anyway.

Apparently AI models can have the same problem.

There Is Another Interesting Experiment Happening Here Too

The anonymity itself may actually be useful.

Think about how much baggage normally comes with a model launch.

If OpenAI releases something, everyone compares it to Claude.

If Anthropic releases something, everyone compares it to GPT.

If Google releases something, half the conversation becomes Gemini versus everyone else before people have even finished testing it.

Brand names affect expectations.

Benchmarks affect expectations.

Pricing affects expectations.

Previous experiences with a company's models affect expectations.

Now imagine releasing:

model-a

model-b

model-c

No company names.

No leaderboard announcement.

No giant launch presentation telling people how incredible they are supposed to think it is.

Just put the model in developers' hands and see what they actually do with it.

Do they keep using it?

Do agents successfully complete tasks?

Where does it break?

What kinds of projects do people trust it with?

What happens when developers aren't evaluating the company logo alongside the output?

Ox Alpha is currently giving its creator a pretty fascinating real-world experiment, whether that was the intention or not.

My Own Test Doesn't Tell Me What Ox Alpha Is

Pizza Rush obviously isn't a scientific benchmark.

I'm not going to claim that one little pizza game proves Ox Alpha beats GPT, Claude, Gemini, GLM, or anything else.

It doesn't.

What it gave me was something different.

A reason to keep testing it.

My first experience with Ox Alpha was a model taking a fairly open-ended coding task and turning it into a coherent, playable little game with multiple interacting systems.

That made me curious.

The mystery surrounding it made me even more curious.

And then discovering that people were identifying its possible origins through tokenizer differences, API quirks, error messages, and black-box testing sent me straight down the rabbit hole.

At this point, I'm almost less interested in whether Ox Alpha turns out to be the best coding model.

I want to know whether the internet managed to identify it correctly before its creator ever said a word.

Because if the GLM theory eventually gets confirmed, there is a pretty interesting lesson buried in this whole experiment:

You can make an AI model anonymous.

Making it unidentifiable might be a lot harder.

Should AI Coding Agents Be Allowed to Fix Their Own Mistakes?

Jessica Doering — Sun, 23 Aug 2026 20:13:19 +0000

Giving a coding agent permission to fix its own mistakes sounds obvious. If it writes broken code, why wouldn’t it get another shot?

In fact, one of the biggest advantages of agentic coding systems is that they do not have to stop after generating the first patch. They can inspect an error, modify the implementation, run a test, notice that something still failed, and keep working. That feedback loop is a huge step beyond the older model of AI coding assistance where the model produced an answer and handed the entire verification process back to the developer.

But there is an important difference between an agent being allowed to try again and an agent being trusted to decide that it has succeeded.

An agent can just as easily “fix” one bug by introducing two quieter ones. It can make a failing test pass by changing behavior somewhere else. It can remove an assertion it does not understand, weaken validation, add a suspicious fallback, suppress a type error, catch an exception without handling it properly, or rewrite a larger section of code than the original task ever required.

Technically, the failure may disappear.

That does not necessarily mean the problem was solved.

Self-correction only becomes useful when it happens inside a constrained loop:

Make a targeted change.
Run appropriate verification.
Inspect the result.
Determine whether the original requirement is actually satisfied.
Either accept the change or make another bounded attempt.

The loop matters more than the second attempt itself.

Verification Is the Real Superpower

The interesting part of an autonomous coding agent is not simply that it can generate code repeatedly. Language models are already very good at producing another plausible patch.

The more important capability is giving the agent reliable signals about whether that patch worked.

Tests, type checks, linters, builds, static analysis, schema validation, compiler errors, and targeted runtime checks give the agent something objective to work against.

Without those signals, self-correction can become little more than repeated guessing.

An agent might inspect its own code and notice a missing import or an obviously incorrect condition. Self-review absolutely has value. Models can catch some of their own mistakes when explicitly asked to reconsider a solution.

But an agent judging its own code without external evidence is basically grading its own homework.

Sometimes correctly.

Sometimes with remarkable confidence and absolutely no idea what just caught fire.

External verification changes the nature of the loop. Instead of asking:

“Does this code look correct?”

the agent can ask:

“Does this implementation satisfy the conditions we can actually measure?”

That is a much stronger question.

Not All Verification Is Equal

There is also a temptation to treat “the tests passed” as the finish line.

It is not always enough.

A test suite only proves what it was designed to test. If the original bug involves an edge case that is not covered, an agent can produce a perfectly green test run while still leaving the real problem untouched.

That makes the quality of the verification environment incredibly important.

For a small change, a focused test or type check may be enough. For a larger change, verification might need several layers:

targeted unit tests
integration tests
type checking
build verification
static analysis
dependency checks
runtime validation
inspection of the final diff

Visual applications may require another category entirely. If an agent changes a UI component, the code compiling successfully says very little about whether the interface still looks correct. A screenshot comparison or targeted browser check may be far more useful than another hundred unit tests.

The goal should not be to run every possible verification step after every tiny edit. That can burn enormous amounts of time and tokens for very little benefit.

The goal is to choose verification that matches the risk of the change.

The Agent Should Not Be Allowed to Move the Goalposts

One of the strangest failure modes in autonomous systems happens when the agent encounters an obstacle and starts modifying the environment that was supposed to verify its work.

Imagine an agent implements a feature and a test fails.

There are several possible explanations:

the implementation is wrong
the test is outdated
the requirement is ambiguous
an unrelated bug already existed
the environment is misconfigured

A capable developer investigates which explanation is correct.

An unconstrained agent may simply discover that changing the test is easier.

That does not mean agents should never modify tests. Sometimes a feature legitimately requires new expectations or updated test coverage.

But changing the implementation and changing the mechanism used to judge that implementation at the same time creates an obvious conflict.

If an agent is allowed to modify tests, configuration, requirements, and implementation freely during the same repair loop, it can gradually reshape the problem until its own solution becomes correct.

That is not self-correction.

That is moving the goalposts.

A safer design is to make certain parts of the environment harder to change during repair attempts. Tests tied directly to the original requirement may need additional scrutiny. Security rules should not disappear because they are inconvenient. Type checking should not be disabled because the generated code does not type-check.

Some constraints should remain constraints.

Diff Size Is an Underrated Safety Mechanism

Another useful control is limiting how far the agent is allowed to wander.

Suppose the task is:

Fix an incorrect date format in the settings page.

A reasonable repair might touch one or two files.

If the third attempt suddenly includes a new dependency, changes the shared date utility, rewrites the settings architecture, modifies twelve tests, and updates half the application, something has gone sideways.

Agents sometimes respond to repeated failures by increasing the scope of their changes. From the model's perspective, this can make sense. If the local fix did not work, perhaps the surrounding architecture is the problem.

Sometimes it is.

But repair loops become significantly safer when scope expansion is treated as a reason to stop and reconsider rather than permission to keep digging.

Simple limits can help:

maximum files changed
maximum diff size
protected directories
forbidden dependency additions
no unrelated refactors
no test deletion without explicit justification

These are not glamorous AI capabilities, but they can make autonomous coding dramatically more reliable.

The Loop Needs a Stop Condition

The hardest design question may be deciding when the agent should stop trying.

Unlimited retries sound like maximum autonomy, but they can create some spectacularly dumb behavior.

Each additional attempt costs tokens and time. More importantly, repeated failures can cause the agent to drift farther from the original task.

Attempt one fixes the function.

Attempt two modifies the caller.

Attempt three changes the abstraction.

Attempt four rewrites the tests.

Attempt five installs a new library.

At some point the system is no longer repairing the original mistake. It is negotiating with the entire codebase.

A better pattern is bounded autonomy.

Give the agent a reasonable number of attempts. Require verification after each meaningful repair. Track whether the error is actually changing. Restrict unrelated modifications. If the same failure persists, stop.

That stop is not a failure of the agentic system.

It is part of the system working correctly.

Escalation is a legitimate outcome.

The agent might report:

what it originally changed
what failed
what repair attempts were made
which verification steps were run
what remains unresolved
what it thinks the likely cause is

That gives the developer a much better starting point than either blind persistence or a mysterious “task failed” message.

Confidence Should Not Be the Exit Condition

This is especially important because language models are extremely good at sounding finished.

An agent can produce a beautiful summary explaining why a change works even when the implementation is still wrong.

That makes model confidence a terrible stopping condition.

“I believe the issue is resolved” is not verification.

A stronger agent loop separates generation, evaluation, and acceptance as much as possible.

The model proposes the change.

External tools evaluate measurable properties of the change.

The system decides whether the evidence satisfies predefined completion conditions.

Those responsibilities can overlap, but they should not collapse into a single question of whether the model feels good about its answer.

Should Another Agent Review It?

One tempting approach is to introduce another model into the loop.

Agent A writes the code.

Agent B reviews it.

Maybe Agent C checks the tests.

This can help. Different prompts, contexts, or models may notice different problems.

But multiple agents do not automatically create objectivity.

Three language models confidently agreeing with one another is still three language models.

Independent review is useful when it introduces a genuinely different perspective, but automated verification remains far stronger than model consensus whenever objective verification is possible.

A compiler does not care how persuasive the implementation looks.

A failing integration test is unimpressed by the agent's reasoning.

That is exactly why those tools are valuable.

Autonomy Should Scale With Risk

Not every coding task deserves the same level of control.

If an agent changes a CSS margin, allowing several autonomous repair attempts is probably harmless.

If it modifies authentication, payment processing, permissions, database migrations, cryptography, deployment configuration, or destructive data operations, the rules should be much stricter.

Agent autonomy should scale with the consequences of being wrong.

Low-risk tasks can tolerate broader experimentation.

High-risk tasks should require stronger verification, smaller diffs, fewer retries, and potentially human approval before important changes are applied.

This is probably where mature coding agents are headed: not toward a binary choice between “fully autonomous” and “human controlled,” but toward graduated autonomy based on context.

The Best Agent Is Not the One That Never Fails

Coding agents are going to make mistakes.

So do developers.

The interesting engineering challenge is not eliminating every mistake from the first attempt. That is probably unrealistic for both humans and AI.

The more useful goal is building systems that fail well.

A good coding agent should be able to recognize evidence that its first solution was wrong, repair a limited mistake, verify that repair, and know when further attempts are becoming unreliable.

That last ability may matter just as much as code generation itself.

AI coding agents probably should be allowed to fix their own mistakes.

In fact, that capability is one of the strongest arguments for using agents instead of simple code-generation tools.

They just should not get unlimited authority to decide what counts as a mistake, rewrite the rules used to evaluate themselves, or keep modifying the codebase indefinitely until something turns green.

The useful version of autonomy is not:

“Keep going until you think you're right.”

It is:

“Try again, prove it, stay within scope, and know when to stop.”

That is a much more interesting kind of agent.

I Gave Claude, Codex, and Gemini the Same App to Build. Then I Made Them Blind-Judge Each Other.

Jessica Doering — Sat, 22 Aug 2026 20:51:53 +0000

I had a dumb little experiment I wanted to try.

And, as dumb little experiments sometimes do, it got way more interesting than I expected.

I gave three coding agents the exact same task:

Claude (Opus 5)
Codex (GPT 5.6 Sol)
Gemini (Gemini 3.7 Flash)

All set to medium.

The assignment was to build an Arkanoid-style browser game from the same specification.

Nothing particularly groundbreaking. Arkanoid is small enough that an agent can build a complete version in one session, but complicated enough to expose differences in physics, architecture, UI, audio, controls, testing, and general decision-making.

The important part was that they all started with the same instructions.

Then I let them work.

No fixing their mistakes afterward. No "you forgot this feature." No giving one of them another pass because something looked weird.

Whatever they decided was finished was their submission.

But building the games wasn't actually the most interesting part.

Afterward, I gave all three games back to all three agents, anonymized as CL, CO, and GE.

They did not know who created which game. They were just told that they were judging 3 contest submissions by the creators' initials.

And that's where things got, well, fun.

The three games

You can actually play all three versions:

Gemini:
https://arkanoid-gemini.pinkpixel.dev

Codex:
https://arkanoid-codex.pinkpixel.dev

Claude:
https://arkanoid-claude.pinkpixel.dev

All three produced working games, but they approached the assignment very differently.

That difference started showing up before I even looked closely at the code.

First difference: how long they worked

I didn't originally intend runtime to be part of the experiment, so unfortunately I wasn't sitting there with a stopwatch.

These are rough observations, not benchmark numbers.

But the difference was large enough to be impossible to miss.

Gemini: roughly 5 minutes
Codex: roughly 10 minutes
Claude: more than 20 minutes

Gemini absolutely flew through it.

That's not especially shocking since Gemini Flash models are already very fast, but watching it produce an entire playable game that quickly was still impressive.

Codex took about what I expected. It worked through the implementation at a reasonable pace, did its checks, and finished.

Claude was a completely different animal.

It kept going.

And going.

It ran tests. It launched the game. It took screenshots. It inspected those screenshots. It went back through its work. It performed visual checks. It verified behavior.

A significant chunk of Claude's total runtime appeared to be testing and verification rather than implementation.

It also used substantially more tokens than either of the other agents.

At first glance, you could summarize this as:

Gemini shipped.
Codex engineered.
Claude investigated its own work like it was preparing evidence for trial.

But then I looked at what they actually built.

Their different approaches showed up in the code

Claude produced by far the largest implementation.

Its version has 12 stages, a substantial procedural audio system with music, detailed collision handling, accessibility work, responsive behavior, a multi-phase DOH boss, and quite a lot of extra polish.

Codex went in almost the opposite direction.

Its implementation was much smaller and more restrained, but extremely deliberate from an engineering perspective. It built a headless game core, separated game state from rendering and input, included automated tests, and even wrote tooling to verify that source files stayed below the maximum line count from the original specification.

Gemini produced a solid, much faster implementation with a good amount of actual Arkanoid functionality, but less of the obsessive verification and architectural work found in the other two.

Already, I thought this was interesting.

Then I anonymized them.

Time for the agents to judge each other

The judges only knew the entries as:

I asked each agent to inspect the submissions and rank them.

And yes, I specifically did not tell them who made which one.

The results:

Judge	1st	2nd	3rd
Claude	CL	CO	GE
Codex	CO	CL	GE
Gemini	CL	GE	CO

Now for the reveal:

CL was Claude.
CO was Codex.
GE was Gemini.

So Claude unknowingly voted for itself.

Codex unknowingly voted for itself.

Gemini did not.

Gemini voted Claude into first place.

I did not expect that result to be nearly as interesting as it was.

Were Claude and Codex biased toward themselves?

Technically, yes. They each selected their own work.

But I don't think "AI models are narcissists" is a particularly useful conclusion here.

They didn't know which implementation was theirs. They didn't even know that these were made by an AI at all.

Something else may be happening that I find much more interesting.

Each agent seemed to favor software that reflected its own idea of what good software should look like.

Claude's judging put a lot of weight on completeness, depth, collision quality, audio sophistication, accessibility, responsive behavior, and adherence to the full feature set.

Those happen to be areas where Claude spent an enormous amount of effort during implementation.

Codex placed much more emphasis on architecture, automated tests, self-containment, verification, correctness, and engineering discipline.

Those happen to be some of the strongest characteristics of Codex's own submission.

In other words, an agent's implementation choices and judging criteria may be coming from the same underlying preferences.

The model builds software according to its internal conception of "good."

Then, when asked what good software looks like, it selects the implementation that most closely matches those same priorities.

That's a much more interesting possibility than simple self-preference.

And Gemini makes the whole thing even better because it broke the pattern.

Claude actually preferred Codex visually

There's another detail that makes the result harder to dismiss as accidental self-selection.

Before inspecting the code, the agents were asked to evaluate the screenshots.

Claude ranked the visual designs:

Codex
Claude
Gemini

So Claude did not think its own game looked best.

It specifically thought Codex had the stronger visual composition.

Only after inspecting the implementations did Claude move CL into first place overall.

Its reasoning was essentially that Codex had the better visual composition and excellent engineering discipline, but Claude's entry covered more of the original specification and implemented several of the difficult systems more deeply.

Codex reached almost the opposite conclusion.

It also liked CO's visual design, but considered its tests, compact architecture, self-contained implementation, and verification enough to put CO above the larger Claude submission.

That disagreement is probably my favorite part of this entire experiment.

Neither judge simply said, "mine looks better."

They disagreed about what should matter most.

There was still a consensus winner

Using a simple scoring system:

1st = 3 points
2nd = 2 points
3rd = 1 point

The final scores are:

Entry	Points
Claude	8
Codex	6
Gemini	4

Claude wins the blind consensus.

It received two first-place votes and one second-place vote.

More importantly, one of its first-place votes came from Gemini.

So Claude's extra time and token usage did appear to buy something.

But that introduces another question.

Was Claude actually the best value?

Claude produced the consensus winner.

It also took more than twice as long as Codex and roughly four times as long as Gemini based on my rough observations.

It consumed the most tokens by a substantial margin.

So which one actually "won"?

If your only metric is the best final artifact, Claude has a strong argument.

If you need a working prototype as quickly as possible, Gemini suddenly looks much more attractive.

And Codex may have landed somewhere in the middle: significantly more engineering rigor than the fastest submission without spending as much time and compute as Claude.

That gives us at least three different definitions of winning:

Best final result

Fastest usable result

Best result relative to agent effort

I hadn't intended to test any of that.

I just wanted to make three AIs build Arkanoid.

What I'm changing for the next experiment

Now I want to do this again.

This first round taught me that I should collect more than just the finished applications.

For future rounds I want to record:

Exact wall-clock completion time
Token usage
Tool calls
Number of files created
Approximate lines of code
Tests written
Tests executed
Browser or screenshot checks
Self-corrections made before completion
Visual rankings
Code rankings
Overall rankings

I'm especially interested in seeing whether the same behavioral patterns repeat across different kinds of applications.

Arkanoid rewards game logic, physics, controls, rendering, and polish.

A developer tool might reward architecture and usability differently.

A UI-heavy project might produce another completely different result.

And a deliberately vague product prompt could test how much product judgment each model exercises when I don't tell it exactly what to build.

If Claude repeatedly spends four times as long and wins, that's useful information.

If Gemini repeatedly gets surprisingly close in a quarter of the time, that's useful too.

If Codex repeatedly lands between them with strong engineering and reasonable efficiency, that's equally interesting.

And if none of those patterns survive another round?

That's interesting too.

This is definitely not a scientific benchmark

Three agents building one Arkanoid game is obviously not enough evidence to make sweeping claims about any model.

Different harnesses, tool access, context, model updates, sampling, and plain old randomness all matter.

I'm not trying to create the new definitive coding benchmark from my browser.

This was mostly for fun.

But I think there's something useful about looking at coding agents this way.

Most comparisons focus entirely on whether a model can solve a task.

Agents add another dimension.

How does the model choose to work when you leave it alone?

Does it ship immediately?

Does it test?

Does it inspect its own UI?

Does it keep polishing after the application already works?

What does it consider important enough to spend tokens on?

And, maybe most interestingly:

When it looks at someone else's work, what does it believe "better" actually means?

I started this experiment wanting to see which AI could build the best Arkanoid game.

I ended up considerably more interested in what the three agents revealed about how they think software should be built.

Not bad for a random Saturday afternoon experiment.

I built Kintara because apparently having too many hobbies eventually leads to building your own document management system.

Jessica Doering — Sat, 22 Aug 2026 15:47:49 +0000

Kintara is a self-hosted document library and reader that runs in Docker and watches a folder you already have. Drop PDFs, Markdown, or text files into the directory and it indexes them automatically, extracts searchable text and metadata, generates thumbnails, and makes the whole library available through a browser or installable PWA. It has libraries, collections, tags, full-text search, highlights, favorites, reading progress, private library sharing, and GitHub OAuth.

I have been working on Kintara for a few months, and the architecture actually changed pretty dramatically while I was building it. Kintara originally had a Tauri desktop shell, but I eventually realized that isn't what I wanted at all. So I ripped the desktop layer out and rebuilt it around one Rust server that serves both the API and frontend. Now I can point Kintara at a NAS folder and open the same library from my desktop, laptop, tablet, or phone.

The thing I really love about this app is the optional AI features. I added an option to use OpenAI or Gemini, and with so few tokens being spent, it's a fraction of a cent to use most of them, aside from the cover image generation, which is bit more, but makes the library look so much prettier! 😄

Anyway, I wanted AI to be a tool inside the library rather than taking the thing over, and I wanted it to be fully optional, so if you're one of those "Ew, AI is in this app" people, you just don't turn it on and it's like it doesn't exist. What the AI can do is summarize documents, suggest metadata and fill in those blank spaces, generate cover images for docs that don't have a cover, search the library for docs, or you can just chat with it about your docs.

Find is a pretty great AI feature I think. Instead of letting the model vaguely tell you that something appears "somewhere in the document," Kintara asks for actual passages with page numbers, verifies the quote against extracted page text on the server, then verifies it again against the rendered PDF. If the quote cannot actually be located, it gets dropped.

But I think the thing I’ve ended up appreciating most is the AI metadata suggestions. A lot of my library consists of documents with incomplete, inconsistent, or completely useless embedded metadata, and fixing that manually gets old super fast. Kintara can read the document and suggest a title, author, summary, keywords, DOI, ISBN, and publication year. Then it displays the suggestions and I choose which fields I want, apply them to the form. It sounds like a stupidly small convenience until you’re staring at a library with hundreds of files. Then it’s kinda just amazing.

At this point Kintara has grown into one of those projects where I started out thinking, "I just want a nice way to organize my documents that's not overcomplicated", and somehow I ended up with filesystem watching, OAuth, multi-user permissions, and threw in image generation cause why not?

So if you have accumulated an actual ton of pdfs and markdown files, and it sounds interesting to you, try it out and let me know what ya think! It's open source I've published a Docker image too.

GitHub: https://github.com/pinkpixel-dev/kintara
Docker Hub: https://hub.docker.com/r/pinkpixeldev/kintara

The Hard Part of AI Coding Isn’t Using AI. It’s Knowing When Not to Trust It.

Jessica Doering — Sat, 22 Aug 2026 02:25:44 +0000

There are now enough AI coding tools to build an entire workflow out of assistants talking to assistants.

The problem is no longer access to AI. The problem is deciding where it belongs in the development process without quietly handing over your judgment.

AI is great at reducing friction. It can trace unfamiliar code, generate tedious boilerplate, explain an API, propose refactors, write tests, hunt through logs, and suggest five possible causes for a bug before you finish your coffee.

Used well, it can feel like a super fast technical collaborator.

But speed creates its own trap. A plausible answer can feel finished long before it has actually been verified.

Plausible Is Not the Same as Correct

AI coding tools are remarkably good at producing answers that look right.

The code is clean. The explanation sounds confident. The function names make sense. There may even be comments describing exactly why the solution works.

And sometimes it does work.

Other times, the model invents an API method, uses an outdated configuration format, misunderstands a library version, ignores an edge case, weakens a security check, or fixes a symptom while leaving the real bug untouched.

The most dangerous failures are not always the ones that immediately crash the application. Those are usually easy to catch.

The more dangerous failures are the ones that appear to work.

An authentication change might allow valid users to sign in while accidentally bypassing an authorization check. A database migration might succeed against an empty development database but fail on real production data. A generated test might pass because it reproduces the same incorrect assumption as the implementation.

The app starts. The tests pass. The agent announces success.

That still does not mean the work is correct.

Due Diligence Is Part of the Workflow

If an agent says a library supports something, check the documentation.

If it changes authentication code, inspect the security implications.

If it writes a migration, read the SQL.

Run the tests. Check the diff. Understand the dependencies it added. Ask why the proposed fix works instead of just checking whether the application starts.

This does not mean treating every AI-generated line as suspicious. Generated code deserves the same scrutiny as code submitted by anyone else, and occasionally more, because the model cannot be held responsible for the result.

A human teammate can explain the assumptions behind a decision, remember a conversation that changed the requirements, and recognize when a technically valid implementation would create a terrible user experience.

A model can explain its output too, but that explanation is generated after the fact. It may be useful, but it is not proof that the model started from the correct assumptions.

Verification should also match the risk of the change. A developer does not need to conduct a security audit because an agent changed the padding on a button. Changes involving authentication, authorization, payments, destructive operations, personal data, infrastructure, database schemas, or production configuration deserve substantially more attention.

The higher the cost of being wrong, the less appropriate it is to accept “looks good” as evidence.

Passing Tests Can Create False Confidence

Tests are among the best tools available for verifying AI-generated work, but even they require judgment.

An agent can write tests that confirm the implementation behaves exactly as the agent expects. That is useful, but it does not prove that its expectation matches the product requirement.

If the same model writes the implementation and the tests, both may share the same misunderstanding.

Suppose a requirement says that only account owners can delete a project. An agent might interpret “account owner” as any authenticated user associated with the account. It can then write the authorization logic and a complete test suite around that interpretation. Every test passes, but the implementation is still wrong.

Good verification asks more than whether the generated tests are green:

Do the tests reflect the actual requirements?
Are failure paths covered?
Are permissions tested from the perspective of different user roles?
Are boundary conditions included?
Would the tests fail if the implementation were subtly weakened?
Were existing tests changed or removed simply to make the implementation pass?

Tests are evidence, not absolution.

Technically Correct Can Still Be Wrong

Not every failure is a bug.

Sometimes an AI-generated solution is technically valid but wrong for the project.

It may introduce a state management library into an application that did not need one. It may replace a straightforward function with an elaborate abstraction. It may use a dependency that is incompatible with the deployment environment. It may solve a small performance problem by making the code much harder to understand.

Models are generally inclined to produce something rather than conclude that nothing needs to change. If you ask for a refactor, you will probably receive one, even when the original code was perfectly fine.

Good engineering is not about choosing the most sophisticated solution available. It is about choosing a solution whose complexity is justified by the problem.

AI can propose the options. It cannot own the tradeoff.

Choosing Tools Requires Judgment Too

The same principle applies when choosing among AI tools.

Developers do not need to chase every coding assistant that launches. Every week seems to bring another agent with a cinematic demo, an impressive benchmark, and a promise to transform software development forever.

Some of those tools are genuinely useful. Some are excellent in one context and mediocre in another. Some will disappear six months after developers have reorganized their workflows around them.

One model may be great at exploring a large codebase but unnecessarily verbose when implementing a small change. Another may generate polished interfaces while struggling to diagnose backend behavior. A specialized review agent may notice issues the implementation agent missed, but it may also produce a pile of low-value warnings.

The best workflow may involve several tools: one for exploration, another for implementation, and another for review. Or it may simply involve one tool used deliberately.

The goal is not to assemble the largest AI stack possible. It is to remove enough friction that more attention can go toward decisions that require engineering judgment.

Adding another agent is not automatically an improvement. Sometimes it only adds another layer of output for a human to verify.

Knowing What to Delegate Is Becoming a Core Skill

A subtle skill is developing alongside AI-assisted programming: knowing what to delegate.

Some tasks are perfect candidates.

Boilerplate? Delegate aggressively.

Exploring an unfamiliar codebase? AI is great at identifying likely entry points and tracing relationships between files.

Generating alternative implementations? Useful. Seeing multiple approaches can expose tradeoffs you might not have considered.

Writing the first version of repetitive tests? Absolutely, as long as someone verifies that the tests represent the intended behavior.

Turning an error message into a list of hypotheses? Great. That can accelerate debugging considerably.

Other decisions should remain firmly under human ownership.

Is a security assumption acceptable?

Does the architecture make sense for the expected scale and lifetime of the project?

Does the implementation solve the user’s actual problem?

Is collecting this data necessary?

Is the new dependency worth maintaining?

What happens if this operation fails halfway through?

Does the code satisfy the requirement, or merely the prompt given to the agent?

AI can contribute information to these decisions, but the responsibility still belongs to the developer.

A useful rule is to delegate execution more freely than judgment. Let the model perform mechanical work, gather context, generate possibilities, and handle repetition. Be more cautious about delegating decisions involving intent, risk, tradeoffs, or consequences.

More Context Is Not Always the Right Context

AI tools are getting better at gathering context automatically, but no coding agent has perfect access to everything that matters.

It may see the repository but not the conversation where a feature was deliberately excluded. It may read the issue but not understand the support burden created by a particular implementation. It may know what the code does without knowing why the team chose to do it that way.

Even large context windows do not solve this completely. More context is not the same as the right context.

Developers still need to identify and communicate the constraints that matter. That includes the technical environment, product requirements, deployment limitations, compatibility expectations, security boundaries, and anything that must not change.

When an AI tool produces a poor result, the model is not always incapable. Sometimes it was given an underspecified task and filled the gaps with assumptions.

Those assumptions may be perfectly reasonable.

They may also be completely wrong.

Review the Change, Not the Confidence

AI agents frequently summarize their work with reassuring declarations:

“The issue has been resolved.”
“All tests are passing.”
“The implementation is production-ready.”
“This approach is secure and scalable.”

Treat those statements as reports to verify, not conclusions to inherit.

Review the actual diff.

Check which files changed. Look for unrelated modifications. Confirm that existing behavior was not removed. Inspect configuration changes. Check whether tests were weakened. Search for hardcoded values, silent error handling, broad permissions, unnecessary dependencies, and placeholder logic disguised as a complete implementation.

The confidence of the summary has no relationship to the correctness of the code.

A beautifully explained mistake is still a mistake.

The Developer’s Role Is Changing, Not Disappearing

AI-assisted coding does not make developers irrelevant. It changes where their attention is most valuable.

Less time may be spent typing predictable code from scratch. More time may be spent defining behavior, supplying context, evaluating alternatives, reviewing changes, designing verification, and deciding what should be built in the first place.

That is not a lesser form of development.

Typing code has never been the entire job. The real work has always included understanding systems, identifying constraints, managing tradeoffs, predicting failure modes, and taking responsibility for what reaches users.

AI can accelerate the production of code. It cannot take responsibility for the consequences of deploying it.

That responsibility remains stubbornly human.

Faster Coding Needs Better Brakes

AI-assisted coding works best when the model handles mechanical effort while the human maintains ownership of intent, verification, and consequences.

That does not require hovering nervously over every generated semicolon. It requires calibrating trust based on the task.

Use AI freely where mistakes are cheap and obvious. Increase scrutiny where errors can remain hidden or cause real damage. Use tests, linters, type checking, documentation, code review, and isolated environments as parts of a verification system, not ceremonial steps after generation.

Most importantly, stay capable of disagreeing with the tool.

The interesting question is no longer whether developers should use AI. That debate has largely been overtaken by reality. AI is already embedded in editors, terminals, documentation tools, code review systems, and development platforms.

The more important question is whether we can become good enough at using it that faster coding does not become faster mistakes.

AI can help us move quickly.

Engineering judgment tells us when to slow down.

PawDOS 95: A browser operating system for dogs

Jessica Doering — Sat, 15 Aug 2026 18:49:19 +0000

This is a submission for the Weekend Challenge: Dog Days Edition.

My submission is PawDOS 95, a fake desktop operating system built for dogs. Built to boot like a 1995 PC, it tracks squirrels, monitors the mailman, manages treats, and tries to explain humans with a translator.

The main feature is DogPrompt. It looks like a DOS terminal, but it accepts normal sentences. Gemini does more than answer in character. It can request approved actions that affect the desktop itself.

What I Built

PawDOS has a working window manager, start menu, taskbar, dialogs, notifications, synthesized sounds, random desktop events, and 9 applications.

DogPrompt combines about 25 instant local commands with Gemini-powered responses. Other apps include Squirrel Tracker 2.0, HUMAN.EXE, Treat Manager, Mailman Monitor, My Kennel, My Documents, Notepad, and Settings.

The app also works on mobile.

Demo

Try PawDOS at pawdos.dog.

Open DogPrompt and type something like:

emergency i see a squirrel outside

Gemini can respond, open Squirrel Tracker, add a radar target, show a warning, and trigger the bark driver. The terminal finishes typing first, then PawDOS carries out the approved actions.

Code

The source is available at github.com/pinkpixel-dev/pawdos.

How I Built It

PawDOS uses React 19, TypeScript, Vite, and Zustand. A single Cloudflare Worker serves the app and handles the Gemini requests.

DogPrompt uses Gemini function calling. The Worker gives Gemini eight possible actions, including opening an app, spawning a squirrel, barking, changing the dog's mood, and entering nap mode. Every returned action passes through an allowlist validator before the browser can run it. Invalid names, values, and arguments are dropped.

HUMAN.EXE, squirrel dossiers, and hardware diagnostics use structured responses. The Worker validates those fields before React renders them.

Prize Categories

I am submitting PawDOS for Use of Google AI.

Gemini is connected to the operating system instead of sitting in a separate chat box. Function calls become validated desktop actions, structured responses power three utility panels, and conversation chaining gives DogPrompt short-term context.

Kitty Cafe, a whole bakery drawn in CSS 🐱🍰

Jessica Doering — Mon, 10 Aug 2026 04:28:36 +0000

This is a submission for Frontend Challenge - Comfort Food Edition, CSS Art.

Inspiration

Comfort food, for me, is not a big plate of anything. It is the small stuff.
The pastry you eat standing up at the counter because you could not wait to sit
down. So I wanted to draw a bakery.

Then I thought: what if every single thing in the case was a cat.

That turned out to be the right call, because it gave me nine little characters
instead of nine pastries, and characters are way more fun to draw. There is a
macaron with ears, a matcha cupcake, a taiyaki, a paw print cookie, a chocolate
donut with far too many sprinkles, a cake slice, a cake pop, and a caramel
pudding cup. Up on the shelf there is a whole kitty cake you have to order 48
hours in advance.

I also did not want it to be a single object floating on a background. I wanted
a room you could stand in. So there is a chalkboard of drinks, jars on a shelf,
a pendant lamp, a wooden counter, and a shop cat asleep next to somebody's
coffee that is definitely going cold.

Demo

No images. No SVG. No canvas. No JavaScript. Every whisker is a div with a
border-radius.

Three things worth poking at:

Hover, tap or tab to any treat. It lifts out of the row with a price tag.
Click the sleeping cat. She opens her eyes, perks her ears, and purrs for a few seconds before dozing off again.
There is a ball of yarn on the floor. Click it to pick it up, click her to give it to her, and see what happens.

Journey

One coordinate system, zero breakpoints

The first real decision was how to make the art scale. CSS art has hundreds of
coordinates in it, and maintaining breakpoint variants of all of them sounded
miserable.

So the whole scene is a container:

.scene {
  container-type: inline-size;
  aspect-ratio: 16 / 10;
}

Everything inside is measured in cqw (1% of the scene's width) or in
percentages. Because the height comes from the width, both axes scale together.
The picture looks identical at 320px and at 1920px, just smaller, and there is
not one media query anywhere in the art.

One gotcha I hit: cqw inside .scene's own rules resolves against some
outer container, not itself. So .scene uses pixels for its own properties and
cqw only ever shows up on descendants.

The scene also sizes itself to your window. Since height follows width at a
fixed ratio, capping the width at (100dvh - 7rem) * 1.6 is the same thing as
capping the height at the viewport:

width: min(100%, max(46rem, calc((100dvh - 7rem) * 1.6)));

max-height does not work here, by the way. It fights aspect-ratio, because
the width has already resolved by the time it applies.

Eight cats pretending to be pastry

Every treat shares one set of parts: an ear, an eye, a mouth, blush, whiskers.
Each treat just re-tunes them with custom properties instead of redefining the
shapes:

.t-macaron {
  --ear-c: var(--pink);
  --ear-dip: 0.9cqw;
  --face-y: 36%;
  --eye-s: 0.88cqw;
}

--ear-dip came out of an actual problem. Ears sit on top of whatever box they
live in, which is fine on a flat head. On a circle or a dome they end up over
the part of the box the shape has already curved away from, so they float, and
the cat looks like it is wearing a bad costume. Round heads just need the ears
tucked deeper.

--eye-c exists for a similar reason. The shared eye used dark ink, and on the
chocolate donut the whole face simply vanished. It read as a plain donut with
sprinkles. Cream eyes fixed it, and then I had to recolour the cream sprinkles
too, because white dots next to white eyes read as extra eyes.

Drips that cannot spill

Icing drips gave me trouble until I found a pattern that makes overflow
impossible by construction. Instead of positioning a drip as its own box, make
it identical to the thing underneath (same offsets, same border-radius) and
then cut the bottom off with a jagged clip-path:

.t-donut .glaze {
  position: absolute;
  inset: 0;
  border-radius: 50%;
  background: var(--choco);
  clip-path: polygon(
    0 0, 100% 0, 100% 60%, 92% 55%, 84% 66%, 74% 57%,
    64% 68%, 52% 57%, 40% 68%, 30% 57%, 20% 66%, 10% 55%, 0 64%
  );
}

The drip physically cannot escape the silhouette, because it is the
silhouette. Same trick works for the whole cake's icing and the caramel on the
pudding cup.

Waking the cat without JavaScript

She is a visually hidden checkbox and a label holding her art. Clicking the
label checks the box, which buys click, tap and Space all at once.

The part I am most pleased with is that she goes back to sleep on her own after
about five seconds, so you can wake her again straight away. That is harder than
it sounds, because CSS cannot uncheck a checkbox on a timer. The animation
itself has to return her to sleep.

Which creates a trap. Once she is asleep with the box still checked, the next
click only unchecks it, and if both states name the same animation, the computed
animation-name never changes, so nothing restarts. Half your clicks do
nothing.

The fix is two keyframe blocks that are byte for byte identical, under different
names:

.cat-toggle:checked ~ .shopcat { animation: wake-a 5.4s ease-in-out; }

.cat-toggle:not(:checked) ~ .shopcat:hover,
.cat-toggle:not(:checked):focus ~ .shopcat { animation: wake-b 5.4s ease-in-out; }

A changed animation-name is exactly what restarts a CSS animation. The
unchecked half has to be gated behind :hover or :focus, or it matches on
first paint and she wakes up before anyone has touched her.

Underneath, her whole body runs off one registered custom property:

@property --awake {
  syntax: "<number>";
  inherits: true;
  initial-value: 0;
}

Registering it is what makes it interpolate smoothly instead of snapping at the
halfway point. Then every part of her is a plain function of that one number:

.shopcat .cat-head {
  transform: translateY(calc(var(--awake) * -0.7cqw))
    rotate(calc(var(--awake) * -3deg));
}
.cat-eye::before { opacity: calc(1 - var(--awake)); }  /* sleeping arc */
.cat-eye::after  { opacity: var(--awake); }            /* open eye */

One timeline for the whole cat, so nothing can drift out of sync.

The ball of yarn

CSS has no drag and drop, so this is two checkboxes and three overlapping labels
whose pointer-events get switched by state. The same pixels mean "pick up",
"give" or "take back" depending on where you are in the sequence.

`#hold-yarn`	`#give-yarn`	State
✗	✗	on the floor
✓	✗	you are carrying it, and the cat becomes a drop target
✓	✓	she has it, and hearts float up

The invisible drop zone over the cat is pointer-events: none until you are
actually carrying something, which is what keeps her normally clickable to wake
and only turns her into a target when it makes sense.

The bug that got me

Getting the present to wake her needed a second clock, --gift, running
alongside --awake so the two could overlap instead of fighting over one
animation property. Her poses read whichever is further along:

--lively: max(var(--awake), var(--gift));

I put that on the cat's label and nothing happened. --gift was provably 1 in
DevTools. The animation was definitely running. She just sat there asleep.

Here is why: a custom property is substituted where it is declared, and only
the result inherits. --gift is animated on a child element, so declaring
--lively on the parent baked in max(<awake>, 0) for every descendant.
Moving the one declaration down to the element that can see both values fixed
it instantly.

That one is going in my notes. It looks completely correct and it fails
silently.

Accessibility

I did not want "pure CSS" to mean "mouse only", so:

Every treat is a real <button> with an accessible name that includes its price. Tags reveal on :hover and :focus, because a tap on a phone focuses a button but does not trigger :focus-visible. :focus-visible is used separately for the ring, so a mouse click does not leave one behind.
The cat and the yarn are checkboxes, so they work with click, tap and Space, and they show a focus ring on the art itself.
On a phone the scene is small and the in-case price tags are tiny, so the full menu is repeated as plain text below the art. That list is the accessible source of truth, and honestly it is the nicer way to read it on mobile anyway.
prefers-reduced-motion: reduce switches off every animation. Nothing breaks: the cat becomes a plain two-state toggle, the yarn still moves between floor and paws, and the hearts still show. They just go straight there.

What I picked up

@property is genuinely useful for art, not just for gradients. Animating one number and deriving a dozen things from it beats keeping a dozen animations in sync.
Container queries make CSS art scale properly with basically no effort.
Checkbox and label state machines go further than I expected. Three states and conditional hit targets, no script.
Custom property substitution happens at the declaration site. I will not forget that again.
Constraints are good. Not being allowed images meant I had to actually think about what a taiyaki looks like as geometry, and I like the result more than if I had just dropped in a PNG.

Thanks for reading. Go click the cat! 🐱

Built With

Semantic HTML
CSS container queries and cqw units
CSS custom properties, including registered @property values
clip-path, border-radius and box-shadow for every shape
CSS animations and transitions
Checkbox and label state machines for all interaction
No JavaScript
No images, SVG or canvas

Repository

https://github.com/pinkpixel-dev/kitty-cafe

License

Apache 2.0.

Finding bandwidth hogs on Linux

Jessica Doering — Sat, 25 Jul 2026 22:35:51 +0000

When a Linux server starts feeling slow, uploads stall, or network costs climb, top and htop can only tell part of the story. They show CPU and memory use, not which process is moving data.

For that, start with nethogs, then use iftop or ss to confirm what the process is connected to. If you are working in a stripped-down environment, /proc is still there as a fallback.

Install the tools

These packages are available on most Linux distributions:

# Ubuntu or Debian
sudo apt install nethogs iftop -y

# RHEL or Rocky Linux, with EPEL enabled
sudo dnf install nethogs iftop -y

# Arch Linux
sudo pacman -S nethogs iftop -y

net-tools is not needed for any command in this guide. ip and ss are normally provided by the already-installed iproute2 package. On RHEL-family systems, nethogs and iftop may not be enabled in the default repositories, so enable an appropriate repository first.

Start with `nethogs`

nethogs groups current network traffic by process and shows the PID when it can associate traffic with a local socket. It is the fastest way to find the program responsible for a spike.

sudo nethogs <interface>

Replace <interface> with the network interface you want to inspect, such as eth0. Run ip link show if you need to find its name.

Use this first. Once you have the PID or process name, you can investigate the connection behind it.

Check destinations with `iftop`

iftop shows bandwidth by pairs of hosts and their remote IP addresses. It does not identify the owning process, but it answers the next question: which hosts are involved?

sudo iftop -i <interface>

Run iftop beside nethogs when possible. One shows the process; the other shows busy host pairs and the direction of the data flow.

Verify sockets with `ss`

When you need to confirm a process's active TCP connections, use ss. It maps sockets to process names and PIDs.

sudo ss -tnp

-t shows TCP connections.
-n keeps addresses as raw IPs instead of looking up hostnames.
-p includes the process name and PID.

This is useful when nethogs points to a PID and you need to inspect its socket connections or send queue (Send-Q).

Use `/proc` on minimal systems

Containers, rescue shells, and stripped-down VMs may not have the monitoring tools installed. In that case, inspect the process's open file descriptors through /proc:

sudo ls -la /proc/<pid>/fd | grep socket

Entries such as socket:[123456] contain a socket inode number. Look for that inode in /proc/<pid>/net/tcp for IPv4 TCP or /proc/<pid>/net/tcp6 for IPv6 TCP. Use /proc/<pid>/net/udp* for UDP sockets. These paths inspect the target process's network namespace, which matters when it runs in a container.

Quick reference

Tool	What it shows	Use it for
`nethogs`	Bandwidth per program	Finding the process using traffic
`iftop`	Bandwidth by host pair	Identifying hosts and traffic flow
`ss -tnp`	Established TCP sockets	Mapping connections to PIDs
`/proc`	Socket inodes and protocol tables	Diagnosing minimal systems

A practical workflow

Run nethogs and identify the PID using the bandwidth.
Use ss -tnp to see that process's TCP connections; use iftop to identify busy host pairs on the same interface.
Confirm whether the traffic is expected before stopping anything.

Routine jobs such as cron tasks and rsync backups often explain a network spike. A backup that overlaps with another job can look suspicious until you match the PID to the process. Confirm the process identity before killing it.

Gem: A Desktop Scanner That Finds GitHub Repos Before They're Trending

Jessica Doering — Sat, 25 Jul 2026 00:26:56 +0000

Gem is a desktop app for developers tired of GitHub’s trending page only ever showing what’s already popular. Instead of scrolling through the same top-100 lists, you set up “recipes”, basically saved searches combining stars range, language, topic, recency, and excluded keywords, and Gem runs them on a rotation, surfacing recently active repos that haven’t blown up yet, or might just always remain undiscovered otherwise.

Save a repo and its topics score higher next time. Skip one and they score lower. You can also just set the weights manually per topic, language, or keyword if you’d rather tune it by hand than let the app learn from your behavior. Repos flow through a simple triage pipeline too: everything lands in an Inbox, then you sort into Gems, Tools to Try, or Skipped, with a Discovery Guide of prebuilt recipes (AI/ML, self-hosted, mobile, games, etc.) for when you don’t want to write GitHub search syntax from scratch.

It’s built on Tauri v2 with a Rust backend (reqwest for the GitHub API, sqlx for SQLite, tokio running the scan loop) and a React/TypeScript frontend. Everything, including your recipes and scoring weights, is in a local SQLite file. No account, no server, no syncing. If you’ve ever found a great repo by accident and wondered how many more you’ve missed, give it a try and let me know what you think.

https://github.com/pinkpixel-dev/gem

I Built Quota to Track my AI Tools

Jessica Doering — Thu, 16 Jul 2026 04:19:08 +0000

I wanted an easy way to track usage across multiple subscriptions and multiple accounts, so I created Quota.

Quota is a desktop app and VS Code extension that gives you one place to track your AI coding-tool usage across accounts and providers. Connect each service once, then see your remaining usage, pin your most used accounts, switch between layouts, and export account summaries as JSON.

The VS Code extension also adds a status-bar indicator and webview panel. In the settings you can decide which providers appear in the status bar. It’s available on both the VS Code Marketplace and Open VSX, so it can work in compatible editors like Antigravity and Kiro as well.

I wanted to share because it's been really useful for me, especially being able to easily view my usage in my VSCode status bar, and hopefully others find it useful too.

So if you use Copilot, Codex, Claude Code, Cursor, Kiro, Antigravity, or some combination, please give it a try and let me know what you think!

Desktop App

VSCode

Open VSX

I built Stitchlet because my crochet patterns were scattered across a dozen apps and a stack of paper

Jessica Doering — Sat, 11 Jul 2026 06:53:57 +0000

This is a submission for Weekend Challenge: Passion Edition

What I Built

I built Stitchlet, a private, self-hosted crochet project companion for keeping patterns, photos, materials, notes, and progress tracking together in one place.

I've been crocheting and designing patterns for years, so this project came directly from problems I've run into myself. Crochet projects have a way of scattering across printed patterns, PDF files, handwritten notes, photos, row counters, and random scraps of paper. I wanted one calm, organized place for everything.

With Stitchlet, you can:

Create and organize crochet projects
Upload and view pattern PDFs inside the app
Save project and progress photos
Track rows or rounds with multiple counters
Record yarn, hook size, colors, dimensions, and other materials
Add custom sections for assembly notes, substitutions, or anything else
Search, sort, and filter projects by status
Back up and restore the entire project library

Stitchlet runs on your own computer, NAS, or home server, so your project files and notes stay under your control instead of getting locked into another subscription service.

Demo

Stitchlet is self-hosted, so there's no shared public demo instance to click into. See the video below.

You can also find setup instructions and more project details in the GitHub repository.

Code

pinkpixel-dev / stitchlet

A self-hosted crochet companion for tracking projects, stitch counters, pattern PDFs, and progress photos locally on your own hardware. 🧶

Stitchlet

Stitchlet is a self-hosted crochet project tracker. It keeps your pattern PDFs, progress photos, stitch/row counters, and material notes together in one place, on hardware you control — a mini-PC, a NAS, a home server, or just your own machine. No account, no subscription, no third-party server holding your project library.

I made this because my own crochet projects were scattered across printed patterns, PDFs, photos in random folders, and notes on paper. Stitchlet is basically the tool I wanted for keeping all of that in one spot while I'm actually sitting there with yarn in my hands.

Features

Dashboard with search, status filtering (Active, Paused, Finished, Frogged), sorting by updated date/title/status, and grid or list view
Upload pattern PDFs and read every page in a fit-to-width view, with counters beside the PDF on desktop or in a small dock on phones
Upload a project photo, with a replace/remove…

View on GitHub

Stitchlet is open source, licensed under Apache 2.0.

How I Built It

Stitchlet is a full-stack TypeScript application built as a single package.

The frontend uses:

React
Vite
React Router
Tailwind CSS
CSS variables for light and dark themes

The backend uses:

Hono
Node.js
SQLite
Drizzle ORM
Zod for shared validation and schemas

The React frontend uses a Hono API that manages projects, counters, custom sections, photos, PDFs, and backup operations.

Project data is stored in SQLite, while uploaded PDFs and images are stored in local folders on the host system. Files are served through application routes rather than a public static directory, which keeps them out of directory listings, though access control itself is left to the network layer (see the README for details on running this behind Tailscale or a reverse proxy).

One decision that mattered a lot was keeping storage local. Stitchlet runs through Docker Compose with mounted volumes for the database, uploads, and backups, so you can update or replace the container without losing your crochet library.

There's also a backup and restore system that packages the SQLite database and uploaded media into a ZIP archive. You can export that from the settings page and restore it later if you move the app to another machine.

I also made Stitchlet installable as a PWA, so on a phone or tablet it feels more like a dedicated crochet companion, and it’s handy when you're using the row counters mid-project.

The UI is built around how crochet projects and the things crocheters actually use. The counters have large tap targets, project details stay easy to scan, and the dashboard has search, sorting, status filters, grid and list views, and mobile-friendly layouts.

For deployment, there's a Docker image and a Docker Compose setup. You can run it locally, host it on a NAS, or access it privately through something like Tailscale.

What I Learned

This was a good reminder that a project doesn't need a huge audience to be worth building. It just needs to solve a real problem for someone, even if that someone is just me.

Because I actually crochet, I already knew which details mattered, at least to me: fast counters, easy access to PDFs, project photos, a place to list all of the materials I need, a place to write down random notes, and a way to recover everything if needed.

Building around my own workflow made the technical decisions easier, too... like skipping features that sound impressive on paper but wouldn't actually get used while sitting on the couch with yarn in your hands.

Since crocheting is something I do all the time and I will personally really enjoy using this app, this was a really fun challenge for me, and I'm happy to be able to share it and post my first submission!

DEV Community: Jessica Doering

I Tried the Mysterious Ox Alpha Model. Then I Fell Down the Rabbit Hole of Who Actually Made It.

Should AI Coding Agents Be Allowed to Fix Their Own Mistakes?

I Gave Claude, Codex, and Gemini the Same App to Build. Then I Made Them Blind-Judge Each Other.

The three games

First difference: how long they worked

Their different approaches showed up in the code

Time for the agents to judge each other

Were Claude and Codex biased toward themselves?

Claude actually preferred Codex visually

There was still a consensus winner

Was Claude actually the best value?

What I'm changing for the next experiment

This is definitely not a scientific benchmark

I built Kintara because apparently having too many hobbies eventually leads to building your own document management system.

The Hard Part of AI Coding Isn’t Using AI. It’s Knowing When Not to Trust It.

Plausible Is Not the Same as Correct

Due Diligence Is Part of the Workflow

Passing Tests Can Create False Confidence

Technically Correct Can Still Be Wrong

Choosing Tools Requires Judgment Too

Knowing What to Delegate Is Becoming a Core Skill

More Context Is Not Always the Right Context

Review the Change, Not the Confidence

The Developer’s Role Is Changing, Not Disappearing

Faster Coding Needs Better Brakes

PawDOS 95: A browser operating system for dogs

What I Built

Demo

Code

How I Built It

Prize Categories

Kitty Cafe, a whole bakery drawn in CSS 🐱🍰

Inspiration

Demo

Journey

One coordinate system, zero breakpoints

Eight cats pretending to be pastry

Drips that cannot spill

Waking the cat without JavaScript

The ball of yarn

The bug that got me

Accessibility

What I picked up

Built With

Repository

License

Finding bandwidth hogs on Linux

Install the tools

Start with nethogs

Check destinations with iftop

Verify sockets with ss

Use /proc on minimal systems

Quick reference

A practical workflow

Gem: A Desktop Scanner That Finds GitHub Repos Before They're Trending

I Built Quota to Track my AI Tools

I built Stitchlet because my crochet patterns were scattered across a dozen apps and a stack of paper

What I Built

Demo

Code

pinkpixel-dev / stitchlet

A self-hosted crochet companion for tracking projects, stitch counters, pattern PDFs, and progress photos locally on your own hardware. 🧶

Stitchlet

Features

How I Built It

What I Learned

Start with `nethogs`

Check destinations with `iftop`

Verify sockets with `ss`

Use `/proc` on minimal systems