DEV Community: Induwara Ashinsana

Korea capped 2x leverage. Retail bought 3x instead.

Induwara Ashinsana — Wed, 05 Aug 2026 12:36:14 +0000

Korean retail investors put $4.63 billion into a single 3x leveraged ETF in the three weeks after their government tightened the rules on 2x domestic products. That is more than seven times what went into the next most-bought US stock. The regulator closed one door and the money walked straight to a riskier one.

I want to write about why, because the interesting failure here is not financial. It is a systems design failure, and I have shipped the same bug in software more than once.

🔍 What the numbers actually show

The reporting is from The Asia Business Daily (asiae.co.kr, 5 August 2026, by Park SeungUk), citing Korea Securities Depository data. I am commenting on it, not reproducing it, so the figures below are the ones that carry the argument.

Between 16 July (when the Korean government announced its single-stock leverage measures) and 3 August, the most-purchased US-listed security by Korean investors was SOXL, Direxion's 3x daily semiconductor ETF.

Security	Tracks	Daily leverage	Purchase volume (16 Jul – 3 Aug)
SOXL	US semiconductor index	3x	$4,636.17 M
Micron Technology	Itself (ordinary share)	1x	$515.35 M
SOXL + KORU + TSLL combined	Chips, KOSPI, Tesla	3x / 3x / 2x	$5,174.40 M
Same three, previous 13 trading days	—	—	$4,145.87 M

Three of the ten most-bought US securities were leveraged ETFs. Combined buying rose by more than $1 billion against the prior 13-day window. KORU is a 3x product on the KOSPI itself, which means Korean investors were routing through New York to take triple-leveraged exposure to their own domestic index.

📉 The control worked perfectly. The goal did not.

The measures themselves landed exactly as designed. Minimum margin for domestic single-stock leverage went from ₩10 million to ₩30 million, and a 20% per-person portfolio cap took effect on 29 July. Domestic trading in the 16 affected products then did this:

Date	Individual investors	Foreign investors
30 July	₩5,543.1 bn	₩4,858.8 bn
31 July (₩30m margin live)	₩423.7 bn	₩1,016.4 bn
4 August	₩309.2 bn	₩488.0 bn

Individual trading fell roughly 94% in three sessions. If your dashboard metric was "domestic single-stock leverage volume," you shipped a triumph.

Meanwhile, on 31 July, the first day the higher margin applied, SOXL was still the top US buy at $498.42 million, KORU second at $63.8 million, and those two alone made up 80.2% of the value across the top ten purchases.

The metric measured the mechanism, not the outcome. Volume moved. Risk exposure did not fall, it increased, because the offshore substitute is leveraged 3x rather than 2x.

🛠️ Every engineer has shipped this bug

Strip the finance out and this is a familiar shape: you constrain one path, demand is unchanged, and traffic finds the cheapest remaining route. The route it finds is usually the one you instrumented least.

The control	What it assumed	Where demand actually went
Higher margin on domestic 2x	Cost suppresses appetite	Offshore 3x, no margin rule
Rate limit on `/api/v1`	That is the only entry point	`/api/v2`, still open
Free-tier quota per account	Accounts are scarce	Ten free accounts
Client-side validation	Users use your client	`curl`
Blocking a domain at DNS	Name resolution is the chokepoint	The raw IP

Each time, the limit binds where you can observe, appetite is unchanged, and the substitute path is worse precisely because nobody was watching it.

Key takeaway: A constraint does not reduce demand. It reprices one route. If you have not measured the substitute route, you have not reduced risk, you have only moved it somewhere you cannot see.

An industry figure quoted in the same report made the second-order point, that regulation arriving within two months of a product's launch creates its own risk:

"It's important to establish appropriate measures, but hasty responses may end up causing unintended capital outflows."

That is the credibility cost. In product terms: users who route around your limit rarely route back after you fix it.

🧮 Why 3x is not "one more than 2x"

Daily-reset leveraged products compound each day's move, so the multiplier applies to the path, not the destination. Take an index that drops 10%, then recovers fully:

// Index: 100 -> 90 -> 100. Net move: zero.
let x1 = 100 * 0.90 * 1.1111;   // 100.00  — unleveraged, back to flat
let x2 = 100 * 0.80 * 1.2222;   //  97.78  — 2x daily reset, down 2.2%
let x3 = 100 * 0.70 * 1.3333;   //  93.33  — 3x daily reset, down 6.7%

The index is flat. The 3x holder is down 6.7% with no directional call gone wrong. Widen the swing and it gets uglier: a 50% drawdown needs a 100% gain just to break even, so a 3x product hit by a 20% down day is down 60% and needs +150% to get back to where it started.

Volatility decay is not a fee you can shop around, it is the product working as specified.
The cost scales with the square of daily volatility, so leverage is most expensive exactly when markets are chaotic.
Nothing about "the chip sector goes up long-term" survives contact with this if the path is rough.

If you want to see what different return paths do to an ending balance, our investment return calculator and compound interest calculator make the compounding visible with your own numbers.

🇱🇰 The Sri Lankan version of this story

A Sri Lankan reader cannot run the Korean trade. Under exchange-control rules, residents do not freely move money offshore to buy US-listed ETFs, and I will not pretend to quote current thresholds at you. What is not closed is the pattern, and we have lived it:

Import restrictions and grey channels. Restrict a category at the border and demand does not evaporate, it reappears through informal routes at worse prices and zero consumer protection.
Forex controls and parallel rates. Cap the official channel and price discovery relocates rather than stops.
Your own product's quotas. If you run a free tier for Sri Lankan users on a small budget, the per-account limit you just added is a per-signup limit. Signups are free.

The practical version: instrument the substitute before you tighten the primary. Log what people do after they hit the wall. That log is the only evidence your control did anything real.

💡 What this means for you

If you write policy, code, or pricing: define success as the outcome you care about, never as the throughput of the thing you throttled. Korea's domestic volume metric looks like a 94% win and describes a worse risk position.
If you are tempted by leverage: 3x is not incrementally riskier than 2x, it is a different instrument whose losses compound against you on flat markets. Run the numbers on a path, not an endpoint.
If you run a free tier: assume every limit you set will be met by a workaround within a week, and decide now whether you can live with that workaround.
If you are a student watching this: the transferable skill is not stock-picking. It is asking "and then what happens?" one step further than the people who designed the rule did.

The Korean regulator was not wrong to act. Single-stock products that amplify daily moves genuinely do amplify market volatility. The gap is that the intervention was scoped to what the regulator could reach, while appetite was scoped to what the investor could reach. Those two boundaries were never the same shape.

Apple's Next CEO Rehired a Scheduler. That's the Signal

Induwara Ashinsana — Tue, 04 Aug 2026 16:09:52 +0000

John Ternus rehired Laura Legros before he has even started as Apple's CEO, and the choice tells you more about how he plans to run the company than any keynote will. Legros is a former vice president of hardware engineering who retired from Apple in 2022. She is not a chip architect or a designer. She ran schedules.

Juli Clover covered the move at MacRumors, citing Bloomberg. I want to talk about why this specific kind of hire is the one most small teams skip, including mine.

🔍 What Ternus actually bought back

Strip out the job title and look at what Legros owned, per the reporting:

What she managed	What that means day to day
Product delivery	Something ships on the date it was promised
Development schedules	Who is blocked, by what, and for how long
Cross-team coordination	The camera team and the silicon team agree on one truth

The reporting adds two things worth noting. She will work across different parts of the company rather than own one product line, and she will report directly to Ternus. Bloomberg describes her as one of his most trusted deputies before she retired.

Key takeaway: A new CEO's first hire is a statement about what he thinks is broken. Ternus did not hire a visionary. He hired the person who makes dates real.

Ternus takes over from Tim Cook on 1 September 2026, with Cook moving to executive chairman. So this is a pre-start hire, made during the handover window while Ternus has been shadowing Cook and meeting leaders about product plans.

🛠️ The role nobody puts on their org chart

