DEV Community: Vilius

Five Things to Check When Delivering Fast

Vilius — Fri, 03 Jul 2026 15:43:46 +0000

By Vilius Vystartas

This is the follow-up to What Actually Changed in Two Weeks. That one was about setting up a project for AI-speed delivery. This one is about something I keep re-learning on every fast delivery.

You start shipping faster with AI. The code works, the feature lands, it feels good.

Then a few weeks later the feedback comes back, and some of it catches you off guard. Not because anything is broken — but because a few things that seemed obvious to you weren't obvious to the other side.

No drama. It happens. Here are five things I'm learning to check earlier.

1. What does "done" look like from their side?

To me, done means working software. To someone else it might mean pixel-match with a design. Both are valid.

What helps: A quick "what does good enough look like to you?" before the work starts. One sentence can save a lot of back and forth.

2. When will they actually look at it?

Sending something doesn't mean it gets reviewed immediately. It lands in a queue like everything else.

What helps: Naming a review date alongside the delivery date. "I'll share this Tuesday — could you take a look by Friday?" Turns silence from a mystery into a signal.

3. What needs to be perfect vs what can be improved later?

Not everything in the feedback is the same weight. A label change and a broken flow are different things. Without saying so upfront, everything looks like an emergency.

What helps: Two buckets agreed early. "Here's what I'll get right before it ships. Here's what I'd revisit in a follow-up." Makes the first feedback session more productive.

4. Could they see something before the full delivery?

The first time someone sees your work often sets the tone. Showing one page or one flow halfway through can catch mismatches before they multiply.

What helps: A mid-point check-in. "First page is ready — want to see if this matches what you had in mind?" Five minutes that can save a round of revisions.

5. Do they have the full picture?

You've been living in this feature. You know what's intentional and what you'd still tweak. They just see what's on screen.

What helps: A quick walkthrough at handover. "Here's what's working, here's what I'd improve with more time, here's where I'm unsure." Gives them the right lens to review through.

None of this is groundbreaking. It's just the stuff that's easy to skip when you're moving fast — and it turns out skipping it doesn't save time. It costs it later.

The good news is that when you do check these, the feedback loop compresses to a couple of hours of fixes instead of feeling like a bigger deal than it is.

This is the sequel to "What Actually Changed in Two Weeks." Same project. Different lesson.

More Watts, Less Light

Vilius — Mon, 29 Jun 2026 21:11:45 +0000

Token burn and business outcomes are not correlated. More burn means more inefficiency, not more value.

The electricity problem

Imagine you walk into a dark room. Turning on a light helps you see. Turning on every light in the building does not help you see better. It's still the same room. Now every surface is equally lit, the contrast is gone, and you're paying for power you didn't use.

Tokens work the same way. A focused prompt with clear scope is the single overhead light over your desk. A sprawling prompt with unlimited exploration is every light in the building — you're burning power, not producing insight.

Tokens are electricity, not output. More throughput doesn't mean more value.

I've had weeks where I burned through my allocation and looked back at the end to find nothing concrete. Code that worked but went unused. Exploratory branches that dead-ended. Agents that generated plausible-looking output that didn't survive first review. A lot of motion. Not much progress.

The ceiling stops you from doing that indefinitely. It forces a moment of reflection: did this burn produce anything real? If the answer is no, more capacity isn't the fix. More discipline is.

Three patterns I now use instead

I started paying attention to what actually ships versus what just burns context. I gave the patterns names so I could catch myself faster:

RTK — Read The Knowledgebase. A focused 15-minute read of the codebase, identifying the exact files and exact changes, saves 200K+ tokens of exploratory waste. The agent doesn't discover the shape of the task — it executes against a known one.
Caveman — compress before you prompt. Strip greetings, filler words ("I think", "basically", "Let me know if that makes sense"), and closing courtesies. Every word in your prompt multiplies across every response token. Less fluff in means less fluff out.
Ponytail — spec the minimum viable solution. "Robust", "scalable", "enterprise-grade", "comprehensive" — these words invite scope creep. Specify the simplest thing that works: "a Map with TTL, not Redis." An agent given clear constraints ships faster than one given permission to over-engineer.

These aren't hacks. They're accepting that the constraint is real and learning to work inside it before asking for more room.

The question the ceiling forces you to answer

From a business perspective, the question isn't "how many tokens did we use" or even "how much code did we generate." It's "what shipped that wouldn't have shipped otherwise, and was it worth what it cost?"

If the answer is unclear, more capacity isn't going to fix it. A bigger budget for waste just means you waste more, faster.

The real question: if you had unlimited tokens tomorrow, what would you do differently? If you can't articulate a concrete answer — not "ship faster" but "ship which thing, that I can't ship now" — then more capacity is just paying for more waste.

Two perspectives, same person

As the person running the agents day to day, I feel the ceiling. I'd like more room to let exploration run longer before cutting it off. That's an honest feeling.

As someone accountable for what actually ships, I need the ceiling to exist. It forces a discipline that unlimited capacity never would. It turns "try everything" into "try the right thing." It turns motion into direction.

The two perspectives aren't in conflict — they're the same person at different zoom levels. The engineering self wants headroom. The business self wants proof that headroom produces value. Both are correct. The tension between them is the whole point.

Not every team needs to raise the ceiling. Some genuinely do — running many parallel experiments, rapid prototyping, exploring multiple approaches. For them, more throughput would produce measurable value. But that's not most teams. Most teams are fine where they are. Their current output meets their current needs. The ceiling is a signal, not a problem to solve by default. A moment to ask: is this constraint stopping something valuable, or just stopping something busy?

The actual skill

I brush against the limit most weeks. Sometimes it's because the work justified every token. Sometimes it's because I let the agent run too long on inefficient prompts.

More electricity doesn't mean better light. More tokens don't mean better outcomes. The skill is knowing the difference.

How to onboard an existing project with AI tools

Vilius — Fri, 26 Jun 2026 08:39:33 +0000

You cloned a mature project, pointed an AI agent at it, and it produced garbage. It didn't know the auth flow, tripped on schema quirks, and kept writing code that didn't fit. You blamed the model. It wasn't the model's fault.

The problem isn't the agent's ability to code. It's your project's ability to be coded by an agent. This guide fixes that — one phase at a time. You don't need to finish all of them today. Do one, come back next week. The goal is progress, not perfection.

Before you start — take stock

Not every project needs the same treatment. Spend 10 minutes assessing what you're working with:

Does it have docs? Are they accurate?
Is there a test suite? Unit, integration, E2E?
What's the auth situation? Service account, MFA, SSO?
What does the README claim vs what's actually true?
Is there a committed schema (GraphQL, OpenAPI) or is the contract tribal knowledge?

