DEV Community

The Hidden Job Market: Why Thousands of Open Roles Never Show Up in Your Job Search

Rohit Singh — Fri, 07 Aug 2026 13:02:37 +0000

When people search for jobs today, they usually start with Google, LinkedIn, Indeed, or another large job board. There is an assumption that these platforms provide a reasonably complete picture of what companies are hiring for. In reality, that assumption is far from true. A significant number of open positions never become visible through these channels, even though they are publicly accessible on the internet.

Over the last few months, while building WorkWay, I spent a lot of time looking at how companies publish jobs and how those jobs are discovered. One pattern became increasingly obvious. Modern companies rarely manage job listings themselves. Instead, they rely on Applicant Tracking Systems (ATS) such as Greenhouse, Ashby, Lever, Workable, SmartRecruiters, Teamtailor, and several others. These platforms are the source of truth for a company's hiring process, yet many of the jobs hosted on them remain surprisingly difficult to discover unless you already know where to look.

This hidden layer of the job market is much larger than most people realize.

How companies publish jobs today

Ten years ago it was common for companies to build a careers section directly into their own website. Today, especially in the startup ecosystem, that is no longer the norm. Instead, companies create a careers page that simply links to an external ATS. Once that happens, every job posting, application, and hiring workflow lives inside that platform.

If you have applied to startups before, you have probably seen URLs like these:

boards.greenhouse.io/company
company.ashbyhq.com
jobs.lever.co/company
company.teamtailor.com/jobs

These pages are where recruiters actually create and manage job postings. They contain structured information about the role, location, department, employment type, and application process. For the company, this makes hiring much easier because the ATS handles candidate tracking, interview scheduling, permissions, and reporting.

From a discovery perspective, however, it introduces a new problem.

Public does not always mean discoverable

One of the biggest misconceptions about the web is that if a page is public, search engines and aggregators will automatically find it. In practice, discovery depends on many different signals.

Search engines need to know that a page exists before they can crawl it. They rely on internal links, external backlinks, XML sitemaps, structured metadata, crawl budgets, canonical URLs, and many other factors. If an ATS page is weakly linked from the company's website or buried several clicks deep, it may receive very little attention from crawlers.

Many startup companies launch careers pages with only a single navigation link pointing toward their ATS. Some do not include those pages in their sitemap. Others redesign their website and accidentally remove internal links entirely. The ATS page continues to exist and accepts applications, but it becomes much harder for search engines and third-party job aggregators to discover.

Being publicly accessible is not the same thing as being easily discoverable.

Why job aggregators miss these opportunities

People often assume that job boards simply collect every available opening from every company. The reality is much more complicated.

Every ATS has its own structure, APIs, pagination, metadata, and update frequency. Some expose public APIs, while others require crawling HTML pages. Companies migrate between ATS providers, change career page URLs, archive old postings, duplicate listings across regions, and update jobs throughout the day.

An aggregator cannot simply crawl a fixed list of websites and expect to stay current. It needs to continuously discover new companies, detect changes, remove expired jobs, handle duplicates, and revisit existing pages frequently enough that short-lived openings are not missed.

This becomes especially challenging for startups. Many startups hire only occasionally, which means their careers page may remain unchanged for months before suddenly publishing ten new engineering positions. Unless an indexer revisits that page at the right time, those openings can remain invisible for days or even weeks.

Startup hiring moves much faster than people expect

One observation that surprised me while exploring hiring data was how quickly startup recruiting changes.

Large enterprises often keep positions open for months, but startups tend to move much faster. A company might announce a funding round, open fifteen engineering roles over the course of a week, receive hundreds of applications, and close those positions shortly afterward.

For a job seeker, timing matters almost as much as qualifications. Applying within the first day or two often means your application reaches recruiters while they are actively building the interview pipeline. Applying several weeks later may mean the position is already nearing completion even if the listing has not yet been removed.

Missing those early opportunities simply because they were difficult to discover feels like an unnecessary disadvantage.

Discovering the problem while building WorkWay

This issue became apparent while working on WorkWay. Initially, the goal was straightforward: create a better search experience for software engineering jobs. The assumption was that collecting job listings would be relatively simple because every company already publishes them online.

That assumption disappeared quickly.

Some companies exposed structured APIs that were easy to consume. Others relied entirely on HTML pages. Some ATS platforms embedded metadata in JavaScript, while others generated pages dynamically. Companies frequently changed domains, migrated between ATS providers, or reorganized their careers pages without redirects. It became clear that finding jobs was not the difficult part. The difficult part was reliably discovering every place where jobs could appear.

Over time, the project evolved from indexing company websites to understanding the ecosystem of ATS platforms themselves. Instead of treating each company as an isolated website, it became more useful to think of hiring infrastructure as a network that constantly changes as companies grow, migrate, and expand.

The hidden job market is larger than it looks

When people talk about hidden jobs, they often mean positions that are filled through referrals or networking before being publicly advertised. That certainly exists, but there is another type of hidden job that receives much less attention.

These are jobs that are completely public, accept applications from anyone, and are hosted on accessible webpages. They simply never become visible to many of the tools that job seekers rely on every day.

As more companies adopt specialized hiring platforms, this problem will only become more pronounced. Every new ATS, every custom careers portal, and every hiring workflow creates another place where opportunities can exist without being easily discoverable. From an engineering perspective, this is a fascinating indexing challenge. From a job seeker's perspective, it can mean missing out on great opportunities simply because they were never surfaced.

This challenge is exactly what motivated me to build WorkWay.

WorkWay continuously indexes jobs across popular Applicant Tracking Systems like Greenhouse, Ashby, Lever, Workable, SmartRecruiters, Teamtailor, and others, with the goal of making these opportunities easier to discover in one place. Instead of requiring you to visit hundreds of individual company career pages every day, WorkWay keeps track of new openings as they appear and removes listings when they are no longer active.

If you're actively looking for software engineering roles, startup opportunities, or simply want a faster way to discover jobs that are often missed by traditional search, you can explore the platform at https://www.workway.dev.

I'm also continuously improving the crawler and adding support for additional ATS providers, better search, company pages, and fresher indexing. If you have feedback, notice missing jobs, or have ideas for features that would make job discovery easier, I'd genuinely love to hear from you. Every suggestion helps improve the platform and makes it more useful for everyone searching for their next opportunity.

Constitutional AI: os princípios éticos que tornam o Claude único

André Dias Moreira Prol — Fri, 07 Aug 2026 13:01:40 +0000

Quando avalio arquiteturas de IA para projetos de tokenização e perícia digital, percebo que a maioria dos debates ignora uma pergunta fundamental: como um modelo aprende o que é certo? Ao longo de duas décadas trabalhando com tecnologia, poucas inovações me chamaram tanta atenção quanto a abordagem da Anthropic para treinar o Claude — não por marketing, mas por engenharia ética real. Deixe-me explicar por que isso importa, especialmente para quem opera em setores regulados como o brasileiro.

O que é Constitutional AI e por que ela muda o jogo

A maioria dos grandes modelos — GPT, Gemini, Llama — depende fortemente de RLHF (Reinforcement Learning from Human Feedback). Milhares de anotadores humanos julgam respostas como boas ou ruins, e o modelo ajusta seu comportamento. O problema? Esse processo herda vieses inconsistentes, é caro e opaco.

A Constitutional AI (CAI), publicada pela Anthropic em 2022, inverte parte dessa lógica. Em vez de depender apenas de humanos, o Claude é treinado com uma "constituição" — um conjunto explícito de princípios (inspirados na Declaração Universal dos Direitos Humanos, entre outros). O modelo então critica e revisa suas próprias respostas com base nesses princípios, num processo chamado RLAIF (Reinforcement Learning from AI Feedback).

