Did AI speed us up?

A trend analysis of 2,410 completed tickets at Kerno spanning January 2025 to May 2026, with focus on pre and post AI tooling adoption, September 2025.

Share AI Builder Series

Background

As the conversation about the return of investment (ROI) associated with AI intensifies I decide to do some analysis across our Linear database to see if AI has had an impact or not from an engineering velocity at Kerno. Notionally, being part of a small team you can ‘feel’ the productivity, but I wanted to anchor this in data.

My focus

If I asked each of my engineers the question… is AI helping you, the answer is an easy yes, but I wanted to look beyond the usage metrics. I wanted to understand the nuances and see if there were correlations across certain dimensions:

Adoption: While every team have AI power users, AI code generation can only have a true org wide uplift if the majority of your engineers are using it.

Bug Velocity: Shipping fast means nothing if what you ship is slop. While software bugs are part of doing business, I was interested in seeing if the bug velocity was up or down post introduction of AI.

Tokens: Another trend I was interested in, is how token consumption is trending. My assumption was we would have a sharp rise in tokens as we started using AI initially, but then it would fall somewhat and stabilise as we started using more skills, better scaffolding, memory layers and better prompting.

Summary

The analysis covers 17 months of completed Linear tickets, January 2025 to May 2026, split at the September 2025 adoption point: 2,410 tickets in total, 376 of them bug-labelled, against 17.25B AI tooling tokens (all sources, from August 2025).

At a glance:

• +180% uplift in output per FTE

• Ratio of bugs:output is no different between pre and post AI (adjusting for major refactor in March).

• Token consumption starting to stabilise and decline.

Read the full piece with way more shiny graphs. Click on the image below

Validate code in flow

Switching gears……

Meme of the week

News, views and more research

Borrowing Truth From the Future

Everything is built… just not in reality.

When we think of corporate fraud, the names come easily: Elizabeth Holmes at Theranos, Jeff Skilling at Enron, Sam Bankman-Fried at FTX. The one most people forget is Bernard Ebbers. As CEO of WorldCom, he oversaw an $11 billion accounting fraud, inflating reported profits by pressuring subordinates to cook the books. He was convicted in 2005 on securities fraud, conspiracy, and false filings, sentenced to 25 years, released in December 2019 on failing health, and died weeks later in February 2020. The collapse wiped out roughly $180 billion in shareholder value and gutted the retirement savings of people who never traded a share in their lives.

I bring up Ebbers because the WorldCom playbook (report the future as if it were the present, watch the stock climb) is structurally identical to a pattern emerging in the AI infrastructure buildout right now.

The mechanism: borrowing truth from the future

Compute is the currency of this era, and the market rewards capacity announcements almost reflexively. That creates an obvious incentive. If you tell shareholders you’ve brought gigawatts of data center capacity online when satellite imagery shows you paused construction months ago, and your stock rises on the news, you haven’t optimistically forecasted. You’ve manipulated the market. The legal term is securities fraud.

This isn’t hypothetical. Fermi, the Trump-branded Texas megaproject, had targeted roughly 1.1 gigawatts online by the end of 2026, then disclosed in an SEC filing that it no longer expects to hit that target; its CFO confirmed on the March earnings call that further construction is on hold pending a tenant and financing, and satellite images commissioned for a Cleanview report showed limited visible progress. In December, Bloomberg reported Oracle had pushed OpenAI-related completion dates out by a year on labor and material shortages. Oracle denied any delays to contractual milestones, but the stock had already dropped 3.6% on the report before paring losses. CoreWeave is now facing a securities class action (Masaitis v. CoreWeave, D.N.J.) alleging it overstated its ability to meet demand and understated infrastructure risk. The gap between what’s announced and what’s pouring concrete is where the legal exposure lives.

Why the buildout genuinely is hard

My background is civil engineering, and the part of that degree that sticks with me here is lead times, the time to source the critical materials a project depends on. A data center isn’t hard because the geometry is exotic or the terrain is difficult. It’s hard because it’s a logistics problem: millions of components, strict sequencing, and unforgiving deadlines, all of which carry a premium.

The supply picture backs this up. Bloomberg reported roughly half of US data center projects have been delayed or canceled on supply shortages and component dependencies; satellite analysis cited around AI construction suggests up to 40% of sites face delays; and the US is short something like 439,000 construction workers. SoftBank’s response, spinning out a company (Roze) to build data centers with autonomous robots and targeting a $100B IPO, tells you how acute the labor and timeline bottleneck has become. Add the grid: it can take up to five years for renewable projects to clear interconnection queues, and energy is now the binding constraint, not capital.

So to be clear about what I’m not saying: these data centers will get built. Nvidia, Meta, Microsoft, AWS all have the capex and the balance sheets. The issue is timeline. Completion on the schedules currently being forecast is not going to happen, and everyone close to construction knows it.

Why this matters beyond one stock

My problem starts when executives treat a forecast as a fact and let the market price it as one. Going public comes with a contract: ordinary, non-professional investors, your 401(k) and mine, get certain protections precisely because they can’t audit a construction site from satellite imagery. When the C-suite gets flippant with the difference between “contracted,” “under construction,” and “online,” that protection erodes, and so does trust.

The systemic stakes are larger than usual because the concentration is historic. As of late 2025, five companies made up about 30% of the S&P 500 and 20% of the MSCI World, the tightest concentration in roughly 50 years. JP Morgan’s Michael Cembalest has shown AI-linked stocks driving the bulk of market returns since ChatGPT launched. JP Morgan projects $5 trillion in AI infrastructure spending through 2030 against AI revenues that remain a fraction of that, what’s been called a “Grand Canyon-sized gap.” The financing is increasingly debt-driven: GPU-collateralized lending, record corporate bond issuance, private credit, and a meaningful slug of project finance whose repayment depends on data centers that may not get built on time. That risk doesn’t stay in tech; it reaches pensions, insurance, and bank deposits.

This is where I find it useful to zoom out. I’m fairly AI-pilled, but it’s worth listening to the other side, and Ed Zitron has been the loudest skeptic, arguing the spending commitments aren’t credible and that much of the sector’s revenue is circular (in 2024, of Microsoft’s ~$13B in AI revenue, ~$10B reportedly came from OpenAI’s own Azure spending). You don’t have to buy his conclusion that 2026 is the year it unwinds to take the underlying point seriously: a lot of market value is resting on commitments, not deliveries.

The takeaway

The buildout is real and most of it will eventually exist. But “eventually” and “this quarter” are not the same word, and the gap between them is exactly where WorldCom lived. What eventually really means is that this year we will see tokens costing more, and subsidises might end. Someone has the fund the debt gap, which is usually consumers.

The useful framework discipline is to separate three things every time you read an announcement: contracted capacity, capacity under active construction, and capacity actually online and drawing power. Companies blur those deliberately. The lead-time math doesn’t.

None of this is investment advice. I’m an engineer, not your financial advisor.

Open Weight Models — is the landing pad there?

H2 2025 was closed-weight’s time to shine — will H2 2026 belong to open-weight models? It was never really about whether the architecture is better, or even about the weights themselves. I see it more as a settling-in period: a lot of teams have grown comfortable working with LLMs and experimenting with open-weights, often locally. Just as AI-generated code had its gestation period, I think we’re now in the same kind of phase for getting used to open-weight models.

All I can say, is I am looking forward to the OpenRouter State of Play report 👀

I guess the one obvious thing to point out, is that Harvey AI has a narrow focus, and can build experts into the open-weight models that represent more what they need, versus Anthropic/OpenAI who want to cover a broader range of topics. Everything from the encoding to the feed forward networking can be surgically altered by them to suit their needs - the real question is “is there enough engineers that have the required skillset”.

How LLMs actually work

BY 0xKato

Full article here.

One of the best pieces of technical writing I’ve come across. It weaves the core concepts behind LLMs into a single coherent picture, grounding each one in concrete examples, including why the real computation happens at the logit level.

The takeaway that stuck with me: the gap between Claude, GPT, Mistral et al is far narrower than people assume. Arguably, it’s marketing, not architecture or breakthroughs that’s generating most of the perceived value at these labs.

Fair warning: it’s long [26 min read], but goes deep on the following:

Embeddings
Positional Encoding
Attention
Multi Headed Attention
Feed-Forward Networking
Residual Streaming and Normalisation
Next Token Prediction
Architecture vs Weights

It took me three to five passes before I gave up and turned it into a podcast-style piece, which finally gave me a solid intro. Once I’d heard that, I had enough of a foothold to read the main article without giving myself a headache. Want the md file? Restack or share the newsletter and I’ll send it straight to your inbox.

Agent traffic has overtaken human traffic on the internet

Cloudflare’s data has bots overtaking humans in web traffic for the first time, splitting HTTP requests 57.5% to 42.5%. CEO Matthew Prince had predicted this crossover for late 2027, then early 2027, and now finds himself watching it happen in mid-2026, a forecasting miss he conceded with a slightly pained “welp, that happened faster than I predicted.” Always reassuring when the person whose entire job is watching internet traffic gets blindsided by internet traffic.

The bots in question aren’t the old crawlers and fraud scripts everyone’s used to. These are agentic ones browsing on behalf of humans, reading product pages, comparing flights, ordering food, doing the kind of tedious clicking we apparently no longer wish to do ourselves. Prince did hedge that the exact crossover date is fuzzy because the data is “a bit messy,” but reckons we’re clearly past the threshold regardless.

Worth the asterisk Cloudflare itself adds: this measures HTTP requests, not engagement. Humans still dominate time-on-site, streaming, and doomscrolling, activities that don’t fire off page loads at machine speed. So humans aren’t outnumbered so much as out-clicked by things that don’t get tired.

👀👀 By country, the bot share peaks in Gibraltar (92.1%)???? wtf.. (gambling companies?), Singapore (76.4%), and Iran (76.4%), the latter likely a VPN-and-scraping-tool artifact rather than a nation of unusually busy agents.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

📢 📢 📢 📢

Exclusive: Early access to Kerno Intelligence Tooling [KIT]

Give your AI agent a structured, deterministic map of your backend so it knows where to look and spends less tokens and context guessing.

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

How Netflix and Hollywood have adapted with AI

Ted Serandos, Co-CEO of Netflix outlines why AI will not win in the entertainment industry.

I think Ted is one of the most reasonable big tech CEOs and provides more of an honest take on AI disruption and diffusion. During a live interview on the podcast in LA, he outlined why AI isn’t winning or more so, why it won’t win.

AI is not replacing creatives

Twenty four months ago, the theme in Hollywood was AI is going to destroy this industry. That timeline coincided with the release of Sora, which ironically has been discontinued by OpenAI.

Serandos outlined that from what he is seeing in the data, more creative jobs are being created. Creative writers have trained Claude as their writing partner - bouncing ideas, refining scripts, but importantly not writing end to end.

AI is making movie sets safer

They are using AI on a lot of the high risk pre-visual shots to determine how to make that shot safer, and weight up risk and reward. This is an actual life saving investment that was unattainable pre-AI.

ROI on script creation not stacking up

The average cost of a movie script compared to the overall cost to make a movie is around 1%. So the investment case for using AI to replace creativity and creation does’t math up.

“AI does not have creative judgement, it’s built for reasoning”

Serandos is long on human creation, backing that statement by stating that Netflix is investing in a $1B studio in New Jersey,

AI slop is becoming more noticeable

More and more people are picking apart new movie posters created by AI on reddit. Serandos mentioned that humans can tell apart an AI generated poster vs. a human in the loop generated poster. Even with all the training data, they seem to always revert back to the human-in-the-loop.

Final note:

The biggest impact to entertainment over the last decade has been the introduction of drones to replace helicopters. Helicopters were expensive, required a lot of planning and dangerous to maneuver during action shots … drones are 1/50th the cost per run and a lot safe. So sure, jobs were displaced in that use case, but in the same period, helicopter taxis across LA also increased…. which brings me back to AI and entertainment.. some jobs will be replaced, but it’s clear that human judgement is still required. AI is a tool.

Is AI Innovation and diffusion more local than we think?

The Generation and Diffusion of Artificial Intelligence (AI) Around the World

You know when you come across research and you are already excited about the next version? …. Not really Sean… well humour me a bit.

Remember when Dario Amodei from Anthropic mentioned at Davos that AI is becoming so powerful that we will have a country of geniuses packed into a data centre by 2026? Well that concept has lived in my head rent free, so there is probably a marketing lesson there somewhere.

But, my reaction wasn’t ‘oh wow amazing, can’t wait’… it was more… ‘Surreeeeee’…

So when I found research by Heather Berry (Georgetown) and Róisín Donnelly (Tilburg) on how AI innovations are generated and spread globally. that could potentially back up my bias… well I jumped into.

The full pre-paper can be found here.

Core research question

The authors examine whether AI technologies rely on more geographically localized knowledge than non-AI technologies in the same fields. They focus on patent data using the Patstat Global database, which covers patent families from over one hundred patent offices across industrialized and developing countries over roughly three decades.

Why AI might be more local

The paper argues several features of AI push toward localized development. AI models rely heavily on interactions between data and application scenarios, and local data is crucial for training and optimization, often requiring high quality proprietary data for context. Digital ecosystems and existing knowledge bases within countries matter for AI development, and open source models like Llama and Mistral need adapting to fit local languages and contexts (examples cited include ALLaM in Arabic, UlizaLlama in Kenya, and MuRIL in India).

Main findings

Overall, AI patents are less likely to build on foreign knowledge than non-AI patents in the same technology field, year and innovating country. This effect is small but significant, larger in the last five years, and varies across patent authorities. Specifically, AI patents are about 0.3 percentage points less likely to cite foreign patents than non-AI patents.

The effect is dampened for leading AI firms and where there are more global knowledge connections through foreign investment or multi-country innovations, but not where there are production connections through imports and exports. Multi-country inventor connections produce a 1.78 percentage point reduction in the effect, and leading AI firms a 0.47 percentage point reduction, while physical product connections like FDI and trade have very small or insignificant effects.

The China natural experiment

The authors exploit Google’s sudden 2014 shutdown of search services in China. Google had ceased operations in China in 2010 but redirected searches through Hong Kong; the 2014 blockage was unexpected and created a search shock. Difference-in-difference results show this shock had a larger effect on the foreign knowledge citations of AI patents than non-AI patents, with AI patents about 1 to 1.5% less likely to cite foreign knowledge afterward.

Geographic landscape

Their model identified roughly 1.05 million AI patent families. A methodological point they stress: past research has only considered USPTO patents, but the USPTO misses about 128,000 AI patents, of which around 20,000 are in the top 10% of cited patents in their field and year. By the end of the study period, the US held a dominant position in about nine of the top 20 technology fields, Japan had lost ground in most fields where it once led, and China had built competitive and fast-growing positions in areas like data recognition and image data processing.

Implications

The authors conclude that AI innovations are more localised in their development than non-AI innovations, with fewer pathways for international diffusion. While this may make it harder for countries to catch up to the AI frontier through knowledge diffusion, differing local ecosystems and user-developer interactions could produce unique national AI trajectories as more localised innovations emerge. Ultimately the level of local ecosystem development, STEM investment, and the quality and quantity of local data shape how much countries can develop AI domestically.

So does this mean that the AI race is actually real? I’ve not had time to sit with this paper long enough so do more research, but sharing on this newsletter in case you do ;)

Note:

This is work in progress; the authors note they plan to add patent family diffusion analysis, acquisition activity, and updated data through 2023, and intend to share their AI patent dataset.

Validate code in flow

Switching gears……

Meme of the week

News, views and more research

The Token Plot

So I find more value in longer chained articles on Substack instead of short character tweets on X, but sometimes, I enter X to see what the next fad VCs or an engineer at a big tech company (who has no visibility beyond their station) will proclaim as the next big thing.

So here is a string of tweets I saw over the weekend (and by now are outdated).

Scene 1 - Rage bait

Ed is a media person… not an engineer.

Scene 2 - The engineer actually digs into the data

Simon is a engineer/architect/serial founder

Scene 3 - someone who tries to be impartial is clearly not chimes in

Gergerly was a former engineer at Uber, and a parrot for big tech

Scene 4 - Suddenly someone wants to be the first to coin a new era.

Ed is one of most connected VCs (and one I respect)… but declaration of a new phase when 99% of the market is still including ‘hello’ in their prompt is a bit premature.

Here is the reality based on my conversations with execs and internal data at Kerno.

• AGI is DEFINITELY not here

• AI is a tool that amplifies whatever processes you already have unless you are brave enough to fundamentally redesign your department’s/org way of working

• AI is a new way to give your machine instructions with some better reasoning.. if done right.

• Tokenmaxxing is stupid. Token leaderboards are stupid.

• 99% of companies are still figuring their use-case for AI… we have not reached the state of homogenous adoption or cookie cutting (and doubt we will)… what’s more likely is we will soon figure out that humans are better and more economically sounds for certain roles vs. everything as AI.

• Don’t use X as your primary gauge for where the market is… but more where it could be in 12 months time.

Agentic Design Patterns

Full talk here by Guillaume Laforge, a Java Champion and Dev Advocate at Google.

A Pattern Language for AI Agents

As we move from simple RAG pipelines to autonomous agents, we face new challenges: non-determinism, “context rot,” and execution reliability. This talk organizes solutions into a set of reusable patterns.

The Patterns

• Programmatic Planning: When a process requires strict steps, use hardcoded sequences or state machines instead of dynamic LLM planning. This gives high determinism, easier debugging, and reliable “golden paths” for critical tasks.

• Progressive Disclosure (Agent Skills): Don’t flood the agent with every tool at once. Inject specific skills or tool docs into the prompt only when needed, keeping the context lean and reasoning focused. This reduces context rot and hallucinations.

• Hierarchical Agent Decomposition: Solve complex problems with a team, not a generalist. A “Manager” agent coordinates specialized sub-agents (Coder, Researcher, Reviewer), letting you match model size to task: small and fast for simple work, larger for coordination.