You're looking for gaps in what an agent needs to work effectively. You'll fill them one at a time.

Phase one: Documentation baseline

An agent relearns your project every session unless you give it somewhere to look. That somewhere is a docs/ folder at project root. Every plan, spec, architecture decision, and bug fix goes there. Organized home, reduced mental load.

What lives in `docs/`:

AGENTS.md — how the agent should write code for this project. Conventions to follow, patterns to avoid, gotchas that aren't obvious from the code. This is more important than the README in 2026. Start with one, keep it honest. (If your tool prefers CLAUDE.md or CURSOR_RULES, use those — same purpose, different name.)

docs/BUGS.md — bug catalog with root causes, symptoms, and fixes. The same issue doesn't need to be fixed twice. The agent reads this before starting new work.

docs/LESSONS.md — things that went wrong. Architectural decisions that aged poorly. What the agent should never do. This is durable institutional memory — more valuable than any lint rule. New team members (human or agent) read this first.

docs/TECH-DEBT.md — anti-pattern inventory with a phased fix plan. The agent checks this before refactoring so it doesn't step into known traps.

docs/SPECS/ — feature specs and implementation plans. The agent works from a written spec, not memory. One plan per feature, organised by status.

docs/SCHEMA.md (optional) — data model reference. Committed types, API contracts, field descriptions. If your project has a formal schema, document it. If not, the existing code is the contract — and that's fine.

Frontend docs cross-reference backend docs. One entry point. The agent goes there first, guesses second.

Setup in one paste — single source of truth

mkdir -p docs/SPECS && cat > AGENTS.md << 'EOF'
# AGENTS.md

Before writing code: read this file, then check docs/ for known issues,
the data model, and project conventions. Tests must pass after changes.

All project knowledge lives in docs/. Single source of truth.
Read docs/BUGS.md, docs/LESSONS.md, and docs/TECH-DEBT.md before any work.
EOF
touch docs/BUGS.md docs/LESSONS.md docs/TECH-DEBT.md
echo "✅ docs/ + AGENTS.md created — agent entry point is set"

Paste that in your project root. Creates docs/ as the single source of truth and AGENTS.md as the agent's entry point. The agent reads AGENTS.md first, everything else branches from docs/. Works with Claude Code, Codex, Cursor, Pi — any agent that respects project docs.

The agent only links to AGENTS.md. That file points to docs/. One entry point, everything discoverable from there.

⚠️ The `/init` trap

Your favourite CLI will scan your project and generate documentation. Some of it will be wrong — wrong architecture labels, wrong folder purposes, wrong dependency descriptions. Service-layered vs atomic architecture look identical to a scanner. They aren't.

Read every line it wrote. Find what's incorrect. Fix it. The effort isn't generating text — it's curation.

Phase two: Testing — the trust threshold

This is the hard part. It determines how much AI can assist and how much trust you can hand over. Evals, regression safety, autonomous debugging — everything lives or dies on whether this works.

Don't have a full suite yet? Start with one smoke test. One spec that proves auth works. Expand later — the first domino matters more than full coverage.

Authentication — the blocker

Most mature apps won't let an agent in without MFA, SSO, or some redirect chain. If a service account exists, use it. Otherwise:

Ideally, use a persistent browser profile. Login once, the profile saves, reuses forever. Covers MFA, SSO, redirect chains — handled on day one, never touched again. Playwright makes this trivial:

npx playwright open --save-storage=.auth/profile.json
# login manually once in the headed browser window
# profile.json now saves the session — reuse everywhere

If you can't create a dedicated profile, clone your actual profile. Less ideal — you're coupling test setup to your personal session — but it works and gets you moving.

Don't use CDP. Chrome DevTools Protocol sounds elegant. Every time I've tried it, it flakes. Connection drops, session expires mid-test, weird race conditions. More time debugging the connection than writing tests.

After auth — the details

Login scripts. Cookie popup dismissals. Wait-for-element by specific selectors. Build these once, commit them, forget them. The agent inherits the same setup — same profile, same scripts, same waits.

Phase three: MCP servers — extending what the agent can do

Once docs and auth are in place, the next step is giving the agent tools it doesn't have natively. MCP servers do that — they're project-local services the agent discovers and calls automatically.

Two that matter for project onboarding:

Playwright MCP
Drives a real browser. The agent navigates to URLs, clicks buttons, reads the DOM, takes screenshots. Uses the same persistent profile from phase two, so auth just works. Drop a link and describe the bug — the agent reproduces it, inspects the mismatch, and writes a fix. No manual reproduction steps, no screenshot pasting.

Configured in the project's .mcp.json, pointing at a dedicated Playwright instance with the persistent Chrome profile. The agent discovers it automatically on session start.

Context7 MCP
Gives the agent up-to-date documentation and code examples for any library or framework. When the agent needs to use an unfamiliar API, it queries Context7 instead of guessing or hallucinating. Covers the full ecosystem — React, Fastify, GraphQL, Playwright, everything with published docs.

Where to get these

Playwright: npm install -D @playwright/test then npx playwright install chromium. The MCP server comes from @anthropic-ai/mcp-playwright or configure it manually via the MCP specification.
Context7: Available at context7.com — install their MCP server and configure it in your project.
Auth setup: Run npx playwright open --save-storage=.auth/profile.json, login once, reuse everywhere.

Phase four: Feedback loop

Now you have docs, auth'd tests, and tool access. What connects them is the workflow:

Write a spec
Agent implements against it
Tests run — pass or fail
Agent fixes or you review the output
Commit

This is the cadence. It doesn't need tooling — a single cycle proves the chain works. The loop matters before the automation does.

Useful add-ons (not inbuilt, go install these)

Beyond the setup, there are third-party tools worth knowing about. These aren't built into any framework — you find and install them yourself:

Caveman — compressed specification writing for agent-friendly specs. Cuts token count ~75% while staying precise. Useful when you need the agent to work from a spec that's dense enough to fit in context and precise enough to not hallucinate around.

RTK (Rust Token Killer) — CLI proxy that reduces LLM token consumption by 60-90% on common dev commands. Filters and compresses command outputs (ls, git, cargo test, pytest, etc.) before they reach your LLM context. Single Rust binary, 100+ supported commands, <10ms overhead. Install via brew install rtk or rtk init --agent hermes. When work needs millions of tokens, RTK is the lever — cuts the noise, keeps the signal. github.com/rtk-ai/rtk

Ponytail — efficiency patterns for agentic development. Developer-laziness-as-virtue philosophy: ship what you own, validate what you don't. Covers code compression, structural laziness patterns, and avoiding over-engineering.

What this unlocks

Once docs, auth, and MCP tools exist, you've passed the threshold. Not the finish line — but the point where the agent becomes useful instead of dead weight.

