Applied Computing has raised a $20M Series A to build a foundation AI model for the oil, gas and petrochemical industry.

Last week an AI-generated GPU kernel ran 18.71× faster than an optimized PyTorch baseline. The model—Fable 5—didn't just edge past the human implementation. It lapped it. Claude Opus 4.8 reached 14.4×. GLM-5.2 hit 11.14×. GPT-5.5 managed 4.34×. Fable's kernel was in a different tier entirely. The exciting read: AI is starting to improve the low-level machinery that makes AI itself cheaper and faster. Specialized performance work that once required rare expertise just got dramatically easier to explore. The uncomfortable read: what happens when the best implementation is also the one nobody on your team would have written—or can fully explain? That question is about to land on every engineering team that ships AI-generated code. The Benchmark Problem A benchmark shows the kernel ran fast under tested conditions. It doesn't show: How it behaves across different GPU hardware How it handles numerical edge cases What happens under months of production changes Whether it degrades gracefully when inputs shift The person who wrote it can't answer these questions either. The AI generated this code through a process that doesn't leave a reviewable chain of reasoning. There's no commit message that says "I chose this approach because X." So the reviewer's job just got harder—not easier. The Real Shift I've been watching this pattern across engineering teams this year. The argument is moving from "can AI generate working code?" to "can our org absorb generated code without breaking quality, morale, or judgment?" The GPU kernel story makes the tension concrete: One side says the code ran, it was measured, it won. Stop moving the goalposts. The other side says somebody still has to know where it can fail and take responsibility when it does. Both are right. AI can make implementation cheaper while making proof more expensive. Senior engineers may write less code but spend more time designing adversarial tests, checking assumptions, planning rollbacks, and deciding whether an impr

We open-sourced Tanso Core: a self-hosted monetization engine for B2B AI products. Usage metering, prepaid credits, entitlements, and Stripe billing in one Spring Boot service, with one property the rest of the stack doesn't have. Every metered event carries its cost. Repo: https://github.com/tansohq/tanso-oss The gap If you sell an AI product today, your monetization stack is split across two categories of tools that don't talk to each other. Billing platforms meter usage and generate invoices, but they have no idea what your inference costs. They can tell you a customer consumed 40,000 events. They cannot tell you whether you made money on them. LLM observability tools know your costs down to the token, but they don't bill anyone. They can tell you a feature costs $0.038 per run. They cannot connect that to what the customer paid for it. So margin per customer, the number that decides whether your pricing works, lives in neither system. Most teams reconstruct it in a spreadsheet, quarterly, if at all. Tanso keeps both sides in one ledger. Every event you ingest records what you billed and what it cost you: input and output tokens, model, provider. Margin per customer, per feature, per model is a query, not a project. What it allows Enforcement at ingestion, not at invoice time. Entitlement checks, usage caps, and credit limits are applied when the event comes in. If a customer is out of credits, the check fails now, not on a reconciliation job three weeks later. For AI products, where a runaway integration can burn real money in an afternoon, this is the difference between a limit and a suggestion. Credits as a first-class primitive. Prepaid credit pools per customer, with grants, deductions, expirations, and full transaction history. Most AI products end up selling some form of prepaid usage. Bolting that onto a subscription-shaped billing system is painful; here it's the core model. Stripe as a payment adapter, not the source of truth. Billing state lives in Tan

Part 2 of a series on building a production banking AI chatbot. By the time the classifier and the semantic cache were both live, I genuinely thought the hard part was behind us. Routing was fast. Caching worked. The demo looked clean. Then the AI team asked me a question that sounded almost administrative. AI Lead: "Can you send over the loan policy PDFs? We need to load them into the knowledge base." "Sure," I said. "Give me an hour." That hour turned into three weeks. Chapter 1 — The PDF That Broke Everything The first document I opened was a loan eligibility policy. Twelve pages. Looked simple enough on screen — headings, a couple of tables, some fine print at the bottom of each page. I ran it through a basic PDF-to-text extractor, the kind that takes minutes to wire up. Skimmed the output. It was garbage. Not wrong garbage — worse. It was confidently wrong. Two columns of a table had been extracted side by side into one long, meaningless sentence. A header that said "Eligibility Criteria" had merged directly into the paragraph below it with no space, so it read Eligibility Criteriaapplicants must be . Numbers from a rate table were scattered through the text with no column headers attached, so a 7.2% interest rate sat next to a completely unrelated clause with nothing telling the retriever they weren't related. Me, in the team channel: "Uh. Has anyone actually looked at what comes out the other side of PDF extraction?" AI Lead: "...No. Why?" I sent a screenshot. Nobody replied for a while. A PDF looks like a document to a human because a human's eyes fill in the layout — the columns, the spacing, which number belongs to which row. To a naive extractor, a PDF is just characters scattered across a page with x-y coordinates. It has no idea "5.5%" and "Senior Citizen FD" are supposed to be read together. It just knows they happened to be near each other on page 4. If the extraction was garbage, everything built on top of it — chunking, embeddings, retrieval — was g

When I started learning programming, I believed my future as a developer depended on one thing: How...

Part 1 of "Multi-Agent Systems in Production: What They Don't Tell You" — a four-part series...