DEV Community: Induwara Ashinsana

OpenAI's data center chief left. Why builders should care

Induwara Ashinsana — Wed, 26 Aug 2026 08:36:04 +0000

OpenAI lost its top data center exec last week, and unlike most executive departures at a frontier lab, this one sits close to something you actually depend on: capacity. Chris Malone, who ran data centers there for roughly 16 months, is out, according to TechCrunch's August 25 report.

I don't care much about who sits where on OpenAI's org chart. I care that the people responsible for pouring concrete are churning while every AI product I build assumes that concrete gets poured on schedule.

🏗️ The bottleneck stopped being the model a while ago

Malone's background says a lot about what the job actually is. Per TechCrunch, he spent nearly five years at Meta and over ten at Google before joining OpenAI in March 2025. That is a career in physical plant: power, land, cooling, supply chain. It is not a research CV.

Look at who else is named in that infrastructure group:

Person	Reported role
Sachin Katti	VP now leading the infrastructure group
Uday Ruddarraju	Data center team lead
Brent Mayo	Build and delivery program lead
Spas Lazarov	Data center engineering lead

Before Malone left, his reporting line was moved off President Greg Brockman and onto Katti. That is a reorg of the group that builds the buildings, at a company whose headline constraint is how many buildings it has.

Key takeaway: The limiting factor on your AI product in 2026 is not model quality. It is whether someone finished a substation in Texas on time.

📉 Thirteen departures is a schedule signal, not gossip

TechCrunch counts 13 senior departures at OpenAI in 2026. The pattern is what interests me, not any single exit:

Who	Role	When they left
Chris Malone	Head of data centers	August 2026
Denise Dresser	Chief revenue officer	August 2026, after 8 months
Brad Lightcap	Chief operating officer	Early August 2026
Fidji Simo	Product and business chief	July 2026, stayed on as advisor
Chloé Bakalar	Head of ethics	July 2026
Bill Peebles	Head of Sora	April 2026, on shutdown
Kate Rouch	Chief marketing officer	April 2026

Two more data points from the same report: the preparedness team that assessed catastrophic risk was disbanded, and the IPO slipped from 2026 to 2027.

You cannot read intent out of any of this, and I won't pretend to. What you can read is variance. Revenue leadership, operations leadership, and infrastructure leadership all turned over inside a few months at the company whose roadmap half the industry has quietly built its 2027 plans around, including the multi-partner Stargate build-out with Oracle, Nvidia, SoftBank and Microsoft.

When leadership churns, plans get re-litigated. Re-litigated plans slip. Slipped capacity plans show up in your app as rate limits, waitlists, region gaps, and price changes.

🌐 What that actually feels like from Colombo

If you build from Sri Lanka, you are already at the thin end of every capacity decision. You feel provider strain earlier and harder than a team in San Francisco does, in four specific ways:

Rate limits tighten from the bottom up. Low-spend accounts get squeezed first. If your org is on a starter tier, you are the shock absorber.
New models land regionally. Preview access, cheaper tiers, and batch endpoints often reach some regions late or not at all.
Latency has no floor you control. Round trips already cost you a few hundred milliseconds. Congestion in a strained region adds more.
Price changes hit harder in LKR. A 20% list-price rise is a 20% rise plus whatever the rupee did that quarter. Card limits and forex controls do the rest.

None of this requires OpenAI to have a bad year. It only requires them to have a busy one.

🛠️ Build so an org chart can't break your product

I use one rule for this: no provider-specific code above the adapter layer. Everything else follows from it.

Route through one interface. One chat() function in your codebase, provider chosen by env var. If swapping providers means touching 40 files, you don't have a fallback, you have a hope.
Keep a real eval set. Twenty to fifty prompts with expected outputs, specific to your product. Without it you cannot answer "is the cheaper model good enough for us" in under a week.
Fail over on 429 and 5xx, not just on outages. Rate limiting is the failure mode you will actually hit.
Cache aggressively. Identical prompts in a Sinhala FAQ bot should hit your database, not a GPU in another hemisphere.
Know your unit cost before you need to. Cost per user, per conversation, per document.

// The whole portability story, roughly
const providers = [openai, anthropic, gemini];

async function chat(messages: Msg[]) {
  for (const p of providers) {
    try { return await p.complete(messages); }
    catch (e) { if (!isRetryable(e)) throw e; }
  }
  throw new Error("all providers exhausted");
}

Three tools on this site exist for exactly this planning work, and I built them because I needed them:

AI API price comparison — per-million-token list prices side by side, so a swap is a number, not a guess.
Model deprecation tracker — which model IDs are on the retirement list before your build breaks.
OpenAI to Anthropic converter — request-shape translation when you need a second provider working this afternoon.

💡 What this means for you

One executive leaving one company is a small event. The reason I wrote about it is that it lands on the exact seam where AI stops being software and starts being civil engineering, and that seam is where small teams get hurt without ever seeing the cause.

Practical version, three things to do this month:

Add a second provider. Not a migration. A tested fallback path and an API key that works.
Write down your worst-case cost. What happens to your margin if inference prices rise 30%? If you cannot answer in ten minutes, model it once and keep the sheet.
Stop treating roadmaps as commitments. Announced capacity, announced pricing tiers, announced launch quarters. Build for what ships, not what is promised.

Bottom line: You cannot control who runs OpenAI's data centers. You can control how many of your assumptions depend on them.

The teams that will be fine through the next two years of AI infrastructure turbulence are not the ones who picked the right provider. They are the ones who stayed cheap to switch.

Thomson Reuters built a frontier model for $40M

Induwara Ashinsana — Tue, 25 Aug 2026 12:31:27 +0000

The Thomson Reuters frontier model announcement landed on 24 August 2026, and the number that matters is not a benchmark score. It's $40 million — talent and compute combined — to take an open-source base model and specialise it until, by the company's own evaluation, it sits alongside the latest frontier models on the work it was built for.

What makes this one worth reading is the admission in Thomson Reuters' press release: they did not start from scratch.

💰 $40 million is the headline, and it's a small number

Frontier labs spend billions. Thomson Reuters spent $40 million and shipped a model called Thomson that it fully owns and runs at what it describes as a fraction of the inference cost of comparable frontier models.

Here's what the release actually commits to, versus what it carefully doesn't:

Claim	Stated in the release?	My read
$40M total, covering talent and compute	✅ Explicit	Real, and small by frontier standards
Built on "a strong open-source foundation"	✅ Explicit	The base model is never named
"On par with the latest frontier models"	✅ CEO quote	Their own early evals, on their own tasks
Trained on less than 10% of TR's content	✅ Explicit	So the ceiling is higher than what shipped
Specific benchmark numbers	❌ Absent	Pointed to a technical report instead
Parameter count, pricing, HF repo name	❌ Absent	Don't assume any of it

Key takeaway: the moat moved. It is no longer "who can afford the biggest training run." It's "who owns data nobody else can legally train on, and who can afford the experts to shape it."

The release says hundreds of subject matter experts were involved, from the design of the training objectives through to the final evaluations. That is an editorial payroll, not a GPU bill.

🔍 The claim that should interest you most

Buried in the middle is an argument aimed straight at everyone building RAG systems:

"The domain-specific gain challenges a common assumption, that the most capable general-purpose models only need access to the right content to perform at an expert level."

In plain terms: giving GPT-class models your documents at inference time is not the same as training on them. Thomson Reuters says its post-training produced gains that content access alone did not.

Treat that as a hypothesis, not a result. It comes from the vendor selling the specialised model, and no head-to-head numbers are published. But it is cheap to test at small scale:

Build your baseline: a strong general model + retrieval over your corpus.
Score it on 50–100 hand-written questions from your actual domain, graded by someone who knows the answers.
Fine-tune a small open model on the same corpus.
Score again with the same rubric, same grader.

If step 4 beats step 2, you've reproduced their argument for the price of a weekend. Our AI fine-tuning cost calculator gives you the token-and-epoch maths before you rent a GPU.

🌐 What this pattern looks like from Sri Lanka

$40 million is not a Sri Lankan budget. The pattern scales down, and the pattern is what's copyable:

Start from open weights. Nobody at the frontier is pretraining from zero for a vertical any more.
Own data that isn't on the open web. This is the real barrier to entry.
Pay for domain experts, not just GPUs. Their spend was talent and compute, in that order in the sentence.
Deploy narrowly first. Thomson's first production surface is one feature — Tabular Analysis inside CoCounsel Legal — not a general chatbot.

Sri Lanka has exactly the kind of data this argument favours, and almost none of it is well-represented in a general model's training set:

Corpus	Why a general model is weak on it
IRD rulings, circulars, gazette notices	Thin on the open web, changes yearly, PDF-locked
Sri Lankan case law and Supreme Court judgments	Poorly digitised, rarely scraped
CBSL circulars and banking directions	Scattered across PDFs, no clean corpus
Sinhala and Tamil professional writing	Chronically under-represented in pretraining data

A model that genuinely understands Sri Lankan tax practice is not a $40 million project. It's a curated dataset, a small open base, and accountants who will tell you when the output is wrong. Their time is the expensive ingredient, and that is the honest lesson here.

⚠️ The licence trap in the free version

Thomson Reuters is releasing a "small" version of Thomson as an open-weight model on Hugging Face — and this is where I'd slow down before getting excited.

The release says it is for academic and non-commercial use, published to help external parties validate the model. That is not the same as open source.

Warning: "open-weight" and "you may ship this in your product" are unrelated statements. A non-commercial licence means a student project is fine and a paid client deliverable is not.

Two things the release does not tell you, and you should not guess at:

Which open-source model it was built on. Only "a strong open-source foundation" is stated. If the base carries its own licence terms, those may travel downstream.
The exact licence text on the Hugging Face release. Read it on the model card, not in a blog post.

If you're unsure how a given model licence maps to commercial use, our LLM licence checker covers the common families, and the self-hosting cost calculator tells you whether running weights yourself is cheaper than an API in the first place.

💡 What this means for you

If you're a student or a small-team builder here, three concrete things come out of this:

Stop treating "train a model" as a billionaire's activity. The gap between "call an API" and "own a model" now has a middle: post-training an open base on data you control. $40 million was the enterprise price. The technique is not.
Audit what data you already have access to. A university lab, a law firm, a hospital, a small accounting practice — each is sitting on a corpus with no public equivalent. That, not compute, is the thing that's hard to buy.
Verify before repeating. No benchmark numbers accompanied this launch, only a pointer to a technical report and two named academic testers. Both were positive; one described citation quality as "generally competitive" with leading models, which is a careful phrase, not a victory lap.

The honest summary: a company with decades of proprietary content and its own editorial staff proved that owning the data and the experts can substitute for owning the largest training cluster. That's good news for anyone building in a small market with deep local knowledge, which describes most useful software work in Sri Lanka.

Commentary based on Thomson Reuters' press release of 24 August 2026. All figures and quotes are from that source; nothing here is independently verified.

Training AI on Copyrighted Books: It's the Download That Bites

Induwara Ashinsana — Mon, 24 Aug 2026 16:16:44 +0000

Is it legal to train AI models on copyrighted books? After the Anthropic case, the honest answer is that the training was ruled lawful and the downloading was what cost $1.5 billion. That split is the entire story, and most coverage flattened it into "AI companies lose."

TechCrunch's piece Is it legal to train AI models on copyrighted books? It's complicated lays out the cases. I want to talk about what they mean if you are building something small here with a laptop, a free tier, and a scraper.

🔍 The ruling everyone read backwards

Judge William Alsup ordered Anthropic to pay a $1.5 billion copyright settlement to writers whose books were used in training. The part that got lost: Alsup ruled the training itself was lawful. He compared an LLM learning from books to a writer studying literature. The penalty attached to something else entirely — Anthropic sourced books from illegal shadow libraries.

Case	Decided by	What actually happened
Anthropic copyright settlement	Judge William Alsup	$1.5B settlement, but training ruled lawful; the liability came from pirated sourcing
Thomson Reuters v. Ross Intelligence	Judge Stephanos Bibas	Not fair use — Ross trained on Reuters content to build a directly competing legal platform
Thaler v. Perlmutter	—	Works that are 100% AI-generated are not copyrightable

Key takeaway: Your legal exposure is not in the model architecture. It's in your data supply chain — where the bytes came from, and whether you can prove it.

⚖️ What a court is actually weighing

Copyright law in the US hasn't been meaningfully updated since 1976, which is why every one of these questions ends up decided case by case. The factors judges weigh, per the TechCrunch piece, include the purpose and nature of the work, the amount used, and the effect on the market — with market impact carrying the most weight.

Factor	The question it asks	Where small teams get caught
Purpose and nature	Is the use transformative, or just a repackage?	Wrapping someone's content in a thin UI is not transformative
Amount used	How much of the original was taken?	Full-corpus scrapes are hard to argue down
Market impact	Does it substitute for the original?	Building the thing your data source sells

IP attorney Cathy Gellis put the mechanism plainly:

"Copyright law hinges on copying, but it doesn't hinge on using the work or experiencing the work, consuming the work, reading the work."

That is why Alsup could bless the training and still punish the acquisition. Reading is not the infringement. Obtaining an illegal copy is.

🛠️ The provenance habit that costs you nothing today

The practical lesson for anyone fine-tuning a model, building a RAG index, or shipping a dataset: log where every file came from, at the moment you get it. Reconstructing that two years later, under pressure, is impossible.

A manifest entry per source costs about thirty seconds:

{
  "source": "https://example.gov.lk/reports/2025-annual.pdf",
  "obtained": "2026-08-24",
  "method": "direct download, public URL",
  "licence": "Sri Lanka government publication, no stated restriction",
  "sha256": "a3f1...",
  "robots_txt_checked": true
}

Four rules I'd hold anyone to:

Never pull from a shadow library. This is the single fact pattern that produced a nine-figure bill. Free is not the same as legal.
Record a checksum per file so you can prove which version you trained on. Our hash generator does SHA-256 in the browser — nothing gets uploaded.
Prefer licensed and public-domain corpora. Project Gutenberg, government publications, Creative Commons, and datasets with an explicit licence field.
Check robots.txt and terms before scraping, and write down the date you checked.

Warning: "I got it from a HuggingFace mirror" is not provenance. If the upstream dataset was assembled from pirated books, inheriting it does not launder it.

📄 The other half nobody plans for: what you can sell

Thaler v. Perlmutter held that fully AI-generated works are not copyrightable. If you're freelancing — logos, marketing copy, landing pages, boilerplate code — that's not academic. It's the question of what your client is actually paying for.

The awkward follow-on, which the TechCrunch piece flags directly: nobody has settled how you'd prove how much AI was involved, or what percentage of human input makes a work protectable.

Deliverable	Human contribution	Practical risk
Prompt in, image out, shipped as-is	Near zero	Client may own nothing enforceable
AI draft, substantially edited and art-directed by you	Meaningful	Much stronger position
AI-assisted code you architected, reviewed, and tested	Meaningful	Standard practice, low concern

My read: keep your working files. Drafts, revision history, the notes where you rejected three versions. That record is the evidence of human authorship, and it's free to keep.

🌐 Why US rulings matter from Colombo

None of these decisions bind a Sri Lankan court. I'm an engineer, not a lawyer, and I'm not going to pretend otherwise. But they matter here anyway, for reasons that have nothing to do with jurisdiction:

Your clients are often abroad. A US or EU company commissioning work will push provenance and IP-warranty terms down to you in the contract.
The vendors you build on are US companies. What Alsup and Bibas decide shapes what OpenAI, Anthropic and Google will and won't ship, and what their terms of service allow you to do downstream.
Licensed data is becoming a paid market. Attorney Jason Henderson framed it as: "Copyright is always about protecting and growing the market." Expect more datasets to carry a price tag rather than a takedown notice.
Competing with your source is the risky shape. Ross lost because it trained on Reuters content to build a Reuters competitor. If you fine-tune on a company's data to sell against that company, fair use gets much harder to argue.

💡 What this means for you

If you're building on a learning budget, the good news is that the expensive mistake in this story is also the easiest one to avoid. Alsup didn't say training on books is illegal. He said helping yourself to pirated copies is.