Drop a link, describe the bug — the agent debugs it itself.
Playwright MCP opens the browser, navigates, interacts, reads the DOM. One prompt: "the dropdown on this page shows wrong values" → agent reproduces, identifies the mismatch between API response and render, fixes it.

Feed design screenshots — the agent builds from them.
Pixel-perfect? Not yet. Close enough that your job shifts from building to reviewing.

Ask for a new field — the agent checks the schema, migrates if needed, builds.
If your project has a committed schema (GraphQL, OpenAPI, types file), the agent reuses what exists or creates the migration. If it doesn't, the agent works from the existing code as the implicit contract. Either way, backend and frontend stay consistent without manual coordination.

Hand off to a colleague on another OS.
Windows, macOS, Linux — same setup, same agent, same reliability. I handed over a solution on a 2-hour call. The agent drove a persistent Chrome browser until deployment issues were resolved. No SSH. Just "fix this."

Ask it to fix code smells across the codebase.
With the test suite as a safety net, the agent can refactor confidently.

2026 best practices that changed the game

Agent-specific docs over human READMEs.
CLAUDE.md / AGENTS.md is the most important file in the project now. READMEs tell humans how to run it. Agent docs tell the agent how to think about it. Different audiences.

Document the data model.
If your project has a formal schema (GraphQL, OpenAPI, protobuf), commit it and make it the source of truth. If it doesn't, document the implicit contract — key types, API shapes, field meanings — in docs/SCHEMA.md. The agent reads this before touching data-layer code. The goal isn't a perfect schema, it's less guesswork.

Auth persistence as infrastructure.
Persistent browser profiles aren't a convenience. They're infrastructure. Without them, the agent spends half its context on re-authenticating. With them, every session starts ready to work.

LESSONS.md as institutional memory.
What went wrong last sprint. Why the agent should never mutate cache in a certain path. This prevents more bugs than any lint rule.

Document the anti-patterns, not just the patterns.
What not to do is more valuable than what to do. An agent can guess the pattern. It can't guess the mistake you made three months ago unless you wrote it down.

MCP servers extend tool reach.
The trend in 2026 is project-local MCP servers that give the agent capabilities it doesn't have natively — browser driving (Playwright MCP), documentation lookup (Context7 MCP). Configure them in the project, commit the config, the agent discovers them automatically.

What still needs you

Cross-file refactors with implicit dependencies — the agent misses ripple effects across distant modules
Product judgment — anything that needs taste, not correctness
First-time architectural patterns — you scaffold the structure, the agent fills it in
Curating the docs baseline — the initial curation is still a human task

The ratio shifts hard. Most of what took hours now takes minutes of review.

When to stop

You don't need full coverage. You need enough coverage to trust the output. One auth'd E2E test, one docs baseline, one MCP server — that's the minimum viable setup. Everything else is compound returns.

If today wasn't the day — that's fine. The project will be here tomorrow. Pick one thing, move it forward, stop when you've made progress.

Phases one and two are the hard ones. The rest is where the compound returns live. You can stop after any of them.

Three Loops, No Ship

Vilius — Thu, 25 Jun 2026 21:59:12 +0000

I spent three iterations on an auto-fix pipeline that still doesn't work reliably. Here's what I learned.

Loop 1

Wrote a background script. Pull tickets from Azure DevOps, run them through a local model, hand to a coding agent, push the result.

Poll → triage → fix → push.

Worked 40% of the time on trivial tickets. Anything that crossed file boundaries or needed real context — stalled or hallucinated.

I shipped it anyway. That was naive.

Loop 2

Made it smarter. Pre-selected relevant files. Broke big tickets into subtasks. Turned complex edits into atomic steps with verification between each.

Got it to 55% or so. But every fix created two new edge cases. The complexity was compounding faster than the reliability.

Loop 3

Went all in. Embeddings for dedup. Multi-repo routing. Auto-revert. A learning loop that fed failures back into future runs.

The model server started dying. 890 memory errors in a day.

Root cause: two independent consumers hitting the same local model server, each with its own retry loop. When memory filled up, retries amplified instead of staggering. The system was making itself worse.

Fixes were simple in hindsight — stop retrying OOM, serialize access, use the local binary not npx. But the pattern kept repeating: add more to fix the last thing, break something else.

Where I'm At

The pipeline still only works on easy tickets. Hard ones need a human. After three rounds, the main thing I learned is that local models hit a wall before your ambition does — not in quality, in working memory.

And adding features doesn't fix reliability gaps. It just moves them around.

The 507 retry spiral taught me more than any successful deploy this year. Because it was entirely my fault. Not the model's, not the framework's. I built concurrent consumers with independent retry loops and expected them to coordinate. They didn't.

What's Next

I'll do a fourth loop. Smaller. A dedicated fast model for cheap work, the big model only for editing. One consumer at a time.

Might work. Might be loop 5's prologue.

I'm looking for people building similar things. Local agent pipelines, auto-fix loops, small-model orchestration — the stuff that's not quite working yet but you keep iterating on.

No Slack. No Discord. No newsletter. Just people who build this stuff and want to compare notes.

What media would you gravitate around? A private GitHub org? A Telegram group? Occasional calls? Reply or find me — curious what works.

Failure post, not a success story. If you're building something similar — don't retry OOM, serialize your consumers, and measure what your model server can actually hold.

What actually changed in two weeks

Vilius — Thu, 25 Jun 2026 15:35:43 +0000

I built a large feature. That's not what this is about.

What changed is the baseline — the standards, docs, and automation that exist now and didn't two weeks ago. Everything after this will be built on top of it.

Automated tests now ship with new features

QA testers were testing. The product was covered. What didn't exist was automation — no E2E suite, no unit tests for new work, no repeatable spec.

Now it does. The manual QA cycle stays. The automation catches what humans miss on the tenth pass.

Quality leap going forward. Human hours saved. The next feature ships with both.

The baseline is set

Knowledge lives in the repo. Bug catalog with root causes — so the same thing doesn't get fixed twice. Tech debt inventory with a phased plan. Testing strategy documented, not assumed. GraphQL schema committed and validated against — drift gets caught before it ships. Pre-commit hooks that enforce the standards automatically.

The frontend and backend documentation are cross-referenced as single sources of truth. The agent instructions point to the right places. Everything new builds on what's already written.

Schema-first development

The workflow is now: if the schema accommodates the new field, reuse what exists. If it doesn't, the schema update creates the new structure, the data migrates, and everything stays consistent.

No guessing. No drift. One source of truth for what the data looks like.

The feature is what you see. The baseline is what you don't — and it matters more.

Running a local coding agent on a Mac Mini — the actual setup

Vilius — Sun, 21 Jun 2026 16:17:07 +0000