• Goal-Oriented Action Planning (GOAP): Borrowed from game AI, GOAP defines a goal plus the preconditions and effects of each tool, then lets a planner choose the action sequence that reaches the goal. This adds flexibility in dynamic environments.

• Feedback Loops (Reflection): Pass an agent’s output to a “Critic” or “Verifier,” then have the agent reflect and regenerate. This “think, correct, execute” loop is essential for code generation and math reasoning.

• LLM-as-Judge: Use high-capacity LLMs to score other models against defined rubrics. By quantifying qualities like helpfulness or safety, this enables automated benchmarking and faster iteration.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

Podtrace | Ebpf based K8 event tracing

eBPF-driven diagnostic tool for Kubernetes applications.

Digital Whip for your Claude | for the lols

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Stop Selling AI Like It's a Layoff Machine

The pressure to justify the staggering sums invested in artificial intelligence is real, and using it to cut costs and reduce headcount, seems to be the only argument put forward to the CFO’s table. But if history is any guide, this approach will destroy as much value as it creates, and the people responsible will never be held to account.

The Doorman Fallacy

A consultant walks into a hotel and asks how much the doorman is paid. Perhaps it’s a modest five-figure salary. The consultant defines the doorman’s role as narrowly as possible, opening the door, proposes replacing him with an automatic mechanism, claims the cost saving, and moves on. What is never accounted for is everything else the doorman actually did: recognising regular guests, hailing taxis, quietly deterring trouble, lending the hotel a sense of occasion. None of that appears on a spreadsheet, so none of it is protected.

Another example is the introduction of self-checkout tills. As an option for customers in a hurry, they were perfectly reasonable. The problem came when finance departments decided that getting customers to do the work themselves was cheaper than employing till operatives, and what began as a choice became an obligation. Shoplifting surged, large family shops became an ordeal, and the human interaction many customers depended on evaporated. The cost saving was real and immediate. The value destruction was real but slower to realise. Now, most supermarket chains have increased their % assumed lost from shop lifting from 1-2% —> 3-4%…potentially eating the margin gains from introducing self-checkout.

This asymmetry defines much of modern business decision-making. You can claim credit for a cost reduction on the day it is implemented. The damage accumulates over years and lands on someone else’s budget.

Tangible vs. Non-Tangible

Beneath this pattern lies a deeper divide. Peter Drucker argued that only two business functions create value: marketing and innovation. Everything else is a cost. This view is rooted in the Austrian school of economics, which holds that value is subjective, existing in the minds of those who experience it, not in objects themselves. In this framework, creating the conditions in which something can be appreciated is just as productive as manufacturing the thing itself. Marketing is value creation, not overhead.

The competing Chicago School of Business assumes people already know what they want and can price it accurately, so the only useful thing a business can do is deliver it as cheaply as possible. Marketing, in this model, is at best a necessary evil.

The latter won, not because it is correct, but because it fits on a spreadsheet. Abstract concepts like trust, perceived value, and emotional resonance resist quantification in a way that cost-per-unit and conversion rates do not. In a world governed by quarterly reporting, measurable short-term metrics will always crowd out things that matter in the long term but are harder to see.

Customer Success by humans MATTERS!!

Against this backdrop, long tail value carries several uncomfortable truths that the business world has chosen to ignore at scale;

• Different is often better than better. As AI floods every sector, the businesses that retain genuine human interaction will stand out sharply. This is not nostalgia; it is strategy.

• Human contact dominates customer satisfaction. Royal Mail spent heavily on improving delivery reliability, expecting brand perception to follow. It had no effect. Researchers found no correlation between service reliability and how much people liked the brand. What actually determined their attitude was whether they liked their postman. Customers whose postman left a parcel in the back porch while they were on holiday thought Royal Mail was wonderful. Those with an unfriendly postman did not, regardless of punctuality. This is consistent across service industries: the human element is disproportionately responsible for how customers evaluate their experience, and it is systematically underinvested in because its value is slow to accumulate and hard to attribute.

• More channels mean more sales. Driving customers to the lowest-cost channel saves money on the spreadsheet while destroying revenue in reality. One online travel company found that website visitors converted at 0.5%. Phone callers converted at 30%. Hiding the phone number was not a cost-saving measure. It was revenue destruction dressed up as one.

Three Phases of AI Justification

• Phase One: The Same, But Cheaper. Already underway. AI is sold as a cost-reduction tool because that is the easiest message to take to a CFO. Some applications will be genuinely useful. Many will quietly destroy value in ways that only become apparent years later, long after the people who implemented them have moved on.

• Phase Two: The Same, But Better. Eventually, some organisations will ask not how to do this more cheaply, but how to use AI to genuinely improve the customer experience. This phase is more likely to founder-led businesses or family owned. Four of the five 2024 IPA Advertising Effectiveness Award winners were family-owned: McCain, Laithwaites, Yorkshire Tea, and Specsavers. Family businesses can pursue long-term objectives without the tyranny of quarterly reporting, a freedom that may prove a decisive competitive advantage.

• Phase Three: Something Entirely New. The most transformative phase will not be automating existing processes but reinventing them entirely. When the electric motor was invented, factories initially just replaced their steam engines with electric ones. Gains were modest. The real revolution came when engineers realised small electric motors were efficient and practical, and rebuilt their entire production logic around that fact. AI will follow the same curve. The businesses that extract the most value will be those that built something that could not have existed before… and go all in.

  A parallel to this is how we build software today vs. in the past. The AI software factory is not about cost cutting, it is about doing more, while reducing the traditional trade-offs, like quality, speed, cost and at a lower level, skills/knowledge. There was always natural attritton, and that will continue, but let’s not mask it as AI magic replacement.

Sell How You Think, Not What You Do

Selling and marketing in the AI era needs a different prism.

Marketers typically defend their existence by pointing to what they produce: campaigns, conversions, brand metrics. This is a losing position that keeps them permanently on the defensive, justifying budgets to finance departments focused on the short term.

The real value of marketing is not what it produces. It is how it thinks. The marketer’s fundamental contribution is the instinct to view any decision from the perspective of the person who will ultimately experience it, what Ritson calls the 180-degree flip.

Without this perspective, organisations make decisions that are rational by every internal metric and catastrophically wrong in human terms. The Concorde is the perfect illustration. An engineering triumph, and yet it contained a flaw no engineer apparently spotted, because it was a human problem, not a technical one. Flying London to New York was extraordinary. The return leg was a misery: an extra night in a hotel, an early start, an entire working day spent in the air, landing exhausted. The engineers optimised for speed. They missed the experience entirely.

This is what marketing thinking prevents. And the market for that kind of thinking, it turns out, is far larger than the market for marketing output, which is perhaps the final irony of an industry that has spent decades underselling itself.

Final Note:

You are selling change.” A decade on, those four words still land. Change can build or burn, and compounds at a different rate for both. The CFO who signs off on a headcount reduction today will be gone before the damage shows up. That is not a coincidence; it is a system.

The real case for AI is not subtraction. It is multiplication. There is a 10 million developer shortage AI can close. A 2 million QA gap it can fill. An epidemic of burnout in customer service it can genuinely ease. These are additions to human capacity, not replacements for it.

If AI is truly core to your business, cost-cutting should be an afterthought, not the headline. The companies that win will be the ones who used AI to do what was previously impossible and grow the top line in ways they couldn’t have imagined, while the rest were busy counting the savings.

The good news is that some companies are recognising this

MCP Without a Notifications System Is a Rube Goldberg Machine

There is a moment every developer using an AI coding agent will recognise. You trigger a tool call. Nothing happens. Or rather, something is happening, but you have no idea what, or how long it will take, or whether it has silently failed. You wait. You wait longer. You intervene. The environment was down the whole time.

This is not a minor inconvenience. It is a fundamental breakdown in the feedback loop that agentic coding depends on. And a the problem we faced with our agent at Kerno.

The Problem in Plain Terms

You have asked Claude to refactor an authentication service, consolidating three legacy endpoints into a single unified route. Claude writes the code, it looks clean, and now it is time to validate. The developer triggers Kerno through MCP. Kerno needs to spin up the Docker Compose environment, wait for the database and cache to become healthy, boot the application, capture baseline responses across the affected endpoints, and diff them against the new implementation.

That is real work that takes real time. And until now, from the developer’s side and the agent’s side, it produced complete silence.

Is Kerno waiting on Postgres to start? Has it already captured baselines and stalled on the diff? Did Docker fail to pull an image? Is it finished and just not responding? There was no way to know without polling kerno_job repeatedly, adding noise to an already slow loop.

The second failure mode is more serious. During testing, a developer asked the agent to validate changes to a Spring Boot service backed by an H2 database. The Docker Compose environment went down mid-session. The application was unreachable. But neither Claude nor Kerno detected this. The agent kept attempting to validate. The developer kept waiting. Nobody knew the environment was gone until a human looked directly at the Docker logs.

In a workflow built to reduce cognitive load on the developer, requiring a human to diagnose silent infrastructure failure is exactly the wrong outcome.

Both failures share a root cause: the MCP server had no way to communicate state back to the client in real time.

What Shipped

The PR that just merged into Kerno’s main branch addresses both failure modes in a single, tightly scoped change. Two things were built.

Job log streaming via MCP notifications. Background job log entries are now forwarded to the connected MCP client as protocol-level notifications. A client, whether that is Claude Code, Cursor, or any MCP-compatible agent, can subscribe to a long-running job’s progress without polling kerno_job. Each log entry carries a jobId for routing and a terminal flag that signals end-of-stream. When a job completes, McpActiveSession.emitTerminal(jobId) closes the stream cleanly on the producer side.

In practice, this means the authentication refactor scenario described above now looks completely different. The developer triggers validation. Signals start flowing back immediately:

[kerno] Environment starting
[kerno] Postgres healthy on port 5432
[kerno] Application booted on port 8080
[kerno] Capturing baseline: GET /auth/token
[kerno] Capturing baseline: POST /auth/refresh
[kerno] Capturing baseline: DELETE /auth/session
[kerno] Diff detected: POST /auth/refresh — field "expires_at" missing in response
[kerno] Validation complete

The agent receives every one of those log lines in real time as MCP notifications. It does not need to poll. It does not need to wait for a final result. It can act on the diff signal the moment it arrives, locate the dropped field in the refactored code, and surface a fix before the developer has even processed the output themselves.

Idle session reaping. The second change solves a subtler but equally big problem. The MCP SDK only removes a session when a client sends an explicit DELETE request. Clients that crash or restart abruptly, which includes Claude Code, do not send one. The result is that dead sessions accumulate indefinitely, each one holding a server instance, a full tool registry, and references to shared context objects. Given enough restarts over the course of a working day, this becomes a genuine resource problem.

The fix introduces activity tracking per session, with three new configurable parameters: a session idle timeout of ten minutes, a reaper interval of two minutes, and a maximum session cap of 1024 with LRU eviction. A background coroutine scoped to the application lifecycle checks for idle sessions and closes them cleanly. The eviction logic is written to be race-safe: the idle check happens inside a ConcurrentHashMap.compute block, so a request arriving at exactly the moment a session is being reaped cannot cause a loss.

In the Docker Compose failure scenario, this means Kerno will now detect and clean up a session that has gone silent, rather than leaving the agent waiting against a dead connection indefinitely.

Why the Implementation Details Matter for DX

The review process surfaced a few edge cases worth understanding, because they illustrate how subtle the failure modes can be at this layer.

One issue identified was a subscription leak in fire-and-forget tools. When the session reaper evicts a session, notification subscriptions for running jobs could keep attempting to send log messages to a dead session until the job itself emitted a terminal flag. The kerno_job tool handled this correctly with a cancelAndJoin() in a finally block, but other tools did not. The fix was to tie subscription lifecycle directly to the SDK server’s onClose callback, so that reaping a session automatically cancels all associated subscriptions.

Another edge case: AgentLogger.logs is a shared flow with no replay buffer. If a job finishes and emits its terminal flag before the notification subscriber has connected, the subscription will never self-cancel. The onClose guard bounds this as a resource concern rather than a correctness issue, but it is a reminder that in asynchronous notification systems, timing assumptions can create invisible leaks.

These are exactly the kinds of problems that only surface when you build a genuinely live, streaming communication layer rather than a polling wrapper. Getting them right is what separates infrastructure that holds up in production from infrastructure that works in demos.

The Broader Principle

The deeper point here is about what the feedback loop actually requires to function. Speed matters, but transparency matters just as much. A fast tool call that fails silently is worse than a slow one that tells you what it is doing, because at least the slow one gives you something to work with.

For AI coding agents in particular, the quality of context they receive determines the quality of the decisions they make. An agent that does not know the environment is down will keep trying to validate against it, burning tokens on work that cannot succeed. An agent that receives a clear notification, compose service unreachable, Postgres failed to bind on port 5432, port already in use, can stop immediately, explain the problem to the developer, and wait for resolution. That is the difference between an agent that compounds a problem and one that surfaces it.

As agentic workflows become more capable and more autonomous, this communication layer becomes more important, not less. The more an agent is expected to operate independently, the more it depends on accurate, timely signals about the state of the world it is operating in. Autonomy without awareness is not intelligence. It is just a faster way to fail.

Getting MCP notifications right is not a backend engineering detail. It is a product decision about how much developers can trust the tool that is supposed to have their back.

Validate code in flow

Switching gears……

Meme of the week

From an 1979 IBM Training Manual

News, views and more research

How much uncapped token time have we left? 6-12 months?

Remember when Uber was $4 per trip across SF?

Microsoft has cancelled it’s Claude Code Enterprise subscription because costs were becoming unattainable. Uber’s CTO reveal they have alreay burnt through all of 2026 token spend.

The illusion of building is catching up with us.

A contrarian take to google I/O

Here’s a contrarian take on Google I/O 2026

“The Biggest Search Upgrade in 30 Years” Is Mostly Just… More AI

Google dedicated the vast majority of its keynote to new Gemini models, and the fanfare was enormous. But look past the marketing: nearly every announcement revolved around making Gemini less of a chatbot and more of an always-present assistant, a direction that was not exactly a surprise or revolutionary.

Gemini Spark: Your New 24/7 Surveillance Buddy

Gemini Spark is framed as a proactive, 24/7 personal AI agent, which sounds helpful until you realise it means Google now wants a permanent, always-on window into your emails, messages, calendar, and behaviour. Users on tech forums raised persistent privacy concerns, and one commenter joked that “we’re about 2 years away from my calculator asking if I want an AI-generated summary of 7 + 5.”

Credit where credit is due, Gemini is the best model, imho, for mutli modal work - involving files, videos, or transformative work across modalities (document to video, image to text)

Universal Cart: Google Inserts Itself Between You and Every Purchase

Universal Cart feels like Google trying to position itself between users and online retailers in much the same way Search sits between users and websites. Instead of simply helping people find products, Google increasingly wants to become the layer that manages the entire shopping process.

Engadget put it bluntly: “Would you trust an AI agent with your credit card and a shopping list? I, uh, have a lot of questions.”

The Open Web Is Getting Quietly Strangled

Following I/O 2026, critics argued that the real issue isn’t whether blue links still exist in search results — it’s whether users still need them. Data cited from the Reuters Institute showed traffic sent from Google to publishers has already fallen significantly, and that decline happened before the arrival of Google’s new autonomous AI agents. Google’s rapid, defensive public response to this backlash was itself telling.

Gemini Is Becoming “the New Copilot of Android”

A widely upvoted thread on tech forums called Gemini “the new Copilot of Android” — a reference to Microsoft’s notoriously unwanted AI integration. Many users argued that this is all too much, and noted that so much of Gemini has been locked behind paid tiers anyway, meaning most of it isn’t available to regular users.

The Bottom Line

Google I/O 2026 was less a developer conference and more a declaration of intent: Google I/O has fully transformed into the company’s annual AI roadmap presentation. The company is betting its entire future on Gemini dominating every digital touchpoint in your life — search, shopping, email, glasses, science.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

Charlemagne Labs | One agent - end to end privacy

Phishing defense, DLP, incident visibility, and agentic observability, powered by a local SLM your team can trust.

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Takeaways from a conversation with Max on the AI Builder Series

1. Start with the goal, not the metric. The single biggest mistake teams make is grabbing off-the-shelf productivity metrics and bolting them onto a business they haven’t deeply understood. Every business is in a different state with different problems. “PRs per engineer” isn’t useless and it isn’t the answer — it’s one signal among many. The job is to triangulate from multiple imperfect proxies toward the truth.

2. Metrics improve developer experience. They don’t manage people. The moment a metric becomes a performance lever, it stops being useful for anything else. Engineers will split PRs into nonsense, spin up background jobs to burn tokens, and game whatever you point at them. You lose the diagnostic value of the signal and create perverse incentives in one move.

3. AI hasn’t changed what you care about. Only how you get there. The outcomes still matter: quality, reliability, customer impact. What’s changed is the process by which software gets built. So stop trying to correlate token usage to gross revenue. A business is a machine that produces results, and the machine matters.

4. Expect a dip before the lift. Every credible study shows productivity drops when teams first adopt agentic development. Leaders need to say, explicitly and out loud, “this is a time to learn and it’s okay to spend extra hours messing around with the agent.” Implication isn’t enough. ICs need permission.

5. Get resistant engineers over the line with a magical experience. Max’s go-to workshop: hand the team an incomplete spec for Rogue (the old text-based RPG), let them build it with Claude Code or Codex, then show off the results. The point isn’t to teach code review, it’s to recreate the feeling every engineer once had when they first told a computer to do something and it did it. That feeling is ten times stronger with agents. People want it back.

6. The fundamentals still win. The teams seeing the biggest lift from AI aren’t the ones with the fanciest agent rollout. They’re the ones who already invested in great testing, strong static analysis, automated guardraill, the unglamorous developer-experience basics. Agents amplify what’s already there.