So: keep a manifest, checksum your sources, prefer licensed and public-domain corpora, and don't fine-tune a model to compete head-on with the people whose data you used. Keep your drafts so you can show human authorship in what you deliver.

Bottom line: Train on what you're allowed to have, and keep the receipt.

None of that requires a lawyer or a budget. It requires a habit, and the cheapest time to start it is on the project you haven't collected data for yet.

Claude Code effort levels: what the A/B test really shows

Induwara Ashinsana — Sun, 23 Aug 2026 19:52:31 +0000

Claude Code effort levels are supposed to be a dial you control, so it matters that people have started asking whether the level you pick is the level you actually get. A post by @argofowl on X, surfaced on Hacker News, claimed Anthropic was quietly reducing selected effort levels while showing users misleading numbers.

Anthropic replied. The reply is more interesting than the accusation.

🔍 What Anthropic actually said

Thariq, from the Claude Code team, posted the same response on X and in the HN thread:

"We sometimes test API serving configs in Claude Code before rolling them out, and one running now maps the numerical effort value differently. That's why Claude may tell some of you it's at '10' on high. The scale isn't 0-100, the number isn't meaningful on its own, and the effort you selected is the effort you're getting. We've run in-depth evals to confirm this doesn't affect model performance."

Read that carefully. It is not a denial of A/B testing. It is a confirmation of it, plus a claim that this particular test is behaviour-neutral. Both things can be true at once.

The original evidence was weak, and the thread said so. As commenter Wowfunhappy put it: the proof was that someone asked Claude what effort level it was set to, and "how would the model even know that?" Others argued effort is injected through the system prompt, so the model might genuinely see it. Nobody in the thread could settle it, which is exactly the problem.

📊 The real issue is unverifiable configuration

Strip out the outrage and what's left is a supply-chain question. You are paying for a product whose behaviour is set by three layers, and you can only see one of them.

Layer	Who controls it	Can you inspect it?	Is it versioned?
Model weights	Anthropic	No	Yes, by model name
Harness / system prompt	Anthropic	Partially	Not publicly
API serving config	Anthropic	No	No
Your prompt, files, CLAUDE.md	You	Yes	Yes, in git

The third row is where this story lives. A serving config can change on a Tuesday afternoon with no release note, no version bump, and no way for you to pin the old one. Commenter cube00 asked the sharpest question in the thread: "Why is it considered acceptable to test on paying customers without letting them know or giving them a way to opt out?"

Key takeaway: "Claude Opus 5, high effort" is not a specification. It's a label pointing at a moving target. Treat model behaviour as an external dependency with no lockfile, because that's what it is.

💰 Why over-thinking is a budget problem here

The complaint underneath the effort-level story is not that the model got dumber. It's that it got longer, and length costs money.

One commenter described asking for a config file update: on the older model it took under 2 minutes to read, parse and patch. On the newer one it ran 43 minutes, pulling containers, spinning up sandboxes, and writing test suites for the whole repo. Same single-file change at the end.

That's funny when your employer pays. It's not funny when you're a student or a two-person shop converting a USD subscription into rupees every month. A few things follow:

Verbosity is the main cost driver, not model choice. One user (perching_aix) reported that comparing like-for-like, the majority of their cost overhead came from the bigger model simply being chattier, and that dropping to low reasoning beat falling back to a smaller model on quality-per-rupee.
Higher effort is not free accuracy. Several developers in the thread independently landed on the same policy: medium by default, high only for genuinely hard architectural work, never the top tiers.
Subscription tiers don't shield you. Limits are real. Burn your weekly quota on a task that needed two minutes of thinking and you've paid for it in lost days, not just tokens.

If you've never actually measured your prompt sizes, our AI token counter will show you what a given context costs against Claude, GPT and Gemini tokenizers before you send it. And if you're budgeting a USD subscription in rupees, the live LKR exchange rate is the number that actually decides whether the $200 tier makes sense for you.

🛠️ Run your own eval instead of arguing about vibes

Here's my honest position. I run agents against this codebase every day, so I have opinions about regressions, and I've noticed that almost all of them evaporate when I write the test down. Human memory of "it felt better last month" is worthless as evidence. So build a tiny personal benchmark. It takes an afternoon.

Pick 5 real tasks from your own repo that you already know the correct answer to. Not puzzles. Actual work: a bug fix, a refactor, a migration, a config change, a test.
Freeze the inputs. Same branch, same files, same prompt text, committed to git.
Log the outputs. Wall-clock time, tokens in and out, and a manual pass/fail you write yourself.
Re-run monthly, and any time you feel a regression.
Use the vendor's channel when you have data. Thariq explicitly asked users seeing a clear regression to file /feedback with the session ID, and offered credits. A session ID beats a complaint.

# crude but sufficient: one row per run, append-only
echo "$(date -Iseconds),opus5,high,$TASK,$SECONDS,$IN_TOK,$OUT_TOK,$VERDICT" \
  >> ~/agent-evals.csv

Five tasks, five minutes of logging each. That CSV is worth more than every "models are getting dumber" thread combined, because it's about your code.

💡 What this means for you

Anthropic's answer here was fast, named, and specific, which is better than the silence you'd get from most vendors. I don't think this particular test is evidence of deliberate degradation, and the accusation that triggered it rested on asking a model to introspect on its own settings, which is not a measurement.

But the structural point survives the debunking. The behaviour of a hosted coding agent is a dependency you cannot pin, cannot diff, and cannot roll back. That's a genuinely new category of risk for anyone shipping software, and it lands hardest on small teams without the budget to keep a second provider warm.

So: default to lower effort than you think you need, keep your prompts short because verbosity is where the money goes, hold a small eval suite you actually re-run, and keep one alternative agent configured so switching is a decision and not an emergency. None of that requires believing anyone is lying to you. It just requires treating the dial on your screen as a hint rather than a contract.

Engineering maturity isn't years served: 3 belief updates

Induwara Ashinsana — Sat, 22 Aug 2026 23:32:29 +0000

Engineering maturity in Sri Lanka is usually measured in years served and job titles collected. Five years, "Senior". Eight years, "Tech Lead". Nobody checks whether anything in your head actually changed.

Thomas Dullien (Halvar Flake) published Three important steps in my maturation process on 21 August 2026. It proposes a different measure: three specific beliefs you had to update. Two of the three land harder here than in Mountain View.

🧠 Step 1: your incentive structure is writing your opinions

Dullien's first realisation comes from his 0day years: he agonised over whether holding an exploit nobody else had made him responsible for what followed. His conclusion was that the agonising was partly vanity.

"Anxiety about the impact of your work is self-flattering, and you have to recognize it as such."

He pairs it with von Neumann's line that "some people profess guilt to claim credit for sin." The instruction is blunt: do not believe everything you think, and ask "how might I be the villain in this story?" Translate that to a Colombo engineering career and it stops being philosophy:

The belief you hold	The incentive quietly holding it up
"Our stack is fine, rewriting is a waste"	You are the only person who knows the stack
"Remote USD work is the only sensible path"	Your last local interview went badly
"Local companies never pay properly"	You've never actually negotiated hard
"I should stay 3 more years for the title"	Leaving means admitting the title was the point

None of those beliefs are automatically wrong. The point is that you acquired them in an order that flattered you, and never tried the other side.

The cheapest version of this discipline is arithmetic. Before deciding a job or a rate is unfair, work out the real number instead of the felt number: our salary and rate tools do net-to-gross and freelance hourly maths in seconds. A belief that survives a spreadsheet beats one that only survives your friends.

⚡ Step 2: determinism is a luxury our infrastructure does not grant

This is the section I'd hand to every CS undergraduate in the country. Dullien argues that the monocausal determinism young programmers get used to is an illusion maintained by generations of electrical and process engineers: computing machines are physical devices subject to wear, unit-to-unit variation, and "probabilistically deterministic behavior." Push on temperature, voltage, electromagnetic fields, or repeated accesses to adjacent DRAM rows, he writes, and it collapses.

"The real world is one where very few things that happen have a single reason, and very few truly deterministic transmission mechanisms. Everything is probabilistic, and everything is multicausal."

Here's my angle. In a well-funded environment that illusion holds for years, because money buys it: dedicated instances, redundant power, generous headroom. On a shared 4-core VPS with a few gigabytes of usable RAM, which is what most Sri Lankan side projects run on, the illusion never gets a chance to form.