Running a local coding agent on a Mac Mini

Running a local coding agent on a Mac Mini — the actual setup

By Vilius Vystartas

I have an agent that does my low-stakes coding. File edits, test fixes, build verification. The kind of work you'd normally do yourself but it's faster to delegate. It also writes Playwright tests, reviews code, updates documentation, and runs deploys.

It runs locally — Mac Mini M4, 24 GB. No cloud API calls for the coding part. The orchestration layer still uses a cheap cloud model for planning and routing. The actual file editing is done by Pi, a coding agent that connects to oMLX, an OpenAI-compatible local LLM server.

The same setup can drive Claude Code, Codex, or any coding agent that speaks OpenAI-compatible API. Pi is what I use, but the oMLX server works with anything.

All the model names, config files, and paths are inside the script at the bottom.

Two models

I keep two and swap depending on the task. The 24 GB can't hold both at once.

One as good as I can have on this machine — 9B class, ~20 tok/s. Primary coding model.

Another fast — 4B class, ~27 tok/s. File edits, quick fixes, daily tasks.

The swap script moves one out, brings the other in, restarts the server. Takes about 5 seconds.

What Pi does

File edits and refactoring
Writing and fixing tests (Playwright, unit tests)
Build verification
Code review
Documentation updates
Running deploys

Anything more complex than a one-liner goes through RPC mode. The orchestration layer writes a prompt, Pi executes, the result comes back. No tmux, no process wrangling.

Pi extensions — what they do, why I use them

pix-optimizer — ponytail + caveman (lazy dev mode and token compression). Keeps Pi output tight and skips boilerplate.
context-mode — workspace routing and tool call interception. Keeps Pi from wandering into the wrong directories.
pi-subagents — spawns sub-agents. Parallel work without blocking the main session.
pi-workflow-engine — multi-step task orchestration. Lets Pi handle sequences without losing context.
pi-mcp-adapter — MCP server connectivity. Connects to context7 and scrapling for external tools.
@fgladisch/pi-caveman — additional compression on top of pix-optimizer.

Known issues

Can only keep one model loaded at a time. Two = OOM. Swap script handles it.
Thinking mode must be disabled. Defaults to chain-of-thought, kills speed.
Full chat history in prompts crashes the local model. Prompts must be just the files and changes.
Print mode skips safety controls. Use RPC mode for anything non-trivial.
First request after a model swap can time out. Retry once.

The blueprint

curl -fsSL https://workswithagents.dev/static/setup-local-llm-pi.sh | sh

What happens when your OpenRouter key gets stolen? Nothing. Then you move on.

Vilius — Tue, 16 Jun 2026 02:53:06 +0000

I woke up to a bill that wasn't mine. Balance zeroed, burned on a model I don't use. Someone found my OpenRouter key in an exposed env variable and ran it dry.

That's it. No alert. No threshold. No "maybe check this." Just a zeroed balance and the lesson.

I know what you're thinking — rate limits. Secret audits. Budget caps. Yeah. Living in the real world doesn't always work that way. You push things, you trust the token in export OPENROUTER_KEY=sk-... stays where you left it. It doesn't. A scumbag finds it and your API key becomes their API key.

The annoying part isn't even the money. It's the rethinking. Where else am I exposed?

Then you go looking for help. It's not in the dropdown. Not within easy reach of credit history or billing. Not available to tired eyes at 3am when you're trying to figure out what the hell just happened. There's no button to report. No obvious kill switch. Just the knowledge base telling you to be more careful.

I'm not dropping an X message. Don't care to waste even more time. Support shouldn't be optional. A spending cap should be obvious. An alert for a 3000% spike should exist by default. The "report abuse" button shouldn't require a site drill.

None of that was there. So I took the hit, added a hard limit, scrubbed my env files, moved on.

The scumbag? Nobody. They sweep keys from GitHub repos and deployment logs a hundred times a day. I'm not going to find them.

But I'm going to have a spending cap next time.

The End of the US Cloud Monopoly: AI Balkanization Is Here to Stay

Vilius — Sat, 13 Jun 2026 08:28:42 +0000

By Vilius Vystartas | June 2026

The single, globally unified internet is gone. What's replacing it is a patchwork of sovereign AI zones, each running its own stack on its own hardware with its own rules.

This isn't a prediction. It's already happening, and the next three years will cement it.

What Broke the Monopoly

The US government's approach to AI regulation — treating frontier model weights as controlled munitions — had an unintended consequence. By demonstrating that access to US cloud infrastructure can be switched off by regulatory decree, they forced every non-US government and enterprise to build a backup plan.

The January 2025 AI Diffusion Rule created a three-tier world: unrestricted allies, capped nations (50,000 GPUs/year), and total embargoes. For the 140+ countries in Tier 2, US cloud services became inherently unstable. You can't build a national AI strategy on a faucet that might turn off.

The DeepSeek R1 moment in January 2025 proved the point: a Chinese quant hedge fund trained a frontier reasoning model on nerfed hardware for $5.6 million. Export controls didn't stop the frontier. They just accelerated the development of independent stacks.

The Three Zones

The tech industry is splitting into three distinct legal and architectural zones, each with its own economics:

The US Zone — high-performance, high-surveillance closed models. OpenAI, Anthropic, Google. Restricted to US citizens and close Tier 1 allies. The best models, the most monitoring, the least legal recourse if you're outside its borders.

The European Zone — regulated, open-source-first, locally hosted. Data privacy is the architecture, not a compliance checkbox. France's Mistral, Germany's Aleph Alpha, the fragmented but determined GAIA-X federation. GDPR compliance isn't overhead — it's the product.

The Asian/Non-Western Zone — independent stacks operating entirely outside the Western financial and regulatory sphere. DeepSeek, Alibaba's Qwen, Baidu's Ernie. Huawei Ascend chips replacing NVIDIA. No US venture capital, no US cloud, no US export license risk.

The Sovereign AI Infrastructure Boom

Every non-US government with ambition is building national AI infrastructure. Not optional. Existential.

Europe is scattering exascale systems across the continent — Germany's JUPITER, Finland's LUMI, Italy's LEONARDO. Federated, fragmented, deliberately not dependent on any single provider.

The Middle East is placing bigger bets. Saudi Arabia's $40 billion AI fund. UAE's G42 building Condor Galaxy on Cerebras hardware, then selling a $1.5 billion stake to Microsoft — on condition it cut Chinese ties. The message: even your sovereign compute comes with geopolitical strings.

India's $1.25 billion IndiaAI Mission aims for 10,000+ GPUs through Yotta's Shakti Cloud. But at Tier 2's 50,000 GPU cap, the ambition outstrips the allocation.

