DEV Community: Sir. Brian

The AI Price War Just Changed How I Architect Software, and Most Devs Haven't Noticed

Sir. Brian — Sun, 09 Aug 2026 16:21:00 +0000

Everyone's watching the AI price war for the wrong reason. The headlines are about how cheap tokens got. The actual story is what cheap tokens do to how you should be architecting software right now.

Here's what changed, and why it matters more than the price cut itself.

Models aren't one thing anymore, they're tiers

The major labs have quietly split their lineups into tiers. Cheap, fast models for routine work. Expensive, deep-reasoning models for the hard stuff. This isn't a pricing gimmick, it's an architecture signal. If your app sends every request to the same model regardless of difficulty, you're either overpaying for simple tasks or underpowering the hard ones.

The pattern worth adopting: route by task, not by app.

function routeModel(task) {
  if (task.type === 'classification' || task.type === 'extraction') {
    return 'cheap-tier-model';
  }
  if (task.type === 'reasoning' || task.type === 'multi-step-planning') {
    return 'frontier-tier-model';
  }
  return 'mid-tier-model';
}

Simple idea. Almost nobody's actual codebase does this yet. Most apps still hardcode one model for everything, which made sense a year ago when the price gap between tiers was small. It isn't small anymore.

Long context windows are killing naive RAG

Multiple frontier models now ship with million-token context windows. A year ago, retrieval augmented generation existed mostly because you had no other choice, you couldn't fit enough context in the window, so you chunked, embedded, and retrieved. That constraint is disappearing fast for a lot of use cases.

This doesn't mean RAG is dead. It means the decision of when you actually need it just got a lot more deliberate. If your dataset fits in context, a vector database might now be solving a problem you don't have anymore.

Nobody's budgeting for the regulation side

While the pricing race gets all the attention, the EU AI Act's high-risk provisions became enforceable this month. Transparency rules now require chatbots to identify themselves as AI, and synthetic media needs to carry labels. If you're shipping anything AI-facing into the EU market, this isn't optional anymore, and I'd bet most side projects and even a few production apps aren't compliant yet.

The real shift

A year ago, the interesting AI engineering question was "which model." Now it's "which model, for which task, at which cost, under which rules." That's a genuinely different architecture problem than the one most tutorials are still teaching.

Is anyone here actually doing tiered model routing in production, or is everyone still hardcoding one model per app? Curious how far ahead or behind the rest of us actually are on this.

Nobody Designs for 2G. Here's What Building in Kenya Taught Me About "Fast" Websites

Sir. Brian — Sun, 09 Aug 2026 15:06:58 +0000

Most performance advice online assumes a baseline that doesn't exist for most of the world. Fast wifi, a recent phone, a stable connection. Lighthouse scores optimized for conditions half the planet doesn't have.

I build web products for businesses in Kenya. A meaningful share of my users are on 3G, sometimes 2G, often on a budget Android phone with limited storage and a browser that hasn't seen an update in a year. Here's what that actually changes about how you build.

Your bundle size is a business decision, not a dev preference

A 2MB JS bundle that loads instantly on your MacBook can take 15 to 20 seconds on a real 3G connection. That's not a slow load, that's a user who left before your app finished parsing. I've watched analytics confirm this directly, drop-off spikes exactly where bundle size peaks.

Skeleton screens matter more than animations

Every extra animated transition is more work for a weak CPU to render. I stripped most micro-interactions out of a recent build and page-perceived speed improved more than any code-splitting change I made that month. Motion is a luxury feature for people with headroom to spare.

Offline isn't an edge case, it's Tuesday

Connections drop mid-session constantly, not from bad code, just from the actual infrastructure. If your app throws away form state on a dropped connection, you're actively costing your users. Basic local persistence before submission became a non-negotiable for me after watching real users lose an entire booking form to a 4 second network blip.

Images are still the biggest offender in 2026

Everyone optimized images years ago and moved on. They didn't. I still regularly find production sites shipping unoptimized hero images at 3 to 4MB. On a fast connection that's invisible. On the connections a huge share of the world actually uses, that single image can be the whole page load.

The real point

"Fast" isn't a Lighthouse score. It's whether the app actually works for the person holding the phone it's meant for. A lot of what gets called premature optimization in tutorials is just basic respect for users outside wealthy, high bandwidth markets, which is most of the world's internet users, not a minority case.

What's the worst assumption you've seen baked into "best practice" web performance advice that falls apart the moment you leave ideal network conditions?

I've Integrated M-Pesa Into 6 Production Apps. Here's What the Docs Don't Warn You About

Sir. Brian — Sun, 09 Aug 2026 15:00:31 +0000

Every payment integration tutorial assumes the same thing. Stripe, sandbox keys, instant webhooks, clean docs.

M-Pesa is the payment rail over 30 million people in Kenya use every day. I've now wired it into six different production apps. The official docs will get you a working sandbox demo in an afternoon. They will not prepare you for what actually breaks in production.

Here's what nobody tells you upfront.

The sandbox lies to you

Sandbox callbacks are fast and predictable. Production callbacks are not. I've seen STK push callbacks arrive 40 seconds after the user already gave up and closed the tab. Your UI has to account for this. Don't build a payment flow that assumes a callback within 3 seconds, because in production, it sometimes just doesn't work that way.

Localhost breaks the whole flow

Callback URLs have to be publicly reachable. That means no localhost testing, ever, without a tunnel. I use ngrok for local dev now by default, on every M-Pesa project, before I write a single line of integration code. Skipping this step costs you a full afternoon of confused debugging the first time.

Phone number formatting will bite you

Users type their number in every format imaginable. 07XX, +2547XX, 2547XX, sometimes with spaces. If you don't normalize this before it hits the API, you get silent failures that look like your integration is broken when it's actually just string formatting.

function normalizeMsisdn(input) {
  const digits = input.replace(/\D/g, '');
  if (digits.startsWith('254')) return digits;
  if (digits.startsWith('0')) return '254' + digits.slice(1);
  if (digits.startsWith('7') || digits.startsWith('1')) return '254' + digits;
  return digits;
}

Small function. Saves you hours.

Idempotency is on you, not the API

Users double tap the pay button. Always. If you're not deduplicating requests on your end using a unique reference per transaction attempt, you will eventually charge someone twice. This isn't an edge case, it happens weekly at any real scale.

The real lesson

Most payment integration content online is written for Stripe and Silicon Valley assumptions. Fast callbacks, clean sandbox parity, predictable network conditions. Building for African markets means building for the opposite of all three. The fix isn't cleverness, it's defensive UI and idempotent backend logic from day one.

Curious if anyone else here has integrated payment rails outside the usual Stripe and PayPal defaults. What broke for you that the docs never mentioned?