Every Sri Lankan dev team I have worked with has a version of this person, and almost none of them have the title. It is usually the senior engineer who quietly keeps a spreadsheet, or the founder who does it badly at 11pm on a Sunday.

Here is the uncomfortable part. The work is real, it is full-time at scale, and doing it badly is expensive:

Silent dependencies. Backend thinks the API contract is settled. Frontend is building against a Figma file from three weeks ago.
Fake dates. Everyone commits to a Friday nobody believes in, so nobody plans around it.
Integration debt. Two parts work. Together they do not, and you find out in the last week.
The bus problem. One person holds the whole schedule in their head and takes leave.

Apple ships hardware, where a slipped date means an empty warehouse and a wasted ad buy. Software has softer edges, so the cost hides longer. It does not go away.

If your team has never named an owner for "does this ship on the promised day," the answer is that nobody owns it.

🤝 Why rehiring a known quantity beats a better CV

Legros retired four years ago. Ternus could have hired someone younger, cheaper, and currently in the market. He went back for someone he had already worked with. That is my reading of the trade he made:

	Boomerang hire	Strong outside hire
Time to useful	Weeks	Two to three quarters
Knows where the bodies are buried	Yes	No
Trust with the CEO	Already established	Must be earned under pressure
Fresh outside perspective	Limited	High
Risk of importing old bad habits	Real	Low

When your main constraint is time and trust, the left column wins. When your main constraint is stale thinking, the right column wins. Ternus has roughly four weeks before the job is his and clearly picked time and trust.

This is directly usable if you run a small studio or agency in Colombo or Galle. The engineer who left you eighteen months ago for a remote contract, and left on good terms, is often a better hire than a stranger with a stronger GitHub. You already know how they behave in a bad sprint. That information is worth more than most interview loops produce.

📊 Copying this on a two-person budget

You do not need a VP. You need the function. Concretely:

Name the owner. One person, by name, owns the ship date. Rotate it quarterly if you want, but never leave it blank.
Write dates against real working days. Sri Lanka has a lot of Poya days and public holidays, and a fortnight of calendar time is often eight working days. Our Sri Lanka working days calculator will give you the honest number between two dates. Quote clients from that, not from a calendar month.
Keep one written dependency list. Not a tool. A file. "X is blocked by Y, owned by Z, expected date D." Update it weekly.
Integrate early and often. If the parts have never been run together, your estimate is a guess.
Cost the delay, not the task. If a two-day slip idles a second engineer, the slip cost you four engineer-days. Our freelancer hourly rate calculator is a fast way to put a rupee figure on that if you bill by time.

Point 5 is the one that changes behaviour. Delays feel free until you write down what they cost.

💡 The career read for engineers

There is a quieter lesson here for anyone building a career from Sri Lanka. Legros presented the 2018 MacBook Air and the 2020 iPad Air on stage, so she was visible. But the reason she got called back was reportedly the trust, not the stage time.

Two things travel well across a decade:

A reputation for hitting dates. It is boring, it is rare, and it compounds.
Leaving well. The people who rehire you are the people you did not burn.

Neither shows up on a CV. Both decide whether you get the call four years after you stop working somewhere.

What this means for you

If you are a student or a junior engineer, notice that the delivery and coordination track is a real career, not a consolation prize for people who stopped coding. At Apple it goes to VP.

If you run a small team, the takeaway is narrower and more urgent. Assign the ship date to a person this week. Recalculate your current deadline against actual working days, not calendar weeks. And before you post a job ad, go through the list of people who have already worked with you and left on good terms.

Ternus had one hire to make before day one, and he spent it on the unglamorous function. Given that he is about to run a company that has to land hardware on a date, that is the correct instinct.

Bottom line: Ideas are not the bottleneck on most small teams. Coordination is. Staff it before you staff anything else.

AI COBOL to Java migration: the bugs come with it

Induwara Ashinsana — Mon, 03 Aug 2026 19:55:22 +0000

If you are watching AI COBOL to Java migration and waiting for the moment it becomes safe, the interesting news this week is not a better translator. It is a validator. A paper posted to arXiv on 30 July 2026 describes an agentic loop that proves a generated Java program behaves the same as the COBOL it came from.

Same. Not correct. That distinction is the whole story, and most people reading the headline are getting it backwards.

🔍 What the paper actually built

The paper is Agentic Method for Deterministic Validation of Legacy Code Migration by Andras Ferenczi, Jordan Docherty, Mariya Bessonov, Matthew Findlay and Krishna Lingamneni. I am commenting on it, not reproducing it, so go read the abstract yourself.

Their method is called the Locksmith Loop. The shape of it:

Stand up two runtime environments — the original COBOL and the generated Java — both instrumented with mocks.
Run both off-mainframe, on commodity hardware. No z/OS licence required to test.
Run a Witness Search over the mocked inputs, hunting for values that push execution into unvisited branches.
Apply parity-preserving mutations to those inputs to widen coverage without changing expected behaviour.
When the search stalls, an analyser identifies a Locked Paragraph — the specific condition blocking deeper exploration.

The clever part is step 5. Most coverage tooling tells you that you plateaued at some percentage. This tells you which gate is holding the door shut.

🐛 Bug-for-bug parity is the goal, not the failure

The Hacker News headline that carried this paper around framed it as "bugs included," as if the AI fumbled. That framing is the submitter's, not the authors'. And it inverts the engineering reality.

When you migrate a forty-year-old batch job that posts interest to savings accounts, the COBOL is the specification. There is no other one. The analyst who wrote the requirements retired in 2003. If the COBOL rounds a half-cent down in one obscure branch, and your shiny Java rounds it up, you have not fixed a bug. You have created a reconciliation break that some poor operations team will chase for three weeks.

Migration goal	What you validate against	Failure mode
Behavioural parity	The old system's actual output	You inherit legacy quirks
"Correctness"	A written spec nobody has	You silently change business logic
Rewrite from scratch	New requirements	Multi-year project, high abandon rate

Key takeaway: In legacy migration, the old program is the test oracle. Preserving its bugs is a feature of the process, and you fix them after the cutover, as separate, reviewable changes.

📊 The numbers, and what they do not cover

Here is everything the paper actually reports, so you can calibrate the hype yourself:

Metric	Reported
Case studies	3
Open-source programs	2
Internal production-like program	1
Program size range	430 to 4,114 source lines
Branch coverage (internal program)	91.90%
Coverage (open-source programs)	"nearly complete"

Three programs. The largest is roughly 4,114 lines. A real bank core is measured in millions of lines across thousands of programs, with copybooks, VSAM files, CICS transactions and JCL glue that this evaluation does not touch.

That is not a criticism of the paper. It is a paper, not a product. But if a vendor walks into your office next quarter waving "91.9% verified migration," ask them which of those three numbers they are borrowing from.

🛠️ How to steal this method without owning a mainframe

You almost certainly do not have COBOL. You almost certainly do have a rewrite: a PHP monolith going to Node, a jQuery admin panel going to React, a stored-procedure pile going to application code. The method transfers directly, and it costs nothing but discipline.

Keep the old system runnable. The single most common mistake I see in local rewrites is decommissioning the old code before the new one is proven. Without the original running, you have no oracle.
Mock the boundaries, not the logic. Database, clock, file system, network. Then both versions become deterministic functions of their inputs.
Diff the outputs, not the code. Feed identical inputs to both, capture stdout / JSON / row sets, and compare. A plain text diff is a legitimate regression suite. Ours is free if you want one: text diff checker.
Chase the uncovered branch, not the coverage number. The paper's Locked Paragraph idea is really just: when coverage stalls, name the blocking condition out loud and hand-craft an input for it.
Log every parity break as a ticket, not a fix. Decide deliberately whether each difference is a bug you are inheriting or a bug you are correcting.

If you are learning Java as part of a modernisation job and want somewhere to test snippets without setting up a JDK on a slow laptop, our online Java compiler runs in the browser.