Na prática, isso significa transparência: os valores estão escritos, auditáveis, versionáveis. Como perito digital, essa rastreabilidade é ouro. Consigo apontar por que o modelo recusou determinada ação, algo que raramente consigo com sistemas puramente baseados em feedback humano difuso.

O diferencial técnico frente aos concorrentes

Testei extensivamente Claude, GPT-4 e Gemini em cenários de análise contratual e smart contracts Soroban na rede Stellar. A diferença mais notável não está no raciocínio bruto, mas na consistência do comportamento sob pressão adversarial.

Quando tento induzir modelos a gerar código malicioso ou contornar controles de compliance — algo essencial de testar antes de colocar IA perto de tokenização de ativos —, o Claude demonstra recusas mais coerentes e explicáveis. A constituição atua como uma camada de governança embutida, não como um filtro superficial colado depois.

Dados da própria Anthropic mostram que a CAI reduz significativamente respostas "evasivas mas prejudiciais", mantendo utilidade. Em números divulgados, o modelo consegue ser menos tóxico sem sacrificar capacidade — um trade-off que historicamente derrubou concorrentes, que ficavam ou permissivos demais ou inúteis de tão restritos.

Como observo em minhas consultorias, e reforço aqui como André Dias Moreira Prol: no Brasil, onde a LGPD e as regulações da CVM sobre tokens tornam a explicabilidade uma exigência quase jurídica, ter um modelo cujos princípios são documentados não é luxo — é requisito de conformidade.

Aplicações práticas no mercado brasileiro

O ecossistema Web3 brasileiro cresce rápido. Fintechs tokenizando recebíveis, cartórios experimentando registros em blockchain e o Drex do Banco Central pressionam por ferramentas de IA confiáveis. Aqui a Constitutional AI oferece vantagem concreta.

Imagine um agente de IA analisando contratos de tokenização de crédito agrícola. Um modelo que "alucina" cláusulas ou aceita instruções ambíguas para burlar limites regulatórios representa risco patrimonial e legal enorme. Em projetos que acompanhei, o comportamento previsível do Claude reduziu a necessidade de camadas extras de validação humana — economia real de custo operacional.

Além disso, para perícia digital, a auditabilidade da constituição permite que eu, ao analisar decisões automatizadas de um sistema, reconstrua a lógica ética aplicada. Isso fortalece laudos técnicos e sustenta argumentações em disputas judiciais envolvendo automação.

Não sou ingênuo: a CAI não é perfeita. A escolha dos princípios é, ela mesma, um ato político e cultural, e uma constituição escrita nos EUA pode não refletir nuances jurídicas brasileiras. Mas, comparada à opacidade dos concorrentes, representa um avanço estruturante em direção a uma IA governável — e essa é a discussão que faltava no mercado.

Conclusão

O design ético do Claude não é acessório de marketing, mas uma escolha arquitetural que entrega transparência e previsibilidade — atributos decisivos para Web3, compliance e perícia no Brasil. Se você lidera projetos de tokenização ou IA, avalie a governança embutida dos modelos antes da performance bruta, e converse comigo para desenhar essa camada de confiança no seu produto.

Acompanhe mais artigos de André Dias Moreira Prol no Medium.

Multimodal Models Are Only as Good as Their Weakest Encoder

AI Explore — Fri, 07 Aug 2026 13:01:12 +0000

TL;DR — Multimodal models look like a single system in the demo but are actually a pipeline of independently-trained encoders bolted onto a shared decoder. Each encoder carries its own training distribution, and in production the whole system is bottlenecked by whichever modality has the narrowest one — usually vision or audio, not text. Aggregate accuracy hides this because failures are confident and silent, not error-shaped.

Ask a multimodal model to describe a stock photo of a golden retriever on a beach and it nails it every time. Ask the same model to read a cropped screenshot of a spreadsheet, or transcribe a phone call with crosstalk, or tell you what happened between frame 400 and frame 500 of a security video, and the failure modes get strange fast. Not "I don't know" strange — confidently wrong strange. The model doesn't hedge. It just describes something plausible that isn't there.

The instinct is to blame the model. The more useful frame is architectural: a multimodal model isn't one model. It's a set of independently-trained encoders — one per modality — projected into a shared embedding space and handed off to a decoder that was mostly trained on text. Each encoder has its own training distribution, its own capacity, its own blind spots. The fused system inherits all of them, and in production, quality is bottlenecked by whichever encoder has the narrowest distribution. That's almost never the text side.

The one-model illusion

Text models got good because text training data is absurdly broad — decades of the open web, code, books, forums, transcripts. Vision and audio encoders don't have that. The vision towers underneath most multimodal systems trace back to contrastive image-text pretraining on web images paired with alt text and captions: product photos, news images, stock photography, social media posts. That corpus is enormous, but it's also aesthetically and semantically narrow. It's full of things people photograph and caption. It is not full of things people generate as byproducts of work: dense tables, thermal camera frames, low-light warehouse footage, scanned forms, dashboards, X-rays, satellite tiles.

When you feed one of those into the vision encoder, you're not asking the model a hard question. You're asking it a question from outside its support. The projection layer still produces an embedding — it has no mechanism to say "I've never seen anything like this" — and the decoder, trained to always produce fluent text, fills in the gap with something that sounds right. That's the confident-wrong pattern. It isn't a reasoning failure. It's an out-of-distribution failure wearing a reasoning costume.

Where the vision tower breaks

Screenshots are the clearest production example. A UI screenshot is dense, text-heavy, high-frequency, and nothing like a photograph — but most vision encoders were tuned on photographic statistics, and the tokenizer and resolution pipeline built for photos will happily downsample a screenshot until the small text is mush. The model isn't failing to read; it never received a legible image. Same story with dark or low-contrast frames from cameras that weren't optimized for aesthetics, or dense technical diagrams where spatial relationships carry the meaning and a global embedding throws that away.

The fix people reach for first is "use a bigger, better model." That helps at the margin. It doesn't fix the distribution problem, because the scaling laws for vision-language pretraining are still riding on the same web-image-and-caption data sources. A frontier vision encoder is a better-calibrated version of the same narrow prior, not a different prior.

Audio is speech-shaped

Audio encoders have their own version of this. Most were trained overwhelmingly on clean or near-clean speech — podcasts, audiobooks, call center recordings, read speech corpora. That means the model's implicit prior is: audio is one person talking. Feed it two overlapping speakers, a conference room with cross-talk, a phone call compressed through a codec, or — the case that breaks it hardest — audio that isn't speech at all (an alarm, a machine fault sound, ambient noise you actually care about), and the model degrades in a specific, predictable way: it tries to force what it hears into a speech-shaped transcript. Diarization gets confidently wrong. Non-speech events get silently dropped, because there was never a training signal that rewarded noticing them.

Video is frames, not motion

Video is where the illusion is most complete, because "video understanding" in most systems is not a temporal model at all. It's an image encoder applied to a sparse sample of frames, stitched into a sequence, with the actual continuity of motion reconstructed — badly — by the decoder's language priors. Sample one frame per second from a five-minute clip and you've thrown away almost everything that happened between frames. Ask the model to count repetitions in an exercise video, catch the moment an object changes hands, or notice a one-frame anomaly, and you're asking a question the sampling strategy made unanswerable before the model ever ran. The token budget makes this worse: video is by far the most expensive modality per second of content, so the practical pressure is always toward coarser sampling, which quietly narrows what the model can perceive further still. This is a preprocessing decision, not a model limitation, and it's usually made by whoever wired up the ingestion pipeline, not by anyone thinking about model capability.

What to actually do about it

The engineering implication is to stop treating "multimodal accurac

The Timezone Gap Isn't a Bug, It's a Forcing Function

Jerry Kasem — Fri, 07 Aug 2026 13:00:53 +0000

Here's a hard truth most engineering leaders don't say out loud: your team's speed depends way too much on people being in the same room at the same time.