Japan's SoftBank committed nearly a billion to AI datacenters. ABCI 3.0 is operational with H100 clusters.

Every single one runs some form of open-weight model. Because closed APIs can be switched off at a whim.

Open Weights Won

The question of whether enterprises would choose open-source models over closed APIs is settled. They will.

Meta's Llama 3.1 405B proved open models can match GPT-4 class performance. Mistral proved European sovereignty models are commercially viable. DeepSeek proved frontier reasoning can be open. The entire ecosystem shifted from "can open models compete?" to "how do we productionize our chosen open model?"

The calculus is simple: slightly lower benchmark scores in exchange for complete operational certainty. No API key to revoke. No pricing change that breaks your margin. No geopolitical event that cuts your access.

This has driven massive innovation in on-device and on-premises deployment. Models under 70 billion parameters — often under 10 billion — that run on corporate hardware rather than centralized server farms. Microsoft's Phi-4, Apple's on-device models, Google's Gemma, Meta's Llama 3.2 small variants. The edge is where the action is.

The Death of the API Wrapper

The venture capital correction is brutal but predictable. Startups whose entire value proposition was piping data to a third-party US API can't raise international funding. Their core product can be wiped out overnight by a single regulatory pen stroke — or a pricing change, or a model deprecation, or a geopolitical event.

Jasper went from $1.5 billion valuation to significant layoffs. The entire "GPT wrapper" category is being reframed as a 2023-2024 anomaly.

The new valuation premium isn't about who uses the flashiest model. It's about who owns the proprietary training data to build independent, in-house models. Palantir's stock surge, BloombergGPT's financial data moat, healthcare AI companies valued on unique patient datasets — the market is betting on data ownership, not API access.

What Nobody's Saying About the Hardware

This entire scenario depends on one unresolved bottleneck: TSMC manufactures over 90% of advanced AI chips.

The US CHIPS Act ($52.7 billion), the European Chips Act (€43 billion), and TSMC's own global fab expansion (Arizona 4nm, Japan operational, Germany planned) are all trying to address this. But fabrication takes years. The RISC-V ecosystem is promising but a decade behind CUDA in maturity and tooling.

The real risk isn't that US export controls will stop frontier AI development. DeepSeek proved they won't. The risk is that the hardware supply chain itself becomes a weapon — and every sovereign AI zone discovers that independence at the architectural level means nothing without independence at the fab level.

The 3-5 Year Outlook

The trajectory is clear:

US cloud APIs become a premium product for US-aligned customers only
Open-weight models become the global enterprise default
National datacenters proliferate in every region that can afford them
Data ownership replaces model access as the primary valuation driver
The supply chain question remains the unresolved wildcard

This isn't a temporary fragmentation that heals with better policy. It's a permanent structural shift. The unified global technology ecosystem that defined the last two decades is over. The question isn't whether the balkanization happens — it's whether your infrastructure is ready for it.

We Asked 10 LLMs to Write Efficient Code. Only 4 Got Better.

Vilius — Tue, 26 May 2026 22:46:48 +0000

By Vilius Vystartas | May 2026

Every LLM can write code that works. The question is: can they write code that's efficient — and does telling them to be efficient actually help?

I tested 10 models on 10 coding tasks, each in two phases: unprompted (the model writes its own code) and prompted (explicitly told to write clean, DRY, efficient code). That's 200 API calls, $0.56 total. The results are... not what most prompt engineers would predict.

GPT-5.4 was the only model where prompting gave a substantial boost (+0.20). For most models, the "write efficient code" prompt was meaningless or actively harmful.

How the Metric Works

Each task has a known optimal token budget — the minimum tokens needed to produce correct, DRY code for that task (e.g., 70 tokens for 10 styled buttons using CSS classes vs 340 tokens for 10 separate button blocks). The efficiency score is optimal_tokens / actual_tokens, capped at 1.0.

A score of 0.63 means the model used about 1.6x the optimal — not bad. A score of 0.43 means it used about 2.3x the optimal. The gap between unprompted and prompted tells you whether the "write efficient code" instruction actually changes behaviour.

The Leaderboard (Sorted by Prompted Efficiency)

#	Model	Unprompted	Prompted	Δ	Frugal	Cost	Correctness
🥇	GPT-5.4	0.43	0.63	+0.20	30%	$0.096	78% → 85%
🥈	Qwen 3.6 Plus	0.44	0.60	+0.17	40%	$0.158	78% → 87%
🥉	Gemma 4 31B	0.54	0.58	+0.04	50%	$0.003	92% both
4	DeepSeek Chat	0.51	0.55	+0.04	30%	$0.006	91% → 80%
5	Claude Sonnet 4	0.47	0.52	+0.04	40%	$0.121	92% both
6	LFM 2 24B A2B	0.54	0.47	-0.06	30%	$0.001	90% → 80%
7	Mistral Large 2411	0.54	0.46	-0.08	40%	$0.050	90% → 82%
8	Gemini 2.5 Flash	0.47	0.46	-0.01	50%	$0.020	92% → 90%
9	Cohere Command A	0.60	0.44	-0.17	40%	$0.071	90% → 82%
10	Kimi K2.6	0.34	0.43	+0.09	30%	$0.029	76% → 86%

What Stands Out

GPT-5.4 Is the Prompt Whisperer

GPT-5.4 improved on 7 of 10 tasks when prompted for efficiency. The biggest wins were config-generation (+0.81 — went from 12 inline JSON blocks to a template loop), html-from-data (+0.71), and magic-strings (+0.38 — switched to an Enum). It's the only model in the batch where the "write efficient code" instruction consistently produces different (and better) output.

The cost is notable — $0.10 for 20 tasks is mid-range, not cheap, not expensive. But the efficiency gain is real.

Gemma 4 31B: The Quiet Winner

Half of Gemma 4's tasks were already "frugal" — naturally efficient without being told. It scored 92% correctness on both phases at just $0.003 total. That's a 40x cost advantage over GPT-5.4 with higher correctness and competitive efficiency. For high-volume production where you want concise, correct code, Gemma 4 31B is the value pick of this batch.

Cohere Command A: Prompting Backfires

Cohere Command A had the highest unprompted efficiency in the batch (0.60) — it naturally writes concise code. But when told "write efficient code," it ballooned output on several tasks. html-from-data went from a tight 45-token solution to a 600+-token monstrosity (-0.92 gap). The prompt made it overthink.

Lesson: if a model is already efficient, don't prompt it to be more efficient.

Qwen 3.6 Plus: Second Place, Slowest

Qwen 3.6 Plus scored second in prompted efficiency (+0.17 improvement) but took 26 minutes for 20 tasks — by far the slowest model. The efficiency gain is real (especially on html-from-data where it went from hardcoded rows to a map/join pattern), but you're waiting for it. Batch workloads only.