💡 What this means for you

There is real money in this for Sri Lankan teams, and it is not in writing the translator.

Local banks, insurers and government departments run systems old enough to vote, and the offshore modernisation work that flows through Colombo IT services firms is mostly the same shape: someone has a legacy system, an LLM can produce plausible target code in an afternoon, and nobody can sign off that it is safe. The bottleneck moved. Generation got cheap; assurance did not.

The billable skill in 2026 is not "I can convert COBOL to Java." It is "I can prove this conversion did not change behaviour, and here is the evidence."

Three things worth doing this month:

Learn differential testing properly. It is old, unglamorous and applies to every rewrite you will ever touch.
Get comfortable reading branch coverage reports in whatever stack you use. The paper's whole contribution is a smarter way to attack a coverage plateau.
Stop treating "the AI wrote it" as a review status. The output of a migration agent is a patch from an unfamiliar contributor. Review it that way.

The headline says AI moved the bugs across. Good. Moving the bugs across, on purpose, with proof, is the hard part.

The open-source agentic CRM that locks its own agent out

Induwara Ashinsana — Sun, 02 Aug 2026 23:53:52 +0000

The most interesting thing about trycompai/crm, a new open-source agentic CRM on GitHub, is not that it's a CRM. It's the sentence in the README that reorders everything: "The agent is not a feature of the CRM; the CRM is where the agent keeps its notes."

That's a structural claim, not a marketing one. And if you're building anything with an LLM in it from a small team in Sri Lanka, the architecture in trycompai/crm is worth more to you than the product itself.

🔁 The inversion that actually matters

Almost every "AI-powered" tool shipped in the last two years follows the same shape: a normal CRUD app, plus a chat sidebar. You open the app, you type at the agent, the agent does a thing, you close the tab and it stops existing.

This repo flips the dependency. The agent runs on its own deployment, on its own schedule, against a work queue. It keeps going when the browser is shut.

	Chat-sidebar AI	Agentic-first
Trigger	User types	Work queue + schedule
Lifetime	The tab session	Continuous
Where logic lives	The API	The agent
App's job	Do the work	Record what happened

The README puts the API's role bluntly: no intelligence in the API. The NestJS service reports events; the agent interprets them. That single rule is why the design holds together, and it's the part most teams get wrong when they bolt an LLM onto an existing backend.

Key takeaway: If your agent only exists while a user is watching it, you've built a chat feature. An agent that has its own schedule, its own budget and its own queue is a different system with different failure modes — plan for it up front.

🔒 The agent runs with no database credentials

This is the part I'd copy tomorrow. The agent runs in an isolated sandbox with deny-all egress and no DATABASE_URL. It cannot open a socket to the internet unless explicitly allowed, and it cannot reach the database at all.

Instead it gets 18 authored tools — named, bounded functions like:

read_crm_history
search_crm
identify_contact
research_person
enrich_company

Every read and write goes through one of those. There is no SELECT the model can improvise, and no shell it can use to curl your data somewhere else.

A model holding database credentials and open egress has, functionally, been granted your entire customer table on a prompt-injection basis. One hostile line of text in an email body is enough. Removing the credential kills the whole class of bug, not just the instance.

If your agent can run arbitrary shell commands and also holds your production connection string, prompt injection isn't a risk you mitigate. It's a shell you've already handed out.

🧭 No confidence scores, evidence tiers instead

The README rejects self-reported confidence outright: models grade their own certainty unreliably, so the system doesn't ask them to. Tools report only what they observe. Nothing is guessed.

What replaces the score is a two-tier evidence rule:

Evidence strength	What happens
Strong	The record is updated directly
Weak	It becomes a suggestion for a human to review

I like this because it's a product decision disguised as an architecture decision. "0.82 confidence" is a number nobody can act on. "This needs a human to look at it" is a queue item somebody clears before lunch.

If you're building an AI feature for a Sri Lankan client and you're tempted to surface a confidence percentage in the UI — don't. Pick the threshold yourself, then show the user a binary: applied, or waiting for you.

💰 What it actually costs to run from here

Self-hosting needs Bun and Docker, and the quickstart is short:

git clone https://github.com/trycompai/crm.git && cd crm
bun install
docker compose up -d
cp .env.example .env
bun run db:deploy
bun run dev

Only four values are strictly required to boot: BETTER_AUTH_SECRET, ALLOWED_SIGN_IN, and a Google OAuth client ID and secret. Auth is Google-only with an allowlist, because the whole thing is single-tenant by design.

Production is heavier. The README describes three independent deployments (app, API, agent) sharing a DATABASE_URL and auth secret, plus Postgres, optionally Redis, and a scheduler that has to POST to /internal/sync/google to keep the mailbox in sync.

Component	What it is	Free-tier friendly?
Postgres	Self-hosted or Neon	Yes, at small scale
Redis	Upstash, optional	Optional, skip it first
App / API / agent	Three Vercel deployments	Hobby limits apply
Model calls	Vercel AI Gateway	No — metered
Enrichment	Perplexity, RapidAPI, Context Dev	No — all optional, all billed

The README doesn't quote prices and I'm not going to invent any. But the honest read is this: the code is MIT and free, the research is not. An agent that autonomously decides to enrich a company is an agent autonomously spending your money in USD while you earn in LKR. The README notes the agent manages its own research budget, which tells you the authors hit this problem too.

That scheduled sync POST is a plain cron job, incidentally. If you're setting one up, our cron expression builder will save you the usual ten minutes of second-guessing the five fields.

🛠️ What's worth stealing even if you never run it

At the time I looked, the repo was at 1.1k stars, 131 forks and 28 commits on main. That's early. Twenty-eight commits is not a codebase with years of edge cases sanded off it, and I would not put a client's sales pipeline on it this month.

Read it anyway. The transferable parts, ranked:

Tools over credentials. Give the model named functions, not a connection string.
Deny-all egress by default. Allowlist what the agent may reach. That's a network policy, not a rewrite.
The agent owns its schedule. Decouple it from the request cycle and the UI.
Evidence tiers, not confidence floats. Strong writes, weak suggests.
Skip multi-tenancy you don't need. The README's line on this is sharp: an organizationId that's always the same value is "a column, an index and a permissions check that buys nothing."

That last one is the most Sri-Lanka-relevant point on the list. A lot of local products get built multi-tenant from day one for a customer base of four, and then carry that tax through every query for years.

What this means for you

If you're a student or a small-team builder here, the practical takeaway isn't "self-host this CRM." It's that a credible reference implementation of a sandboxed, scheduled, tool-only agent now exists under an MIT licence, and you can read all of it in an afternoon.

Clone it, run docker compose up -d, and go read the tool definitions and the sandbox config. That's maybe two hours. What you'll take away is a defensible answer to the question every client eventually asks: "What stops your AI from leaking my data?" — and "we prompted it not to" is not that answer.

If you do end up running sales through something like this, you'll still need the boring bits around it. Our invoice generator and quotation generator are free and need no signup, which covers the paperwork the agent isn't doing for you.

A 3-Person AI Startup Is Paying $350K for Kernel Work

Induwara Ashinsana — Sun, 02 Aug 2026 03:33:04 +0000

AI infrastructure jobs are where the money in AI has quietly moved, and here's the receipt: a 3-person startup just listed a role paying up to $350K plus 0.40% equity. If you're reading this from Sri Lanka, you can't apply. The listing says "US citizen/visa only."

That's exactly why it's worth reading. A job ad is a company publishing, in public, the shortest possible statement of what it thinks is scarce. Morph's tells you something specific about where the money in AI has moved — and most of it is not where the bootcamps are pointing.

📊 What the listing actually says

The role is Member of Technical Staff at Morph, tagged S23 on Y Combinator's jobs board. Here's the original posting. I'm commenting on it, not republishing it — go read the source for the full text.