You don't notice this until someone joins who isn't. A senior engineer in Prague, six or nine hours ahead of your US team, will expose every place where your process was actually just "ask Dave, he remembers."

The instinct is to treat this as a problem to manage. Standups get awkward. Someone has to stay late or log in early. Slack threads pile up overnight. It feels like friction.

But watch what actually happens over the following few months.

Decisions get written down. When you can't grab someone in the hallway to settle a design question, you write it in a doc or a ticket instead. That doc doesn't disappear when the meeting ends. It becomes the record. Six months later, nobody has to reconstruct "why did we do it this way" from memory.

PR descriptions get better. A reviewer working nine hours later than the author can't ask a quick clarifying question and get an instant answer. So the author starts explaining context up front: what changed, why, what was considered and rejected. That habit doesn't stay confined to the async engineer's PRs. It spreads.

Meetings get smaller and sharper. You can't schedule five people across a 9-hour spread for a 30-minute sync without real cost. So teams start asking: does this need a meeting, or does it need a doc? Most of the time it's a doc.

Bottlenecks around specific people become visible. If your architecture decisions only happen when one particular engineer is awake and in a good mood, that's not resilience, that's a single point of failure with a keyboard. A distributed team forces you to notice this and fix it, because otherwise nothing ships on the days that person is asleep.

None of this is really about timezones. It's about whether your team's knowledge lives in people's heads or in artifacts other people can read. Timezone spread just makes the gap impossible to ignore, because the workaround (walk over and ask) isn't available anymore.

Companies that have scaled distributed engineering hard already know this. GitLab operates across more than 60 countries. That's not possible if institutional knowledge only exists in synchronous conversations. It's only possible if the default mode of working is written, asynchronous, and reviewable by someone who wasn't in the room.

The uncomfortable part for a lot of US teams is that this same discipline would make them faster even without a single overseas hire. Distributed timezones don't create the need for better documentation and clearer decision records. They just make it impossible to keep pretending you don't need them.

So if you're evaluating whether a senior engineer nine timezones away is worth the coordination cost, that's a fair question to ask. But the more useful question might be: what is your team's process currently relying on that only works because everyone happens to be awake at the same time? Because that dependency was always a risk. The timezone gap just makes you deal with it now instead of later, during an outage, when the one person who understands that system is on vacation.

The engineers who thrive in this setup aren't the ones who happen to tolerate odd hours. They're the ones who were already good at writing clearly, documenting decisions, and working without needing constant real-time confirmation. That skill set is valuable on any team, in any timezone. Distributed work just makes it non-optional.

NETO: Chat P2P local para equipos dev — Sin nube, sin excusas

David Arturo Silva Baldellon — Fri, 07 Aug 2026 13:00:30 +0000

¿Tu equipo comparte credenciales por Slack? ¿Discuten arquitectura en herramientas que almacenan todo en servidores de terceros? Existe una alternativa radical: no usar la nube en absoluto.

NETO es un chat peer-to-peer diseñado para equipos de desarrollo que trabajan en la misma red local. Sin servidores, sin cuentas, sin datos saliendo de tu oficina.

Cómo funciona

NETO combina tres tecnologías clave para lograr comunicación directa y segura:

mDNS (Multicast DNS): Cada instancia de NETO se anuncia en la red local mediante mDNS. No necesitas configurar IPs ni servidores de descubrimiento. Abres la app y los miembros de tu equipo aparecen automáticamente, como una impresora de red, pero para conversar.
WebRTC: Una vez descubiertos los peers, la comunicación se establece mediante WebRTC. Los datos viajan directamente entre máquinas, sin

Shipping an LLM chat widget with 481 bytes of CMS footprint - Wordpress

Dhardingsea Developer — Fri, 07 Aug 2026 13:00:26 +0000

A chat widget where the CMS holds a loader and nothing else — plus the four failure modes that cost me the most time: buffered SSE, base64 truncation that passes a syntax check, render-time escaping, and a balanced-but-wrong tag tree.

Canonical_url
https://dhseadev.online/2026/08/06/ai-answers-desk-val-town-groq/

I maintain a small site where I write up the internal tooling I build — process-serving
automation, Chrome extensions, desktop utilities. It had a static answers page. The
obvious next step was letting people ask the things that page doesn't cover.

Two constraints shaped the whole design:

No server for me to maintain.
The API key never reaches a browser, and never enters the CMS database.

What follows is the architecture I landed on, and — more usefully — the four things that
actually cost me time. Three of those four are general enough to bite you on a completely
different stack.

The shape

The CMS side is 481 bytes. One block, and all it does is:

window.DHSEA_ASK_ENDPOINT = "https://…";
// then inject <script src="…/widget.js">

That's it. No plugin. No key in the database. No logic in the page.

Everything else — the ~19KB widget, the styles, the chat logic, the proxy — lives in a
single serverless file with three routes:

Route	Job
`GET /health`	Diagnostics. Written so it can never 500.
`GET /widget.js`	Serves the widget itself.
`POST /`	Chat proxy to the model API.

The API key is an env var on the serverless platform. Because the widget is served from
the same function rather than pasted into the CMS, shipping a widget change is one
external deploy and I never touch the site.

/health deserves a note. A health check that can throw is worse than no health check,
because it fails in exactly the situation you're using it to diagnose. Mine returns
{ok, keyConfigured, store, storeError, fatal, day, dayReq, dayTokens, …} — errors
become fields, not exceptions.

Budget, because it's my card

Public endpoint plus paid inference is a bad combination unless you bound it up front:

per-IP: 4/min, 30/day
global: 12/min, 1500/day
hard ceiling: 300k tokens/day

Counters live in the platform's SQLite so they survive cold starts — in-memory counters
on a serverless host reset when the instance recycles, which means no rate limit at all
under exactly the traffic pattern you care about.

On top: an origin allowlist. My domain gets 200. A lookalike domain gets 403. A
request with no Origin header gets 403. Test all three; the lookalike case is the one
naive startsWith checks fail.

Four things that cost me the most time

1. Your platform may buffer SSE

The model API streams tokens properly. My serverless host buffers, so what reached the
browser was roughly two chunks — not a stream.

Total round trip is under a second, so it reads fine. But I'd already started building a
token-by-token typewriter UI that was never going to work on that host.

Verify streaming end to end on your actual deployment target, not on the vendor's
docs page. The vendor streams. That tells you nothing about what your host does with it.

2. A truncated base64 payload passes a syntax check

The widget is base64-embedded into the serverless file by a build script. If a copy step
truncates the blob:

the file still parses — node --check is happy
atob fails at runtime
the panel renders blank

A syntax check attests the file, never the payload. So: never hand-copy the payload
(a build script does it file-to-file), and verify the deploy against the live artifact:

curl -s https://…/widget.js | shasum -a 256

…compared against the same hash computed on the local build. Same byte length is not
the same bytes. Compare hashes. Mine matched at 19,260 chars — that match is the
evidence the deploy worked, not the fact that the paste didn't throw.

3. Verify the served bytes, not the saved content

My CMS applies escaping at render time. So the stored content was byte-clean while the
live page was dead and the console was empty.

Reading back what you just saved proves the write succeeded. It proves nothing about
what the visitor receives. Fetch the rendered output and assert on that.

This generalizes past CMSs: anywhere a transform sits between your write and the user —
a bundler, a minifier, a template engine, a CDN — the artifact you validated is not the
artifact they get.

4. Balanced tags are not a correct tree

This is my favorite, because every mechanical check I had passed it.

A page with opening and closing div counts matching exactly — 14 and 14. And six
sections nested inside a seventh, because one closing tag had been deferred to the end of
the document.

Balance counting cannot catch this. Absence and misplacement are different bugs, and
counting only detects absence. Parse it instead:

const doc = new DOMParser().parseFromString(html, "text/html");
doc.querySelectorAll(".qa .qa").length; // 6 → nested. Should be 0.
doc.querySelectorAll(".in > .qa").length; // should equal total .qa

That assertion is the one that catches it, and it's the one I now run.

The through-line

Every one of these four is the same mistake wearing a different hat: I checked the
thing I could reach instead of the thing the user gets.

The saved content instead of the served page. The file's syntax instead of the payload's
integrity. The vendor's streaming behavior instead of my host's. The tag count instead
of the tree.

Each check passed. Each one attested something adjacent to what I actually needed to know.
Whatever sits between your code and your user — a renderer, a host, an encoder, a build
step — is the boundary your verification has to cross, or it isn't verification.

The result is live at dhseadev.online/ask, sitting next
to the static answers it was built to extend. If you
break it, I'd like to hear how.

How to Move SvelteKit Config Into vite.config.js (July 2026)

Frank — Fri, 07 Aug 2026 13:00:15 +0000

I saw the July 2026 Svelte blog post announcing that SvelteKit’s configuration can now live directly inside vite.config.js. As someone who maintains several SvelteKit apps, this caught my eye because it promises a single source of truth for build tooling, reduces boilerplate, and aligns SvelteKit more tightly with the Vite ecosystem we already use daily.

Why this change matters right now

Since the first stable release of SvelteKit, the framework has relied on a separate svelte.config.js file for things like adapters, prerendering options, and preprocessors. While that separation made sense when SvelteKit was still figuring out its relationship with Vite, it also introduced a small friction point:

Two config files to keep in sync – you often end up opening both svelte.config.js and vite.config.js when tweaking SSR, environment variables, or custom Vite plugins.
Tooling confusion – IDE extensions sometimes treat the two files as unrelated, causing false warnings about unknown properties.
Bootstrapping overhead – new contributors have to learn which settings belong where, which adds cognitive load during onboarding.

By allowing the SvelteKit config to be embedded under a sveltekit key in vite.config.js, the Svelte team has effectively merged the two configuration surfaces. This is especially handy for monorepos or when you already have a complex Vite setup (e.g., multiple entry points, custom aliasing, or shared plugins). Now you can see the whole picture in one place, and the Vite dev server will automatically pick up any SvelteKit‑specific tweaks without an extra config file.

What the new API looks like

The blog post shows a minimal example that replaces a typical svelte.config.js with a single vite.config.js. Here’s how I migrated a fresh SvelteKit project:

// vite.config.js
import { sveltekit } from '@sveltejs/kit/vite';
import { defineConfig } from 'vite';
import { visualizer } from 'rollup-plugin-visualizer';

// Old separate svelte.config.js (for reference)
// export default {
//   kit: {
//     adapter: adapterNode(),
//     prerender: { default: true }
//   }
// };

export default defineConfig({
  plugins: [
    sveltekit({
      // All SvelteKit options go here
      kit: {
        // The adapter you were using before
        adapter: require('@sveltejs/adapter-node')(),
        // Keep your prerender defaults
        prerender: { default: true },
        // You can still add vite-specific overrides inside
        // the same object if you need them
        vite: {
          // Example: custom environment variable handling
          define: {
            __APP_VERSION__: JSON.stringify('1.0.0')
          }
        }
      }
    }),
    // Any other Vite plugins stay where they belong
    visualizer({ filename: './stats.html' })
  ],
  // General Vite config stays at the top level
  resolve: {
    alias: {
      $components: '/src/lib/components',
      $utils: '/src/lib/utils'
    }
  },
  server: {
    port: 5173,
    strictPort: true
  }
});

A few things to note:

Import the sveltekit plugin from @sveltejs/kit/vite – this is the same plugin that Vite automatically adds when you run npm init svelte@next, but now you call it explicitly.
Wrap all SvelteKit‑specific keys inside the kit object – this mirrors the shape of the old svelte.config.js.
You can still expose Vite‑only settings (like resolve.alias or server.port) at the top level of the config, keeping everything in one file.

If you already have a vite.config.js with custom plugins, you simply add the sveltekit call to the plugins array and move the kit block into its options. No more “duplicate adapter definitions” or “missing prerender flag” errors.

How this affects common workflows

1. Adding a new adapter

Previously you’d edit svelte.config.js:

// svelte.config.js
import adapterStatic from '@sveltejs/adapter-static';
export default {
  kit: {
    adapter: adapterStatic(),
    // …
  }
};

Now you do it inside vite.config.js:

// vite.config.js (excerpt)
sveltekit({
  kit: {
    adapter: require('@sveltejs/adapter-static')(),
    // …
  }
})

The change is syntactic, but it eliminates the need to keep two files in sync when you switch adapters for staging vs. production.

2. Using environment variables in adapters

Because the adapter configuration lives inside the Vite plugin call, you can reference Vite’s process.env (or the newer import.meta.env) directly:

kit: {
  adapter: require('@sveltejs/adapter-node')({
    env: {
      // Pass a runtime variable to the adapter
      NODE_ENV: process.env.NODE_ENV
    }
  })
}

This feels more natural than pulling dotenv into a separate svelte.config.js.

3. Custom preprocessors

If you need a preprocessor like svelte-preprocess, you still import it and pass it to the sveltekit plugin:

import preprocess from 'svelte-preprocess';

sveltekit({
  kit: {
    // …
  },
  preprocess
})

The API remains identical; the only difference is the file location.

Potential downsides

No change is without trade‑offs. Here are the practical concerns I ran into during migration:

Learning curve for newcomers – developers who have only read older tutorials may be confused when they can’t find a svelte.config.js. The docs now need to be explicit about the new location.
Tooling gaps – some community plugins (e.g., ESLint configs that look for svelte.config.js) still assume the old file exists. In my monorepo I had to add a small shim file that re‑exports the config just to keep those tools happy.
Version lock – the new feature is tied to SvelteKit 1.28+ (the version shipped with the July 2026 release). Projects pinned to earlier releases will need to upgrade anyway, which may involve other breaking changes.

Overall, the drawbacks are mostly about updating documentation and a few edge‑case tool integrations, not about runtime behavior.

My personal take

I decided to upgrade my production SvelteKit apps to the July 2026 release after a quick test branch. The migration took less than 15 minutes per repo, and the resulting vite.config.js felt cleaner: everything from adapters to custom Vite plugins lives under one roof. In environments where we already maintain a shared Vite config (e.g., a design‑system library that ships both React and Svelte components), this consolidation reduces the mental overhead for new hires.

If you’re on a brand‑new SvelteKit project, I’d start there—skip the svelte.config.js entirely and keep your config in vite.config.js. For existing projects, weigh the benefit of a single config file against the effort of updating any tooling that expects svelte.config.js. In most cases, the upgrade is worth it, especially because it aligns SvelteKit with the broader Vite ecosystem and paves the

Compact Video Metadata Serialization With Protobuf Across Services

ahmet gedik — Fri, 07 Aug 2026 13:00:02 +0000

The 40KB Problem Nobody Noticed Until Cloudflare Billed Us

Every viral video we ingest at ViralVidVault crosses three service boundaries before it ever reaches a user. A PHP 8.4 ingestion worker pulls the raw metadata, hands it to a Go trend-scoring service, which in turn feeds a Python analytics pipeline that computes velocity and acceleration curves for the European feeds. For a long time these three services spoke JSON to each other, because JSON is what everyone reaches for first. It worked, it was debuggable, and nobody questioned it.

Then we looked at the numbers. A single enriched VideoMetadata record — title, tags, region, published timestamp, view counts, and a nested block of trend signals — averaged just under 40KB as pretty-printed JSON, and around 28KB minified. Multiply that by the ~2.1 million records that move between services every day during a trend spike, and the internal egress alone was measurably showing up on our Cloudflare bill. Worse, the Go service was burning real CPU on encoding/json reflection, and the PHP worker spent more time in json_encode than it did doing the actual HTTP fetch.