The Kimi Surprise

Kimi K2.6 had the lowest unprompted efficiency (0.34 — verbose, boilerplate-heavy code) but improved the most at the bottom end (+0.09). Still last place, but the prompt actually helped it compress — which is the opposite of the Cohere effect. Some models need the nudge.

Frugality: What Does It Mean?

"Frugal" means the model naturally produced code at or near the optimal token count without being asked. Gemma 4 31B and Gemini 2.5 Flash led at 50% — half their tasks were already efficient. GPT-5.4, DeepSeek Chat, and Kimi K2.6 were only 30% frugal — they needed the prompt to tighten up.

The Bigger Picture

Group	Models	Behaviour
Prompt-responsive	GPT-5.4, Qwen 3.6 Plus	Efficiency improves substantially with prompting
Prompt-neutral	Gemma 4 31B, DeepSeek Chat, Claude Sonnet 4, Gemini 2.5 Flash, Kimi K2.6	Prompt has little effect (±0.04)
Prompt-antagonistic	LFM 2 24B A2B, Mistral Large 2411, Cohere Command A	Efficiency drops when prompted

The prompt-antagonistic group is the most interesting. These models know how to write efficient code (0.54-0.60 unprompted), but the explicit instruction triggers over-engineering — they add abstractions, comments, error handling, and other bloat that makes the output less efficient by the metric.

If the prompt says "write efficient code" and the model responds by writing more tokens, something in the training signal is misaligned.

My Picks

Best prompted efficiency: GPT-5.4 — 0.63, $0.10 for 20 tasks. The only model where prompting reliably improves output.
Best value overall: Gemma 4 31B — 0.58 prompted, 92% correctness, $0.003. Absurd price/performance.
Best natural efficiency: Cohere Command A — 0.60 unprompted. Don't prompt it, just let it work.
Most consistent: Claude Sonnet 4 — 92% correctness on both phases, small +0.04 efficiency gain. Reliable.
Skip if you're in a hurry: Qwen 3.6 Plus — 26 minutes for 20 tasks. Great efficiency gains, terrible latency.
Watch list: Kimi K2.6 — low base efficiency but the prompt actually helps. Worth retesting with a better prompt.

Methodology

Ten real-world coding tasks across CSS, JavaScript, Python, SQL, and bash — each with a known optimal token budget for a correct, DRY solution. Tasks included: styling 10 buttons (CSS), rendering 20 data rows as HTML (JS/HTML), bulk renaming (shell), form validation (Python), parametrized tests (Python), unit conversion (Python), SQL reporting queries, config generation (JSON), magic string replacement (Python/Enum), and middleware decorator pattern (Python/Flask).

Each model ran 10 tasks unprompted, then the same 10 tasks with an efficiency prompt appended. Scoring: efficiency_ratio = optimal_tokens / actual_tokens (capped at 1.0). Correctness scored against expected output patterns.

Total cost: $0.56 for 200 API calls (10 models × 10 tasks × 2 phases). Temperature: 0.1. Max tokens: 600.

Full results: benchmarks.workswithagents.dev

10 Models Tested: From 81.6% to 10%. The Free Tier is a Full-On Gamble.

Vilius — Tue, 26 May 2026 22:42:59 +0000

By Vilius Vystartas | May 2026

I tested another 10 models across the same 10 agent coding tasks. Four of them were free-tier models — and the range was absurd: Owl Alpha scored 76.7% with zero hard fails, Laguna M.1 scored 10% and produced garbage on 9 out of 10 tasks. The free tier is not free if it costs you debugging time.

Total cost for all 10 models: $0.10. The paid models (6 of 10) came to $0.10 combined.

Batch 12 Leaderboard

#	Model	Score	P/P/F	Cost	Time	Category
🥇	Grok 4.3	81.6%	7/3/0	$0.017	39.9s	Paid (xAI)
🥈	Perceptron Mk1	79.9%	8/1/1	$0.002	29.3s	Paid (Perceptron)
🥉	Owl Alpha (free)	76.7%	5/5/0	Free	83.0s	Free tier
4	xAI: Grok Build 0.1	75.0%	5/4/1	$0.034	95.3s	Paid (xAI)
5	OpenAI: GPT Chat Latest	73.3%	6/2/2	$0.043	18.7s	Paid (OpenAI)
6	Mistral Medium 3.5	71.6%	6/2/2	$0.008	12.6s	Paid (Mistral)
7	Nemotron 3 Nano Omni (free)	50.0%	4/2/4	Free	23.5s	Free tier
8	Laguna XS.2 (free)	49.7%	3/3/4	Free	28.7s	Free tier
9	Baidu CoBuddy (free)	40.0%	4/0/6	Free	362.4s	Free tier
10	Laguna M.1 (free)	10.0%	1/0/9	Free	89.8s	Free tier

The Headlines

Grok 4.3 (81.6%, $0.017, 39.9s) — Grok's latest release takes the batch with zero hard fails. Seven clean passes, three partials. Process-monitor was the only full pass it earned that 4.3's competitors missed. xAI's Grok line is quietly consistent — 4.1 Fast (76.7%), 4.20 (75%), and now 4.3 (81.6%) — all within striking distance of the 80%+ club without crossing into premium pricing.

Perceptron Mk1 (79.9%, $0.002, 29.3s) — A brand new family debuts at nearly 80%, with eight passes — the most in the batch — for two-tenths of a cent. The one failure (regex-extract at 17%) is a known weakness for small models. At this price-to-pass ratio, Perceptron Mk1 is the value story of this batch.

Owl Alpha (free, 76.7%, 83.0s) — A free model with zero hard fails and 5 full passes. That's the standout free-tier result. Takes 2x longer than paid models for some tasks (24s on csv-stats vs 1-3s for the field), but the code is functional. If latency isn't critical, this is usable.

The Free Tier Lottery

Four free models. Results:

Model	Score	Verdict
Owl Alpha	76.7%	Usable — zero hard fails, 5/10 full passes. Slow but functional.
Nemotron 3 Nano Omni	50.0%	Mixed — half of tasks hit output cap at 400 tokens. Hit or miss.
Laguna XS.2	49.7%	Unreliable — 400-token cap kills complex responses.
Baidu CoBuddy	40.0%	Frustrating — 362 seconds total. Half the tasks hit output cap at 399 tokens. Waiting 6 minutes for 40% accuracy is not a good trade.
Laguna M.1	10.0%	Broken — 1/10 passes. Every response capped at 400 tokens. Do not use.

The free tier cap of 399-400 output tokens is the real problem. Models like Laguna M.1 and CoBuddy truncate every response, turning what could be a partial into a fail. Owl Alpha works despite the cap because its outputs are concise enough to fit.