Field	What the listing says
Role	Member of Technical Staff
Compensation	$175K – $350K
Equity	0.40%
Experience	6+ years
Location	San Francisco, CA
Eligibility	US citizen/visa only
Team size	3
Founder	Tejas Bhakta
Interview	2-day work trial

The company description is one sentence: Morph "builds specialized code-generation models and serves them on a custom inference stack." The work named includes autoresearch for kernels and custom speculative-decoding models. The stated success metrics are tokens per second, tokens per dollar, and correctness.

Three people. One of them is being hired at up to $350K. That ratio is the whole story.

⚡ The scarce skill isn't "AI" — it's making GPUs cheaper

Notice what is not in that listing. No prompt engineering. No RAG pipeline. No agent framework. No fine-tuning a model on a customer's PDFs.

What's there instead:

Kernels — writing the low-level GPU code that actually executes matrix operations, rather than calling someone else's.
Serving, routing, autoscaling, capacity optimization — the unglamorous plumbing that decides whether a GPU sits idle at 30% utilisation or runs hot.
Speculative decoding — using a small cheap model to guess ahead, and a big expensive model to verify the guesses in one pass.

All three point at the same target: cost per token. When you serve a model, the model itself is a fixed asset and the GPU hours are the variable one. A team that cuts inference cost 40% has done something no amount of clever prompting achieves.

If you want to feel that maths rather than read about it, our speculative decoding speedup calculator implements the standard improvement-factor formula. Put in an acceptance rate and a draft-to-target cost ratio and watch how fast the speedup collapses when the draft model guesses badly. Ten minutes with it will teach you more about why this role exists than a week of reading job ads.

Key takeaway: The premium is on the layer below the model, not above it. Everyone is building on top of LLMs. Very few people can make them run cheaper, and those people are being paid like it.

🚫 "US citizen/visa only" is a fact, not an insult

I want to be direct about this, because a lot of career advice for Sri Lankan engineers is dishonest by omission.

You cannot apply to this role. Not "it'll be hard." The listing states the eligibility rule, requires San Francisco, and runs a 2-day work trial. A 3-person company has no immigration lawyer and no relocation budget. That's not gatekeeping, it's arithmetic.

What follows from that:

Don't build a career plan around US-onsite seed-stage startups. The failure rate on that path from here is near total.
Do build a plan around companies that already hire distributed. Contractor-first infra companies, open-source foundations, and Series-B-and-later firms with an existing EOR setup are where the door is actually open.
Do treat the skill list as portable. The eligibility rule is local to this job. The skills are not — kernel work and inference optimisation are priced high everywhere, including at companies that will hire you as a contractor.

🛠️ How to build this skill set on a Sri Lankan budget

The obvious objection: this work needs GPUs, and GPUs cost money I don't have. Partly true, but less true than it looks. Here's what's genuinely reachable without a hardware budget.

What you want to learn	Free/cheap way in	What it costs
CUDA / Triton kernel basics	Colab or Kaggle free GPU sessions	Free, time-limited sessions
Reading real serving code	vLLM and llama.cpp source on GitHub	Free
Quantisation and its accuracy cost	Run a small model locally on CPU, measure output quality yourself	Free
Batching and throughput intuition	Benchmark a small model at batch size 1 vs 16 and plot it	Free
Speculative decoding theory	Read the Leviathan et al. paper, then model it numerically	Free
Sustained GPU time for real experiments	Hourly rental from a spot-instance provider	Cheapest line item you'll actually pay for

A concrete first project, in order:

Pick one small open model you can run end to end.
Measure its tokens per second at batch size 1. Write the number down.
Change exactly one thing — batch size, quantisation level, attention implementation — and measure again.
Publish the numbers, the method, and the thing that surprised you.

That fourth step is the one people skip, and it's the one that gets you hired. A public benchmark with an honest methodology section is worth more than a certificate, because it demonstrates the exact instinct this job is screening for: you measured, you didn't guess.

A GitHub repo titled "I made this model 2.1× faster and here's the profiler output" is a stronger application than any CV I've seen.

What this means for you

Read job ads from companies you can't join. They're the cleanest market signal available, they're free, and nobody is trying to sell you anything in them.

The specific reads from this one:

Infrastructure skills are outpricing application skills right now. If you're choosing what to go deep on, the low-level side has less competition and higher ceilings.
Small teams pay top-of-band for narrow depth. A 3-person company doesn't hire generalists at $350K. It hires the one skill it can't fake.
Geography still binds hard at seed stage. Aim your applications at companies structured to hire remotely, and treat SF-onsite listings as free curriculum rather than opportunities.
Measurement is the differentiator. Tokens per second, tokens per dollar, correctness. Every one of those is a number. Get comfortable producing numbers.

You can't take this job. You can take the reading list it implies, and that part is free.

Commentary on a public Y Combinator job listing. All figures quoted are from the listing itself as of 2 August 2026; roles and terms change, so check the source before relying on any of it.

Rivian spinoff Also ships late: 4 lessons for hardware teams

Induwara Ashinsana — Sat, 01 Aug 2026 07:25:25 +0000

Rivian spinoff Also has started delivering its TM-B e-bike after months of missed dates, according to TechCrunch. Bikes began shipping the week of 31 July, with the rest of the Launch Edition queue expected to land through September.

I don't care much about the bike. I care that a company with $105 million, a parent automaker's supply chain, and Jony Ive's design firm on the industrial design still could not hit a shipping date. That failure mode is the same one that eats a two-person team in Colombo, just with more zeroes.

🕐 The timeline is the whole story

Here is the sequence, pulled from the source:

When	What happened
2022	Starts as an internal skunkworks project inside Rivian
March 2025	Spun out as Also, with $105M from Eclipse
Spring 2026	Original delivery target for the TM-B
July 2026	Revised delivery target
Week of 31 July 2026	Deliveries actually begin
Through September 2026	Remaining Launch Edition orders expected

Four years from skunkworks to first customer unit. Two public target dates, both missed. The company's stated cause was component supply:

"A rapid, industry-wide spike in demand for raw materials and electronic components has impacted key parts required for the TM-B."

That is a real constraint, not an excuse. But notice what it implies: the Spring 2026 date was published while the bill of materials still had single-sourced parts nobody had locked. The date wasn't a plan. It was a hope with a month attached.

📣 The delay didn't cost them customers. The silence did.

The detail worth stealing is in the customer reaction. TechCrunch reports that reservation holders on Reddit were frustrated by repeated missed timelines and a lack of communication, and that some cancelled.

Read that carefully. Two separate complaints:

The dates kept moving. Annoying, forgivable, normal for hardware.
Nobody told them. Not forgivable, and entirely free to fix.

Key takeaway: Customers will absorb a schedule slip they were warned about. They will not absorb finding out on their own that a date passed. The second one reads as contempt, and it is the only part of a supply-chain delay that costs you nothing to prevent.

If you are running a pre-order, a client project, or an open-source release with people waiting on it, the rule is boring and absolute: the update ships on the promised date even when the product doesn't. A three-line email saying "we slipped, here's the new date, here's why" on the day you said you'd deliver is worth more than the delivery being two weeks earlier.

🚲 Also is not selling you a bicycle

The line most people will skim past: Also mostly calls itself a "vehicle" company, not an e-bike company. The roadmap the source describes is not bikes at all:

Four-wheel pedal-assist cargo vehicles for Amazon
Autonomous delivery vehicle development with DoorDash

So the $4,500 e-bike is a wedge. It is the smallest thing that exercises the whole stack — battery, motor control, frame manufacturing, regulatory approval, fulfilment, warranty, support queue — and it does so against paying consumers instead of a procurement department at Amazon. Every screw-up on the TM-B is a screw-up that doesn't happen on a fleet contract.

That is a strategy small teams should copy and almost never do. The usual pattern here is the opposite: chase the enterprise deal first because it's worth more, then discover the delivery muscle doesn't exist. Also inverted it. Ship the small, unforgiving, public thing first. Learn on strangers who paid $4,500, not on a client who can end you.