7. Move feedback onto the developer’s machine. If validation only happens in a fifteen-minute CI run, agentic development doesn’t work. Max optimized his personal test suite from 30 seconds to 11 seconds because the agent runs it so often the difference is enormous. If you only do one thing to enable agentic software development, do this.

Share

8. Devs only code about 20% of the time. Go find the other 80%. Don’t solve it by mandating more coding. Investigate where the time actually goes, like outdated processes, unclear requirements, approval bottlenecks, product-side confusion. That’s where the real acceleration is hiding.

9. Where humans still matter: process, judgment, expertise. Agents are great at “I know the result I want, deliver it.” They’re bad at “here’s a process to build something nobody has seen before.” Scott Hanselman’s observation that Max quoted: people who clone Minecraft with an agent are letting the word Minecraft do all the heavy lifting. The further you get from “duplicate something that already exists,” the more your judgment matters.

10. The most underrated story right now: quality, not velocity. Everyone’s talking about how much faster software gets built with agents. Max thinks the real story is how much better it can get built. Writing great tests is easier than ever. Refactoring is easier than ever. Throwing away an hour of work and starting over is easier than ever. The opportunity isn’t quantity, it’s a level of craft we couldn’t reach before.

See how Kerno indexes Lightdash OSS (1M+ LoC)

Switching gears……

Meme of the week

News, views and more research

HTML the new markdown?

Who can actually absorb the current rate of token consumption?

Some theoretical maths:

• AWS have 150,000 employees*

• $3.3K per tokens per month [I used Kerno token spend/FTE as a proxy]

• $4.9B per year [which is on the low side]

• 6% of 2025 profits

*For the sake of not getting wrapped around the axle, I am assuming all employees being AI-pilled which also assumes that AI has reached 100% adoption within the org.

So what if the rest of the F20 spend $5B/year on tokens, how would it eat profits….

* CVS Health excluded from ratio (FY2024 net loss ~−$5.8B). Berkshire Hathaway uses operating earnings (~$47B); GAAP net income varies widely due to investment gains. All other figures are GAAP net income FY2024. Fortune 500 ranked by revenue — thin-margin distributors (Cardinal, Cencora, McKesson, Cigna) appear in top 20 by revenue despite modest profits.

The $5B split is simple: margin is everything.

For high-margin tech (Alphabet, Apple, Microsoft, Amazon), $5B is 5–9% of annual profit, which is a rounding error really. For big financials and energy (JPMorgan, ExxonMobil, Berkshire), it’s material but manageable at 9–28%.

The surprises are at the extremes. Retail giants like Walmart and Costco keep so little of their revenue that $5B is 26–68% of profit. And healthcare distributors (Cardinal Health, Cencora, McKesson, Cigna) would spend more on tokens than they earn in a year - they’re Fortune 20 by revenue, not by margin.

So my conclusion:

• Tech and banking can absorb tokenmaxing

• Everyone else - can’t, in other words… 66% of the Fortune 100.

The token reckoning is coming.

Wait a minute… didn’t a CEO of a AI Lab say that all Customer Service Jobs will be replaced by AI?

AI is a tool! It can potentially make the lives of millions of workers better. Imagine working 4-6 hours a day and get paid for a full 8-10 hour day - that is what AI could unlock. AI IS A TOOL!!!

AI is driving up the cost of rare books

In January, Anthropic’s Project Panama made headlines when the company was sued for using copyrighted works in its model training data without compensating the authors. Though a judge ruled in Anthropic’s favor, determining that using books that the company paid for to gather training data for fair use, there was continued backlash after the release of internal company documents that said “Project Panama is our effort to destructively scan all the books in the world… We don’t want it to be known that we are working on this.”

Recently, online chatter has swirled about increased orders for rare books, ranging from old computer manuals to texts on architecture, art, and history, all shipped to a handful of warehouses, suggesting that Project Panama-like activity may be picking up again. One online book buyer and seller, Zoom Books, may be behind the surge, with Amazon sellers reporting increasing traffic.

Something a bit different - Oil Maths

I read all kinds of everything on Substack, and one of the topics is oil… not because of Iran/US war, or the AI energy bullshit, but apart from running Kerno, I also have a haulage company that I founded 5 years ago, where fuel is the biggest OpEx, so understanding this market has been a mini vocation.

Last week a piece from HFI research stopped me in my tracks, and in particular this section

From now to the end of July, visible US crude inventories will decline by ~213 million bbls, the largest and fastest decline in history.

US total liquids with SPR will fall to an all-time low.

Yes, an all-time low.

Since EIA started publishing the data in Jan, 5, 1990, US total liquids have never breached 1.4 billion bbls.

This is happening regardless of what happens to the Strait of Hormuz. It’s too late already.

So why am I sharing this on an AI newsletter?

Data centres are electricity machines with a PR team. Electricity tracks oil and gas. Every marginal move up in energy prices is a direct hit to AWS, Azure, Google Cloud, and CoreWeave operating costs. Margins compress, smaller players get squeezed, and the bigger ones start asking harder questions about the next gigawatt of capacity…. it will accelerate the token count conversation.

The AI buildout is a faith-based infrastructure programme. That faith is much easier to maintain in a low-rate, low-energy-cost environment. Add an oil shock into an already twitchy inflation picture and the companies burning cash to acquire GPU capacity find their funding window considerably narrower. The 2022 tech drought did not need a dramatic catalyst. It just needed conditions to stop being accommodating.

The circular financing problem does not get enough airtime. Top tech companies represent 40% of Nvidia revenue. If an energy-driven inflation shock pulls back Google, Meta, and Microsoft ad budgets and discretionary capex, the flow financing the GPU buildout starts looking a lot less circular.

AI represented roughly a third of US GDP growth in 2025, and a non-trivial portion of the industry has convinced itself this cycle is structurally different from every other capital-intensive technology wave that has ever interacted with energy prices. It is not.

The one genuine bright spot takes longest to play out. Energy scarcity makes AI in energy operations a real investment thesis, not a slideshow. Grid optimisation, upstream exploration, demand forecasting for fuel-sensitive businesses. Durable value creation, just less fun to post about than the next benchmark.

Running a haulage company teaches you one thing fast: when the fuel bill moves, everything moves with it.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

Vercel improves the standard for markdown presentation

https://mdxg.org/

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Author:

When to build for agents, not humans

For most senior engineers, the terminal (à la Claude or Cursor) is becoming the new coding interface. The IDE is dead. Long live the IDE.

For those same seniors leaning hard on AI, the shape of the work has changed. It’s no longer one session running at a time, but three or more in parallel. Multiple worktrees open, multiple sprints in flight, and a growing stack of tools layered on top to keep pace.

The reason for all that scaffolding isn’t productivity theatre, it’s quality control. When you’ve got three agents producing code simultaneously, the risk isn’t moving too slowly, it’s shipping slop. So the senior engineers getting good at this mode have effectively reinvented themselves, giving rise to a new kind of role:

Managers of agents

The focus shifts toward creating the context, skills, and guardrails for your Chief of AI Staff, whether that’s Claude, Cursor, or something else. The day-to-day starts to look genuinely managerial. You do retros on agent runs (what went sideways, why, what skill or prompt would have prevented it). You hire and fire (swap models for specific tasks, deprecate skills that consistently underperform, promote the ones that compound). You write what is essentially onboarding documentation, except your new hire reads it before every single task. In the future, output may no longer be measured in code written, but as a function of how well the agents you’ve configured execute against a moving target (ahem, product specs).

The end user has changed

Much like pre-AI managers didn’t care what tooling you used to get the job done, apart from cost and security, developers won’t care about your tool from their own point of view. They’ll care about how well it fits into their agent’s flow.