The deterministic model	What actually happens on shared, budget infra
Build passes or fails on code	Build gets OOM-killed because something else spiked at the same moment
Failed test = real bug	Failed test = contention, timeout, or a cold cache
Lab performance score = user experience	Lab score looks good; real field data still fails Core Web Vitals
The deploy caused the outage	The deploy, plus a health check, plus a redirect loop, together caused it

I've been on the wrong side of every row in that table. The costliest was assuming a failed build meant broken code. It usually meant two heavy jobs had landed in the same minute on the same box, and the fix was scheduling, not debugging.

His corollary is worth sitting with: the scientific method is a classifier deliberately biased against accepting things as true, so a large class of true things will never be scientifically demonstrated. If you are chasing an intermittent production issue with no reliable reproduction, you are not failing at engineering. You are working where proof is unavailable and probability is all you get.

💡 Step 3: emotion is information, not interference

The third update gets dismissed fastest by technical readers, which is roughly the evidence for it. Dullien argues the reason-versus-emotion split is a western cultural construct, not a neurological fact, and that in most non-western cultures integrating deliberation with emotion is the normal model.

His trivia hook: your gut's enteric nervous system contains as many neurons as the entire cerebral cortex of a dog, and your body forward-deploys neurons into muscles and extremities as latency optimisation. That information reaches you as feeling, not sentences. Then the logical argument, which is the part that convinces:

"Attempting to eliminate a particular source of information almost certainly makes the quality of your decisions worse."

That is an information-theoretic claim, not a self-help one. If a codebase makes your stomach drop every time you open it, that reaction encodes pattern-matching your verbal brain hasn't finished compiling. Same for the client whose emails you keep postponing, or the review where you couldn't articulate the objection but knew there was one.

Note his caution: this is not an argument for acting on impulse, but for treating the feeling as a signal to investigate rather than noise to suppress.

Key takeaway: Maturity here isn't years on the job. It's noticing your incentives before they finish writing your opinions, dropping the assumption that one cause explains one effect, and treating your gut reaction as unlabelled data rather than a defect.

🛠️ Four things I'd actually change on Monday

Write down the counter-narrative. For your strongest technical opinion this quarter, write the best version of the opposite case. If you can't write a good one, you don't understand your own position.
Stop saying "the root cause". Say "the largest contributing cause". Running things on cheap infrastructure, I have almost never found a single cause.
Log the environment, not just the error. Free RAM, load average, and concurrent jobs at failure time. Half of your "bugs" will resolve into contention.
Treat dread as a ticket. When part of the codebase or a client relationship consistently makes you avoid it, open an issue for the avoidance itself.

🚀 What this means for you

If you are a student or a junior engineer here, take the second update seriously first. Coursework and tutorials run inside a deterministic sandbox that production, especially production you can afford, does not provide. Probabilistic thinking is the difference between an engineer who can operate a system and one who can only write code for it.

If you are further along, the first update is the expensive one. Nobody will tell you that your architectural preference is really a job-security preference, or your rate opinion really a confidence problem. You catch that yourself, and the only tool that works is arguing against yourself in writing.

The third is free. It costs nothing to stop treating your own discomfort as a bug in your reasoning. It is data. Check it, but don't throw it away.

The original post is short and has no signup wall. Read it in full rather than trusting my summary.

Nvidia is buying power, not just selling GPUs

Induwara Ashinsana — Sat, 22 Aug 2026 03:05:16 +0000

The Nvidia Cloverleaf data center partnership announced on Friday tells you where the real constraint in AI has moved, and it is not the chip. TechCrunch reported that Nvidia has taken a minority stake in Cloverleaf, a company founded in 2024 that raised $300 million that year and sits between utility companies and data centers, arranging power and site infrastructure.

Nvidia did not buy a chip designer. It bought a piece of the electricity supply chain. That reframing is worth thinking about if you build software from anywhere outside a well-supplied grid.

🔌 The bottleneck moved from silicon to substations

Read the deal literally. Cloverleaf's product is not compute. It is power sourcing and site infrastructure — the interconnect agreements, the substations, the land next to a utility that can actually deliver load. Nvidia buying into that layer is an admission that shipping more GPUs does not help if nobody can plug them in.

This was not a one-off either. The same week, per the reporting:

Deal	Announced	Reported size	What Nvidia bought into
SB Energy (OpenAI-linked, Ohio)	17 Aug 2026	$1.5 billion	Data center project with an energy parent
Cloverleaf	21 Aug 2026	Several hundred million (WSJ), minority stake (Reuters)	Utility-to-data-center power intermediary

Terms were not disclosed by either company, so treat the dollar figures as press reporting rather than filings.

Key takeaway: When the company that sells the shovels starts buying the mines, the scarce input is no longer shovels. For AI in 2026, the scarce input is grid capacity.

💰 The circular money problem you should price in

Here is the part I would not skip over. Nvidia sells GPUs to data centers. Nvidia is now also investing in the companies that build and power those data centers. Some of that capital flows back as GPU orders.

That is not illegal or even unusual in capital-intensive industries. Telecom vendors financed carriers for decades. But it has a specific consequence for you as a buyer of compute:

Capacity gets built ahead of demand, because the supplier has a reason to underwrite it.
Rental prices can stay soft while that overbuild is absorbed, which is good for small teams.
Prices can also snap back if the financing loop tightens, because the underwriting was never a market signal in the first place.

So the cheap H100-hour you rent today is partly a subsidy artefact. Plan for it to be temporary, and do not architect anything that only works at today's price.

📊 Why this argues against buying hardware from Sri Lanka

Every few months someone asks me whether they should import a used GPU and self-host a model. The Cloverleaf story is a decent argument for "no", and the reason is the same one Nvidia just paid for: power is the real line item.

A rented GPU-hour bundles things you cannot buy separately at small scale:

What you actually need	Rented cloud GPU	Self-hosted box in Sri Lanka
Electricity at industrial rates	Included in the hourly price	Domestic tariff, on your bill
Cooling	Included	Your problem, year-round
Uptime through a grid fault	Included	UPS, and hope
Import duty and forex exposure	None	Paid up front, in USD
Ability to stop paying	Instantly	Never, you own it

I am not going to quote a break-even number here because it depends entirely on your utilisation and your tariff block. Run it yourself: our GPU buy vs rent calculator handles the hardware side, and the Sri Lanka electricity bill calculator will tell you what the extra load does to your monthly block.

The short version: self-hosting wins only at high, sustained utilisation. Most small teams run their GPU at single-digit percent duty and pay for the other 90-plus percent of the month in idle electricity.

🛠️ What I'd actually do with this information

Nothing about this deal changes your code today. It changes what you should assume about prices over the next two years. Concretely:

Treat compute as a variable cost, not an asset. Rent. Keep the ability to walk away when a cheaper region or provider appears.
Measure cost per unit of work, not per hour. An hour is meaningless. Tokens served, documents embedded, minutes transcribed — those are the units you can actually optimise. The RAG cost calculator is built around exactly that framing.
Right-size the model before renting a bigger card. Most projects I see are renting for a model that would fit in less VRAM with sane quantisation. Check with the LLM VRAM calculator before upgrading.
Keep your inference layer provider-agnostic. One interface, swappable backends. If the subsidised era ends, you migrate in a day instead of a quarter.
Do the boring optimisations first. Caching, batching and a smaller model beat any hardware decision, and they cost nothing but attention.

Bottom line: The infrastructure arms race is happening at a scale you will never participate in, and that is fine. Your advantage was never capital. It is that you can change your architecture in an afternoon and they cannot.

💡 What this means for you

If you are a student or a small-team builder in Sri Lanka, the Cloverleaf deal is not a story about Nvidia's balance sheet. It is a signal about three things:

Cheap compute is currently being underwritten by the companies that benefit from it existing. Use it, enjoy it, do not depend on it forever.
The bottleneck is physical. Grid interconnect and cooling are slow, permitted, regulated things. That means the compute glut arrives on a construction timetable, not a software one.
Your leverage is efficiency. Nobody in Sri Lanka is going to out-capital a hyperscaler. But a well-cached, well-batched, right-sized pipeline running on rented hardware competes fine on output.