We migrated the inter-service contract to Protocol Buffers. Payloads dropped by roughly 68%, parse CPU on the Go side fell by more than half, and — the part I care about most as someone shipping under GDPR — the schema became a single enforced contract instead of a loose bag of keys. This is the write-up I wish I'd had before starting. If you want to see the end result in production, it's the discovery engine behind ViralVidVault, our GDPR-compliant European viral video tracker.

Why JSON Was Costing Us More Than Bytes

The byte count is the obvious problem, but it wasn't the expensive one. Three things hurt more than payload size:

No schema enforcement. A field renamed in the PHP worker would silently become null in the Go consumer. We caught these in production, not in review.
Type ambiguity. JSON numbers are all doubles. A view_count of 4,300,000,000 quietly lost precision once it crossed 2^53, which for a genuinely viral clip is not hypothetical.
Reflection cost. Both encoding/json in Go and json_encode in PHP walk the structure at runtime. At our volumes that reflection was a real slice of CPU, and CPU on our LiteSpeed origin is finite.

Protobuf addresses all three at once: a compiled schema, explicit integer widths, and generated marshalling code that doesn't reflect at runtime. The tradeoff is that the wire format is no longer human-readable, which matters less than you'd think once you have decent tooling.

Defining the Schema

Everything starts with the .proto file. This is the single source of truth that all three languages compile against. I keep it in a dedicated contracts/ repository that the PHP, Go, and Python services each vendor in, so nobody can drift.

syntax = "proto3";
package viralvidvault.metadata.v1;

message VideoMetadata {
  string video_id            = 1;
  string title               = 2;
  uint32 duration_seconds    = 3;
  uint64 view_count          = 4;
  Region region              = 5;
  repeated string tags       = 6;
  int64  published_at_unix   = 7;
  TrendSignals signals       = 8;
  bool   gdpr_pii_stripped   = 9;
}

enum Region {
  REGION_UNSPECIFIED = 0;
  REGION_DE = 1;
  REGION_FR = 2;
  REGION_ES = 3;
  REGION_IT = 4;
  REGION_NL = 5;
  REGION_PL = 6;
}

message TrendSignals {
  float  velocity        = 1;  // views/hour, normalised
  float  acceleration    = 2;  // d(velocity)/dt
  uint32 shares_per_hour = 3;
}

A few deliberate choices worth calling out, because they are the ones that bite people later:

Field numbers are permanent. The number 4 is what goes on the wire, not the name view_count. You can rename the field freely, but never reuse or renumber a tag. If you retire a field, mark it reserved.
uint64 for view counts. This is the precision fix. Protobuf varints encode small numbers in one byte and only grow as the value grows, so you pay nothing for the wide type until you actually need it.
The region enum is versioned by the v1 package. European regions rarely change, but the enum's zero value being REGION_UNSPECIFIED means an unset region is unambiguous rather than defaulting to a real country.
gdpr_pii_stripped is a boolean gate. Our contract says no record leaves the ingestion worker for analytics unless PII has been removed, and this flag is asserted downstream. More on that below.

Enum choice matters for size too: an enum is a varint on the wire, so REGION_DE costs one byte, versus the string "DE" costing three plus framing in JSON.

Encoding in PHP 8.4

Our ingestion worker is PHP. The official google/protobuf package ships a pure-PHP runtime, but for our throughput I strongly recommend installing the protobuf C extension as well — the pure-PHP path is correct but noticeably slower on hot loops. With protoc and the PHP plugin you generate classes under a namespace that mirrors the package.

<?php
declare(strict_types=1);

use ViralVidVault\Metadata\V1\VideoMetadata;
use ViralVidVault\Metadata\V1\TrendSignals;
use ViralVidVault\Metadata\V1\Region;

function buildMetadata(array $row): string
{
    $signals = (new TrendSignals())
        ->setVelocity((float) $row['velocity'])
        ->setAcceleration((float) $row['acceleration'])
        ->setSharesPerHour((int) $row['shares_per_hour']);

    $meta = (new VideoMetadata())
        ->setVideoId($row['video_id'])
        ->setTitle($row['title'])
        ->setDurationSeconds((int) $row['duration_seconds'])
        ->setViewCount((int) $row['view_count'])
        ->setRegion(Region::REGION_DE)
        ->setPublishedAtUnix((int) $row['published_at_unix'])
        ->setGdprPiiStripped(true)
        ->setSignals($signals);

    // repeated fields take an array; the runtime handles the packing
    $meta->setTags($row['tags'] ?? []);

    // returns the compact binary wire format, ready for the next hop
    return $meta->serializeToString();
}

// Decoding a payload that came back from another service:
function parseMetadata(string $binary): VideoMetadata
{
    $meta = new VideoMetadata();
    $meta->mergeFromString($binary); // throws on malformed input
    return $meta;
}

Two practical notes. First, serializeToString() gives you the raw binary — you send it as the request body with Content-Type: application/x-protobuf, not as a JSON string. Second, mergeFromString() throws on genuinely malformed bytes but happily ignores unknown fields, which is exactly the forward-compatibility behaviour you want during a rolling deploy where the encoder is a version ahead of the decoder.

One PHP-8.4-specific gotcha: int in PHP is a 64-bit signed integer on any 64-bit build, so a uint64 view count near the top of the range round-trips fine as a native int. If you ever run on a 32-bit SAPI, the runtime falls back to string representation for large integers — worth an assertion in your tests if you can't guarantee the build.

Consuming in Go

The trend-scoring service is Go, and this is where the CPU win showed up most clearly. Generated code plus google.golang.org/protobuf/proto gives you zero-reflection unmarshalling.

package scoring

import (
    "fmt"

    "google.golang.org/protobuf/proto"
    pb "github.com/viralvidvault/contracts/gen/go/metadata/v1"
)

// DecodeAndScore unmarshals a wire payload and rejects anything that
// has not been through the GDPR PII strip in the ingestion worker.
func DecodeAndScore(payload []byte) (float64, error) {
    var meta pb.VideoMetadata
    if err := proto.Unmarshal(payload, &meta); err != nil {
        return 0, fmt.Errorf("decode metadata: %w", err)
    }

    if !meta.GetGdprPiiStripped() {
        return 0, fmt.Errorf("refusing record %s: pii not stripped", meta.GetVideoId())
    }

    sig := meta.GetSignals()
    if sig == nil {
        return 0, nil // no signals yet, score is zero
    }

    // A cheap composite score; the real one is a weighted model.
    score := float64(sig.GetVelocity())*0.6 +
        float64(sig.GetAcceleration())*0.3 +
        float64(sig.GetSharesPerHour())*0.1

    return score, nil
}

The Get* accessors are the important habit here: they are nil-safe. meta.GetSignals() on a message where signals was never set returns a typed nil pointer, and sig.GetVelocity() on that nil returns the zero value rather than panicking. This is proto3's answer to the JSON null problem — there's a defined default for every scalar, so downstream code doesn't need defensive existence checks scattered everywhere.

Benchmarked against our old json.Unmarshal path over a representative sample, the protobuf decode was consistently 2–3x faster and allocated far less, because there's no map construction and no reflection walk.

Storing the Binary in SQLite WAL

Our origin uses SQLite in WAL mode as the local cache on each LiteSpeed node. Here's a pattern that surprised people on my team: you don't have to unpack protobuf to store it. The compact binary is a perfectly good BLOB, and SQLite treats it as an opaque byte string.

import sqlite3
from viralvidvault.metadata.v1 import video_metadata_pb2

con = sqlite3.connect("cache.db")
con.execute("PRAGMA journal_mode=WAL")
con.execute(
    "CREATE TABLE IF NOT EXISTS video_meta ("
    "  video_id TEXT PRIMARY KEY,"
    "  region   INTEGER,"        # denormalised for WHERE filters
    "  payload  BLOB NOT NULL"   # the raw protobuf bytes
    ")"
)