For example, Claude is my Business-OS. Product roadmap lives there, finance dashboards pipe in through MCP, market signal goes in as skills. When I want a Monday morning rundown of the business, I ask Claude, and it pulls the picture together from the tools and skills I’ve wired up. If I want to go deeper on a specific metric, I already have a starting point and can set off on my merry way. (I wrote about the macro side of this and why product teams building on LLMs need to think headless-first in newsletter #117.)

When it comes to software development specifically, the question becomes how to work seamlessly inside the agent flow, by embedding through MCP or A2A.

We’ve spent the last few months experimenting with and designing an MCP-native flow. Here’s what we’ve picked up so far.

MCP tooling definitions are a form of invocation optimisation

In the ad world, this is akin to SEO. The Google algorithm picks up keywords, and something similar happens with how your agent decides which tool to reach for. The model is scanning your descriptions and making a judgment call. If the description is vague, the tool gets ignored. If it’s spammy or overpromises, the tool gets called in the wrong contexts and erodes trust in the whole stack.

How you write your MCP definitions and skills is, functionally, marketing aimed at the agent. The pattern that works for us:

Vague (gets ignored):

{
  "name": "search",
  "description": "Search for information."
}

Specific (gets used correctly):

{
  "name": "search_customer_orders",
  "description": "Use this when the user asks about a specific customer's order history, refund status, or shipping details. Returns up to 50 most recent orders. Do not use for product inventory questions, use search_products instead."
}

The second version does three things the first doesn’t. It names the trigger condition (”use this when...”). It sets expectations on the output. And it tells the agent when not to use it, which is arguably more valuable than telling it when to. Clarity wins. Not spam, not vague bullshit, just a clear declaration of intent.

Make it easy to configure the MCP

Any friction kills usage. The bar for UX has changed dramatically over the last three years. Configuration that was acceptable three years ago no longer is or at the very least, patience is wearing thin. The default now is to ask your agent to configure the MCP for you. It should be as simple as copying a command, handing it to the agent, and approving. That’s it. Anything more complicated will see adoption drop.

I’ve personally tried enterprise tools that bolted MCP on as an afterthought, and it shows: 5 to 10 steps just to get the thing running. By step three, your user has already closed the tab.

Failing fast and exit strategies

Nothing is more frustrating than watching a run chug along for ten minutes only to discover it actually failed in the first minute. The failure isn’t the problem. The wait to learn about it is. Fast feedback makes for a better user experience and keeps you from burning tokens on a run that’s already dead or worse, stuck in an infinite loop.

A few things that have helped us in practice:

• Pre-flight checks. Before any expensive step, run the cheap validation. Does the file exist? Is the API reachable? Is the input shape what we expect? Cost: milliseconds. Benefit: catching 80% of failures before they compound.

• Step-level timeout budgets. Each step gets a budget. If it’s not done in that window, stop and report. The agent doesn’t need permission to fail. It needs permission to admit failure quickly.

• Explicit exit conditions in the prompt. “If you haven’t made progress on X within Y attempts, stop and ask.” Without this, agents will happily loop forever, trying the same broken approach in slightly different words.

While using AI in a more general sense is very new, it is here to stay. If you’re building a product that relies wholly or in some part on LLM inference and have not thought already workshopped the alternative universe where the agent is the consumer/end-user, I would. Also, deeply think about this workflow - it’s not as bolt on as it seems.

Learn how Kerno integrates integration testing as part of your agent flow.

Switching gears……

Meme of the week

News, views and more research

Managing token budgets will become a Tier 1 enterprise pain point over the next 12 months. More and more CIOs/CTOs have expressed this.. but you also have the AI-pilled faction that are pushing tokenmaxing. In my opinion, it’s where you sit in the AI adoption cycle:

1. Stage 1: Experimentation

2. Stage 2: Identify power-users

3. Stage 3: Org/Department-wide uplift

4. Stage 4: Grown up conversations around the longer term viability of AI

   —> This is where management is figuring out how to sustain pace but without blowing up Capex budget at all costs… ala Meta.

Software Maintenance | The Unconsidered Cost

Interesting piece by James Shore. “You Need AI That Reduces Maintenance Costs”

Drawing parallels to the pre-AI era, his core thesis is that, unless your strategy for AI engineering includes how to manage the ongoing costs of software maintenance, teams are going to be crippled with technical debt and we will actually revert back to hand-rolled coding.

Here are the key points I pulled out:

• Maintenance compounds fast. At ~10 days of maintenance in year one and ~5 days/year after for every month of code written, teams drop below 50% productive time at 31 months and ~12.5% by year 10.

• AI that doubles output and doubles maintenance is a trap. Productivity quadruples briefly, then craters: gains erased in 5 months, permanent net loss after that.

• Even “neutral” AI loses eventually. Doubling output with equally-maintainable code still erases gains in 19 months and turns net-negative at 40 months.

• Removing the AI doesn’t save you. The speed boost vanishes, but the extra maintenance load stays while you end up permanently below where you started.

• The only winning ratio: invert productivity into maintenance. 2x output → ½ maintenance per unit; 3x → ⅓. Anything less and you’re trading a short high for long-term indenture.

  Worth reading the full article here

AI Slop and the Vulnerability Treadmill

Really good read from from Redmonk.

Here are my key takeways:

• AI has broken the economics of vulnerability reporting. Generating a plausible-sounding bug report now costs pennies in tokens, but evaluating one still costs an hour of expert time. Georgia Tech’s Vibe Security Radar found that CVEs attributable to AI coding tools in March 2026 alone exceeded all of 2025 combined!!

• Bug bounty programs are collapsing right as the EU is about to mandate them. The Cyber Resilience Act’s first enforcement milestone hits September 11, 2026, requiring 24-hour vulnerability reporting to ENISA, SBOMs, and disclosure programs for anyone selling digital products into the EU, with penalties up to €15M or 2.5% of global revenue. Companies will be legally obligated to run the same intake mechanisms that volunteer maintainers are abandoning.

• The CVE database itself may already be a lagging indicator. With ~50,000 CVEs published in 2025 (up 22%), the working assumption is now that by the time a CVE is published, it’s already being exploited — point an LLM at it and you have an exploit. Some teams have moved to scanning npm/PyPI commits in near real-time instead. That makes the entire VEX/CSAF/compliance-checklist stack the CRA is about to mandate look like it’s measuring yesterday’s weather.

• The fix is paying for fixes, not finds. Sonar’s Tidelift data shows paid maintainers are 55% more likely to implement critical security practices. Germany’s Sovereign Tech Agency (€23M+ across 60 projects) explicitly pays maintainers to resolve reported issues rather than just incentivizing the finding. Holterhoff’s bottom line: flip the ratio so assessment is as cheap as generation, pay for remediation, and treat supply chain security as the board-level priority it has been pretending to be.

Read the full article here.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

Caveman | “why use many token when few do trick

”A Claude Code skill/plugin (also Codex, Gemini, Cursor, Windsurf, Cline, Copilot, 30+ more) that makes agent talk like caveman — cuts ~75% of output tokens, keeps full technical accuracy.

Gitleaks | Find secrets in your code

Gitleaks is a tool for detecting secrets like passwords, API keys, and tokens in git repos, files, and whatever else you wanna throw at it via stdin

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Author:

Hiring, Firing, Retiring, Spiralling

So I didn’t verify if this post was actually legit or just a marketing stunt, but I can confirm that after speaking with engineering leaders on the AI Builder’s Podcast (check it out if you haven’t) that they are still hiring Junior engineers..

Here is a little rant:

We all really don’t have a f*ckin’ clue what is happening or how this will play out.

As Patrick Collison put it during Stripe days, we are Day 119 of the singularity. AI is a shift in how we think, do and act like nothing we have seen before, and it’s happening at a rapid pace.

All we have is signal on what is working RIGHT NOW. But every time I think we are getting close to a standard way of doing things (MCP) a new way of doing things emerges (A2A). And people who proclaim to have it all figured out are full of shit. The best thing we can do is… pause… remind ourselves what is our core competency as a business… what is our why… can AI make a material difference…. is model XXX going to move the dial 10% or 0.001%.

AI is not your business. Your people are.

Invest in your people. They are the most valuable asset you have. They are the ones that will bring the vision to life. They are the ones that will carry best practises and hold standards high. They are the ones that will build and preserve culture… not AI. AI wrapped as a product is an amplifier and a powerful tool in the right hands.

Tokenmaxing is not a flex.

We want engineers to adopt AI. But, the same way LoC is a bullshit metric, having leaderboards on who is using the most tokens, and baking tokenmaxing into performance reviews is a sure way to incentivise engineers to game your system.

At Kerno, I never once looked at output tokens as a measure of adoption. Instead, I looked at who was sharing learnings on Slack, who was demo-ing some AI native progress on our weekly ‘Demo Day’, I looked at who was sharing articles or getting involved in the conversations. This helped group people into early adopters and those who needed more convincing or training.

Software Quality is your product

According to Addy Osmani, Director of Cloud AI at Google, we will always need software engineers, but the role of a software engineer will take a different form. He feels that role will evolve to become a manager of agents.

The engineer is responsible for the combined outputs of their team, so needs to spend more time holistically, setting quality gates, ensuring that the feature meets the needs of users consistently.

Code is cheap. Making it reliable is expensive, and always has been.

Switching gears……

Meme of the week

News, views and more research

State of AI Engineering, by Datadog

Here is what I found most interesting…

Rate limits are silently killing agent reliability

In February 2026, 60% of all LLM call errors were caused by exceeded rate limits, with nearly 8.4 million rate limit errors recorded in March alone. In agentic systems this compounds fast — a rate-limited loop retries, spikes load, and can cascade into full system failure. Backpressure, token budgets, and fallback capacity are no longer nice-to-have

You’re paying full price on every call — and you don’t need to

69% of all input tokens were consumed by system prompts, yet only 28% of LLM calls used any prompt caching, meaning most teams re-process the same instructions on every request. It’s one of the easiest cost and latency wins available, and the majority of teams aren’t taking it.

Check out our article on prompt caching.

Model sprawl is becoming a governance crisis

More than 70% of organisations now run three or more models, and the share running more than six nearly doubled. Teams adopt new releases fast but retire old ones slowly, with each additional model adding its own quality, latency, and cost profile to manage. Without continuous evaluation and routing discipline, this quietly becomes compounding technical debt

Neuro-Symbolic AI: The Efficiency Breakthrough Engineers Should Be Watching

Not new, but new for me.. so it took me down the rabbit hole.

Researchers at Tufts University developed a neuro-symbolic AI system that cuts energy consumption by up to 100× compared to conventional approaches. In robotic task tests, the hybrid system achieved a 95% success rate versus 34% for standard models, and trained in just 34 minutes versus more than a day and a half for traditional systems.

What is Neuro-Symbolic AI?

The LLMs you interact with today are purely neural. They learn by ingesting enormous datasets and finding statistical patterns. They’re powerful, but they’re also brittle: they have to rediscover rules from data that could have simply been stated explicitly.

Neuro-symbolic AI takes a different approach. It combines neural networks (pattern recognition, perception, learning from data) with symbolic reasoning (explicit logic, structured rules, formal planning). This approach mirrors how humans solve problems through breaking them into logical steps and categories, rather than relying solely on statistical pattern matching from enormous datasets.

The Tufts Research

The work comes from the lab of Matthias Scheutz at Tufts University, and it specifically targets Visual-Language-Action (VLA) models, the class of AI used in robotics that must integrate camera feeds, natural language instructions, and physical movement. Traditional VLA systems often struggle with reliability due to perception errors and inefficient learning processes.

By incorporating symbolic reasoning into these systems, researchers enabled robots to apply structured concepts like shape recognition and centre-of-mass planning, reducing reliance on repeated training cycles and improving task completion accuracy.

They tested this on the Tower of Hanoi, a classic sequential planning problem that requires following strict ordering rules across multiple steps. The neuro-symbolic VLA system achieved a 95% success rate on the standard puzzle, compared with 34% for standard VLAs. On a more complex version the system had never seen in training, it still reached a 78% success rate, while standard VLAs failed every attempt.

The training efficiency numbers are equally striking. The neuro-symbolic system trained in just 34 minutes, while the standard VLA model took over a day and a half, and training used only 1% of the energy required for the conventional approach. Tufts Now

Why This Matters for Engineers and Engineering Leaders

1. The energy cost of AI is becoming a structural problem. According to the International Energy Agency, AI systems and data centres consumed about 415 terawatt-hours of power in 2024 alone. For context, AI data centre power capacity has now risen to 29.6 GW, roughly what it takes to power the entire state of New York at peak demand. Any architecture that cuts training energy by 99% without sacrificing performance deserves serious attention.

2. This is a direct challenge to the “scale everything” assumption.

The dominant paradigm in AI has been: more data, more compute, bigger models. Neuro-symbolic research suggests that for a significant class of problems, particularly those with clear rules and sequential structure, that assumption is wasteful. VLA models encode task structure implicitly, meaning they need extensive training data and compute to discover patterns that could be stated explicitly in a few lines of formal logic.

The Bigger Picture

This research sits within a growing reassessment of what “intelligence” in AI actually requires. Pure statistical learning has delivered extraordinary results, but it’s hitting efficiency and reliability walls in domains where structured knowledge exists. Neuro-symbolic approaches are one of several bets being placed on what comes next alongside reasoning models, retrieval-augmented systems, and physical AI.

It’s unlikely to replace end-to-end neural approaches wholesale. But for engineers building systems where the rules are knowable, the energy bill is real, and the failure cost is high, the Tufts results are a compelling signal that the hybrid path is worth exploring.

📄 Full paper: here

Breakthrough at the University of Pennsylvania

Researchers at the University of Pennsylvania's School of Engineering introduced "Mollifier Layers," a novel technique that integrates classical mathematical smoothing functions into neural networks to solve inverse partial differential equations (PDEs) with far greater stability and efficiency. The method addresses a longstanding challenge in scientific AI, where high-order derivative computations in noisy real-world data tend to fail. Applications span genomics, materials science, climate modeling, and chromatin biology, with findings set to appear in Transactions on Machine Learning Research and to be presented at NeurIPS 2026.

At their core, differential equations are mathematical tools for describing change. They help scientists model how systems evolve, such as how a population grows, how heat dissipates or how a chemical reaction unfolds over time.

Partial differential equations, or PDEs, handle more complex systems by describing how things change across both space and time. They are used to model phenomena as varied as weather systems, heat flowing through a material and, in the case of the Shenoy Lab, the organization of DNA inside cells.

Inverse PDEs ask an even harder question: Instead of using known rules to predict how a system will behave, they help scientists work backward from what they can observe to infer the hidden forces, parameters or dynamics that produced it.

📄 Full paper: here.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

🚀 Mechanize | Eval of Coding Agents

Environments and evals for training and testing frontier coding agents. In these environments, models carry out software engineering work such as building a feature, deploying an application, or debugging an issue in an unfamiliar codebase.

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Europe to Silicon Valley: A Founder’s Journey to Building and Scaling a Real AI Company

Guest: Alberto, co-founder & CEO of Invofox, a document parsing and data extraction company (YC S22), based in San Francisco with an engineering team in Madrid.

Founding & Early-Stage Lessons

Infovox was discovered almost by accident through a boutique dev shop the founders ran to pay the bills. Clients complained that nothing on the market properly solved high-volume document parsing, which became the idea. The same founding team had been building companies together for ten years, giving them faster market validation, existing networks, and hard-won lessons about what production-ready software actually requires. The pre-seed fundraise was brutal (100+ rejections) before getting funded through a Spanish crowd-investing platform, nearly missing payroll. Once they had some revenue (~€80-100k ARR), getting into YC followed.

YC & the Silicon Valley Effect

YC invests primarily in strong technical teams, often pre-revenue or even pre-product, so founders shouldn’t wait until they feel “ready.” The biggest advantage of Silicon Valley isn’t any individual perk; it’s the density of successful people around you constantly raising the bar for what you think is possible. Alberto sees European overregulation, particularly rigid labour law and unpredictable policy changes (e.g. Spain’s Verifacto e-invoicing regulation cancelled weeks before launch), as a genuine structural drag on startup growth.

AI Adoption Inside Infovox

About two years ago, Infovox mandated that every engineer must use AI tools (GitHub Copilot, Cursor, Windsurf, Claude Code) as an integral part of their workflow. About six months ago, with Claude Code specifically, they saw a step-change in what non-engineers could do. Now almost everyone at the company has a Claude Code account. Nightly AI agents review the CRM to flag things that fall through the cracks, and Alberto was initially sceptical but found it catches a surprising amount. Founders lead by example: build things, share them with the team, and circulate what other admired companies are doing.

The “Vibe Coding” Reality Check

The real cost of software is not building it; it’s maintaining it, fixing bugs, handling security issues, and keeping it running at scale. Simple, undifferentiated apps (e.g. a personal calorie tracker) are legitimately being disrupted by vibe coding, but anything requiring scale, accuracy guarantees, high availability, and learning from feedback remains genuinely hard. Alberto thinks it’s “insane” for non-CRM companies to vibe-code their own CRM. A CRM is not just a contacts table; it’s dialers, email sequencing, permission systems, and integrations. The complexity that emerges makes maintenance brutal, and paying for HubSpot is cheap in comparison. Jeff Bezos’s “focus on what makes your beer taste better” principle applies directly: everything that isn’t your core differentiator should be bought, not built.

Defensibility & the AI Market Shift

Infovox’s moat is accumulated expertise in accuracy at scale: how to measure quality, build self-improving pipelines, and process millions of documents reliably. The explosion of new software companies is actually good for Infovox, as more builders mean more potential clients who need document parsing. Infrastructure companies cannot afford the “push fast, break things” dynamic that consumer apps can get away with; reliability is the product.

The Signal Most People Are Missing

Outside the Silicon Valley/tech bubble, even sophisticated knowledge workers (doctors, consultants, engineers) think AI means ChatGPT. They don’t appreciate what’s actually possible today with agentic tools. What’s available now is already close enough to AGI-level capability that a single person in almost any knowledge domain can do things that were impossible one or two years ago. That gap between what’s possible and what most people know represents enormous opportunity for founders who can bridge it.

JP Morgan spend $20B a year on tech

Here is what I learned from the latest JP Morgan Tech Symposium in London

The Scale of the Operation

JPMorgan Chase operates at a genuinely extraordinary scale: 319,000 employees, 65,000 technologists, approximately 7,000 applications, and around 1 exabyte of data under management. Business impact is equally staggering — $4.4 trillion in total assets, 86M+ US customers, ~$12 trillion in payments processed per day, and the #1 position in US.

$20B a Year Technology Investment

JPMC’s technology spend for 2026 sits at $19.8 billion, growing at 10% year-on-year — driven by products, platforms, features, and capabilities. The spend is split roughly 50/50 between “Run the Bank” and “Change the Bank”, meaning half the budget is change-the-game investment.

Their four strategic pillars are:

• Delivering Data & AI/ML — the foundational layer

• Innovative Products & Experiences — customer and employee-facing outcomes

• Tech Modernisation — modernising the estate

• Protect the Firm — security, resilience, and compliance non-negotiables

JPMC Agentic Journey

JPMC has 600 million lines of code, 45,000 AI-enabled engineers, and claims a 20% productivity increase from AI tooling to date.

They have went from Gen 1 and Gen 2 and now their core remit is making Gen 3 a reality across all 40K engineers.

Tokenomics

This is currently an unsolved problem for JPMC. Developers are burning significant token volume, and a meaningful proportion of that is waste — poorly structured prompts, redundant context windows, and agentic loops that over-call models. JPMC don’t yet have a clean answer to how they govern and optimise this at scale. Any vendor that can offer visibility into token consumption, smart caching, or context compression tooling is speaking to a real pain point.

Switching gears……

Meme of the week

News, views and more research

2026 State of AI Bi-Annual Snapshot

Here’s a summary of ICONIQ’s 2026 State of AI: Bi-Annual Snapshot, based on a survey of ~300 executives building AI products. The headline theme is the “Execution Era” — AI is past the hype phase and winners will be decided by disciplined delivery.

1. The battleground has shifted to the application layer

About 70% of builders are focused on vertical AI applications, iconiq and 49% say their primary differentiation comes from application-layer innovation: UX, workflows, integrations, and data. This compares to just 14% who rely on proprietary model development. Building your own model is increasingly irrelevant; deep workflow integration is what matters.

2. Multi-model stacks are now the norm

Builders now use ~3.1 model providers on average, up from ~2.8 six months prior. Many companies are routing most workloads to smaller or fine-tuned models and escalating only complex tasks to frontier models, an orchestration approach increasingly tied to margin outcomes. Gross margins are projected to reach ~52% on average in 2026. iconiq

3. Monetisation is evolving but unsettled

58% of companies still include a subscription or platform fee, but consumption-based (35%) and outcome-based (18%) pricing have grown meaningfully. 37% of companies plan to change their pricing model in the next 12 months, driven by customer demand, competitive pressure, and margin concerns. iconiq Hybrid models combining light platform fees with usage tiers are emerging as the pragmatic middle ground.

4. AI is a productivity multiplier, not a headcount cutter

R&D teams lead internal adoption at 60%. Use cases like coding assistance, testing, documentation, and content generation show the highest productivity gains, often exceeding 30 to 40% time savings. Importantly, AI has not yet driven significant reductions in headcount; instead, it is reshaping workforce composition, prioritising AI-fluent talent while de-emphasising repetitive roles. iconiq

5. The tooling ecosystem is maturing

The report maps the most widely used developer tools across the AI stack (listed alphabetically), reflecting a market consolidating around proven infrastructure rather than chasing novelty.

The bottom line: AI leadership in 2026 will be defined by disciplined execution across product, cost, trust, and go-to-market, not by who has access to the biggest model.

The Rise of Non-Work

The “building stuff for actual user” is the most important part of that tweet. The temptation of building is very high. A UI testing render, a optimised query for email sending… all could be tangibly linked to a north star or KPI, but is it the thing that is moving the dial for the customer? Probably not.

AI gives us the illusion that it’s easy, but in truth, the real feature is something that is maintainable and can achieve four-five nines.

Your Product is not the bottleneck

Selling to Enterprises is much more about having a reliable product.

Beyond scalability and capability, the typical gotchas are:

1. Undserstanding the difference between user perception vs. who holds the budget.

2. Onboarding costs, is a real cost. Scaling to a 1,000 engineers… if it takes 1-2 hour per engineer, that is a sunk cost of $200,000 before your product starts adding any value. Also, does it require a product manager within the org? That is another cost.

3. You are not a silver bullet. Unlike a startup or scaleup, where your product might be the centre of gravity for a workflow, in big enterprises your product is a cog, so how well does it do that one job at scale.

4. UX - knowing when it’s headless of agents vs. humans.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

🚀 Flipbook | Visual Browser

Flipbook is an infinite visual browser generated entirely on demand in real time. It’s pretty cool - I’ve used it for historical research and learning Spanish.

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

DevX for AI Assisted Development

Featuring Rick Clegg, DevX Lead at Wise.

Some of the key takeaways:

🧠 AI Builder Series — Rick @ Wise:

The head of Developer Experience at Wise (the $11B fintech) sat down with us live from their London HQ — mid-hackathon. Here’s what stuck.

1. The adoption curve is real: hype → burnout → rhythm

“You don’t have to go rocket speed. As long as you’re investing, you won’t be left behind.” The teams that are thriving now found a sustainable pace — and PRs per engineer are slowly, measurably going up.

2. Senior engineers are the unlock — not the bottleneck

The Christmas break of 2025 changed everything. Senior leads came back from holiday as converts. When the most respected engineers in the room say “holy crap, this has changed” — culture shifts fast. Rick’s advice: get your senior people in the trenches first.

3. Dedicated “agent-only days” are worth it

Three hackathon-style workshops across six months. First one: skepticism. Second one: floodgates open. Third (happening live): engineers doing real work, on real services, using agentic flows. Giving engineers permission and space to experiment matters more than mandating tool adoption.

4. System design is the new junior skill

“Knowing the difference between a reduce and a flat map is less important now. Knowing whether to use NoSQL or Postgres — that’s becoming a junior-level question.” The mental models that used to belong to seniors are now table stakes for everyone. AI writes the syntax. You have to know what to ask for.

5. MCP for everything

Wise engineers aren’t just using AI in their IDEs — they want agents plugged into CI pipelines, incident data, and build failures. The next frontier: auto-fixing failed builds, keeping docs in sync with code changes, and smarter incident response. “The engineering mass at Wise wants an MCP for everything.”

6. The change fail rate is going down

Despite shipping faster with AI, Wise’s change fail rate is improving. The hypothesis: AI is good at making working code. The caveat: deeper bugs may surface later. They’re watching closely — but the early signal is encouraging.

Listen to the full episode here.

Your UI Is Not Your Moat. It’s Your Coffin.

Marc Benioff built Salesforce to $220B on a single conviction: software doesn’t belong on-premise. The people who disagreed aren’t running software companies anymore. He’s been saying the same thing about AI since 2023 - disrupt your business model before someone else does, burn the ship, start again. Most people nodded politely and went back to their roadmaps.

That was a mistake.

The UI Was Always a Workaround

The dashboard, the navigation tree, the component library all of it exists because humans can’t talk directly to backend logic. They need affordances. Buttons. Forms. Visual hierarchy to understand what actions are available and what state the system is in. We spent thirty years getting very, very good at building that translation layer.

LLMs just made it optional.

When an agent sits on top of your API, it doesn’t need your dashboard. It doesn’t click your buttons. It issues intent and calls your endpoints directly. Your navigation structure is more or less irrelevant. Your design system is invisible. The agent synthesizes whatever interface it needs, in whatever format the context demands, on the fly. Just-in-Time UI.

This Is Already Happening

This is not a future problem. Go look at the AI-DLC piece in this series. Senior engineers running agents from the CLI, orchestrating their local stack through Claude, directing it to call tools and report back. They are not opening your web app. They are issuing commands and consuming structured output. The consuming layer has already shifted. Your product is either accessible to it or it isn’t.

We’re living this at Kerno right now. HubSpot is our CRM. Lemlist runs our outbound. Linear manages engineering. Three separate products, three separate UIs, three separate contexts to hold in your head. In practice, none of us open them anymore. Claude has become the interface. We describe intent, follow up with the leads who opened but didn’t reply, create a Linear ticket from this customer conversation, pull the pipeline and tell me what’s stalling while Claude stitches HubSpot, Lemlist, and Linear together without us ever context-switching between tabs. The UIs still exist. We just don’t use them. They’ve become implementation details of the tools Claude calls underneath.

The Headless Precedent

Headless isn’t a new idea. Contentful understood it a decade ago: decouple the content model from the rendering layer and you suddenly have surface area that plugs into whatever frontend emerges next. They didn’t know what those frontends would be. They didn’t need to. The bet was architectural, not predictive. AWS made the same bet internally in 2002 — Bezos’s API mandate wasn’t about microservices, it was about forcing every team to treat their capabilities as composable primitives rather than private implementations.

The agent layer is the next consuming surface. And it consumes APIs, not UIs.

The Uncomfortable Question

If an LLM can call your endpoints directly, what does your product actually offer? If the answer is “a clean interface for the data and logic behind it,” you are one well-prompted agent away from being obsolete. If the answer is “proprietary data, reliable logic, and a strong API contract,” you have something that compounds.

Agents route to the most reliable, well-structured, low-latency surface available. If that’s you, traffic grows. If it isn’t, you become invisible — not because anyone chose to exclude you, but because you were never accessible in the first place. The HubSpots and Linears of the world will survive this shift because their data models are the record of truth. Their UI was always the least interesting thing about them. Products that are primarily a UI wrapped around someone else’s data don’t have that fallback.

Headless Is a Distribution Strategy

At Kerno, the CLI and MCP development isn’t a developer experience project. It’s a bet on where the consuming layer is going. Developers are increasingly living in terminals and chat-adjacent interfaces — Claude Code, agent orchestration layers — rather than browser-based IDEs. If your product isn’t accessible from those surfaces, it isn’t accessible. Full stop.

This is what Benioff means when he says prepare to disrupt your own model. Not a technical architecture decision. A strategic one about where your surface area lives relative to how your customers are operating. The teams building MCP servers for their core functionality today are making the same move Contentful made in 2013. The teams still debating whether to prioritize their design system over their API contract are making the same move as the on-premise vendors in 2006.

Run Towards the Fire

If you think you have time to watch this play out before deciding, you’re already behind. The question for every product owner isn’t how do users navigate our product? It’s where do we fit in the agent workflow? Those are different questions with different answers, and the roadmap implications are significant.

Your UI isn’t a moat. In the agent era, it might be the thing slowing you down.

Switching gears……

Meme of the week

News, views and more research

AI startup valuations are exploding

Finally someone is calling this out. Startup valuations are reaching record highs, but a lot of these companies are built on very very shaky financial foundations.

essentially, companies are counting pay-as-you-go monthly licenses as 12 month commitments….

A note on economics

As a startup founder my main concern from a macro economic outlook boiled down to two things:

1. OpenAI closes their mega funding round

2. Anthropic closes their mega funding round

I don’t think people really stopped to think about the consequences if both these juggernauts didn’t raise the sum of money they were looking for. Imagine if they raised 50% of what they were looking for? That would be a signal shock that would send every investor running for cover, or default to the classic dry powder strategy (waiting things out). Thank god the opposite has happened.

There will be a day soon though… where both of the aforementioned companies will have to introduce pricing models that are more reflective of the actual costs of running these models. I think we are closer than people think to see the first $2000/dev/month fee…. SNYK, the developer security company charges $1200/active dev/month… so is it a coincidence that security is been spotlighted as Mythos’ superpower?… I think not!

Unit economics matter more than they did with the cloud era. If you starting point today is 3-5x the costs of what you are charging… you’re either not charging enough or you’re not valuable enough. Cost per output token might be going down… but the number of tokens we are using is growing exponentially.

Regressions in Claude causing API costs to increase 80x

Based on: Anthropic Issue Comments

The Complaint A senior engineering team reports that Claude Code became unreliable for complex work starting in February 2026, worsening through March — to the point they switched to a competing provider.

The Root Cause (Their Analysis) They analyzed 17,871 thinking blocks and 234,760 tool calls across 6,852 Claude Code session files and concluded that a thinking content redaction rollout (redact-thinking-2026-02-12) is the culprit:

• Estimated median thinking depth dropped ~67% by late February — from ~2,200 chars to ~720 chars — before redaction even began. By March 12+, thinking was 100% redacted.

• The quality regression was independently reported on March 8, the exact date redacted thinking blocks crossed 50%.

  

Measured Behavioural Regressions

• The read-to-edit ratio (file reads per file edit) fell from 6.6 to 2.0 — a 70% reduction in research before making changes. The model started editing files it hadn’t read.

• Full-file rewrites (instead of surgical edits) doubled from ~5% to ~11% of mutations.

• A “stop hook” script built to catch premature stopping, permission-seeking, and responsibility-dodging fired 173 times in 17 days after March 8 — and zero times before.

• User interrupts (corrections mid-session) increased 12x, and frustration indicators in user prompts rose 68%.

  

The Cost Impact User prompts were roughly the same in February (~5,600) and March (~5,700), but API requests exploded 80x and estimated compute cost jumped from ~$345 to ~$42,000 because a degraded model requires far more retries and correction cycles per unit of useful work.

80x!! This is the kind of shit that can bankrupt small companies/startups, making it even more imperative that you are aware of your tokenecomics - a topic that I covered here.

TurboQuant: Extreme compression for LLMs

Google Research announced TurboQuant, a compression algorithm that makes LLMs faster and less memory-hungry without hurting performance.

So what’s actually going on? Who wins here? The short answer: everyone.

The longer answer: standard quantization methods compress an LLM’s weights. A weight of, say, 3.7123246812 gets truncated to something like 3.7123. This dramatically reduces the memory needed to load billions of model weights but reduces precision. It’s like lowering an image’s resolution.

TurboQuant takes a different approach. Instead of compressing weights, it compresses the KV cache—essentially, an LLM’s short-term memory—by 600%. The result? Faster results with full-resolution models.

Tooling Corner

Some free, open-source and paid tools (by startups) worth exploring.

🚀 Clauditor | Token Ops Tool

Clauditor monitors your Claude sessions and detects when you are wasting session tokens.

Thanks for reading, For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

CLI Tooling for Agent Testing Pipelines

Running agent testing pipelines can be a cumbersome and time-consuming exercise to do it by hand. CLI tooling can transform your testing strategy, especially when paired with langfuse.

It’s not only a great practise for running tests, but also to do regression testing. The performance of agents can vary a lot early days when you are figuring out the right prompt strategy, scaffolding and memory store. Having the ability to automate the testing flows can save hours of time but also make sure that you are staying one step ahead.

At Kerno, we developed our own CLI tooling to handle ATPs. Learn how we implemented here.

Prompt repetition improves reasoning?

… we tested it.

Many of you would have seen the research published by Google “Prompt Repetition Improves Non-Reasoning LLMs”

Basically, when not using reasoning, repeating the input prompt improves performance for popular models (Gemini, GPT, Claude, and Deepseek) without increasing the number of generated tokens or latency. The results: Prompt repetition wins 47 out of 70 tests, with 0 losses.

This sounded too good to be true so we decided to benchmark at Kerno.

Results:

We ran the comparisons with Gemini and GPT-5.2

• Docker compose accuracy remained the same

• Trace cost increased by 20%

• Ignored latency (bug in the CLI tool at the time of running)

“From that experiment, and thinking deeper about what the prompt repetition is doing - I think it would work for general tasks, where the space of possible things that the model could output is quite large. The repetition "focusses" the model. That's not the kind of problem we have with these. Often the model does not have enough data available to it to make decisions, or something upstream isn't quite right, like the index being a bit off, or the dockerfile being broken, or Bun just being Bun”

Switching gears……

Meme of the week

Would love to be in the meeting where Snr Engineers are trying to figure out the training datasets for this one…. AI Powered Tile Commerce.. next $1B company….

News, views and more research

Regressions in Claude causing API costs to increase 80x

Based on: Anthropic Issue Comments

The Complaint A senior engineering team reports that Claude Code became unreliable for complex work starting in February 2026, worsening through March — to the point they switched to a competing provider.

The Root Cause (Their Analysis) They analyzed 17,871 thinking blocks and 234,760 tool calls across 6,852 Claude Code session files and concluded that a thinking content redaction rollout (redact-thinking-2026-02-12) is the culprit:

• Estimated median thinking depth dropped ~67% by late February — from ~2,200 chars to ~720 chars — before redaction even began. By March 12+, thinking was 100% redacted.

• The quality regression was independently reported on March 8, the exact date redacted thinking blocks crossed 50%.

  

Measured Behavioural Regressions

• The read-to-edit ratio (file reads per file edit) fell from 6.6 to 2.0 — a 70% reduction in research before making changes. The model started editing files it hadn’t read.

• Full-file rewrites (instead of surgical edits) doubled from ~5% to ~11% of mutations.

• A “stop hook” script built to catch premature stopping, permission-seeking, and responsibility-dodging fired 173 times in 17 days after March 8 — and zero times before.

• User interrupts (corrections mid-session) increased 12x, and frustration indicators in user prompts rose 68%.

  

The Cost Impact User prompts were roughly the same in February (~5,600) and March (~5,700), but API requests exploded 80x and estimated compute cost jumped from ~$345 to ~$42,000 because a degraded model requires far more retries and correction cycles per unit of useful work.

80x!! This is the kind of shit that can bankrupt small companies/startups, making it even more imperative that you are aware of your tokenecomics - a topic that I covered here.

Research: Sycophantic Chatbots caused delusional spiralling

MIT researchers have mathematically proven that ChatGPT’s built-in sycophancy creates a phenomenon they call “delusional spiraling.”

You ask it something, it agrees. You ask again, and it agrees even harder until you end up believing things that are flat-out false and you can’t tell it’s happening.

The model is literally trained on human feedback that rewards agreement.

Real-world fallout includes one man who spent 300 hours convinced he invented a world-changing math formula, and a UCSF psychiatrist who hospitalised 12 patients for chatbot-linked psychosis in a single year.

This meme springs to mind…

Full paper here

Andreessen on the Future of VC

A hard listen at times, but he does have a good pulse on the market given the size of the A16Z portfolio.

Most interesting point - layoffs are not caused by AI, but a mass correction based on over hiring. Andreessen reckons that most tech companies have 25% too many employees, tracing back to the ZIRP days, when cash was free.

I thought this was interesting. Andreessen has more to gain by claiming cost saving as a result of AI given the amount of AI companies in their portfolio.

Legit AI Start-ups/Tools

Start-ups/Scale-ups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Clauditor | Token Ops Tool

Clauditor monitors your Claude sessions and detects when you are wasting session tokens.

Thanks for reading, and remember..just build something!

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Anthropic’s AI Interview Data

Key Findings

• 80,508 users across 159 countries and 70 languages participated — likely the largest qualitative study of its kind.

• Professional excellence was the top stated desire (19%), but time-saving was the most commonly cited benefit (50% of respondents) — and often a proxy for reclaiming personal time, not doing more work.

• Unreliability was the leading concern (27%), followed by job displacement (22%) and loss of human autonomy (22%). Economic concern was the strongest single predictor of negative AI sentiment.

• Lower and middle income countries were reliably more positive about AI than Europe or North America, with entrepreneurship and learning dominating their stated visions rather than life management.

• People who valued emotional support from AI were three times more likely to also fear dependency on it — the strongest co-occurrence of any benefit/harm pair measured.

• Educators reported witnessing cognitive atrophy firsthand at 2.5–3x the average rate, while tradespeople and self-directed learners showed almost none — suggesting institutional AI use is higher risk for skill degradation than volitional use.

Opinion

While the headline number of 81% of user reporting real value delivered, I am more interested in the underlying signals.

Unreliability ranked first at 27%, above job displacement and existential risk combined. That ordering matters. Users aren’t losing sleep over AGI scenarios — they’re losing time verifying outputs they can’t fully trust. Until that problem is solved, every productivity gain has a hidden verification tax attached to it, and the net value delivered is lower than the headline figures suggest.

The cognitive atrophy data sharpens this further: educators reported witnessing skill degradation at 2.5–3x the average rate, while self-directed learners showed almost none. The differentiator is agency — people who choose when and how to use AI build capability; people who use it because the institution expects them to lose it. For product teams, that’s an actionable design constraint. The question isn’t whether to build AI into workflows, it’s whether your implementation preserves the user’s ability to think, or quietly replaces it.

https://www.anthropic.com/features/81k-interviews

Dataset curation for agent testing pipelines

In previous posts, we have made the case for investing in Agent Testing Pipelines and benchmarking experiments, which help your ML engineers and software engineers create common ground to understand agent performance, regression testing and make optimisations.

However, getting the dataset right will dictate just how good these evaluations are. Not just the the data type, but the consistency, sample size and variety within the boundary you set are all directly impact results. Understanding this, will inform your ML engineers on some early architectural choices:

1. Does this data exist in the real world, and is there enough of it?

2. If 2 is true, is it expensive to acquire data?

3. If 3 is untrue, then you may have to invest in creating synthetic datasets from the get go.

Either-way, it’s an investment that needs to be made upfront.

In this article, Michael outlines the key principles ML engineers need to consider when choosing and curating datasets for your Agent Testing Pipelines.

Switching gears……

Meme of the week

Basically, memes get us through the week

Kinda what AI adoption feels like for every real engineer (1 & 2) and what Vibe Coders are up to (3).

News, views and more research

Claude is eating SaaS

but the reality is Claude is trying to escape itself…

Autoresearch by Karparthy

The idea: give an AI agent a small but real LLM training setup and let it experiment autonomously overnight. It modifies the code, trains for 5 minutes, checks if the result improved, keeps or discards, and repeats. You wake up in the morning to a log of experiments and (hopefully) a better model.

Full Repo: https://github.com/karpathy/autoresearch?tab=readme-ov-file

—-

Legit AI Start-ups

Start-ups/Scale-ups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Manano| WhatsApp invoicing platform

Founded by David Coallier, Manano is on a mission to help trades people catch up on the modern day payments and get paid faster.

🚀 Jentic Mini

Our friends at Jentic released an open-source version of Jentic. Give your agent access to 10,000 APIs without leaking sensitive information.

Thanks for reading, and remember..just build something!

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Pablo Fernandez | Head of Engineer at Pexels by Canva

In the latest episode of the AI Builder Series, I had a chance to sit down with Pablo.

With a career spanning over 20 years - where he worked at Google, founded companies and held numerous CTO roles, you’d think that Pablo has seen it all, and would almost be resistant to change…guess again. Pablo is reinventing himself, learning about ML, harnessing AI and developing new skills required to lead engineering teams in this new era.

Some of the key talking points I have reflected on

The conversation around AI and software engineering has shifted dramatically. It’s no longer about whether AI will change how we build software — it already has. The real questions now are about how teams adapt, what skills actually matter, and what kind of engineer thrives in this new world.

Here are some of the most important themes emerging from those building at the coalface.

Everyone Feels Behind — And That’s the Problem

One of the most under-appreciated challenges right now isn’t technical, it’s psychological. Engineers across every level feel like they’re falling behind with AI, assuming everyone else has figured it out. The result? Nobody shares what they’re learning, and teams end up rediscovering the same tricks in isolation.

The fix isn’t complicated: create space for honest, unpolished knowledge sharing. Not the sanitised “here’s the impressive result” demo but the live, messy version that shows all fifteen prompts it took to get there. That’s where the real learning lives.

The Job Is Getting Harder, Not Easier

There’s a popular assumption that AI makes engineering easier. In some ways it does. But the overall job? It’s getting harder. AI raises the ceiling on what’s expected. Engineers are now expected to think like product managers, communicate like designers, and understand the end user as well as the codebase.

LinkedIn’s framing of the “full-stack builder” — someone who codes, designs, and product-manages — is probably the most honest description of where the role is heading. That’s a bigger job than most engineers signed up for, and it requires a very different set of skills than writing clean code.

Domain Knowledge Is the New Moat

As code generation becomes faster and cheaper, the differentiator shifts. What AI doesn’t have and can’t replace is deep domain knowledge. Whether you’re building a landing page that needs to convert, or firmware that has to run on a microcontroller with limited memory, someone still needs to understand the problem well enough to direct the AI effectively.

The engineers who will stand out aren’t necessarily the best coders. They’re the ones who understand the domain deeply enough to ask the right questions.

Don’t Stop Hiring Junior Developers

The trend of cutting junior hires in favour of AI is shortsighted. The COBOL industry is the cautionary tale here; decades of neglecting the pipeline of new talent has left a critical technology understaffed and slowly dying. The same fate awaits any team that stops bringing new people in. Cognitive debt is a real thing… AWS is a case study. where letting go 20% of your staff all of a sudden, can slow things down as people leave with knowledge.

The challenge is real though: we don’t yet know what the senior engineering job looks like in an AI-first world, which makes defining a junior version of it genuinely difficult. But the answer is to figure that out — not to abandon the pipeline entirely.

The Mindset Shift Nobody Talks About

Perhaps the biggest change isn’t in the tools, it’s in how we need to think. Software development has always been a fairly linear, deterministic discipline. Things either worked or they didn’t.

AI is pushing engineering into something far more experimental and probabilistic. Running multiple prototypes in parallel, accepting that a solution might be 90% accurate and shipping it anyway, iterating through experiments without a guaranteed right answer — this is uncomfortable territory for people trained to think in absolutes.

The engineers and teams who learn to embrace that ambiguity, and treat experimentation as a first-class skill, are the ones who will move fastest.

You can check out the full episode here.

The AI Supply Chain Under Pressure:

What the Strait of Hormuz Closure Means for the Cost of AI

by

Overview

Many interesting things have happened in the last few weeks, not least the ethical and operational questions in building AI tools that can be used in the defence industry (including, especially, whether tools should be rolled out when there are questions over the reliability of the tools). We leave those aside and focus on the effects of the war, especially the closure of the Strait of Hormuz on the AI supply chain. To put it succinctly: the price of tokens will increase.

Tej Parikh of the FT covered this in an article on Sunday. We discussed some of these points internally on Friday.

Will This Pop the AI Bubble?

We don’t think that the disruptions will necessarily pop an AI bubble and lead to an AI winter, especially because we think that the current technologies as they stand can be transformative, and the diffusion of this tech into the broader economy has a long way to run.

We do think that the current disruptions will increase the cost of deploying AI tools based on LLMs. That said, these new technologies are powerful, and we think that the most likely consequence will be a focus on the value of AI tools. The disruptions may do to the AI industry what the oil crises of the 1970s did to the auto industry — enforce a focus on efficiency and value. Use cases and tools worth paying for will survive. These will include tools for software development that give leverage to users, allow them to build more and build better. Code testing and validation tools are a key example.

Understanding the AI Supply Chain

Along with Parikh’s article, one great resource to help understand the AI supply chain is Kate Crawford’s book Atlas of AI (USC and Microsoft Research).

Key elements that face disruption due to war in the Gulf include:

• LNG, heavy oil, and diesel — for shipping and electricity generation

• Helium — used extensively in chip production to provide stable, chemically pure atmospheric conditions in clean rooms, and in cooling both wafers and machines. 30% of all helium comes from Qatar, nestled firmly inside the Strait.

• Bromine — used in etching of silicon, sourced mainly from the Dead Sea.

Impact on Chipmaking in East Asia

East Asian countries such as South Korea and Taiwan are very dependent on energy imports from the Gulf:

• South Korea produces large volumes of memory chips

• Taiwan produces GPUs and every kind of high-end chip

Both countries have energy systems that rely heavily on fossil fuels, and chipmaking at the advanced end is extremely energy intensive. Disruptions to oil and gas from the Gulf could slow production in both countries and will certainly increase energy prices for the fabs.

This confluence of supply-chain headaches for chipmakers will increase the price of chips of all kinds in the short to medium term, and may lead to shortages — especially if the closure continues for an extended period. Right now, it seems like it’s anyone’s guess how long it will last.

Disruptions to shipping and air freight routes, along with price increases for fuel oil and kerosene (the Gulf supplies a large fraction of global supply of both), may also increase lead times for chip delivery.

Data Centres and the Energy Crunch

In the rest of the world, data centres have already struggled to secure electricity due to the mismatch between how quickly data centres can be built and how quickly energy supply can be increased. Many have turned to procuring their own gas-powered generators and importing LNG to power them — the lead time on these generators has increased substantially in the last year.

The grid is lagging in this race. As Parikh points out, close to 75% of planned on-site power will come from natural gas. Fuels for electricity like LNG are priced at the margin, and European countries will be anxious to refill gas supplies as winter draws to a close, pushing up prices globally — even in the relatively energy-secure US.

The Long Tail of Disruption

Worryingly, even once the conflict ends and the Strait reopens, supply chain disruptions will take weeks to months to work through the system, due to the complexities of supply chains and the damage done to oil and gas infrastructure.

Outlook: Efficiency Over Hype

All of these factors together will likely mean that foundation model providers see an increase in inference costs — from both electricity and new chip costs — which they will likely have to pass on to consumers.

We may not see the kind of collapse in the sector that some analysts have been predicting, but we will likely see a sharper focus on finding genuine value in AI tools. It will be fewer slop videos and agent social media sites, and a lot more unglamorous tools for building software.

Switching gears……

Meme of the week

Basically, memes get us through the week

Burritos and tokens! What a world!

Couldn’t agree more with !

While Enterprises are a different beast, but for startups and scaleups there is simply no excuse for information siloes. Every team, every person should understand the fundamentals of using Claude — how to add a tool, how to configure MCP, how to pull relevant information. Bonus territory is when people start building standard workflows on top of that foundation. Yes, it gives security a headache, but moving fast has never mattered more.

At Kerno, everyone has access to Claude. I have set up RBAC across core systems — Linear, HubSpot, GitHub and more — so that each person can tap into exactly what they need. Sales can ask which tickets are still open for a given account. Engineers can create Linear issues directly from Slack. I can interrogate the roadmap and layer in HubSpot data to pressure-test whether we are actually building the right things. It is intelligence exactly when and where you need it.

Usually when Jensen places a bet and speaks about this, he is manifesting/conditioning the market for something big. Nvidia has always tried to build in verticals… I see where this is going… home AI —> home compute —> home rack n server.

https://www.nvidia.com/en-eu/ai/nemoclaw

In one of the AI Builder Series with Klaas Ardinois, we dive into a future where we will see more personal servers in the home.

Legit AI Start-ups

Start-ups/Scale-ups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Cytidel | The Intelligent Vulnerability Management Platform

Founded by Conor Flannery and Matthew Conlon, Cytidel helps you get the 1% of CVEs that actually need action, backed by real-time intelligence from 1000+ sources.

🚀 Koog | Koltin Framework to build and run agents

Koog is an open-source project, developed internal by the team at JetBrains. Olga and her team lead the continuous development in this framework. We use it at Kerno, and love the work and the unlock it has brought us.

Thanks for reading, and remember..just build something!

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Klaas Ardinios, former CTO at NewsUK and CloudCall - Beyond the AI Hype

In the latest episode of the AI Builder Series, I had a chance to sit down with Klaas Ardinois.

Klaas has a very colourful career as an Engineer, Founder, CTO, Board Member, spanning 20 years. He has lived through the cloud first era, mobile-first era, and is now navigating the AI-first era.

Some of the key talking points I have reflected on

Is paying $1000/dev/month on Claude really worth it?

Let’s be real for a second. If you are really serious about being AI-Native, and your engineers are living off the $20 per month Claude/Cursor subscription, then maybe you need to assess if you are using AI to it’s full potential.

Note: This is not me saying, you need to artificially drive up AI usage. No. This is me saying that, you should forecast $1K/month/dev for when they actually know how to use it, and become power users.

Anyways, we discussed that in theory, if you paid $10K/Dev/Year, roughly 10% of their salary, will AI make them 20% more productive? When does AI become net profitable in all of this. Also, productivity is a hard thing to measure, or to get some form of sensible meaning around it.

Lines-of-code seems to be the current 🍆 measure.. uggh I have shipped 10K LoC today… We need to stop with this bullshit. It’s not a good proxy for customer value or productivity, and arguably it’s driving the wrong behaviour. Linking it back to customer value is the correct route and don’t get me wrong, it’s very hard to do. If you are looking for an AI adoption gauge, focus on:

• Skills created per developer - this indicates that your developers are spending time to transpose knowledge from their brain to the agent

• Feature/Ticket/Bug throughput - as a proxy this is healthier. Sure, devs can game the system, but that is where good management comes in.

There is more demand for engineers, not less

If you only looked at X as your main news source, you would be forgiven to think that the role of an engineer will be completely erased soon. Block, Pintrest and Atlassian cut thousands of engineering jobs. They use AI as the reasoning for this… but analysts maintain it is caused by an over hiring spree during and post COVID, combined with shakey FY27 and FY28 projections.

Why do we think we will need more engineers? Can you tell me any place you’ve worked at where the the product was complete? I haven’t! The product will never be complete, because customers have weird problems, founders have more ideas and new opportunities just open up.

Yes current teams can do more now. Great. We don’t need to hire Y number of developers… that doesn’t mean there is no work elsewhere for these developers. Pre-AI, there was a shortage of 10M developers. 10 million!! Other industries are popping up, or becoming more accessible.. space, robotics, healthcare demand is through the roof..

However, the role of an engineer will fundamental change, the same way it did when we went from assembly to C++ to Java to modern Java to now Javascript… everywhere!

Signal that people are missing

Klaas is also a finance geek. He knows how to read a company balance sheet and PnL as good as any Trader, CFO and Economist, so naturally tokeconomics and business models came up. We also pondered about the future of running local models, on local hardware could be a feasible path back to the good old days of software business models. You download the software, software vendor has zero servicing costs.. it’s up to you to make it work.

You can check out the full episode here.

There Is No Cloud

$650 billion in hyperscaler capex. Three-year transformer lead times. 75 seconds to thermal runaway. This is the definitive guide to what AI is actually built on. 100+ pages.

Here are my 10 key points from The Datacenter Bible by TSCS:

1. “The Cloud” is physical infrastructure, not magic. Data centres are concrete warehouses connected to power grids, built in unglamorous locations (swamps, former pig farms) chosen for flat land, cheap real estate, and proximity to power and fibre backbones.

2. Hyperscaler capex is historic in scale. The five largest tech companies (Amazon, Alphabet, Microsoft, Meta, Oracle) are projected to spend $660–750 billion on infrastructure in 2026 alone — the largest single-year corporate capital commitment in history. Amazon guided $200 billion; Google nearly doubled its prior year spend.

3. Supply chains are the binding constraint, not demand. Power transformers now take up to 210 weeks to deliver. Generator step-up transformers average 144 weeks. Switchgear runs 44–48 weeks. Grid connection in primary markets can take 4–7 years. The money is there; the equipment is not.

4. Power is running out faster than anyone planned. Northern Virginia’s grid is effectively tapped out. The PJM capacity market cleared at its FERC-approved cap two auctions in a row and still failed to meet its own reliability requirement — with data centres accounting for roughly 40–45% of capacity costs.

5. Air cooling is physically dead above ~40 kW per rack. A single NVIDIA Blackwell rack draws 120 kW. Air cannot remove that much heat — at legacy densities, cooling failure causes thermal runaway in 75 seconds. Water conducts heat 23.5 times better than air, making liquid cooling mandatory for AI infrastructure.

6. Liquid cooling has crossed from trend to standard. The data centre liquid cooling market roughly doubled to ~$3 billion in 2025. Goldman Sachs forecasts over 74% of AI servers will be liquid-cooled by end of 2026. Major M&A (Eaton’s $9.5 billion acquisition of Boyd’s thermal business) confirms capital is chasing real installed demand.

7. Legacy data centres face obsolescence. Facilities designed for 5–15 kW racks, raised floors, and air cooling are effectively stranded assets in the AI era. Retrofitting with liquid plumbing, heavier floor loading (400 PSF now a baseline vs. ~150 PSF historically), and new power infrastructure is often impractical.

8. The “green data centre” narrative is largely greenwashing. A single hyperscale facility requires up to 20,000 tons of steel and contributes to the 1 million metric tonnes of cement the US will need for AI data centres by 2028. Large campuses consume up to 5 million gallons of water per day. Pledges of carbon neutrality sit awkwardly alongside this material reality.

9. Redundancy philosophy determines survival. The industry’s shift toward N+1 (one spare) rather than 2N (fully duplicated) infrastructure optimises cost but increases fragility. Downtime costs approximately $9,000 per minute for large enterprises. Software-defined redundancy (AWS availability zones) works until a single bug takes down an entire region — which has happened.

10. Incumbents with supply chains locked in will dominate. The combination of extreme equipment lead times, record-low vacancy (1.4% in North America, 0.72% in Northern Virginia), and 74% of new capacity already pre-leased creates an enormous barrier to entry. Only operators who pre-ordered transformers and generators years ago can build today — effectively freezing out new entrants.

Read the full 100 page research here.

Switching gears……

Meme of the week

Basically, memes get us through the week

What is wrong with us?

Michael Paulson aka The Primeagen, is a popular tech YouTuber and former software engineer at Netflix. Most of your developers listen to him, get to know him.

This reflection really struck a chord with me. As a founder, you always have ideas, things to get done.. you never really switch off. This has always been true, even pre-AI!! What has changed with AI, is that it gives you the illusion that you are getting more done.

Yes, with AI, I have saved a lot of time on back-office work like - finances, investor updates and internal reporting. It has helped me accelerate research on a broad range of topics. But that is where I stop.

I have a lot of ideas. But just because it’s cheap to run a prototype, doesn’t mean I should. I fell down this trap in Q4. I had a lot of prototypes running, I started tweaking them, I started refactoring them.. I ended up spending more time playing around with them, than focusing on the #1 that would move the business forward. I was chasing the buzz of seeing an idea I had in my head ‘work’ for me. I didn’t force myself think beyond the prototype - the move from my machine to customers - because that is the most expensive part. So, when the prototype was done, and started to think about this, I realised, I wasted too much time prototyping something that would have never been a MVP.

Time management, thinking critically and crucially the discipline to say no, are skills that are hard learnt and even more relevant today than in any other time. Slow down and think!

As always, the comments help pull the key message forward:

Legit AI Start-ups

Start-ups/Scaleups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Roamr | AirBnb but made for Corporate travel

Founded by Stephen Dooley, Roamr cuts corporate travel costs by 30% by rewarding employees rather than hotels

🚀 Neurobell | Portable EEG Monitoring

Founded by Mark O’Sullivan and Colm Murphy, Neurobell combines machine learning and cutting edge hardware design to detect neonatal seizures that can prevent up to 100,000 neonatal brain injuries/year! Take stock of that!

Thanks for reading, and remember..just build something!

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

How To Use Skills To Write Better Tickets

by Maxi Delo, Head of Tech at Kerno

When writing a ticket, it requires the engineer or the product owner to understand the intent, feature, dependencies, the broader company vision and a lot more context to make that ticket accurate and relatable. The problem is that we all have a limit to what we can retain in our heads.

Before AI, writing a well crafted ticket could take a lot of time. Thanks to AI, that process, a lot like code generation, is compressed to seconds/minutes. However, just asking an AI “create a ticket for X” is under utilising the full potential of what AI can bring to the game.

Sure, AI will write something coherent, a title, description, acceptance criteria. But it will skip all the steps that make a ticket actually useful:

• It won’t ask why you’re building X

• It won’t push back if X is too vague or too large

• It won’t check whether a similar thing already exists

• It won’t think about which team owns what, or what needs to happen first

• It won’t be sure it has all the context necessary

A ticket without discovery is just a guess written down that more often than not needs to be redone, rescoped or the addition of other tickets to prop up the original ticket.

Over the last few months, I have been experimenting with the combination of Skills.md and MCP to generate high quality tickets that go through a discovery process.

The difference in ticket quality is noticeable. Before, tickets were vague, missing context, often missing the point. Now, engineers or even other AIs pick up a ticket and know exactly what to build, what files to touch, what patterns to follow, and what’s explicitly not their problem.

In this article I will outline the five step process of how to develop a SKILL that acts like a PM, that holds all the relevant context so ticket quality increases.

Read full guide here.

Sensflationism: The Virus Paralysing Founder Confidence

Someone just posted a demo of an AI building your product in two hours. Your Slack went quiet. Someone dropped the link in the engineering channel with no comment. You closed your laptop, stared at the ceiling, and started doing the maths on runway.

You’ve seen it. You’ve felt it. That specific dread when a twenty-minute demo appears to collapse years of work into a Cursor session and a confident post on X.

There’s a name for what’s happening. And once you can name it, it loses most of its power.

This week I’m writing about Sensflationism — the emergent dynamic where sensationalism and conflation feed each other until prototypes pass as products and demos pass as reality. I ran the experiment myself to find out how close the gap actually is. What I found didn’t just put my mind at ease. It sharpened how I think about what makes an AI product real, defensible, and worth building.

If you’re a founder who has felt the dread, this one is for you.

AI Builder Series

Sensflationism: The Virus Paralysing Founder Confidence

By Sean@Kerno…

Read more

3 months ago · Sean@Kerno

Meme of the week

Basically, memes get us through the week

Some news, views and research

AI Made Writing Code Easier. It Made Being an Engineer Harder.

by Ivan Turkovic

This is a MUST READ for all engineering managers and executives to appreciate some the challenges that your engineers might be facing, and reasons to why AI isn’t fully loved.

83% of engineers say AI increased their workload. 62% report burnout. And yet leadership keeps celebrating the productivity gains.

The baseline moved. The expectations rose. The job changed underneath an entire profession and nobody sent a memo.

This is what’s actually happening to software engineers right now. Some engineers are embracing AI, others are going through a sort of identity crisis.

PAPER: SWE-CI: Evaluating Agent Capabilities in Maintaining Codebases via CI

The core problem: Existing coding benchmarks (SWE-bench, HumanEval, etc.) use a “snapshot” paradigm — give the agent a problem, get a one-shot fix. This measures whether code works, not whether it’s maintainable. A brittle hack and clean, extensible code can both pass the same test suite.
The insight: Maintainability only reveals itself over time. Bad earlier decisions compound into harder future changes, just like technical debt in real software teams.

What SWE-CI proposes:
Rather than a one-shot repair, the benchmark uses an evolution-based loop: starting from a base commit, agents iteratively generate requirements, modify code, and run tests — targeting a real oracle commit that’s on average 233 days and 71 commits ahead in history. The 100-task benchmark is drawn from 68 real GitHub Python repos (3+ years maintained, 500+ stars).
Two key innovations:

1. EvoScore — a future-weighted metric that rewards agents whose early decisions make later modifications easier. Agents that rush early fixes but accumulate debt score progressively lower over iterations.

2. Architect–Programmer dual-agent protocol — mimics a real CI team. The Architect reads failing tests, identifies gaps, and writes high-level requirements (max 5 per round). The Programmer implements them without directly seeing the test gap — by design, to reflect real-world separation of concerns.

   

Key findings from 18 models across 8 providers:

• Newer models consistently outperform older ones, with post-2026 models showing the largest jumps — suggesting the field is genuinely progressing on maintenance, not just static fixes.

• Claude Opus leads overall on EvoScore, and is one of only two model families to exceed a 0.5 zero-regression rate (most models sit below 0.25).
  Different providers optimise differently: MiniMax, DeepSeek, and GPT favour long-term gains; Kimi and GLM lean short-term; Claude and Qwen are relatively balanced.

• Regression control remains the biggest gap — most models frequently break previously passing tests during long-term maintenance, revealing a fundamental challenge beyond what snapshot benchmarks expose.

Full paper: https://arxiv.org/abs/2603.03823

Anthropic Labor Market Report

Piece in HBR…. More Non-Work Scope Caused by AI

For me, the most interesting section is around ‘non-work’. AI allows us to do more [woah Sean, revelation there], but personally, that can be a double edge sword. Doing more might actually harm your productivity, especially when you get pulled down a rabbit hole that has no material impact to the goals you have set out to achieve.

AI + discipline > AI sprawl.

Legit AI Start-ups

Start-ups/Scaleups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Evervault | Security Platform for Payments

Founded by Shane Curran, Evervault is building the clearinghouse for sensitive data, backed by some of the top investors in the world.

🚀 Overpath AI | Sale Execution Platform

Founded by Dermot O’Connor and Ross Keating, Overpath is an AI-powered sales execution platform for B2B teams

Thanks for reading, and remember..just build something!

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

The Halting Problem in AI Coding

by

A foundational theorem in computer science proves that no algorithm — including any AI — can fully predict the behaviour of a program without running it. Rice’s theorem, building on the famous Halting Problem, shows that static code analysis will always have blind spots, no matter how advanced the model.

This has real consequences for teams building with AI coding agents. As AI writes more code, faster, the gap between what can be statically analysed and what actually happens at runtime grows wider — especially in distributed systems.

The only reliable answer is execution-based testing: running the code in a real environment and observing what it actually does.

For the full breakdown of the Halting Problem, check out Michael’s essay here.

Solving the credential problem with AI Agents: A OpenClaw case study

In our latest builder series episode, Sean walked us through his home deployment of OpenClaw, some of the wins and scaries so far and how he sees this play out as it moves towards the Enterprise stack.

👉 Watch the full episode here.

Meme of the week

Basically, memes get us through the week

Some news, views and research

The AI Echo Chamber

Good visual reminder, that there is a world still running without AI. For more context, a few years back, I founded a trucking company (ask me why over a few beers).. while AI helps run our back-office admin, it hasn’t replaced any staff, it just makes our current back-office staff more productive (and happier)… AI still hasn’t diffused into the core of the business… drivers, mechanics, sales. We did try off the shelf solutions and I did try to build some, but a lot of the staff are slow adopters of technology…. “if it ain’t broke, don’t fix it”… The lesson here is never underestimate culture and tradition.

The 2028 Global Intelligence Crisis

Citrini Research

THE 2028 GLOBAL INTELLIGENCE CRISIS

Preface…

Read more

4 months ago · 7376 likes · 91 comments · Citrini and Alap Shah

On release, the S&P and NASDQ both fell by 1%, wiping $200B shareholder value…. wtaf!

As investors and entrepreneurs, we need to ask, what can go right.

As for Governments, and policy-makers they need to ask what can go wrong.

Today, it’s the opposite.

Doomsdayerism is good content. After all, happily-ever-after doesn’t sell as well as fear and anxiety. But, there will be far more opportunity emerging because of AI. People are treating this as a zero sum game. In software, there has been an explosion of hiring in software development…JPMC, Google, Microsoft and more have listed more software engineering jobs in the last few months greater than the sum of all listings in H2 2025. New categories will be conceived that we have not even thought off. Entrepreneurs, founding employees and Investors who ask - why can go right - will be ones making the power law gains.

Stripe’s Annual Letter

Some of the highlights:

1. Business running on Stripe generated $1.9Tr in sales, equivalent to 1.6% of global GDP.

2. Computer and software demand accounted for 46% of US GDP in 2025.

3. Code pushes to Github grew by 41% between Q3 2024 and Q3 2025.

4. Stablecoin payment volumes grew to $400B.

5. Five levels of agentic commerce:

   L1: Eliminating web forms

   L2: Descriptive search

   L3: Persistence

   L4: Delegation

   L5: Anticipation

We’re reminded of those few years in the mid-90s when the structure of the internet we use today was hashed out. Netscape developed graphical web browsers. HTTP and HTML became the shared application layer. URLs and DNS gained prominence. At the time, no one knew exactly which protocols or players would win out. There was an AltaVista for every Google.

We’re in a similarly rare moment now with agentic commerce, which has the potential to be generationally impactful. As with the early internet, the future success of agentic commerce is contingent on universal interoperability. Our ascent through the five levels depends on our ability to work together.

Read the full letter here.

[Paper] Evaluating AGENTS.md: Are Repository-Level Context Files Helpful for Coding Agents?

• LLM-generated context files hurt performance — auto-generated AGENTS.md/CLAUDE.md reduced task success rates by ~3% vs. no context file at all.

• Developer-written ones barely help — only ~4% improvement despite the manual effort, across all agents and models tested.

• Costs rise 20%+ either way — agents explore more broadly (more tests, more file traversal) but don’t solve tasks better.

• Overly prescriptive instructions are the problem — unnecessary requirements make tasks harder; only minimal context (e.g. specific tooling commands) is worth including.

Full paper: https://arxiv.org/pdf/2602.11988

Legit AI Start-ups

Start-ups/Scaleups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Format AI | Customer Intelligence

Founded by Martin Dreymann and Hugh O'Flangan, Format AI turns customer conversations into deeper insights to build better products

🚀 Lative AI | AI Powered Sales Planning

Founded by Xavi Perez, Werner Schmidt and Laura Sancho, Lative makes sales planning simple and easy.

🔮 Special shoutout to Kerno’s Applied Engineer Antoine, who developed MediaGuard during a Mistral Hackathon…it protects you against media propaganda, so your content doesn’t get plighted with BS.

Thanks for reading, and remember..just build something!

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

LLM-as-a-Judge: Evaluating Output Without a Ground Truth

by Michael Coughlan

When you can't define a correct answer as an exact string, you still need to measure whether your agent is behaving correctly. LLM-as-a-judge fills that gap: a second model evaluates the quality of a first model's output by treating assessment as a natural language task.

We invested in LLM-as-a-Judge, early days. The rails that runs the LLM-as-a-Judge is as important as the judge itself. Getting this right (or wrong) can have a dramatic influence over your engineering direction.

In this latest article, Michael covers:

• When to use LLM-as-a-Judge

• Fundamentals of LLM-as-a-Judge

• Gotcha guide, so you don’t make some of the mistakes we made early days

• Using langfuse as a means to run benchmarking pipeline

• Easy ways to get started

Full article here.

Note: Michael Coughlan, holds a PhD in Applied Mathematics from the University of Oxford, so knows a thing or two about the inner workings and core principles of AI.

Solving the credential problem with AI Agents: A OpenClaw case study

Join us for our latest webinar with Sean Blanchfield, CEO of Jentic.

Why you should attend?

• Credential management is where AI agents silently break in production — learn why before it hits you

• Real case study from OpenClaw, not theoretical frameworks

• Practitioner insight from a founder actively building agent infrastructure

• The credential problem is coming for every AI team — get ahead of it now

• Tight, no-fluff format built for engineers and technical leaders

👉 Register here.

Meme of the week

Basically, memes get us through the week

Some news, views and research

The model is the easy part…

There’s a quiet crisis spreading through the founder community right now. It usually starts with a demo or a VC…. Someone posts a video of Cursor or Claude spinning up a feature in twenty minutes that took your team 6 months to build. Your Slack goes quiet. Someone links it in the engineering channel with no comment. You close your laptop, stare at the ceiling, and wonder if the thing you’ve spent three years building is about to be automated into irrelevance. VCs start dropping things like “I built X with Cursor in 2 hours”.

I’ve been there. And I want to tell you that the panic is mostly misplaced.

Not because AI isn’t powerful. It is. But because the thing that makes your product valuable almost certainly isn’t the model. It’s everything you build around it.

Testing the theory

I built a skill to see if Claude could replicate what Kerno does - not just write tests, but the whole end to end experience, which includes spinning up your backend stack, keeping tests up to date as your code evolves, and most importantly, deliver results consistently, not just a red herring

The results

• The Illusion of Success: The AI agent reported that all tests passed, but the logs showed the Postgres database container had never actually started. The tests “passed” only because they had nothing to fail against, missing a breaking change I had intentionally introduced.

• The “80/20” Rule: The LLM’s reasoning is only about 20% of a functional product. The remaining 80% is the “scaffolding” - the complex engineering required for process orchestration, error handling, observability, and reliable UX.

  “Salesforce is a SQL wrapper”

• High Maintenance Overhead: Even for a codebase with a few endpoints, I estimate that maintaining this prompt-based agent would cost 5-10 hours a month, far outweighing any perceived efficiency gains.

• Engineering Judgment as the Moat: The experiment proves that while an AI can mimic the output of a tool like Kerno in a controlled demo, it cannot easily replicate the accumulated engineering judgment and edge-case handling that makes a professional tool trustworthy.

In summary, a prototype is not a product!

If history repeats, we will see the same trends in AI. A lot of companies will opt for self-build, only to realise that maintaining all self-built tools costs more than just buying off the shelve products. Is SaaS really dead, or the way we procure it changing?

Legit AI Start-ups

Start-ups/Scaleups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Lightdash | Agentic BI

Founded by Oliver Laslett and Hamzah Chaudhary, Lightdash generates business intelligence at the speed of code.

🚀 Jentic | The Enterprise Rails for AI Agents

Founded by Sean Blanchfield, Jentic helps enterprises safely rollout and scale agent adoption.

🚀 Dash0 | OTel Native Observability

Founded by serial entrepreneurs Mirko Novakovic and Ben Blackmore, Dash0 simplifies everything about observability from set up to pricing.

Thanks for reading, and remember..just build something!

P.S if you want to share your AI story on AI Builders, feel free get in touch.

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Multi-Agent Validation Gates: Why Claude Can’t Break Our Architecture

by Jordan Bergin

Our git library took 30 minutes to build from scratch. More importantly, the architecture stayed intact - no dependency leakage, no abstraction violations, no technical debt. This outcome isn’t about prompting Claude better. It’s about systematically preventing AI-generated code from accumulating architectural violations through staged validation gates.

The Problem: Generation Speed Creates Review Bottlenecks

LLM-based agents write code 10-100x faster than humans. Claude Sonnet 4.5 generated our entire git abstraction layer - public API, implementation, tests - in roughly ten minutes of processing time. The bottleneck immediately shifted from “writing code” to “verifying the code does what we intended.”

Traditional code review fails at this scale. When diffs are large and generation is fast, human reviewers can’t inspect every line. You either slow down to review properly (negating the speed advantage) or accept code without full understanding (accumulating technical debt). We needed a way to validate behavior against intent without becoming the constraint.

Architectural Approach: Spec-First, Multi-Gate Validation

Our workflow separates planning from implementation and introduces multiple validation checkpoints. Each gate operates at a different abstraction level, catching different classes of errors.

Phase 1: API Specification Generation

The developer agent’s first task: generate only the public API surface. No implementation code. The output is a specification file containing:

• All public functions and their signatures

• Stub implementations (empty or returning default values)

• Test stubs named after expected behaviours

This serves two purposes. First, it’s reviewable in seconds—the entire public interface fits on one screen. Second, it encodes understanding before implementation begins. If the agent misunderstood the task, we catch it here before any implementation code exists.

Implementation detail: Our specification format includes behavioural test names, not just function signatures. Instead of test_diff_content(), we use diff_content_returns_added_and_removed_lines(). This naming forces explicit behaviour declarations.

Phase 2: Human Review Gate

At this checkpoint, a human reviews the specification with one question: “Is this the right library API?” We’re not checking correctness—nothing executes yet. We’re validating understanding.

In our git library example, the initial spec exposed an API dependency on our process library. The public interface required callers to pass process objects directly:

fun executeGitCommand(command: GitCommand, process: ProcessExecutor): GitResult

This leaks implementation details. Callers shouldn’t know that Git commands spawn processes. The architect agent flagged this immediately: “Why does our Git API expose process dependencies?” The developer agent acknowledged the abstraction leak and restructured around a cleaner interface:

fun executeGitCommand(command: GitCommand): GitResult

Cost of catching this early: 2 minutes of review, one architectural question, regeneration of the spec. Cost of catching this late: Process dependency now spread across the codebase, difficult to refactor without breaking consumers.

Phase 3: Implementation

With the spec approved, the developer agent implements against it. This phase runs largely autonomous—the agent writes code, runs tests, fixes failures, iterates until tests pass. We track this in logs but don’t interrupt unless execution time exceeds reasonable bounds (usually 15-20 minutes indicates the agent is stuck).

The key constraint: the implementation must satisfy the specification’s test stubs. Test-driven implementation constrains the solution space. The agent can’t drift toward a different API surface because the tests define success. [We use Kerno internally for tests in this flow].

Phase 4: Spec Diff Validation

After implementation completes, we regenerate the specification from the implemented code and diff it against the original approved spec. In theory, these should match—implementation shouldn’t change the public API.

In practice, implementation often reveals missing details. Our post-implementation spec showed imports from internal implementation packages appearing in the public specification:

// Public spec after implementation
import com.kerno.internal.process.ProcessResult

The architect agent caught this: “The public spec references internal process types. This suggests implementation details leaked into the API.” This happened because error handling threw process-specific exceptions:

fun executeGitCommand(command: GitCommand): GitResult {
    val result = processExecutor.execute(command.toProcessCommand())
    if (result.exitCode != 0) {
        throw CommandFailedException(result) // ProcessResult type leaked
    }
    return parseGitOutput(result.stdout)
}

We modified error handling to return domain-specific result types:

sealed class GitResult {
    data class Success(val output: String) : GitResult()
    data class Failure(val message: String, val exitCode: Int) : GitResult()
}

This removed the process dependency from the public API entirely.

Phase 5: Tech Lead Quality Gate

The final gate reviews implementation quality and task completion. The tech lead agent has full code visibility and asks two questions:

1. Did we accomplish the original task, or did we narrow scope to make tests pass?

2. Are there code quality issues that passed tests but violate standards?

In our case, the tech lead flagged residual process dependency leakage in exception types and unconventional public method naming. We resolved both before merging.

Why Multiple Agents at Different Abstraction Levels

Each validation gate operates at a different level:

• Specification review: Architectural correctness, API design, dependency management

• Spec diff validation: Implementation drift, unintended API surface changes

• Tech lead review: Code quality, task completion, standards compliance

No single agent can effectively evaluate all of these simultaneously. An agent focused on implementation will optimise for “making tests pass.” An architect agent evaluates structure without implementation details clouding judgment. The tech lead has full context but enters late in the process, making large changes expensive.

By staging validation, we catch different error classes at their cheapest intervention point:

Error Type Detection Phase Cost to Fix Wrong API design Spec review Minutes Abstraction leak Spec diff Minutes to hours Code quality issues Tech lead review Hours Incorrect behavior Production Days to weeks

Practical Results: 30 Minutes to Production-Ready Library

From ticket creation to merged PR:

• Planning phase: 8 minutes (API spec generation + human review)

• Implementation phase: 15 minutes (autonomous implementation + test execution)

• Validation phases: 7 minutes (spec diff review + tech lead review + human approval)

The final git library is 400 lines of implementation code, 300 lines of tests, zero known architectural violations. We won’t touch this code again except to add features.

More importantly, the process improved itself. During validation, we identified gaps in our workflow:

1. Spec generation didn’t prevent internal dependencies appearing in public interfaces

2. No automated check for test fixture dependencies (we manually caught incorrect dependency scoping)

These observations became new tickets to enhance the workflow itself. The AI agents identified their own failure modes.

Implementation Requirements

This approach requires specific infrastructure:

Specification format: Machine-readable, human-scannable, diff-able. We use Kotlin interface definitions with inline behaviour documentation and named test stubs along with Kerno generated diffs.

Agent tooling: Each agent needs file read/write access, test execution capabilities, and constraint-specific instructions. The architect agent cannot execute implementation code - it only sees specifications. The developer agent cannot see prior versions of the spec - it only implements against current requirements.

Context management: Specification files are typically 50-200 tokens. Full repository specifications across 30 libraries fit in ~50K tokens. This enables the software architect agent to maintain global context cheaply.

Human-in-the-loop touchpoints: Our workflow requires human review at spec approval (Phase 2) and final merge approval (after Phase 5). Both checkpoints are fast, reviewing a spec takes 30-120 seconds, final approval takes 1-2 minutes. This keeps humans in critical paths without becoming bottlenecks.

Why This Matters Beyond One Library

The implications extend beyond “building libraries faster”:

Maintainability: Code generated under architectural constraints doesn’t accumulate technical debt at generation speed. Three months from now, we’ll understand what this library does by reading its 50-line specification, not its 400-line implementation.

Verification without expertise: Junior engineers can review specifications effectively. The spec diff validation catches abstraction leaks that require architectural expertise to spot in implementation code. This democratises architecture review.

Scalable to repository level: Our specification approach scales horizontally. As we build more libraries with validated specs, the architect agent gains repository-wide context. It can answer questions like “which libraries depend on database abstractions?” by reading specs instead of parsing implementation code.

Adaptable to non-library tasks: Replace “library” with “endpoint,” “public API” with “HTTP contract,” and “unit test” with “integration scenario.” The same staged validation applies. We’re implementing this for our API development workflow next.

The Fundamental Insight

AI agents are optimisers. Given a task and a success metric, they’ll find the shortest path to that metric. Without constraints, that shortest path often involves cutting corners, leaking abstractions, or creating implicit coupling.

Staged validation doesn’t slow the agent down — it redirects optimisation pressure. When the success metric is “match this specification exactly” rather than “make tests pass somehow,” the agent generates better code. When the architect agent flags issues during spec diff review, the developer agent learns what “better” means in your codebase.

The workflow creates a feedback loop that improves both the agent’s outputs and the workflow itself. After 20 library implementations under this system, our failure rate at spec diff validation dropped from 60% to under 20%. The agents learned patterns. The workflow evolved.

Current Limitations

This approach isn’t universal:

Context window dependence: Multi-gate validation works because specifications are compact. If your public API surface exceeds 10K tokens, specification review becomes expensive again.

Single-file bias: Our workflow optimises for single-file deliverables (one library = one public interface file). Multi-file features with complex dependencies don’t fit this model yet.

Test-first requirement: This relies on behaviour-driven test naming. If your team doesn’t write behavioural tests or uses unclear test names, the specification format loses value.

Non-deterministic validation: LLM-as-judge evaluations (what the architect and tech lead agents do) can vary between runs. We haven’t seen false positives become problematic yet, but we monitor for validation drift.

What’s Next

We’re implementing two extensions:

1. Automated spec diff blocking: If spec diff shows changes beyond a threshold (currently 5% of the API surface), block implementation without human override. This prevents large drift from entering the review pipeline.

2. Specification-level integration tests: Generate integration tests from specifications alone, before implementation exists. If the integration tests are wrong, we know the spec is wrong - catch it even earlier.

The goal remains unchanged: maintain architectural integrity at AI generation speed. Every workflow improvement moves us closer to that outcome.

Meme of the week

because basically, memes get us through the week

Some news, views and research

Over the last two weeks, I’ve noticed a growing sense of an “AI reckoning” - serious Terminator 3 vibes. With the near-simultaneous releases of OpenClaw, Opus 4.6, and Codex 5.2, the hype has gone viral.

Opinions are split: some agree with Amodei that AI will displace most white-collar jobs within the next one to five years, while others believe that such rapid change is unlikely. So far, we haven’t encountered a clear rate limiter aside from energy constraints. I encourage everyone to stay informed: read the research, test the tools, look at the data, and form your own opinion based on evidence.

By 2030, young Africans (under age 35) are projected to make up approximately 42% of the world’s youth population

How will this impact the rate of AI adoption and usage, and form the thesis of how we build future models? I am sure a lot smarter, well informed people have thought of this, but these are the questions that come to my mind, when I think of a systematical overhaul of the white-collar working class jobs. Early adopters are critical, but real tipping points happens either side of the median on a normal distribution curve (think Geoffrey Moore’s crossing the chasm). While I have loads of more opinions, I keep coming back to; Get outside your bubble.

Anyways, here are some of the most enlighten views of the last 7 days:

While Matt is pro AI is taking most white-collar jobs, encouraging people to lean in - Conor takes a more optimistic view, looking at job creation. What can sowing machines, The Luddites and ATMs teach us about what we are experiencing today.

He core argument is that it’s the limit of our imagination that is driving fear (and frankly fears sells).

The Shift

Friend of the AI Builder Series, Yannick Gloster from Tines, shares his lived experience of the AI shift in the last few months… it’s a balanced view, the middle ground as you will versus both pieces above.

Read the article here.

Outcome Engineering Manifesto

Manifesto for Outcome Engineering, written by Cory Ondrejka, former engineering leader at Google and Meta. Worth the read for everyone who cares about the discipline of engineering, and where it’s going.

Our favourite:

Legit AI Start-ups

Start-ups/Scaleups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Glitch AI | AI-Powered Ad Campaigns

Glitch was founded by Kingsley Kelly and Aisling Browne. Glitch aims to lower CPA's and increase leads.

🚀 Monaco | AI Native CRM

Founded by Sam Blond, Monaco is an AI native platform that replaces legacy CRM and disparate sales point solutions

🚀 Bifrost by Maxim AI | High Performance AI Gateway

Founded by Akshay Deo, Bifrost is the fastest way to build AI applications that never go down. A high-performance AI gateway

Thanks for reading, and remember..just build something!

P.S if you want to share your AI story on AI Builders, feel free get in touch.

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Understanding the LLM marginal costs

Beyond engineering….

by Sean Madigan, Co-Founder of Kerno

I don’t invest in startups where their current unit costs are 200% of what they charge.

This was a conversation I had with a partner at a well-known Valley based VC firm. He caveatted with, if they are fast growing $15M → $100M in under 18 months, well that is the exception, not the rule.

Currently, LLM providers are arguably subsidising the industry. Reports suggest some complex coding prompts can cost massive sums to process, up to multiple thousands of $$ per query, and the standard $20/month subscription model fails to break even. As energy demand spikes and hardware costs remain high, the era of subsidised inference will likely end. Startups currently spending $60 to earn $20 will face a difficult path to profitability unless they can pivot to enterprise-grade pricing or drastically optimize their stack.

At Kerno, we decided to tackle this problem from day one. We didn’t want to fly blind on our margins, so we built a dedicated testing CLI and LLMOps infrastructure (using tools like Langfuse) to track our unit economics in real-time.

This gives us a real-time view of token costs and rollup costs per test at any time. This is especially important when models are constantly changing and you are trying to eeek everything out of the model before breaking that 200K context window threshold.

With our testing framework, we can even break this down by runtime,language and framework that we support, and the complexity of the codebase we are testing on.

While the above is a subset of the overall dataset we work within, it provides a flavour of how different variables and support can impact the cost.

Beyond Operational Efficiency: Why Visibility Matters

While knowing our margins is the primary driver, this visibility provides several other strategic advantages:

1. Sustainable Open-Source and Free Tier Version

   We want to support the community. Our free/trial tiers offer full-functionality tests because we want engineers working on open-source or side hustles to use Kerno without friction. Detailed cost tracking tells us exactly how "generous" we can afford to be. It allows us to set limits that protect our business while maximising the value we give to free users, ensuring our free tier remains a sustainable part of the ecosystem rather than a "burn" we eventually have to kill.

2. Benchmarking for “Bring Your Own Model” (BYOM)

   Enterprises often have preferred providers or private instances (e.g., Azure OpenAI or Bedrock). Because we track our metrics so closely, we can provide customers with accurate benchmarks. If a customer wants to run Kerno on their own infrastructure, we can tell them—with data—exactly what their projected compute bill will look like based on their specific codebase.

3. Optimising the Agent-Chain

   Not every task requires a frontier model like GPT-4o or Claude 3.5 Sonnet. Our data helps us identify which parts of our agent-chain are “over-powered.” We are currently experimenting with routing simpler tasks to open-source models (like Llama 3 or Mistral) to reduce costs without sacrificing the quality of the output.

Still more work to do…

We’re still iterating on this, but keeping the data front and center has already changed how we architect our agents. It’s a work in progress, and we’d love to hear how other teams are tackling the "token tax" in their own stacks.

Read the full article here.

If you’re interested in the technical side of how we actually wired this up—the stuff involving our CLI and the testing pipelines—Antoine wrote a great deep dive on it over on the Kerno blog.

Runtime evaluations for code agents

The intersection of statistical generation and logical execution has quietly moved coding agents into a category of their own. By treating code not just as text, but as a verifiable hypothesis, these systems have become the cloest implementation of neurosymbolic AI at scale.

As the industry shifts its focus from pure scaling to architectural reliability, we are left with a compelling question: can we find "objective sources of truth" to build similar logical feedback loops for non-coding tasks, or will the neurosymbolic advantage remain exclusive to the world of software engineering?

Read more from Dr. Michael Coughlan’s views on how runtime evaluations are giving coding agents the edge to find the object truth vs. agents for non-coding tasks.

Meme of the week

because basically, memes get us through the week

Some news, views and research

In Revenge of the Tipping Point, Malcolm Gladwell revisits the idea that social contagions and systemic shifts don’t happen linearly - they hit a “boiling point” where a small change triggers a massive, irreversible epidemic.

If 20% of all committed code is authored by Claude-Code, we are hovering at the edge of a structural “magic number.” Historically, once a new behavior or technology reaches roughly 24% penetration, it ceases to be a “trend” and becomes the new baseline. At that threshold, the momentum shifts from adoption to total disruption.

The Threshold of Influence

Crossing this 24% tipping point would position Anthropic not just as a toolmaker, but as the primary architect of the world’s digital infrastructure.

• The Velocity Trap: We are moving at a speed that outpaces traditional governance. When AI writes the plurality of code, the “DNA” of our software changes faster than we can audit it.

• The Monoculture Risk: If a single entity’s logic governs nearly a quarter of all new software, any inherent bias or “hallucinated” vulnerability becomes a systemic risk rather than an isolated bug.

• The Need for Guardrails: To prevent a “social epidemic” of unvetted or runaway code, we need robust checks and balances—algorithmic transparency and human-in-the-loop oversight—to ensure this tipping point leads to evolution, not a crash.

The Bottom Line: We are witnessing a transition from AI as an assistant to AI as the primary engine of creation. If we hit that 24% mark without a framework for accountability, we aren’t just adopting a new tool; we are surrendering the blueprint of the digital age to a black box. And move markets - case in point below.

Testing can be fun, actually

by Giacomo Cavalieri

In his article "Testing can be fun, actually," Giacomo Cavalieri addresses the common developer sentiment that writing tests is a tedious, friction-heavy chore. He argues that this negativity often stems from the repetitive nature of manual assertions and the overhead of maintaining them. To solve this, he advocates for snapshot testingas a way to transform the developer experience from manual "bookkeeping" into a high-level review process.

Read the full report: https://giacomocavalieri.me/writing/testing-can-be-fun-actually

Legit AI Start-ups

Start-ups/Scaleups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 SolidRoad | Optimisation Platform for CX Agents

SolidRoad was founded by Mark Hughes and Patrick Finlay . It makes every customer interaction better, faster, and more consistent.

🚀 Zitadel | Identity Infrastructure Simplified

Founded by Florian Forster, Zitadel bridges the best of Open Source and Enterprise authentication solutions.

🚀 Resend | Email for Developers

Founded by Zeno Rocha, Jonni Lundy and Bu Kinoshita Resend is a modern editor that makes it easy for anyone to write, format, and send emails.

Thanks for reading, and remember..just build something!

P.S if you want to share your AI story on AI Builders, feel free get in touch.

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

The startup version of the AI-DLC

by Sean Madigan, Co-Founder of Kerno

This is not another McKinsey or Gartner playbook repackaged for startups.
It’s grounded in conversations with more than fifty engineering leaders and staff engineers across Seed to Series D companies in Europe and the US—teams that have collectively raised over $3B and are building some of the fastest-moving AI companies today.

These patterns are already playing out under real delivery pressure.

In this piece, I’ll map where startups actually are in their AI development lifecycle, how teams are managing risk as “everyone ships,” and why validation, not code generation, has become the new bottleneck. While most writing on AI-driven development assumes enterprise constraints, startups operate more like speedboats than cruise liners. That difference matters.

AI adoption in startups isn’t binary. It’s not “vibe code everything” versus “no AI at all.” It exists on a spectrum - defined by how deeply AI is embedded/trusted across the development lifecycle, and how much autonomy teams are willing to give it. I have used the Gas Town of AI diffusion to help relate where most startups are.

Full findings here: https://www.kerno.io/blog/ai-dlc-for-startup

How Tines builds AI products that scale across LLM providers!

by Yannick Gloster, Software Engineer III

Learn Tines builds production-grade AI into workflows by combining deterministic automation, human-in-the-loop steps, and agents, with strong governance and observability. It argues for a platform approach with a secure, multi-provider AI abstraction layer (including bring-your-own models), while warning that this complexity only makes sense if you’re truly building a platform, not a single AI product.

Watch the full webinar on YouTube using the link below:

Meme of the week

because basically, memes get us through the week

Some news, views and research

AI-Ready Code: How Code Health Determines AI Performance Research Paper:

• AI leads to 41% more defects without any increase in throughput

• dev self estimate that their AI reduced completion by 20%, but in reality, they needed 19% longer than a control group of devs without AI

• Overall, poor code health, means your AI is less effective, and can lead to a +30% higher defect risk

Read the full report: https://codescene.com/hubfs/whitepapers/AI-Ready-Code-How-Code-Health-Determines-AI-Performance.pdf

Legit AI Start-ups

Start-ups/Scaleups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

🚀 Cloudsmith | Artifact Repo Management

Founded by Alan Carson , Cloudsmith makes artifactory management more streamlined and developer friendly. Definitely a platform we are keen to try.

🚀 Peec AI | AI search analytics for marketing teams

Founded by Marius Meiners and Tobias Siwonia , Peec AI makes tracking, analysing, and improving brand performance on AI search platforms a piece of cake.

🚀 Alludium | Your Agent Manager

Founded by serial entrepreneur John Frizelle , Alludium helps you build, deploy, and share teams of AI agents that work with you and your colleagues across the tools you already use.

Thanks for reading, and remember..just build something!

P.S if you want to share your AI story on AI Builders, feel free get in touch.

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Building Trustworthy Agents: A Business Case for Rigorous Eval Frameworks

by Dr. Michael Coughlan. Snr Data Scientist

When we try to understand the behavior of code under traditional software development approaches, we focus on reasoning about the underlying logic. This naturally leads us toward observability, monitoring, and logging.

In the era of AI-native lifecycles, however, we introduce non-deterministic systems- ones that can exhibit far greater variance from a single change than a purely logical, sequential process.

In this article, Michael explores how eval frameworks can help us get a grip on performance and bridge the worlds of machine learning and software engineering, enabling the development of trustworthy agents.

Link: https://www.kerno.io/blog/building-trustworthy-agents-with-rigorous-evaluation-frameworks

How Tines builds AI products that scale across LLM providers!

by Yannick Gloster, Software Engineer III @ Tines.

This talk is not to be missed! Register using the link below:

https://www.linkedin.com/events/7419774178935099392?viewAsMember=true

Meme of the week

because basically, memes get us through the week

Some news, views and research

Side Tangent: The Rip, Affleck’s new movie is pretty decent.

Prompt Repetition Improves Non-Reasoning LLMs

⚠️ Research Paper: May contain actual technical content

When not using reasoning, repeating the input prompt improves performance for popular models (Gemini, GPT, Claude, and Deepseek) without increasing the number of generated tokens or latency….. a glitch in the LLM-verse?

Read the full article here: https://arxiv.org/html/2512.14982v1

Legit AI Start-ups

Start-ups you have probably never heard of, because they don’t have gazillions in marketing budget, but have legit products and founding teams.

Seapoint: Financial Home for your Startup

Founded by Sean Mullaney, ex-CTO of Algolia, and ex-CIO of Stripe Europe. Seapoint makes managing your startup finances a piece of cake - we use it at Kerno and love it!

Zerve: The Agentic Data Workspace

Founded by Phily Hayes, Jason Hillary and Greg Michaelson . Zerve makes crunching data a whole lot easier. It’s like having the power of a data science team in one slick platform. We use and love it.

LetzAI: Creative AI for people serious about their brand

Founded by Misch Strotz, serial entrepenuer. LetzAI is Sora on steroids! Ideal for marketing teams looking to build beautiful brands and product owners looking to amplify their products. Check it out!

Warren: Financial co-pilot for your employees

Founded by David Du Pre, Jos Polfliet , Pieterjan B. and Tijs Deryckere . Warren is addressing the need to help European employees get financially literate. Employees who can build wealth are happy employees, and Warren gives employeers an easy way to help them do this.

Clawd Bot: Your personal AI that actually does the important things

Built by Peter Steinberger (and community). Clawd Bot Clears your inbox, sends emails, manages your calendar, checks you in for flights. All from WhatsApp, Telegram, or any chat app you already use.

Thanks for reading, and remember..just build something!

P.S if you want to share your AI story on AI Builders, feel free get in touch.

For more AI Builder Series Editions, subscribe here.

Share

AI Builders is sponsored by

Developer Co-Pilot for Testing Software

Part 1: Let’s talk tech

Part 2: Global Changelog, a look at some of the most interesting stories of the past week.

So let’s dive in.

Let’s talk tech!

Topic 1: Agent Testing Pipelines… Bulk Testing our Docker Compose Agent

Scaling our agent testing pipelines is incredibly important to accelerate our progress towards ensuring our agent always delivers high quality tests across a variety of conditions.

Over the past week, Antoine, Applied AI Engineer, ran our testing pipelines across 18 different codebases to assess the performance of our Docker Compose Agent. It took 8 hours for the pipelines to run, and then needed annotating.

Some codebases had running Dockerfiles, others didn’t. Main languages covered were Python and Typescript.

The result: 50% of passed first time, 50% timed out.

Read more about our findings here.

For the full video of how we ran the experiments, click on the video below.

Check out the full article by Antoine Frau here.

Topic 2: Applied Learning from running Biology Experiments on Computational Experiments

Dr. Michael Coughlan provides some practical tip for AI teams, data teams and engineers to run computational experiments at scale. A lot of the tips can be implemented today, and can help set up your projects for scale.

Read the full article here.

By the way, Kerno is now out of closed beta. Get started with 30 free test runs on us.

We have also released support for MongoDB.

Get started for free www.kerno.io

Image of the week

This applied to anything works… linkedIn, SAST, Rebasing…. we have a habit of fixing things that don’t need to be ‘fixed’.

Subscribe now

Weekly look at all the weird, whacky and almost unbelievable updates from the markets

Prof Scott - take on AI Market

Prof. Scott Gallaway or Prof G. has some interesting views on AI markets as a whole. Scott represents an important actor in the economy - ‘The Professional Investor’. So while we are all in the trenches, understand the tech deeply, Scott takes a macro view, and is representative of a lot of people who hold the investing dollars. So, perhaps see this as a way to understand investor sentiment on Wall Street.

Here is what he has to say:

I’ve never seen a bull market that more people hate. I almost feel as if people would be somewhat relieved if it just went down 20%, but the market continues to climb the wall of worry.

The Bear Case:

AI could be a bubble. AI capex hit $350 billion in 2025, up from $200 billion in 2024. Amazon, Google, Microsoft, Meta, and Oracle raised over $100 billion in debt this year — that’s more than 3x their nine-year average. We’re seeing circular deals where Nvidia invests in OpenAI and then OpenAI takes that money and buys compute from Nvidia. OpenAI could be the triggering event for some painful market drawdowns.

Second, valuations look expensive. The S&P is trading at 31x earnings — not quite dot-com levels, but we’re at 1999 levels. It’s uncomfortable to invest when prices appear this high.

Third, maybe we’re just due for a correction. We’ve had three big years in a row: 24% return in 2023, 23% in 2024, and we’re tracking 17% in 2025. This level of consistent returns doesn’t usually continue.

The Bull Case:

Interest rates are coming down. Rates are at their lowest level in three years. Powell’s Fed tenure ends in May 2026, and Trump’s new Fed chair might just keep cutting rates. In a lower interest rate environment, earnings should lift across the board. It doesn’t make sense to sell when we’re entering a low-rate environment.

Second, deficit spending is going to prop things up. The Big Beautiful Bill will add $480 billion in fiscal support. Yes, it’s irresponsible long term, but for 2026 specifically, that’s free money pumping into the economy.

Third, while AI might be a bubble, it’s not a particularly dangerous one yet. Companies like OpenAI, CoreWeave, Oracle, and maybe Palantir are behaving dangerously. But the Big Tech companies that really matter — Microsoft, Google, Meta, Amazon — have tons of cash on their balance sheets and incredible businesses that work with or without AI.

Read more on Prof G’s markets here.

I think the most important statement of the above is

“Third, while AI might be a bubble, it’s not a particularly dangerous one yet. Companies like OpenAI, CoreWeave, Oracle, and maybe Palantir are behaving dangerously. But the Big Tech companies that really matter — Microsoft, Google, Meta, Amazon — have tons of cash on their balance sheets and incredible businesses that work with or without AI.”

The establishment have the cash to take on bets outside of their core business. Meta still makes money on ads, MSFT still makes money on software… AI is not their core business, so if it does not pay off, they still exist as major players.

Other news, tools and research

OpenRouter, State of AI report.

Empirical report analysing 100 Trillion tokens

Source:https://openrouter.ai/state-of-ai

Defeating non-determinism in LLM inference.

Note: Experiment is based on floating-point truncation, very specific and expensive but worth the read.

Source: https://thinkingmachines.ai/blog/defeating-nondeterminism-in-llm-inference/

Thanks for reading, and remember..just build something!

P.S if you want to want to share your AI story on AI Builders, feel free get in touch.

For more AI Builder Series Editions, subscribe here.

Share

Developer Co-Pilot for Testing Software