Nvidia is buying substations because it has to. You do not have that constraint, and you should be glad about it. Build things that get cheaper when compute does, and that still work when it does not.

Facts in this post come from the TechCrunch report linked above. Deal terms were not disclosed by Nvidia or Cloverleaf; reported figures are attributed to the Wall Street Journal and Reuters via that article.

OpenAI vs Anthropic: enterprise AI loyalty is near zero

Induwara Ashinsana — Fri, 21 Aug 2026 06:38:35 +0000

New spending data on OpenAI vs Anthropic enterprise market share says the two labs are swapping the lead every few months, and that churn is the part worth your attention. TechCrunch reported on Ramp's corporate card data showing Anthropic still ahead but OpenAI closing through Q3.

Most people will read that as a scoreboard. I read it as evidence that lock-in barely exists right now. If you build software from Sri Lanka on a small budget, that is leverage you should be using.

📊 What the data says, and what it doesn't cover

Ramp is a corporate card and expense-management company. It tracks spending across more than 70,000 American businesses, so it sees which AI vendors actually get charged, not which ones get announced.

Data point	May 2026	July 2026
Anthropic share of AI spend	41%	~44%
OpenAI share of AI spend	39%	~40%
Ramp customers paying for any AI	~50% (March)	~56%

Anthropic took the lead in May and has held it. But Q3-to-date growth is running OpenAI's way, which is the whole story behind the headline.

Before you treat those percentages as gospel, note the limits TechCrunch itself lists:

American businesses only.
Excludes large enterprises that run spend management through providers like American Express.
Covers corporate card and bill-pay spending, not every purchasing route.
Skews toward tech, because Ramp is popular in Silicon Valley.
Percentages only. No dollar amounts were shared.

TechCrunch is blunt about it: "This isn't a measure of the total market." It's a directional read, not a census. Treat it that way.

🔁 Eight weeks is the new switching cost

Look at the shape of the movement rather than the values. A lab ships a model, spend moves. Another lab ships, spend moves back. Ramp economist Ara Kharazian told TechCrunch that GPT-5.6 Sol is "really good, increasingly the choice for developers," while Fable 5 "disappointed both in adoption and real-world application."

That is a market where a two-month-old quality gap rearranges buying decisions. Which means the switch itself has become cheap: same chat-completions shape, same tool-calling pattern, same streaming semantics. Changing providers is a config change and a round of eval runs, not a rewrite.

Key takeaway: Nobody has moat-grade lock-in on the model layer today. Design for that, and every future price cut and capability jump is yours to take. Design against it, and you're volunteering for a rewrite you didn't need.

🛠️ How to build for a market that flips every quarter

Provider-agnostic does not mean a heavyweight abstraction framework. It means being disciplined about four things.

Layer	Hardcode to one vendor?	Why
Model IDs	Never	Put them in config or env. They change more often than your code.
Prompts	No	Store as data (files or DB rows), not string literals scattered in handlers.
Tool / function schemas	No	Keep one JSON schema definition, map it per provider.
Vendor-only features	Isolate	Caching, batch, computer use — behind a flag, with a plain fallback path.

A minimal seam is often enough:

type LLM = {
  complete(prompt: string, opts?: { model?: string }): Promise<string>;
};

const provider: LLM = process.env.LLM_PROVIDER === "openai"
  ? openaiAdapter
  : anthropicAdapter;

Then three habits that make the seam real:

Keep an eval set. Twenty to fifty of your own prompts with expected outputs. Without it, "the new model is better" is a vibe, and vendor benchmarks are marketing.
Log every call with the model ID. When quality shifts, you want to know whether it was your prompt or their silent update.
Re-test on release, not on renewal. Run your evals when a new model drops, then decide with numbers.

💰 What lab churn does to your bill

This is the part that helps anyone earning in rupees and paying in dollars. Competition this close is what keeps prices falling and free tiers alive. When 56% of a card provider's customer base is already paying for AI and the leaders are four points apart, neither side can afford to price like a monopoly.

Practical moves for a small team here:

Price the workload before you commit. Our AI token counter and AI model comparison let you cost a feature before you write it.
Split by task. Cheap models for classification, extraction, and formatting. Expensive ones only where reasoning quality shows up in the output.
Re-price quarterly. If the leaderboard moves every two months, your cost assumptions from January are already stale.

⚠️ The retention clause matters more than the leaderboard

One detail in the piece is worth more to Sri Lankan dev shops than the market share numbers: Anthropic warned users of its higher-end Fable tier that it must retain their data for 30 days under regulatory mandates. That caused a round of public anger, though the article notes the criticism was somewhat oversimplified, since Fable targets specific use cases rather than general chat.

If you're doing client work for a bank, a hospital, or a European customer, retention terms are a procurement fact. Before you ship, get answers to:

How long is prompt and output data retained, and can that be turned off?
Does the tier you're on differ from the tier the marketing page describes?
What does your own client contract promise about sub-processors?
Can you point to the vendor's written policy, not a blog post?

A model that scores two points higher and violates your client's data clause is worth zero. Check the terms before the benchmarks.

💡 What this means for you

Don't pick a "winner." The lead changed in May and is being chased in August. Anyone telling you one lab has permanently won is selling something.
Build a seam, not a framework. One adapter interface, model IDs in config, prompts as data. That's a day of work and it buys you every future price drop.
Own your evals. Your twenty prompts beat any public benchmark for deciding what actually works on your product.
Read the retention terms first, especially for client work under an NDA.
Treat volatility as a discount. Two well-funded labs fighting over enterprise spend is the best pricing environment a small team in Colombo is going to get. Stay in a position to switch, and you keep collecting the benefit.

The investors being warned about weak stickiness are right to worry. For the rest of us building things, weak stickiness is the good news.

Waymo's cheaper robotaxi is a cost story, not an AI story

Induwara Ashinsana — Thu, 20 Aug 2026 10:34:52 +0000

Waymo's next-generation robotaxi, the Ojai, is now open to every rider in three US cities, and the part worth studying isn't the driving. It's the bill of materials. TechCrunch reported on 19 August 2026 that the Ojai is cheaper to build, operate and maintain than the Jaguar I-Pace it replaces.

That one sentence is the entire strategy. Waymo isn't scaling because the car finally got smart enough. It's scaling because the car got cheap enough. If you build anything with a per-unit cost attached, that distinction is your problem too.

🚕 What was actually announced

Stripping out the press-release energy, here is what the source states:

Detail	What the source says
Vehicle	Waymo Ojai, running Waymo's sixth-generation driving system
Open to all riders in	Los Angeles, Phoenix, San Francisco
Next cities	Denver, Las Vegas, San Diego, later in 2026
In-car assistant	Google Gemini
Built by	Zeekr (owned by China's Geely), on Zeekr's SEA-M platform
Autonomy hardware fitted	At Waymo's Arizona factory, after the vehicles are imported
Fleet in commercial service	About 300 Ojais
Imported in July 2026 alone	725 vehicles
Projection	On pace for 5,000 in the US by end of 2026, per research firm MoffettNathanson

Notice what is missing from that list: any claim that the new car drives better. The upgrade being sold is economic.

💰 The gap between 300 and 725 is the real headline

Around 300 Ojais are carrying passengers. But 725 landed in the country in a single month. That is not a demand signal, it's a throughput signal.

Every one of those vehicles has to pass through the Arizona factory to get its autonomy hardware fitted before it can earn a cent. So the constraint on Waymo's growth right now is not the model, not the roads, and not rider appetite in Los Angeles. It's a retrofit line.

Key takeaway: When a company that has spent a decade on the hard AI problem starts optimising its factory instead of its model, the technology is no longer the bottleneck. The supply chain is.

I find that genuinely useful as a diagnostic. Ask it about your own project:

Is the thing slowing you down the quality of your output, or the cost of producing each unit of it?
If you doubled demand tomorrow, what would break first — accuracy, or your bill?
Are you still tuning the demo when the demo already works?

Most small teams I talk to are still polishing the model when their actual ceiling is that every customer costs them money.

🌐 Why the border decides your hardware cost

The source notes that tariffs on imported vehicles have added cost to this programme. Waymo is a company with effectively unlimited engineering budget, buying from a manufacturing partner it has worked with since 2021, and its unit cost is still partly set by customs policy rather than by the factory.

Anyone who has imported hardware into Sri Lanka knows that feeling exactly. The invoice from the supplier is the small number. The landed cost is the real one, and it is decided by duty structures you do not control and that change without warning.

Concrete version of the same lesson:

A GPU that costs $600 abroad is not a $600 GPU once it clears Colombo.
An EV's sticker price abroad tells you almost nothing about what it costs to put on the road here — our Sri Lanka EV import tax calculator exists precisely because that gap surprises people.
Any hardware-flavoured startup plan built on foreign retail prices is a fiction until you run the duty math.

If your business model depends on hardware crossing a border, model the border before you model the product. Waymo can absorb a tariff surprise. You cannot.

🛠️ The levers Waymo pulled, translated for a small team

What Waymo is doing here is not exotic. It's four ordinary cost moves executed at scale, and each one has a version you can run this month.

Waymo's lever	Your equivalent
Replacing the Jaguar I-Pace with a purpose-built Zeekr vehicle	Dropping the expensive managed service you used to ship v1
Fitting the autonomy hardware in-house in Arizona	Owning the integration work instead of paying per-seat forever
Using Gemini as the in-car assistant rather than a bespoke voice stack	Calling a general model API instead of training your own
Importing 725 units in one month	Committing to volume pricing only once demand is proven

The pattern in all four: buy the commodity, build the differentiator. Waymo's differentiator is the driving system. The vehicle, the assistant and the platform underneath are all bought in. They spent their scarce money on exactly one thing.

That's the discipline worth copying. If you are a two-person team in Colombo building something on AI APIs, your differentiator is almost certainly not the model. It's your data, your distribution, or your understanding of a local problem nobody in San Francisco will bother to solve. Everything else should be rented as cheaply as you can rent it.

💡 What this means for you

Three things I'd actually act on:

Separate your "does it work" budget from your "does it pay" budget. These are different projects. A working demo says nothing about whether unit 1,000 is profitable. Waymo proved the driving years ago and is only now solving the second problem.
Find your retrofit line. Every product has one step that quietly caps how fast you can grow. It is rarely the glamorous part. Find it, measure it, then decide whether to widen it or design around it.
Price the whole chain, not the component. Tariffs got Waymo. Egress fees, per-seat licences, payment gateway cuts and import duty will get you. Cost the delivered thing, not the parts list.

The robotaxi headline will be read as an AI story. It isn't. It's a company that finished the research phase and discovered the second half of the work is manufacturing, logistics and arithmetic. That second half is where most products actually live or die, and it's the half that a small team in Sri Lanka can be just as good at as anyone in California.

Linear's AI usage data: why 65 PRs a week proves little

Induwara Ashinsana — Wed, 19 Aug 2026 14:20:37 +0000

AI usage patterns in software teams got a rare piece of hard data this week: Linear published Edition 01 of its data report, written by Tim Qi, drawn from aggregated activity inside its own product. The number everyone will quote is that teams which connected a coding agent went from 21 pull requests a week to 65.

That figure is real. It is also close to meaningless on its own, and Linear says as much inside the report. The parts worth your attention are quieter.

🔍 Read the definitions before you quote the numbers

Every adoption chart in the report rests on a specific definition, and the definition is generous.

Metric	What it actually measures	Sample
"AI-active" user	At least one AI interaction (in-app or Slack conversation, or an agent session) in a 28-day window	127,000 paid users
PR volume	Pull requests opened per workspace per week	47,900 paid workspaces
Coding-agent cohort	4,280 teams with an agent vs 2,607 without	6,887 paid teams
Company-size adoption	Same 28-day AI-active bar, split by headcount	199,000 paid users

So when the report says product roles moved from 12% to 34% AI-active between January and June 2026, that is not "a third of product managers use AI daily." It is "a third touched it at least once in a month." Those are very different claims, and the gap between them is where most AI-adoption headlines go wrong.

Key takeaway: A 28-day "at least once" bar measures curiosity, not dependence. Adoption charts built on it show how many people tried the thing, not how many rely on it.

📊 The real shift is in who files work, not how much gets filed

Strip out the throughput noise and one pattern is genuinely new: non-engineers are now shipping code artifacts.

Function	Attaching PRs, Jun 2024 → Jun 2026	Change
Engineering	20% → 34%	+14 pts
Product managers	3% → 10%	+7 pts
Designers	1% → 8%	+7 pts

A designer group going from 1% to 8% is an eightfold relative move. Alongside it, AI authorship of issues went from fewer than one in a thousand to just under half of all issues created.

Adoption growth by function over January–June 2026 tells the same story:

Product: 12% → 34%
Engineering: 12% → 30%
Founder: 14% → 30%
Design: 6% → 22%
Go-to-market: 5% → 18%

Product overtook engineering. For a five-person team in Colombo where the founder already writes copy, files bugs and reviews Figma, this is not a disruption; it is the tooling finally matching how you already work. The interesting question is not "will roles blur" but "who reviews the output when everyone can produce it."

⚡ "Motion rather than value" is their phrase, not mine

The report is unusually honest about its own limits. Two caveats are stated outright:

Looking at pull requests indicates motion rather than value. An opened PR says nothing about the value of the change.

The data is a picture of adoption inside our own customer base, not the market at large.

There is no data in the report on defect rates, review burden, revert frequency, or whether any of those PRs shipped. The authors say they intend to cover the full lifecycle, from token spend to outcomes, in future work. Until then, the +111% two-year rise in overall PR volume describes artifacts created, not problems solved.

Run the arithmetic on the headline. Sixty-five PRs per workspace per week, with three reviewers, is roughly 22 reviews per person per week on top of their own work. Nobody's reading capacity tripled between 2024 and 2026. If generation went up 3x and review capacity stayed flat, the constraint simply moved, and the report has no visibility into what happened at the new constraint.

🛠️ What a small Sri Lankan team should actually do with this

The report is drawn from paid Linear workspaces, which skews toward funded startups. Three things translate anyway:

Treat review capacity as the scarce resource. Cap open PRs per author before you raise agent throughput. A queue of 40 unreviewed agent PRs is worse than 10 human ones.
Enforce small diffs on agent output. Agents happily produce 900-line changes. A 900-line diff does not get reviewed; it gets approved.
Watch the currency mismatch. Agent tokens are billed in USD while salaries are paid in LKR, so per-seat AI tooling costs a Sri Lankan team far more in relative terms than it costs the median workspace in this dataset. Estimate spend before you commit: our AI token counter gives you a per-prompt figure, and the LKR exchange rate tool turns a USD subscription into a number your budget recognises.

For students and solo builders, the useful signal is different. Non-engineers filing PRs at 8-10% means the floor for "can contribute code" dropped. The differentiator is no longer typing the code; it is judging whether the change is correct.

💡 The metrics they didn't publish are the ones to track

The interesting measurements are the ones absent from Edition 01, and every one of them is free to collect from your own git history.

Metric	Why it matters	How to get it
Merged ÷ opened PRs	Separates shipped work from motion	GitHub API, or `gh pr list --state all`
Time to first review	Shows where the queue is backing up	PR timestamps
Revert + hotfix rate	The closest cheap proxy for quality	Commit message grep
% of PRs over 400 lines	Predicts rubber-stamped reviews	`git log --shortstat`

A starting point that costs nothing:

# hotfix/revert share of the last 200 commits
git log -200 --oneline | grep -icE '^\w+ (revert|hotfix|fix: regression)'

Track those four for a month before and after you add an agent. That is a better dataset for your team than any industry report, because it is measured on your codebase, with your reviewers.

🚀 What this means for you

Linear's report is worth reading, and its honesty about its own limits is worth more than its charts. Take three things from it:

Adoption numbers rest on soft definitions. Check the window and the threshold before you repeat a percentage.
The role boundary moved. Designers and PMs attaching PRs at 8-10% is the durable finding, not the throughput jump.
Nobody has published the quality half yet. Until someone does, throughput claims about coding agents are unfinished sentences.

If you run a small team here, the cheapest advantage available right now is measuring the thing the vendors have not measured. Review latency and revert rate take an afternoon to instrument, and they tell you whether your agents are helping or just producing.

The agentic SDLC: steal the eval, skip the five agents

Induwara Ashinsana — Tue, 18 Aug 2026 18:01:58 +0000

The agentic SDLC is having its moment, and most of the coverage focuses on the wrong part of it. On the Stack Overflow Podcast, Ryan talks to Suneet Malhotra, Senior Manager of Test Engineering at Motorola Solutions, about a five-agent end-to-end pipeline built on MCP servers.

My reaction was not "I want five agents." It was: the two smallest ideas in that episode are the only ones a two-person team in Colombo can actually run, and they're the ones nobody is copying.

🔍 The agent count is the least interesting number

Five agents wired across the lifecycle is an org-chart diagram more than an engineering insight. It tells you Motorola Solutions has enough scale to justify a dedicated stage per phase. It does not tell you that five is correct, or that four fails.

What the shape actually admits is more useful:

Agents are placed at handoffs, not at tasks. Design → spec, spec → code, code → test.
Handoffs are where requirements quietly get lost, so that's where the cost sits.
MCP is the plumbing choice, not the idea. It's what makes each stage able to read the ticket, the repo, and the test results without a bespoke integration each time.

If you take one structural lesson: agents earn their keep at the seams between phases, not inside them. Automating "write the code" is crowded. Automating "did the spec survive the handoff" is not.

🛠️ Specification enrichment is the cheapest stage in the whole pipeline

The technique I'd implement tomorrow is specification enrichment: an extra stage that runs immediately after design, before anyone writes implementation code. QA moves left, into the requirements themselves.

Concretely, it's one prompt against your design doc that asks the questions a good tester would ask in review:

What are the boundary values, and what happens at each one?
Which inputs are unspecified, and what does the system do when it gets them?
What's the failure mode when a dependency is down?
Which acceptance criteria are untestable as written?
What did this spec assume without saying?

For a Sri Lankan tool like an EPF or tax calculator, that stage is the difference between shipping and shipping wrong. "Calculate the tax" passes review. "What happens at exactly the bracket boundary, at zero income, at a negative deduction, when the effective date falls mid-year" does not, until you answer it.

Key takeaway: the bug you catch in the spec costs one prompt. The same bug caught after a user files it costs a rebuild, a redeploy, and your credibility on a page Google already ranked.

You don't need an agent framework for this. You need a checklist prompt and the discipline to run it before you open the editor.

📊 Cohen's kappa is the part I'd steal first

The genuinely technical idea in the episode is using Cohen's kappa to compare multiple LLMs acting as judges. This matters because "LLM-as-a-judge" has a silent failure mode: your judge agrees with you often enough to feel right, and you never check how much of that agreement is luck.

Kappa corrects for chance agreement:

κ = (p_o − p_e) / (1 − p_e)

p_o = observed agreement
p_e = agreement expected by chance

Worked example, my numbers, not the episode's. You hand-label 100 outputs pass/fail and 80 are passes. Your judge also calls 80 passes, and agrees with you on 84 of the 100 items.

Quantity	Value
Observed agreement (p_o)	0.84
Expected by chance (p_e)	0.80×0.80 + 0.20×0.20 = 0.68
Cohen's κ	(0.84 − 0.68) / (1 − 0.68) = 0.50

84% accuracy reads like a working judge. A kappa of 0.50 says half the headroom above chance is unexplained. On an unbalanced dataset, raw accuracy flatters you badly.

The conventional reading of kappa (the Landis and Koch bands, widely used in inter-rater work):

κ range	Interpretation	Would I ship on it?
< 0.20	Slight	No
0.21 – 0.40	Fair	No
0.41 – 0.60	Moderate	Only with human spot-checks
0.61 – 0.80	Substantial	Yes, with sampling
0.81 – 1.00	Almost perfect	Yes

Run this across two or three candidate judge models and you get something an accuracy score can't give you: evidence about which model to trust, and whether your rubric is the actual problem. If every model scores fair, the rubric is ambiguous, not the models.

💰 Running this on a learning budget

The gap between a Motorola Solutions pipeline and a solo build in Sri Lanka is not intelligence. It's tokens per change. Five agents on every commit is a monthly bill; two agents at the two highest-leverage points is a rounding error.

Where I'd spend, in order:

Stage	Worth it solo?	Why
Spec enrichment	Yes, first	One call, catches requirement bugs before code exists
Judge / eval agent	Yes, second	Tells you whether anything else you automate is working
Code generation	Already have it	Your editor does this
Test generation	Maybe	Useful once specs are enriched, weak before
Release / deploy agent	Not yet	Needs infra maturity you probably don't have

Two practical notes. First, a hand-labelled set of 50 to 100 examples is enough to compute a meaningful kappa, and you can build one in an afternoon. Second, before you commit to a judge model, price the workload: our AI token counter shows how much context each eval call actually burns, and the model comparison tool lists input and output pricing side by side. Judges run on every candidate output, so per-token cost compounds faster than you'd expect.

💡 What this means for you

Read the source episode as a report from a large test-engineering org, not a blueprint. The transferable parts are small and cheap:

Put an agent at the handoff, not the task. Design-to-spec is the highest-yield seam.
Enrich the spec before writing code. Five questions, one prompt, before the editor opens.
Never trust a judge you haven't measured. Compute kappa on a hand-labelled set. Accuracy alone will lie to you on unbalanced data.
Buy the two stages that pay, skip the three that don't. Agent count is not a maturity score.

Bottom line: an agentic SDLC isn't a fleet of agents. It's the two places where you stopped guessing.

I'm commenting on the Stack Overflow Podcast episode linked above, not reproducing it. The five-agent pipeline, MCP plumbing, Cohen's kappa evaluation and specification enrichment are theirs; the worked numbers, budget ordering and opinions here are mine.

A photorealistic Magic card browser and the cost of pretty UI

Induwara Ashinsana — Mon, 17 Aug 2026 21:39:37 +0000

Why beautiful websites feel slow is a question I keep running into, and this week a Magic: The Gathering card browser gave me a very clean example of it. Oracle went up on Hacker News with the tagline "Search every Magic card ever printed", built, per the site's own footer, by Egstad from DBCo.

It got 3 points and 2 comments. The first comment was not about the design. It was a complaint that the logo animation was eating CPU. That gap between what was built and what was noticed first is the part worth writing about.

🎴 What Oracle actually ships

Ignore the visuals for a second and the feature list is a serious search tool. From the site itself:

Capability	What it covers
Colour filters	Mono, two, three and five-colour combinations, named guilds like Azorius and Rakdos
Type filters	Planeswalkers, Legends, Battles, Sagas, Equipment, Vehicles, Lands, Artifacts, Enchantments, Tokens
Format filters	Standard, Pioneer, Modern, Legacy, Vintage, Pauper, Commander with EDHREC ranking
Effect search	Counterspells, board wipes, removal, card draw, ramp, mill, lifegain, landfall, reanimation
Sorting	Name, release date, set number, rarity, colour, price in USD / EUR / TIX, mana value, power/toughness, artist, EDHREC rank
Display modes	Small grid, large grid, list, text
Result granularity	One per card, every artwork, every printing, or paper only

That last row is a detail most people would skip. "Every printing" versus "one per card" is a real data-modelling decision, and exposing it as a user-facing toggle means someone thought hard about who is actually searching.

The site does not state where its card data comes from, so I won't guess. What it does state is the intent, and the creator said it plainly in the thread.

🎭 The real bet: the data is commodity, the feel is the product

The top comment made the obvious objection: Gatherer already "has all the same info in a much snappier package." The creator's reply was that they knew about both Gatherer and Scryfall and wanted something that felt "a bit more cinematic and photorealistic."

That is not a dodge. It is the entire product thesis, stated honestly.

Key takeaway: when the underlying data is public and everyone can have it, the only remaining place to compete is the experience layer. That's a legitimate strategy, but it means presentation is no longer decoration. It is the feature, and it gets judged as harshly as a wrong tax bracket would be.

This matters for anyone here building tools. Almost every dataset a small team can build on is already available to competitors. Bus timetables, exchange rates, exam results, public gazette data. You will not win on having the numbers. You might win on the ten seconds it takes someone to find the one number they came for.

But if the experience is your product, then a stutter is a bug in your core feature, not a cosmetic nit. Which is exactly what happened here.

⚡ What "cinematic" costs on a mid-range phone

The complaint was specific: a particle animation on the logo pulling roughly 5% CPU, on a page whose job is to sit there while you read card text. The creator asked, reasonably, what hardware that was measured on.

Both people are right, and that's the interesting part. On a recent laptop, 5% is noise. Here is what the same background cost looks like as you move down the device ladder:

Device class	5% sustained CPU means
Recent laptop, plugged in	Genuinely nothing
Laptop on battery	Fan spins up, measurable battery drain on a long session
Mid-range Android, 4GB RAM	Competes with your own scroll and image decode; jank shows up first here
Older phone, thermally throttled	The animation and the content fight, and the content loses

The device most Sri Lankan students and freelancers are browsing on is not the device most of us develop on. An effect that costs nothing on a MacBook is a frame budget you've already spent before the user has scrolled once.

There's a second bill too. A card browser is, by definition, a very large number of high-quality images. Photorealistic rendering of card faces and foils means bigger assets, and mobile data in Sri Lanka is bought in finite bundles. Anything image-heavy should be compressing aggressively before it ships. We keep a free image compressor and an HTML/CSS/JS minifier online for exactly this reason, and both run in your browser rather than uploading anything.

🧭 The Escape-key problem

The second complaint was navigation: the commenter couldn't get out of a full-screen card view without pressing Escape. The creator's answer was that cards open in a lightbox, so Escape returns you to the grid, and called it a common pattern.

He's right that it's a common pattern. He's also, I'd argue, losing the argument, because the user reported being stuck anyway.

A convention only works when the user recognises it. If someone has to be told the pattern after the fact, the pattern didn't do its job on their screen.

Two things break the lightbox convention quietly:

On touch, there is no Escape key. The entire keyboard affordance is unavailable to a phone user, and the visual close target has to carry the full load.
A photorealistic full-bleed view can swallow the exit. The more immersive the view, the more the close control looks like part of the artwork instead of a control.

The fix is cheap and unglamorous. A visible close button with a real hit area, a click on the backdrop, and browser-back mapped to close. Three of them, not one, because you don't know which one any given person will reach for.

💡 What this means for you

Oracle is a well-made thing built on a defensible bet, and I'd rather see this than the tenth identical minimal-grey search page. But the feedback loop it hit in public is the one to learn from. Here's what I take from it:

Pick your competitive layer deliberately. If the data is commodity, say out loud that experience is the product, then hold yourself to that standard.
Set a frame budget before you add the effect. Idle animation should be near-zero cost, because "idle" is where users spend most of their time.
Test on the cheapest device your audience owns, not the one on your desk. Chrome DevTools CPU throttling at 4x costs nothing to turn on.
Never let a keyboard shortcut be the only exit. Half your traffic has no keyboard.
Compress before you ship. Especially with image-heavy pages on metered mobile data.

Delight is worth paying for. Just know the price, and know whose device is paying it.

LLM gender bias hides in how you write, not who you are

Induwara Ashinsana — Mon, 17 Aug 2026 01:38:15 +0000

LLM gender bias turns out not to live where most of us have been looking for it. A paper posted to arXiv on 13 August 2026, It's How You Ask: Gender-Associated Linguistic Bias in LLMs by Katherine Van Koevering and Anjalie Field, reports something more awkward than a name-swap test: putting a woman's name in the prompt changed nothing, but writing in a hedged, polite register produced large and consistent differences in what the model gave back.

I want to argue that this finding is much bigger than gender, and that if you ship anything with an LLM behind it, it is now your bug to fix.

🔍 What the paper actually measured

The authors tested prompts across four models and three document types, varying the linguistic register rather than the stated identity of the user. The features they looked at are the ones sociolinguists have long associated with women's speech in English:

Hedges — "I think maybe", "sort of", "just wondering if"
Tag questions — "…that would work, wouldn't it?"
Collective reference — "we should", "our team needs", instead of "write me"

Prompts carrying those features got responses that were shorter, less sophisticated, and less formal, and the effect held after controlling for prompt complexity. So this is not the model correctly reading a vaguer request and giving a vaguer answer.

Signal in the prompt	Effect on the response
Explicit gender cue (a name)	No effect reported
Hedges, tag questions, collective reference	Large, consistent effect
Prompt complexity (controlled for)	Not the explanation

Key takeaway: The models are not discriminating on identity. They are discriminating on style — and style correlates with identity, which produces the same outcome while passing every name-swap fairness test you were running.

🌐 Why Sri Lankan English sits directly in the blast radius

Here is the part that made me stop and rewrite my own prompt templates.

The register the paper flags as penalised is, more or less, the default polite register of Sri Lankan professional English. Think about how a typical email from a Colombo office actually opens:

I was just wondering if you could kindly help me with a small thing.
We were hoping to maybe put together a short proposal, if that's okay?

That is three hedges, one collective reference, and a softener, in two sentences. Nobody wrote it that way because they were unsure. They wrote it that way because in Sri Lankan English, going straight to "Write a proposal." reads as rude.

The paper's own framing is that these features are culturally embedded and outside conscious control. That is the sharp end of it. If the workaround is "just write more assertively", then the workaround is asking people to code-switch out of their own dialect to get the same service everyone else gets by default. For a student in Kandy writing a scholarship statement, or a freelancer pitching an overseas client, that is a real and invisible tax.

I have not seen data on non-native or South Asian English registers specifically, and the paper does not claim to have tested that. So treat this as my inference, not their finding. But the mechanism generalises cleanly: if politeness markers depress output quality, every high-politeness English variety is exposed.

⚡ Why "just add a system prompt" won't fix it

The instinct for most of us building on top of an API is to patch this at the instruction layer: append "treat all requests with equal rigour regardless of phrasing."

The paper closes that door. It reports that these linguistic features are encoded in early transformer layers and entangled with other features. In plain terms:

The register signal is picked up early, well before whatever your system prompt is trying to steer.
It is entangled — you cannot cleanly isolate and suppress "hedginess" without dragging along whatever else those representations carry.
So mitigation has to happen either in training, or outside the model entirely, in your application layer.

Option three is the only one available to a small team in Sri Lanka. Which is fine, because option three is also the cheapest.

🛠️ What to actually build if you ship an LLM feature

Concretely, a prompt normalisation step between your user's text and the model:

Layer	What it does	Cost
Normaliser	Rewrites the user's raw input into a flat, direct instruction before it hits the model	One cheap small-model call, or pure regex for common hedges
Eval pair	Runs the same request in hedged and direct form, compares outputs	Runs in CI, not per-request
Length floor	Flags responses well below the median for that request type	Free

A regex-only normaliser gets you a surprising distance. Stripping a fixed list of openers ("I was just wondering if", "would it be possible to", "sorry to bother you but") costs nothing per request and is fully auditable, which matters more than elegance when you are debugging why one user's output looks thin.

If you want to sanity-check your own phrasing before wiring anything up, our AI Prompt Formatter turns rough or over-softened notes into a direct instruction, and the Word Counter is enough to measure the response-length gap between two phrasings of the same request. That is the whole test, and it costs you nothing.

Run this once today: take one real prompt from your app. Write it twice — once hedged, once blunt. Send both. Count the words in each reply. If the gap is large, you have shipped the bug.

💡 What this means for you

If you use LLMs for work: you are probably leaving quality on the table through politeness alone. Be blunt with the model and polite with the human. They are different audiences.
If you build on an API: name-swap fairness tests are no longer sufficient evidence that your product treats users equally. Add register to your eval set.
If you teach or mentor: telling students to "prompt better" is fair advice, but be honest that you are teaching a dialect, not a skill.

The uncomfortable version of this result is that the fairness checks the industry standardised on were testing the variable that turned out not to matter. Names are easy to test, so we tested names. Register is hard to test, so we mostly didn't.

The useful version is that the fix is within reach of a two-person team with a free-tier API key and an afternoon. Normalise the input, measure the output, ship it. You do not need to wait for a model provider to solve this for you.