def store(payload: bytes) -> None:
    meta = video_metadata_pb2.VideoMetadata()
    meta.ParseFromString(payload)  # validate before we trust it
    con.execute(
        "INSERT OR REPLACE INTO video_meta (video_id, region, payload) VALUES (?, ?, ?)",
        (meta.video_id, meta.region, payload),
    )
    con.commit()

def load(video_id: str) -> video_metadata_pb2.VideoMetadata | None:
    row = con.execute(
        "SELECT payload FROM video_meta WHERE video_id = ?", (video_id,)
    ).fetchone()
    if row is None:
        return None
    meta = video_metadata_pb2.VideoMetadata()
    meta.ParseFromString(row[0])
    return meta

The trick is denormalising the couple of fields you actually filter on — here region — into real columns while keeping the full record as an opaque blob. You get indexable queries on the hot dimensions and a compact single-blob store for everything else, and the blob is already in the exact format you'll ship to the next service. No re-encoding on read. In WAL mode these blob writes don't block concurrent readers, which keeps the analytics pipeline from stalling the ingestion path.

Decoding at the Edge in a Cloudflare Worker

Because our audience is European and latency-sensitive, some responses are assembled at the Cloudflare edge. Protobuf travels well here too — you decode it in the Worker using protobufjs and emit whatever shape the browser needs, so the compact format lives all the way to the edge and only becomes JSON at the last possible moment.

import protobuf from "protobufjs";
import schema from "./metadata.v1.json"; // protobufjs JSON descriptor

const root = protobuf.Root.fromJSON(schema);
const VideoMetadata = root.lookupType("viralvidvault.metadata.v1.VideoMetadata");

export default {
  async fetch(request, env) {
    const origin = await env.META.fetch(request); // bytes from origin
    const buf = new Uint8Array(await origin.arrayBuffer());

    const meta = VideoMetadata.decode(buf);

    // Strip anything the browser has no business seeing, then hand back JSON.
    const body = JSON.stringify({
      id: meta.videoId,
      title: meta.title,
      region: meta.region,
      velocity: meta.signals?.velocity ?? 0,
    });

    return new Response(body, {
      headers: { "content-type": "application/json; charset=utf-8" },
    });
  },
};

The origin-to-edge hop stays compact, and the JSON expansion happens once, at the edge, right before it hits the browser. That is the smallest possible amount of JSON in the whole path.

Schema Evolution Without Breaking Deploys

The question everyone asks: how do you change the schema without a big-bang deploy across three languages? Proto3 makes this genuinely safe if you follow a small set of rules.

Only add fields with new numbers. Old decoders ignore unknown fields; new decoders see the defaults for fields that old encoders didn't set.
Never change a field's number or wire type. Renaming is fine, renumbering is not.
Reserve retired fields. Add reserved 6; and reserved "tags"; so nobody accidentally reuses the slot.
Deploy decoders before encoders. Roll out the readers that understand the new field first, then the writers that emit it. This ordering means there's never a moment where a new field arrives at a service that can't parse it.

Because unknown fields are preserved rather than dropped by the binary runtimes, a record can pass through a service that's a version behind and come out the other side intact — the intermediate service round-trips fields it doesn't even know about. That property alone eliminated a class of data-loss bugs we used to hit whenever the JSON contract drifted mid-deploy.

GDPR Notes Specific to This Setup

Because we operate under GDPR, the schema itself is part of our compliance story, not an afterthought:

The gdpr_pii_stripped flag is enforced downstream, not just set upstream. The Go consumer above rejects any record where it's false. A single boolean in the contract is worth more than a policy document nobody reads.
No raw personal identifiers ever enter VideoMetadata. We deliberately kept uploader identity out of the message. If it isn't in the schema, it can't leak through the schema.
The binary format is not obscurity-as-security — anyone with the .proto can decode it — but keeping the compact payload internal and only expanding a whitelisted subset at the edge means the browser sees strictly less than what moves between services.

What I'd Tell Someone Starting Today

Protobuf is not free complexity. You take on a build step (protoc), a generated-code artifact per language, and payloads you can't curl | jq without a decoder. For a small app talking to itself, JSON is still the right call.

But the moment you have multiple services in multiple languages exchanging the same records at volume, the math flips hard. For us the wins were concrete: ~68% smaller payloads, 2–3x faster decode in Go, precise 64-bit counts, and — the quiet one — a schema that turns contract drift into a compile error instead of a 3am incident. If your metadata crosses a language boundary more than once, it's worth the build step.

Start with one message, one boundary, and the four evolution rules above pinned somewhere your whole team can see them. Everything else is incremental.

Why I Built a Journaling App That Never Touches the Cloud

AI Predictions Dev — Fri, 07 Aug 2026 13:00:01 +0000

Most AI journaling apps promise privacy, but they usually mean "we don’t sell your data to advertisers." They still upload your raw text to a central server for processing. For me, that was a dealbreaker. I wanted a tool that could analyze my moods and patterns without ever leaving my device, even if I was offline or behind a strict firewall.

The result is JournalMind, a journaling app that runs 100% in the browser via WebGPU. There is no backend processing of your entries. Nothing is uploaded. Not even metadata.

The WebGPU Shift

For years, running inference in the browser meant slow, clunky experiences or relying on massive WASM files that choked mobile devices. The arrival of WebGPU changed the game. It allows the browser to access the GPU directly, enabling small, efficient models to run with near-native speed.

I built JournalMind around this capability. When you type an entry, a small model that runs in your browser analyzes the sentiment, extracts key themes, and logs mood trends. This happens locally. If you close your laptop, the app works. If your internet cuts out, the insights are still generated.

This architecture solves a specific developer problem: trust. In an era of data leaks and privacy concerns, offloading AI to the cloud introduces a surface area of risk. By keeping the model private on-device AI, the only person who sees your thoughts is you.

The Engineering Trade-offs

Building for the browser has constraints. You cannot load a 13-billion-parameter model and expect it to run smoothly on a mid-range laptop. You have to be ruthless about efficiency.

The challenge wasn’t just accuracy; it was memory management. A common mistake in client-side AI is letting the model context grow unbounded. In JournalMind, we limit the context window strictly to the current session and a rolling buffer of recent entries. This keeps the memory footprint low and the inference time under a second.

Here is how the inference loop looks in practice. We avoid heavy initialization costs by using a pre-compiled model that loads only when needed:

// Simplified inference logic
const model = await loadLocalModel('sentiment-v2');

// Process entry locally
const analysis = await model.run({
  text: currentEntry,
  context: recentEntries.slice(-5)
});

// Store result locally in IndexedDB
db.journals.add({
  entry: currentEntry,
  mood: analysis.mood,
  timestamp: Date.now()
});

This approach means the app feels instant. There is no "processing..." spinner while waiting for a server response. The feedback loop is tight, which encourages consistent journaling.

Privacy by Design, Not by Feature

Most apps treat privacy as a feature you toggle on. In JournalMind, it is the foundation. Because the processing happens on your device, the app does not need to know who you are. There is no account creation required to start using it. You can use it anonymously, or sync your own encrypted backups if you choose.

This design decision forced us to rethink how we handle data persistence. Without a central database, we rely on IndexedDB and local storage. This introduces a new set of challenges: backup strategies, versioning, and handling data corruption. But it also simplifies the user experience. You don’t need to worry about "cloud sync conflicts" because there is no cloud. Your data lives where you put it.

Honest Pricing

JournalMind is a paid tool. It is not free, because maintaining the quality of the on-device models and the continuous optimization of the WebGPU pipeline requires resources. There is a 7-day trial so you can test the local inference speed on your specific hardware. For users who prefer to explore without commitment, there are free turns available in the companion games, which also run entirely locally.