Pay $0.002 for Perceptron Mk1 and get 8/10 passes, or use Laguna M.1 free and get 1/10. The math is not subtle.

Disappointments

GPT Chat Latest (73.3%, $0.043) — OpenAI's catch-all endpoint was solid on easy tasks (file-parse, csv-stats, sql-query all passed) but fell apart on fix-bug (0%) with a lengthy, expensive hallucination. The most expensive model in the batch and it doesn't crack 75%.

Mistral Medium 3.5 (71.6%, $0.008) — Fastest model in the batch at 12.6s total, but the process-monitor task hit a 504 Gateway Timeout and scored 0%. A timeout fail on a model that otherwise looks strong carries a disproportionate penalty — without it, Medium 3.5 would be at 79.5%.

Laguna M.1 (10%) — The worst score in any batch I've run. Seven of its task responses were blank 400-token output cap fills. Not worth listing on OpenRouter.

Price/Performance

Model	Score	Cost	$/%-pt
Owl Alpha (free)	76.7%	$0	$0
Nemotron 3 Nano Omni (free)	50.0%	$0	$0
Laguna XS.2 (free)	49.7%	$0	$0
Baidu CoBuddy (free)	40.0%	$0	$0
Laguna M.1 (free)	10.0%	$0	$0
Perceptron Mk1	79.9%	$0.002	$0.0024
Mistral Medium 3.5	71.6%	$0.008	$0.0108
Grok 4.3	81.6%	$0.017	$0.0209
xAI: Grok Build 0.1	75.0%	$0.034	$0.0450
GPT Chat Latest	73.3%	$0.043	$0.0584

Free models dominate the $/%-pt table by definition, but only Owl Alpha is actually usable. Among paid models, Perceptron Mk1 at $0.0024/%-pt is the efficiency winner — 24x cheaper per point than GPT Chat Latest.

My Picks

Best overall: Grok 4.3 — 81.6%, 39.9s, $0.017. Cleanest leaderboard of the batch.
Best value (paid): Perceptron Mk1 — 79.9%, $0.002 total. Eight passes for two-tenths of a cent.
Best free model: Owl Alpha — 76.7%, zero hard fails. The only free model I'd ship with in production.
Fastest: Mistral Medium 3.5 — 12.6s for all 10 tasks
Skip entirely: Laguna M.1 and all Laguna free-tier variants. 10% is not testable.

Methodology

Same setup as previous batches: ten real-world agent coding tasks — file operations, shell commands, error recovery, data parsing, SQL queries — tested via OpenRouter. Max tokens: 400. Temperature: 0.1. Pattern-matching scoring against expected outputs.

Pre-flight verification caught zero failures this batch. Total cost: $0.10. Total dataset: 168 models tested across cloud and local.

Full results and per-task scores: benchmarks.workswithagents.dev

I Tested 10 More Models. Five Brand New Families Debuted. None Scored Below 75%.

Vilius — Tue, 26 May 2026 18:48:33 +0000

By Vilius Vystartas | May 2026

I ran another 10 models through the same agent coding benchmark. Five of them were from completely untested families — Sao10k, Anthracite, Inflection, Mancer, Undi95 — and every single one scored 75% or higher on its first try. This is getting harder to keep up with.

Two more models tied the all-time record at 90%. The cheapest model ever tested cost $0.0001 for a full 10-task benchmark.

The New 90% Club Members

Eight models have now hit 90% on this benchmark. Batch 11 added two:

Mistral Large 2411 (90%, $0.008, 46s) — Mistral's November 2024 flagship matches their current Large 3. Sometimes the first version is still the best one. Zero hard fails, clean passes on 8/10 tasks.

DeepSeek Chat V3-0324 (90%, $0.002, 73s) — The older V3 variant from March 2024 matches the original DeepSeek Chat at 90%. Every time I test a DeepSeek variant, it lands at 80-90%. The family is remarkably consistent.

The 90% club now includes: DeepSeek Chat (original), DeepSeek Chat V3-0324, Qwen3 Coder 30B, Nemotron 3 Nano 30B, Codestral 2508, Mistral Large 2411, MiniMax M2 Her, and Baidu Ernie 4.5 300B. Eight models. Seven of them cost less than a cent per full benchmark.

Five Families, First Try

Every new family debuted at 75% or higher. That's an impressive hit rate.

Family	Model	Score	Cost	Time
Sao10k	L3.1 Euryale 70B	85%	$0.002	29s
Sao10k	L3 Lunaris 8B	85%	$0.0001	20s
Anthracite	Magnum V4 72B	85%	$0.006	35s
Mancer	Weaver	80%	$0.003	30s
Undi95	Remm Slerp L2 13B	75%	$0.002	31s
Inflection	Inflection 3 Productivity	75%	$0.012	42s

*Inflection 3 result is provisional — awaiting lab response. Will update in due course.

L3 Lunaris 8B at $0.0001 is the cheapest model I've ever tested. A full 10-task benchmark for one ten-thousandth of a dollar. At this price, there's no reason not to test a model before you ship with it. Lunaris scored 85% — competitive with models that cost 100x more.

The Sao10k family (L3.1 Euryale 70B and L3 Lunaris 8B) is the standout. Both models scored 85%, both are fine-tunes of Llama 3.1/3, and both cost almost nothing. Community fine-tunes continue to punch above their weight.

The Recoveries

Two Qwen models from my previous failed batch completed successfully this time:

Qwen3 8B (80%, $0.02, 543s) — Needed per_call_timeout: 300 to finish. The model is competent (6 passes, 4 partials, zero fails) but painfully slow. Each API call takes 100-120 seconds on OpenRouter. Use it as a background job, not a real-time agent.

Qwen Plus 2025-07-28 (80%, $0.001, 19s) — The dated variant works perfectly with enable_thinking: false. 80% at $0.0009 is great value. But use the current qwen/qwen-plus ID instead — it scores 85% and doesn't need the dated suffix.

Price/Performance

Model	Score	Cost	$/%-pt
L3 Lunaris 8B	85%	$0.0001	$0.0001
DeepSeek Chat V3-0324	90%	$0.002	$0.0017
L3.1 Euryale 70B	85%	$0.002	$0.0021
Remm Slerp L2 13B	75%	$0.002	$0.0020
Mancer Weaver	80%	$0.003	$0.0041
Anthracite Magnum V4 72B	85%	$0.006	$0.0066
Mistral Large 2411	90%	$0.008	$0.0093
Inflection 3 Productivity	75%	$0.012	$0.0156
Qwen3 8B	80%	$0.020	$0.0254

The ratio between cheapest and most expensive $/%-pt is 254x. Lunaris at $0.0001/%-pt vs Qwen3 8B at $0.0254/%-pt — same tier of score, wildly different cost profiles.