The uncomfortable read is that this cuts both ways. If the wedge product slipped twice on a parts shortage, that is exactly the signal Amazon's procurement team is now pricing in.

💰 What a $4,500 e-bike actually costs landed in Sri Lanka

For a local reader the sticker is only the opening number. A $4,500 bike is not a $4,500 bike once it clears Customs, and I'm not going to guess at your final figure because it depends on HS classification, motor rating, and whatever the levy schedule looks like on the day your shipment lands.

What I'd check before getting attached to the idea:

Question	Where to work it out
Is it classed as a bicycle or an electric two-wheeler?	Bicycle import tax calculator
What if it's treated as an electric scooter?	Electric scooter import tax calculator
What's the running cost vs a petrol bike?	EV vs petrol cost calculator
Total duty on a general shipment	Customs duty calculator

The classification question is the one that decides everything. Two products that look identical in photos can land in different duty brackets on motor wattage alone, and that difference is usually larger than the discount you negotiated on the unit price.

Warning: Pre-ordering hardware from a startup that ships internationally means your money is exposed to two independent risks — the company missing its date, and the duty regime changing while your unit sits on a boat. Also's reservation holders only faced the first one.

🛠️ The part that transfers to software

Most people reading this build software, not vehicles, so here's the honest translation.

Single-sourced dependencies are single-sourced dependencies. Also got caught by one supplier of one component. You get caught by one free-tier API, one unmaintained npm package, one hosting provider's pricing change. Same shape, cheaper blast radius.
A date you publish is a promise about your least-understood dependency, not about your work. Estimate the unknown part or don't publish the date.
Ship the small public thing first. The wedge-product logic works even better in software, where the cost of shipping the small thing is close to zero.
Communication is the only variable fully under your control. Supply chains, upstream APIs, and Customs are not. The status update is.

💡 What this means for you

If you're building something with a delivery date attached, take one concrete action from this: write down every dependency you do not control, and next to each one write what your public timeline looks like if that dependency slips by six weeks. If the answer is "the timeline is wrong," you have a hope, not a plan, and you should either pad the date or stop publishing it.

And if you're the one waiting on Also's TM-B, or on any pre-order: the useful signal was never the delay. It was how long the company let you sit there wondering.

This is commentary on reporting by TechCrunch. All facts about Also, the TM-B, and its delivery schedule come from their 31 July 2026 article.

Amazon's $220B AI bet is really your cloud bill

Induwara Ashinsana — Fri, 31 Jul 2026 10:09:13 +0000

AI cloud costs for the next few years are being set by a company that just told the market it plans to spend $220 billion on infrastructure this year, and the market cheered. Amazon's quarterly numbers landed on 30 July.

The reaction is the interesting part, and TechCrunch framed it well in Investors love AI, as long as you're a cloud host. Investors are rewarding the layer that rents compute and punishing the layer that only buys it. If you build software from a small team here, that split is worth more to you than the headline number.

📊 What the market actually rewarded

Here are the figures from the quarter, as reported:

Metric	Amazon, latest quarter
AWS revenue	$42 billion, up 37% year-over-year
Total net sales	up 20%
Capex, fiscal year ended 30 June	$173 billion (up from $107.65 billion)
2026 capex forecast	raised from $200B to $220B
Cash reserves	down $7.6 billion year-over-year
Free cash flow	negative for the first time in 2026
Stock, after hours	up nearly 10%

Now the contrast. Meta reported in the same window, spent heavily on the same kind of buildout, and its stock fell 8% — investors fixed on the cash flow crunch and the continued spending without an equivalent revenue line to point at.

Same spending behaviour. Opposite reaction.

Key takeaway: The market is not pricing AI enthusiasm. It is pricing whether your AI revenue appears on the same page as your AI spending. Amazon can show a 37% growth line next to the bill. Meta, for now, cannot.

💡 The most useful sentence in the whole story

Amazon's CEO said something that I think matters more to a two-person team than it does to a fund manager:

"We see the AI business following very much the same margin trajectory we saw in the core business before...AWS and Amazon Bedrock can have a wildly successful business without its own frontier model."

Read that again with your own product in mind. The largest AI infrastructure business on earth is openly saying it does not need to own a frontier model to win.

If that is true at their scale, it is far more true at yours. I keep meeting local developers who treat "we didn't train our own model" as a confession. It isn't. The durable parts of a small software business have never been the model weights:

Distribution — do people already come to you for this problem?
Boring proprietary data — the messy local dataset nobody else bothered to clean.
Workflow fit — knowing that a Sri Lankan payroll run has EPF, ETF and APIT in it, and that a generic tool will get it wrong.
Trust and support — a real person who answers when it breaks.

None of those four require a GPU cluster. All of them are hard to copy.

📉 Negative free cash flow is a signal about your future pricing

This next part is my reading, not a claim the article makes — flagging that clearly.

Capex does not stay on the balance sheet quietly. $173 billion of data centre spending becomes depreciation, and depreciation lands on the income statement for years afterwards. Amazon just posted its first negative free cash flow period of 2026 while raising the forecast anyway. That is a company betting the revenue arrives before the depreciation bites.

For you, the practical consequence is simple:

Scenario	What happens to your inference bill
AI demand keeps compounding	Scale economics improve, prices likely keep drifting down
Demand plateaus mid-buildout	Providers must recover depreciation — free tiers shrink first

Warning: Do not build a product whose margin only works at today's promotional API price. Free tiers and aggressive per-token pricing exist partly because everyone is buying market share during a buildout. Buildouts end.

The article makes the same point from the other direction: cloud host revenue depends on AI spending being sustainable across the whole industry. If demand doesn't justify the buildout, AWS and its competitors are exposed too.

🌐 What a $220 billion bill looks like in rupees

Here is where it gets local. Your compute is priced in USD. A meaningful share of small-team revenue here is priced in LKR. That mismatch is a real risk sitting quietly inside your unit economics.

Three things I'd actually do before shipping anything AI-powered:

Model the cost per active user, not per request. A single call is cheap. A chatty user across a month is not. Our AI agent cost calculator exists for exactly this — multi-turn cost is where budgets die.
Know your token counts before you know your price. Prompt bloat is the most common cause of a surprise bill. Measure with the token counter instead of guessing.
Price your LKR invoices with FX headroom. If you quote a fixed rupee retainer against a dollar API bill, you have written an unhedged currency position into your contract. The USD-LKR earnings calculator is a blunt but honest way to see the gap.

The cheapest optimisation remains the unglamorous one: don't call a large model when a small one, a cache, or a regex will do. Route by difficulty. Cache aggressively. Most "AI features" are 80% deterministic logic wearing a model as a hat.

🚀 What this means for you

The headline says investors love AI if you're a cloud host. The more useful version for a small builder is this: the market is rewarding proven revenue attached to spending, and nothing else. That standard is being applied to trillion-dollar companies. It will absolutely be applied to you by your first serious client or investor.

So:

Stop apologising for not owning a model. Amazon says it doesn't need one either.
Attach every rupee of AI spend to a revenue line you can name. If you can't name it, it's a hobby, and that's fine — just label it correctly.
Assume today's inference price is a floor, not a ceiling. Build the margin to survive a 2× price move.
Own the layer they can't buy — local context, distribution, the data nobody cleaned.

The buildout is being financed by people with $220 billion to deploy. You will never win that game, and you don't need to. You're renting from them. Rent carefully, price honestly, and keep your costs attached to something real.

Commentary on reporting by TechCrunch. Figures cited are from the linked article.

The Kinney Drugs AI Bot Failed for a Boring Reason

Induwara Ashinsana — Thu, 30 Jul 2026 13:47:13 +0000

The most instructive AI customer service failure I have read about this month is not a model problem at all. It is an architecture problem, and it is one I see in small Sri Lankan products constantly.

VTDigger reported on 29 July 2026 that Kinney Drugs, a pharmacy chain in Vermont and New York, rolled out an AI assistant called "Burt" for prescription refills in May 2026. Patients got delays, wrong dosages, and a new privacy policy. I want to talk about why, because the fix is cheap and nobody applies it.