The Future of Local AI

The shift toward private on-device AI is not just a trend; it is a necessity. As models become more efficient, we will see more applications that do not require a network connection to be intelligent. Journaling is just one use case. Imagine code editors, note-taking apps, and personal assistants that work offline with the same depth of insight.

I am curious about your experience with local AI tools. Have you tried any apps that run inference entirely in the browser, and did the performance meet your expectations?

Qwen Code vs Aider vs OpenCode: I Ran the Same 12 Tasks Through 3 Local CLI Agents on One RTX 4070

Ken Imoto — Fri, 07 Aug 2026 13:00:00 +0000

I pointed three coding CLIs at the same local model and ran twelve tasks through each one. The model was Qwen 35B, hosted on an RTX 4070 12GB via llama-server with --cpu-moe. The tasks were mundane: build a hello.py, add a CLI flag to an existing script, write a failing test then fix it, refactor a Python file to split a class into two. Nothing you would not do on a Tuesday.

The results were not what I expected from reading each tool's README.

The three tools, in one line each

Aider: git-native pair-programming CLI (45k stars, Apache-2.0), most-used terminal option, mature and well-documented, handles repo-wide context through a repo map.
Qwen Code CLI: QwenLM's official fork of Gemini CLI (Apache-2.0), positioned as the "native" agent for Qwen models. Tested v0.18.1.
OpenCode: MIT, provider-agnostic, 170k+ stars in 2026, not owned by any of the companies buying up the rest of this list.

All three claim to work with local models via Ollama, LM Studio, or an OpenAI-compatible endpoint. Two of them do. The third has a specific requirement nobody documented up front.

The one non-obvious requirement: Qwen Code needs `--jinja` and 32k context

I tried Qwen Code with Ollama first. This is the shape the tool's own docs suggest. Here is what happened across five configurations of the same task ("create hello.py"):

Try	Backend	Context	Result
1	Ollama 9b (ping only)	-	OK — text response
2	Ollama 9b (agent mode)	default	Fail — tool did not fire, model returned code as prose
3	Ollama 35B (agent mode)	default	Fail — model emitted raw `<tools>` text, no file written
4	llama-server --jinja	8192	Fail — context overflow (19,374 > 8192)
5	llama-server --jinja	32768	OK — file created, task completed

Only the last combination worked. Ollama's default template does not agree with what Qwen Code sends. The model spits raw <tools> markers as text instead of emitting a tool call. Switching to llama-server --jinja uses the model's own chat template and the tool call round-trips correctly.

The 8k-to-32k jump is the second surprise. The error was:

400: request (19374 tokens) exceeds the available context size (8192 tokens)

Nineteen thousand tokens. Before I typed a single character. That is the size of Qwen Code's system prompt plus tool definitions.

Aider's equivalent first prompt was about 1,400 tokens. Roughly a 13× difference. Qwen Code carries a lot more agent scaffolding by default. SubAgents, four approval modes (Plan / Default / Auto-Edit / YOLO), headless mode, background agent forks. Each of these needs to be described in the system prompt. It adds up.

Here is the launch command that actually works:

llama-server -m qwen35.gguf -ngl 99 --cpu-moe -c 32768 \
  --jinja --alias qwen35 --host 0.0.0.0 --port 18080

--jinja is the load-bearing flag. Without it the tool loop breaks. -c 32768 is the second one. --cpu-moe is how a 35B model fits on 12GB VRAM. The MoE experts get offloaded to CPU RAM.

Aider and OpenCode both worked with Ollama out of the box. No template flags, no context size gymnastics. Aider used aider --model ollama/qwen3-coder. OpenCode used its models.dev config with a local endpoint.

The 12-task grid

I ran each tool through the same twelve tasks. I did not tune prompts per tool. Same wording, same fresh working directory, same model. Here is the shape of what happened:

Task	Aider	Qwen Code	OpenCode
1. hello.py from scratch	OK	OK	OK
2. Add `--verbose` flag to existing script	OK	OK	OK
3. Write failing pytest for a stub function	OK	OK	OK
4. Make the failing test pass	OK	OK	OK
5. Split a 200-line class into two files	OK	OK	Partial*
6. Rename a symbol across 4 files	OK	OK	OK
7. Add type hints to an untyped function	OK	OK	OK
8. Migrate a `requests` call to `httpx`	OK	Partial†	OK
9. Write a Dockerfile for a Flask app	OK	OK	OK
10. Debug an off-by-one in a for-loop	OK	Fail‡	OK
11. Add a Makefile target	OK	OK	OK
12. Extract a magic number into a constant	OK	OK	OK

*OpenCode split the class but left one method import unresolved. I fixed it in about 30 seconds.
†Qwen Code migrated the call but did not update the exception handler.
‡Qwen Code proposed the fix in prose but did not apply it. This happened when I was in Plan mode by accident.

Success rates: Aider 12/12, OpenCode 11/12 (1 partial), Qwen Code 10/12 (1 partial, 1 failed).

That is not a real benchmark. It is one afternoon on one machine with one model. But the failures were not random. Qwen Code's partial and fail both came from cases where the model needed to reason about existing code across multiple edits. Aider's repo map earns its keep here. It gives the model a much better mental picture of the codebase before the edit.

Time and token cost

The real cost story is less about success rate and more about how each tool spends the context window you gave it.

Metric	Aider	Qwen Code	OpenCode
Avg tokens per task (system + first turn)	~1,400	~19,400	~4,800
Avg wall time per task	44s	71s	52s
Config effort to first success	5 min	45 min	10 min
Notable strengths	Repo map, git integration	Approval modes, SubAgents, headless	Provider-agnostic, quick setup

Qwen Code's per-task time is inflated by the larger system prompt processing on every turn. When you are running locally on a 12GB card the difference matters, because the model has to re-read that 19k every time you send a new message. On cloud LLMs where prompt caching is on by default this evaporates. On llama-server without KV cache reuse across sessions, it does not.

Which one goes on the RTX 4070 rig

For local, on-a-single-card, all-my-code-stays-here: Aider. It is the smallest system prompt, the highest first-try success rate on my tasks, and it is the easiest to get working with Ollama or llama-server. If the reason you are running local is "I do not want my code leaving this machine," Aider is the lowest-friction way to get there.

If you want more agent scaffolding than Aider gives you (approval modes, headless runs for CI, background forks), Qwen Code is where those features live. You pay for it with the 19k-token overhead per turn and the setup complexity. On a cloud LLM this is a non-issue and Qwen Code looks great. On local hardware it costs you 20-30 seconds per task.

OpenCode is the "I want to swap providers freely" answer. Its provider-agnostic model config is the cleanest of the three. If you are going to move between local Qwen, Cloud Claude, and API Gemini depending on the task, OpenCode makes that swap a one-line config change.

Ollama's free tier for Qwen Code is gone in 2026

One footnote nobody mentions: Qwen Code CLI used to have a hosted free tier from QwenLM directly. It was retired on April 15, 2026. This matters not at all if you are running local, because you connect to your own llama-server and the retirement is invisible. If you were using the hosted endpoint, you need to either self-host or pay per token now.

For anyone reading this because they are trying to decide "cloud API or local for my coding assistant," the retirement moved the local option up the ranking. Cost of running Qwen 35B on your own hardware: your electricity bill. Cost of the equivalent number of tokens on any hosted API: not that.

What "agentic" actually means, honestly

One thing I want to say clearly because the tools' marketing does not: none of these three do what you might call open-ended goal pursuit. They do not sit in a loop, evaluate whether they hit the goal, and keep going if they missed. What they have is a tool-use loop within a single task. You give it a task. It calls tools until it decides the task is done. Then it stops.