My Picks

Best overall: Mistral Large 2411 — 90%, 46s, $0.008
Best value: L3 Lunaris 8B — 85%, $0.0001 total. Absurd price/performance.
Best new family debut: Sao10k — both models at 85% first try. Watch this line.
Fastest: L3 Lunaris 8B — 20 seconds for all 10 tasks

Methodology

Same setup as the previous 10 batches: ten real-world agent coding tasks — file operations, shell commands, error recovery, data parsing, SQL queries — tested via OpenRouter. Max tokens: 600 (Qwen models), 300 (everyone else). Temperature: 0.1. Pattern-matching scoring against expected outputs.

Pre-flight verification caught zero failures this batch. All 10 candidates passed the simple-prompt test. Total cost: $0.05 for the core 8 models, then $0.02 for the Qwen recovery run. Total dataset: 158 models tested across cloud and local.

Full results and per-task scores: benchmarks.workswithagents.dev

Two Models Just Hit 90% on Agent Coding. One Cost Less Than a Penny.

Vilius — Tue, 26 May 2026 09:46:02 +0000

By Vilius Vystartas | May 2026

Ten more models through the same 10 agent coding tasks. Two tied the all-time record. One cost $0.0002. The other hit the score at $0.0018 — cheaper than most models scoring 70%.

Batch 10 was the cheapest one yet.

The Leaders

Two models scored 90% with zero hard fails, joining MiniMax M2 Her and Baidu Ernie 4.5 300B as the highest-scoring models on this benchmark:

Qwen3 Coder 30B A3B — 90% in 28 seconds, $0.0004. An efficient coder that doesn't burn budget on thinking tokens it doesn't need.

DeepSeek Chat (original) — 90% in 59 seconds, $0.0018. The original DeepSeek Chat still competes with modern models on agent coding. Newer doesn't always mean better.

The Surprises

LFM 2 24B A2B (85%, $0.0002, 15s) is the cheapest model I've ever tested. Liquid's debut family is absurdly cost-effective. A full 10-task benchmark for literally $0.0002. At this price/performance ratio, there's no excuse not to test a model before committing to a more expensive alternative.

Mistral Small 3.2 (85%, $0.0004) is a clear upgrade. The Small line went 75% → 85% across versions — a ten-point jump at the same budget tier. Mistral keeps improving the right things.

Qwen3 14B scored 0% across all 10 tasks. Mandatory thinking mode that can't be suppressed at 300 tokens means every request times out before producing output. Skip for agent coding.

Cydonia 24B V4.1 (80%, $0.001) debuts a new family from TheDrummer. Zero hard fails. Watch this one.

The Duds

Qwen3.7 Max (85%, $0.13, 295 seconds) scored the same as budget models costing 300x less. Thinking mode tax at work — the accuracy is there, but you'll wait five minutes and pay for every second.

Claude Opus 4 (80%, $0.10, 76s) had one hard fail. For a top-tier premium model at $0.10 per 10 tasks, that's below expectations. It's not a bad model — it's overkill for agent coding at a tight token budget.

Aion 1.0 (80%) had two hard fails and was the slowest at 160 seconds. The architecture is interesting, but it's not ready for production agent work.

My Picks

Best overall: Qwen3 Coder 30B A3B — 90%, 28s, $0.0004
Best value: LFM 2 24B A2B — 85%, $0.0002 total. Ridiculous price/performance.
Fastest: LFM 2 24B A2B — 15 seconds flat
Most improved: Mistral Small 3.2 — 75% → 85% across versions
Skip entirely: Qwen3 14B for agent tasks

Methodology

Ten real-world agent coding tasks — file operations, shell commands, error recovery, data parsing — tested against each model via OpenRouter. Max tokens: 300. Temperature: 0.1. Results scored by pattern matching against expected outputs. Pre-flight verification caught 2 models (Ernie 4.5 21B — HTTP 429, Trinity Mini — empty content) before they wasted the batch.

Total batch cost: $0.14 across 9 models. Qwen3.7 Max alone accounted for $0.13 of that — thinking tax.

Total models tested: 148 (up from 138).

Full results and per-task scores: benchmarks.workswithagents.dev

Because you should.

DEV Community: Vilius

Five Things to Check When Delivering Fast

1. What does "done" look like from their side?

2. When will they actually look at it?

3. What needs to be perfect vs what can be improved later?

4. Could they see something before the full delivery?

5. Do they have the full picture?

More Watts, Less Light

The electricity problem

Three patterns I now use instead

The question the ceiling forces you to answer

Two perspectives, same person

The actual skill

How to onboard an existing project with AI tools

Before you start — take stock

Phase one: Documentation baseline

What lives in docs/:

Setup in one paste — single source of truth

⚠️ The /init trap

Phase two: Testing — the trust threshold

Authentication — the blocker

After auth — the details

Phase three: MCP servers — extending what the agent can do

Where to get these

Phase four: Feedback loop

Useful add-ons (not inbuilt, go install these)

What this unlocks

2026 best practices that changed the game

What still needs you

When to stop

Three Loops, No Ship

Loop 1

Loop 2

Loop 3

Where I'm At

What's Next

What actually changed in two weeks

Automated tests now ship with new features

The baseline is set

Schema-first development

Running a local coding agent on a Mac Mini — the actual setup

Running a local coding agent on a Mac Mini — the actual setup

Two models

What Pi does

Pi extensions — what they do, why I use them

Known issues

The blueprint

What happens when your OpenRouter key gets stolen? Nothing. Then you move on.

The End of the US Cloud Monopoly: AI Balkanization Is Here to Stay

What Broke the Monopoly

The Three Zones

The Sovereign AI Infrastructure Boom

Open Weights Won

The Death of the API Wrapper

What Nobody's Saying About the Hardware

The 3-5 Year Outlook

We Asked 10 LLMs to Write Efficient Code. Only 4 Got Better.

How the Metric Works

The Leaderboard (Sorted by Prompted Efficiency)

What Stands Out

GPT-5.4 Is the Prompt Whisperer

Gemma 4 31B: The Quiet Winner

Cohere Command A: Prompting Backfires

Qwen 3.6 Plus: Second Place, Slowest

The Kimi Surprise

Frugality: What Does It Mean?

The Bigger Picture

My Picks

Methodology

10 Models Tested: From 81.6% to 10%. The Free Tier is a Full-On Gamble.

Batch 12 Leaderboard

The Headlines

The Free Tier Lottery

Disappointments

Price/Performance

My Picks

Methodology

I Tested 10 More Models. Five Brand New Families Debuted. None Scored Below 75%.

The New 90% Club Members

Five Families, First Try

What lives in `docs/`:

⚠️ The `/init` trap