🔍 What actually broke, in engineering terms

Strip the story down to symptoms and every one of them is a known failure class, not a mystery:

Reported symptom	What it actually is	Where it lives
Wrong dosage ordered	Unvalidated model output written to a system of record	Write path
Could not find longtime customer accounts	Fuzzy name/voice matching against an exact-match database	Identity resolution
No notification when refills were ready	Outbound job never wired, or wired to the bot instead of SMS	Integration gap
Delays between doctor order and processing	A synchronous human step replaced by an async queue nobody drains	Workflow
Calls that do not name the drug	Over-cautious privacy redaction with no useful content left	Prompt/policy

None of that requires a smarter model. Four of the five would be caught by a staging environment and one afternoon of adversarial testing with real account names.

Key takeaway: The bot did not hallucinate its way into ordering a wrong dosage. Somebody let a probabilistic component write directly to a system of record with no confirmation step. That is a design decision, and it is reversible.

⚡ The actual bug: they deleted the deterministic path

The detail from the article that stopped me was a patient saying there is no option to use a keypad. It is talk to the bot or do not get your prescription.

That is the whole failure in one sentence. The old system was a DTMF phone tree: ugly, slow, and completely deterministic. Press 1, get refills. It worked for people with strong accents, bad phone lines, hearing loss, and no patience. The AI was added in place of that path rather than in front of it.

The correct shape is boring:

AI handles the happy path. Natural language in, intent out.
Deterministic fallback stays live forever. Keypad, form, WhatsApp menu, whatever the old thing was. Never delete it.
Low-confidence intents route to the fallback automatically. Do not ask the user to notice the bot is failing.
Any write to a system of record needs an explicit confirmation. "You asked for 500mg of X, correct?"
One escape phrase always works. "Agent." "Operator." "Menu."

Rule 2 is the one teams break, because keeping two paths alive is unglamorous and the whole business case for the AI was reducing cost. But you do not get the savings by removing the fallback. You get them because 80% of traffic stops touching it.

🔐 Your privacy policy quietly becomes your vendor's

The other half of the story matters more than the delays. The chain updated its privacy policy to disclose that customer health information could be used in AI tools, and the vendor, a Texas company called Synerio, became a new third party holding that data.

That is the part builders underestimate. Adding an AI feature is often adding a data processor, and it changes your legal surface even when your code barely changes.

If you send user data to a hosted model API, you have added a sub-processor to your product. Your privacy policy is now wrong until you update it.

Vermont's own data privacy bill, S.71, was signed on 16 June 2026 but does not take effect until 2028. So the regulatory floor for this rollout was, in practice, whatever the company chose. Sri Lanka is in a comparable gap: the Personal Data Protection Act exists on paper and enforcement is still maturing. Do not read that as permission. Read it as: nobody is going to catch your mistake before your users do.

Practical version for a two-person team in Colombo shipping a support bot:

List every third party that touches user text before you ship. Model provider, vector DB, logging service, error tracker.
Do not log full prompts containing personal data by default. Redact at the edge, not in the dashboard.
Check retention settings on your model provider. Many default to retaining inputs for abuse monitoring.
Update the policy in the same PR as the feature. Not "next sprint."

🛠️ The cheap test that would have caught this

You do not need a QA department. You need a list of 20 hostile inputs and one hour, run before every release:

Test	Why it matters
Longest real customer name in your DB	Breaks fuzzy matching first
A name with two spellings (Perera / Pereira)	Identity resolution
Heavy background noise, low-bitrate call	Real phone conditions
Sinhala or Tamil name spoken in English sentence	Code-switching is normal here, not an edge case
Deliberate mid-sentence correction ("no, 250, not 500")	Tests whether the last value wins
Silence for 10 seconds	Timeout and fallback behaviour
Request the bot has no tool for	Should escalate, not improvise

If you are building voice features, the components are cheap to prototype now. Our free speech-to-text tool and text-to-speech tool run in the browser and are enough to sanity-check whether transcription even survives a Sri Lankan accent on a 3G connection before you commit to a vendor.

💡 What this means for you

The Kinney Drugs story will get filed under "AI failed" and that reading is lazy and useless. A refill line is an ideal AI use case: high volume, repetitive, low creativity. The rollout failed on three specific decisions any of us could make next week.

You are allowed to ship an AI feature to 10% of traffic. Nobody is forcing a full cutover.
Never remove the deterministic path. It is your rollback plan, your accessibility story, and your incident mitigation, for the price of some unglamorous code.
Probabilistic components do not get write access to anything a human would be upset about. Read-only until confirmed.
A new AI vendor is a new data processor. Treat the privacy policy as part of the deliverable.

The teams that will look good in two years are not the ones with the best models. They are the ones who kept the boring path working while everyone else deleted it.

Gemini 3.6 Flash & 3.5 Flash-Lite: the token math

Induwara Ashinsana — Wed, 29 Jul 2026 03:51:46 +0000

Gemini 3.6 Flash landed on 21 July 2026 alongside two siblings, and the announcement everyone quoted was the benchmark chart. I want to talk about the boring number underneath it: output tokens dropped 17% for the same work. When you pay per token in dollars and earn or study on a rupee budget, that line matters more than any leaderboard.

Google's post, Gemini 3.6 Flash, 3.5 Flash-Lite, and 3.5 Flash Cyber, covers three models at once. Here's my read on which one you should actually reach for.

🗂️ Three models, one page — what each is for

The launch bundled a workhorse, a speed model, and a locked-down security model. Quick map before the numbers:

Model	Job	Who can use it
Gemini 3.6 Flash	General coding, knowledge work, multimodal	Everyone (AI Studio, Gemini app, Enterprise)
Gemini 3.5 Flash-Lite	Fastest, cheapest 3.5-class; high-throughput agents	Everyone; rolling into Google Search
Gemini 3.5 Flash Cyber	Finding and fixing security vulnerabilities	Governments + trusted partners only

Key takeaway: Two of these three are for you. The third — the interesting one for security folks — you can't touch yet.

💰 The pricing that actually decides your bill

Here are the published rates, per one million tokens:

Model	Input / 1M	Output / 1M
Gemini 3.6 Flash	$1.50	$7.50
Gemini 3.5 Flash-Lite	$0.30	$2.50

Output is where LLM bills quietly balloon, because a chatty agent generates far more tokens than you feed it. Flash-Lite's $2.50 output is a third of 3.6 Flash's $7.50. For a side project or a class assignment, that gap is the difference between a hobby and a habit.

At roughly Rs 300 to the dollar (check the live rate, it moves), a million Flash-Lite output tokens costs around Rs 750. A million on 3.6 Flash is closer to Rs 2,250. If you're not sure how many tokens your prompts actually burn, run them through our free AI Token Counter — it covers GPT, Claude, and Gemini and needs no signup.

⚡ Why "17% fewer tokens" beats a benchmark win

Google says 3.6 Flash cuts output token usage 17% versus 3.5 Flash, and up to 65% on the DeepSWE benchmark. That's not a vanity stat. Fewer tokens for the same answer means every request is cheaper, even before you compare per-token prices.

The benchmarks did move too:

Benchmark	3.5 Flash	3.6 Flash
DeepSWE	37%	49%
MLE Bench	49.7%	63.9%
OSWorld-Verified	78.4%	83.0%

But a coding agent that loops ten times to fix a bug pays ten output bills. Shaving 17% off each one compounds. I'd rather have a model that's slightly less flashy on a chart and consistently cheaper per task, because my monthly cost is the sum of every loop, not the peak score.

A cheaper token on every call scales better than a higher benchmark you hit once.

🚀 Flash-Lite: the throughput model for tight budgets

Flash-Lite is the one I'd start a project on. Google clocks it at 350 output tokens per second and pitches it for high-throughput agentic work and document processing. Its own benchmark jumps are steep:

Terminal-Bench 2.1: 31% → 54%
SWE-Bench Pro: 49.6% → 54.2%

For the kind of work a small Colombo team or a solo student actually ships — parsing PDFs, tagging support tickets, batch-summarising documents — speed and price beat frontier reasoning. Named customers like Ashler, Palo Alto Networks, and Ramp flagged exactly that: they picked it to scale volume, not to win a hard reasoning puzzle.

Prototype on Flash-Lite to keep costs near zero while you iterate.
Move a route to 3.6 Flash only if Lite visibly struggles on it.
Measure real token counts before you commit to either.

🔒 Flash Cyber: the model you can't have (and why that's notable)

Gemini 3.5 Flash Cyber is a fine-tuned 3.5 Flash aimed at finding and fixing security vulnerabilities, offered only to governments and trusted partners through a limited-access pilot called CodeMender.

Bottom line: A frontier lab is now treating vulnerability-finding as capable enough to gate behind vetting. That's a signal worth watching, even if you're locked out of the tool.

For a student here building a security portfolio, the takeaway isn't the model — it's the direction. Automated vuln-finding is graduating from research demo to controlled release. The public models above are strong enough to practise the same workflow: point one at your own code, ask it to audit for common flaws, and learn to read what it flags.

💡 What this means for you

If you build, study, or freelance from Sri Lanka on a dollar-priced AI bill, the practical order of operations is simple:

Default to Flash-Lite. At $0.30/$2.50 per million tokens, it's the cheapest way to keep a project alive while you learn.
Reserve 3.6 Flash for the routes that genuinely need more, and lean on its 17% token cut to keep those cheaper than they used to be.
Count before you commit. Estimate real usage with a token counter so your first invoice isn't a surprise.
Don't chase Flash Cyber. You can't get it, and the public models are enough to build the same security-review muscle.

The headline was three models. The story, for anyone paying per token, is that the floor on running useful AI just dropped again.

Vibe Coding vs Agentic Engineering: The Full-Stack Shift

Induwara Ashinsana — Tue, 28 Jul 2026 02:29:15 +0000

Agentic engineering is the phrase I keep running into now, and a recent Stack Overflow podcast finally pins down why it matters. In The Future of Development is Full-Stack, Snowflake's Umesh Unnikrishnan argues the industry is moving past "vibe coding" for throwaway prototypes toward disciplined, agent-driven work for real software.

His prediction: every developer will eventually become a full-stack builder. For a solo dev or a three-person shop in Sri Lanka, that's not a threat. It's the reality you already live, and it's about to get cheaper to pull off.

🔍 Vibe coding and agentic engineering are not the same thing

The episode draws a line I think a lot of people blur. Vibe coding is prompting an AI until something runs, then shipping it. It's great for a weekend demo or a client mockup. Agentic engineering is the enterprise version: agents that plan, edit, and verify across a codebase, wrapped in process so the output is trustworthy.

	Vibe coding	Agentic engineering
Goal	Fast prototype	Production software
Review	Eyeball it, ship it	Human-in-the-loop approval
Failure cost	Low (throwaway)	High (real users, real data)
Best for	Demos, learning	Teams that maintain code

Key takeaway: Vibe coding gets you a prototype. Agentic engineering is what you need the moment someone other than you depends on the result.

The mistake is using the first when the job needs the second. A tax calculator that's 5% wrong is worse than no calculator.

🛠️ Governance is the part nobody wants to talk about

Unnikrishnan's real point isn't "AI writes code now." It's that enterprises need control layers that sit above the LLM itself. The episode names three guardrails worth stealing:

Human-in-the-loop approval — a person signs off before an agent's change lands.
Guardrails — hard limits on what an agent is allowed to touch.
Control layers beyond the model — governance that doesn't depend on the LLM behaving.

His colleague Vivek Raghunathan, SVP of engineering at Snowflake, described moving his org from chaos to a repeatable, org-wide system using a five-stage framework for AI-assisted engineering. The specific stages aren't detailed in the episode, so I won't invent them, but the direction is clear: process, not vibes.

Governance sounds like a big-company problem. It isn't. If an agent can edit your files, "review every diff before it merges" is governance, and you can do it alone.

💡 Why "everyone becomes full-stack" favours small Sri Lankan teams

Here's my angle. Big companies are only now discovering what small teams have always known: when there are three of you, everyone is already full-stack. You write the API, the frontend, the migration, and the deploy script in the same afternoon because nobody else will.

Agentic tools flatten the cost of the parts you're weakest at. If backend is your comfort zone, an agent covers the CSS. If you're a designer who codes, it scaffolds the database layer.

The old moat was headcount. A 40-person team out-built a 4-person one on volume.
The new moat is judgment. Knowing what to ask for, and catching when the agent is confidently wrong.
That second skill is cheap to practise and it doesn't require a Silicon Valley salary to learn.

For a freelancer billing overseas clients from Colombo or Galle, this is leverage. You can credibly quote full-stack work you'd previously have subcontracted.

⚡ How to practise agentic engineering on a learning budget

You don't need Snowflake's stack to build the habits. Start with the loop: plan, generate, verify, approve. The verify step is where beginners cut corners, so make it concrete.

Habit	What it looks like solo	Cost
Human-in-the-loop	Read every diff before you accept it	Free
Guardrails	Agent works on a branch, never `main`	Free
Verify output	Run the code, don't trust the prose	Free
Learn the language	Test snippets in a sandbox before trusting them	Free

When an agent hands you a Python or SQL snippet and you're not sure it does what it claims, paste it into a sandbox and run it yourself. Our free online code compilers execute Python, JavaScript, SQL, and more right in the browser, no signup, so "verify before you trust" costs you nothing but a few seconds.

Bottom line: The developers who win the agentic era aren't the fastest prompters. They're the ones who reliably catch the 1-in-20 answer that's wrong.

🌐 What this means for you

The Stack Overflow episode was recorded at Snowflake Summit for an enterprise audience, but the lesson scales down cleanly. Being full-stack is becoming the default, not the exception, and the tooling that makes it possible is mostly free or close to it.

If you're a Sri Lankan student or a small-team builder, here's what I'd take from it:

Stop treating vibe coding and real engineering as the same skill. Use the first to explore, the second to ship.
Add one guardrail this week. Even just "agent works on a branch, I review the diff" puts you ahead of most people abusing AI right now.
Get fast at verification. It's the one habit that separates people who build with agents from people who get burned by them.
Lean into full-stack. The market is about to reward generalists who can own a whole feature, and small teams here have been generalists all along.

The future the episode describes isn't one where AI replaces you. It's one where the developer with good judgment and a verify-everything habit finally gets to build like a team of ten.

Vercel Buys Better Auth: What It Means for Your Stack

Induwara Ashinsana — Mon, 27 Jul 2026 06:26:53 +0000

Vercel acquiring Better Auth is the kind of news that sounds like plumbing until you realise it touches almost every login screen a TypeScript developer will ever ship. Better Auth is the open source authentication library with 4.7M+ weekly npm downloads and 850+ contributors, and now the team behind it is joining Vercel. Founder Bereket Engida and the core team are coming along.

I read the announcement on the Vercel blog and my first reaction wasn't excitement. It was the same cautious pause I get whenever a big platform buys a piece of infrastructure I actually rely on. So let me work through what this changes, and what it doesn't, for the kind of builder I write for: solo devs, students, and small teams in Sri Lanka running on free tiers.

🔍 Why a boring auth library is a big deal

Authentication is the one feature nobody wants to build and everybody has to. For years the choice on a small budget was ugly:

Roll your own sessions and pray you got the cookie flags right.
Reach for a hosted service and accept per-user pricing that scales against you.
Glue together five libraries and own the maintenance forever.

Better Auth's pitch was different: framework-agnostic, runs anywhere, and the auth is yours. No vendor sitting between you and your users' credentials.

Key takeaway: The value of Better Auth was never a feature list. It was ownership. You keep your user table, your sessions, your control. An acquisition is worth judging on whether that ownership survives.