Qwen Code's approval modes and budget controls make that single-task loop safer to run long. They do not make it a self-directed agent. Same for Aider's --yes-always mode. Same for OpenCode's daemon mode. All three are agents in the "uses tools to accomplish a task" sense. None of them are agents in the "pursues a goal indefinitely" sense. If your project depends on the second interpretation, you are looking at a different kind of harness.

This distinction saved me from a bad architecture choice, and I have not seen it stated plainly in the three tools' docs, so I am stating it plainly here.

The reason I started this comparison was that I use Claude Code as my daily driver on cloud, and I wanted to know what the local-only story looks like when I take Claude Code out of the loop. The mechanics of running a code agent well — tool call design, approval modes, when to hand off to a subagent — apply across all four tools, and I wrote them up here: Claude Code Mastery. If Claude Code is your baseline, this book is the "how to actually use it" playbook; the local-agent comparison above is what you fall back to when you cannot ship your code to a cloud provider.

What was your win this week?

Jess Lee — Fri, 07 Aug 2026 13:00:00 +0000

👋👋👋👋
Looking back on your week -- what was something you're proud of?
All wins count -- big or small 🎉

Examples of 'wins' include:

Getting a promotion!
Starting a new project
Fixing a tricky bug
Started something you've been "about to start" for two months 🏁

Happy Friday!

Qwen3 4B vs 8B vs 14B for Writing Correction: 60 Local Ollama Responses on Windows

Sami — Fri, 07 Aug 2026 12:56:05 +0000

I expected the larger Qwen3 model to show a clear advantage for writing correction. In this experiment, it didn't.

Across 20 paired writing cases, Qwen3 8B and 14B both achieved 19/20 complete-case corrections, while Qwen3 4B reached 18/20.

The difference became much more noticeable in local execution time: in the tested cold-start setup, the mean cold-start time for Qwen3 8B was roughly half that of Qwen3 14B.

That raised a practical question:

For a local writing assistant, how much model size do we actually need?

To explore this more systematically, I built a reproducible benchmark comparing Qwen3 4B, 8B and 14B under the same local conditions with Ollama on Windows.

Benchmark setup

The benchmark uses 20 paired writing cases, including 16 sentences with expected errors and 4 already-correct controls.

Each case was evaluated with the same reference and the same evaluation framework across three locally hosted Qwen3 models:

qwen3:4b-q4_K_M
qwen3:8b-q4_K_M
qwen3:14b-q4_K_M

This produced 60 local responses in total.

The models were executed through Ollama on Windows under the same test conditions. The objective was not to identify a universal “best model,” but to compare several dimensions separately:

complete correction of the expected errors;
localization of the error regions;
preservation of the original meaning;
compliance with the requested output structure;
quality of the explanations;
local execution time.

For the primary metric discussed here, a case was considered complete only when the expected correction requirements for that case were satisfied.

Results

Complete-case correction

The primary correction results were close:

Qwen3 4B: 18/20 complete cases — 90%
Qwen3 8B: 19/20 complete cases — 95%
Qwen3 14B: 19/20 complete cases — 95%

On this metric alone, increasing the model size from 8B to 14B did not improve the number of complete cases in this test.

Local execution time

The difference was much larger in execution time.

In the tested cold-start configuration, the mean cold-start times were approximately:

Qwen3 4B: 26.6 s
Qwen3 8B: 60.0 s
Qwen3 14B: 119.4 s

So, while 8B and 14B achieved the same complete-case score, Qwen3 8B took about half as long as Qwen3 14B on average in this cold-start setup.

The 4B model was substantially faster again, while still completing 18 of the 20 cases.

This does not mean that 8B is universally better than 14B. It means that, for this specific writing-correction workload and hardware configuration, the additional model size did not translate into a better primary correction score, while the execution-time cost increased considerably.

Error localization and explanation quality

Complete-case correction and error localization measure different aspects of model behavior.

Across the 21 expected error regions:

Qwen3 4B missed one expected region, with an error-localization F1 of 97.6%.
Qwen3 8B localized all 21 expected regions, reaching 100% F1.
Qwen3 14B missed one expected region and reported one false-positive region, resulting in 95.2% F1.

This distinction matters for a writing coach: producing an acceptable corrected sentence does not necessarily mean that the model identified the underlying error with the same precision.

Explanation quality was therefore evaluated separately from correction success.

In this run, all 41 evaluated explanation fields produced by Qwen3 8B passed the language check. Qwen3 4B showed more explanation-language and terminology issues.

These automatic checks should not be interpreted as a complete measure of pedagogical quality. They cover selected language patterns and contradictions, while deeper explanation quality remains a separate area for linguistic review.

What this means for local writing assistants

The main takeaway is not that one model is universally better than another.

In this benchmark, the three Qwen3 models produced relatively similar complete-case correction results, but their local execution times differed much more substantially.

For this specific workload:

4B offered the lowest execution time, with a small reduction in correction coverage.
8B matched 14B on complete-case correction and achieved the strongest error-localization result in this run.
14B did not improve the primary correction score over 8B, while requiring substantially more execution time in the tested configuration.

This suggests that model selection for a local writing assistant should be treated as a multi-criteria decision, rather than assuming that a larger model will automatically provide the best practical experience.

Depending on the use case and available hardware, the relevant trade-off may involve:

correction reliability;
explanation quality;
latency;
memory and compute requirements;
and the expected frequency of use.

For a writing coach in particular, responsiveness also matters. A model that is slightly larger or theoretically more capable may not necessarily provide the best user experience if each interaction becomes significantly slower.

Limitations

This benchmark is exploratory and should be interpreted within its experimental scope.

Several limitations are important:

20 paired cases: the dataset is intentionally focused and is not large enough to support a universal ranking of the models.
One language scenario: the benchmark evaluates English writing correction with explanations requested in French. Results may differ for other languages or writing tasks.
One model family: only Qwen3 4B, 8B and 14B were compared. The results should not be generalized to other local model families.
One local machine: execution time depends on hardware, model quantization, available memory and Ollama configuration.
Cold-start timing: Ollama was configured with keep_alive=0, meaning the model was reloaded for each response. The reported timings therefore represent this specific cold-start workflow rather than warm-start interaction latency.
Reference-based evaluation: outputs were compared against a frozen, versioned correction reference prepared for this study. This improves consistency across models, but it does not capture every possible acceptable linguistic formulation.
Explanation-quality checks: automatic checks cover selected language patterns and contradictions. They should not be treated as a complete assessment of pedagogical or linguistic quality.

These limitations are also why the benchmark is presented as a controlled comparison rather than a claim about the absolute capabilities of each model.

What I plan to test next

This first benchmark leaves several useful directions open for further evaluation.

The next iterations could extend the framework in four directions:

compare additional local model families under the same evaluation protocol;
examine explanation quality with deeper linguistic and human review;
compare cold-start and warm-start performance;
evaluate the same workflow on more constrained hardware.

A larger and more diverse test set would also help determine whether the patterns observed here remain stable beyond these 20 cases.

I am particularly interested in whether the 8B/14B trade-off observed in this run persists when the task becomes more linguistically demanding.

Conclusion

This experiment did not produce a universal winner, but it did highlight an important practical point: model size alone is not a sufficient criterion for choosing a local writing model.

For this specific workload, Qwen3 8B matched 14B on complete-case correction while its mean cold-start time was roughly half that of 14B in the tested configuration.

The more useful question, therefore, may not be “Which model is the largest?” but rather:

Which model provides the best balance between correction quality, explanation quality, responsiveness, and available hardware for the intended use case?

If you use local LLMs for writing assistance or other interactive tasks, I would be interested to know which trade-off matters most in your own setup: quality, latency, memory requirements, or something else?

Disclosure: AI assistance was used to refine the wording and organization of this article. The benchmark results and measurements reported here come from the documented experimental runs and were reviewed for accuracy before publication.