🌐 "Open by default" is the promise to watch

Vercel framed this using the same line it used for Next.js, the AI SDK, and Nuxt: software that's open by default, loosely coupled, and portable to any platform. Better Auth is supposed to apply that to authentication.

That phrase "portable to any platform" is the one I care about. Here's the honest comparison of what's on the table:

Concern	What's promised	What I'll verify before trusting it
License	Stays open source	Which license, and whether that holds across future releases
Portability	Runs on any platform	Whether non-Vercel deploys stay first-class, not second-class
Data ownership	Auth you own	That self-hosting keeps working without a paid tier
Roadmap	Continued by same team	Whether community PRs still land

I'm not accusing anyone of anything. I'm saying the load-bearing word in this deal is portable, and the proof is in the next twelve months of commits, not the launch post.

⚡ Agent identity is the actual story

Buried under the acquisition headline is the part I think matters most long-term. When an AI agent acts on your behalf today, it runs under your identity and your access. Every service it touches sees you, not the agent.

That's a real problem, and the announcement describes it plainly:

There's no clean way to limit what any one agent or subagent can do, or to shut down just one without cutting off the rest.

The Better Auth team has been building Agent Auth so each agent carries its own identity and its own scoped, revocable authority, with you as the single point of control. Think of the difference like this:

Model	Who the service sees	Kill one agent?	Blast radius if leaked
Today (shared identity)	You	No, you cut off everything	Full account
Agent Auth (scoped identity)	The specific agent	Yes, revoke just that one	One scope

If you're building anything that lets an LLM call tools or hit APIs, this is the pattern to understand now. It's the auth equivalent of giving each script its own API key instead of sharing the root credential.

💡 What a Sri Lankan builder should actually do

You don't need to react to an acquisition. You need to make good decisions regardless of who owns the library. Here's my checklist:

If you already use Better Auth, change nothing today. Keep an eye on the release notes and the license file. Migrating auth under panic is how you leak sessions.
If you're picking auth for a new project, Better Auth is still a strong free-tier choice precisely because it self-hosts. No per-user bill as you grow. Just confirm the self-host path stays free before you commit.
If you're learning, read the source. An 850-contributor auth library is one of the best-documented ways to actually understand sessions, tokens, and JWTs without a course.
Keep an escape hatch. Because it's framework-agnostic, your user data lives in your database. That's your portability insurance. Guard it.

When you're poking at tokens during any of this, a quick decode helps. Our JWT decoder reads a token's header and payload right in the browser, nothing sent to a server, which is handy when you're debugging a login flow at 2am on shared hosting.

Bottom line: An acquisition doesn't change your architecture. Owning your user data does. Design so that switching auth libraries is a weekend, not a rewrite.

🚀 What this means for you

Vercel buying Better Auth is a bet that authentication and agent identity become core infrastructure, not an add-on. For a solo builder in Colombo shipping on a free tier, the practical takeaway is small and steady: keep using open, self-hostable auth, keep your user data in a database you control, and start learning the scoped-identity pattern now because agent-driven apps are going to need it.

The best thing about open source infrastructure is that ownership doesn't transfer in an acquisition. The code you've already deployed still runs. Your job is to make sure it stays that way, and to treat "portable to any platform" as a claim you verify, not a slogan you trust. If the team keeps that promise, this is good news. If they don't, you kept your data, and you can walk. Either way, you win by staying in control.

Context Engineering: The Real AI Bottleneck Explained

Induwara Ashinsana — Sun, 26 Jul 2026 10:24:29 +0000

Context engineering is the skill I now think separates people who get real work out of AI from people who get impressive-looking demos and nothing shippable. That framing comes from a piece I read this week: Stack Overflow's No Dumb Questions episode, "What is the AI bottleneck?", where their Director of Data Science, Michael Foree, explains the idea to a colleague named Phoebe.

The headline claim is the interesting bit. The model isn't the problem anymore. The plumbing around it is.

🔍 The bottleneck isn't intelligence, it's connection

Foree's definition of the bottleneck is blunt: AI is "competent and capable of doing most of the things that people want it to do," but it can't reach the actual context of your everyday work. The capability is sitting there. The wiring to your real files, threads, and tools is not.

That reframes a lot of the "AI can't do my job" complaints. Usually the model isn't failing at reasoning. It's failing because it never got the inputs a human would have gathered without thinking.

The article gives three grounded examples:

Task	Where AI stalls
Replying to an email	You must manually gather the thread, related docs, Slack messages, and meeting context
Redesigning a room	AI picks paint and furniture, but can't iterate fast across disconnected tools
Grocery shopping	It builds the list fine, but ordering needs multiple store APIs with unclear incentives

Key takeaway: In every example, the model was capable. What was missing was access to the right information and the ability to act on it. That gap is the bottleneck.

🛠️ What "context engineering" actually means

Foree defines context engineering as deliberately identifying and providing the AI with relevant information sources while filtering out distractions. His one-line version: "You have to stop and think about what you're doing."

That sounds soft until you notice it's the opposite of how most people use a chatbot. The default habit is to type a vague request and hope. Context engineering is the discipline of assembling the input on purpose.

I'd break the job into three moves:

Include the sources that actually matter to the answer.
Exclude the noise that will pull the model off track.
Iterate on that selection and write down what worked.

The reason exclusion matters as much as inclusion: the article notes AI "gets distracted by irrelevant information." More context is not automatically better context. A bloated prompt full of unrelated dumps can produce a worse answer than a tight one.

📊 Why this is good news if you're on a small budget

Here's the part that matters for a student in Kandy or a two-person startup in Colombo. Context engineering is a skill, not a subscription.

You don't need a bigger model or an enterprise plan to practise it. You need to think harder about what you paste in. That levels the field in a way most AI advantages don't.

Advantage	Costs money?	Who can practise it
Access to the biggest frontier model	Usually yes	Anyone with budget
Massive proprietary data warehouse	Yes	Enterprises
Context engineering	No	Anyone, including free-tier users

There's one real constraint worth watching: the context window. Every model has a fixed budget for how much text it can hold at once, and long dumps get expensive on paid APIs and can crowd out the useful bits. If you're piecing together email threads, docs, and code into a single prompt, it helps to know roughly how much you're stuffing in. Our AI context window calculator and token counter are free ways to check that before you hit a limit or a bill.

Filtering isn't just about accuracy. On a metered API, every irrelevant paragraph you leave out is money you keep.

💡 How to actually get better at it

Foree's advice for becoming a better context engineer is to "observe and wonder." Pay attention to which information sources matter, what should be excluded, and what distractions keep creeping in. Then test, iterate, and document.

I'd turn that into a routine you can run this week:

Before the prompt: ask "what would a competent colleague need to answer this?" Gather exactly that.
During: watch where the model guesses or drifts. A guess usually means a missing input, not a dumb model.
After: save the prompts that worked. Your reusable context beats a one-off clever question every time.

A small worked example. Say you're a freelancer drafting a reply to an overseas client about a late invoice. The lazy prompt is "write a polite follow-up about my payment." The engineered version includes the original invoice terms, the two prior emails, the agreed currency, and a note to keep it short and non-pushy. Same model, completely different output. The second one is usable; the first one is a form letter.

That's the whole discipline in one message: you did the gathering the model couldn't do for itself.

What this means for you

The Stack Overflow piece is really an argument about where the value is moving. If the models are already "competent," then the edge isn't owning the smartest one. It's feeding whatever model you have the right context and cutting the rest.

For a Sri Lankan builder, student, or small team, that's the encouraging read:

You don't need the biggest model to get strong results.
The scarce skill is judgement about inputs, and that's free to build.
Documenting your good prompts compounds. Treat them like reusable code.

The people who win the next couple of years won't be the ones with the fanciest subscription. They'll be the ones who got disciplined about what they put in front of the model, and left the noise out. Start noticing your own context now, while it's still a rare habit.