A data team I work with has the typical issue with their backlog of having many small to medium complexity tickets; not all the interesting kind like data modelling etc, but many requests from stakeholders for new fields etc that enhance their data exploration. The backlog is full of tickets like add region column to the accounts mart, expose this staging model to the reporting layer, update the description on that dimension. Bread-and-butter analytics engineering. The kind of work that’s genuinely valuable, unambiguously well-defined, and also somewhat tedious. The kind of work that would be better done by a machine if possible.

The team lead asked me: “Could AI do this?”

“Sure,” I said. “Maybe we could build an agent.”

Phase 1: The CLI Agent

In mid-December I sat down and built a CLI agent in Python. Tools included: Jira API, GitHub API, git operations, file reads and writes - all wrapped around Claude as the reasoning engine using the Claude SDK. The architecture was simple: deterministic scaffolding around an LLM. My code handled authentication, API calls, repository setup. Claude did the thinking.

It worked. The agent would read a Jira ticket, create a branch, explore the dbt project, write the SQL and YAML changes, open a pull request, and transition the Jira status. I named the project JiraDE1.

I was writing the agentic loop myself… deciding tool order, handling errors, managing retries. Every edge case was my problem. The agent was capable but rigid, and I was spending more time on the scaffolding than on the domain logic that actually mattered.

Phase 2: The REPL

In January I added an interactive mode jirade chat, a conversational REPL with twenty-two tools. For the tickets where full autonomy was overkill, I could guide the agent through the work, nudging it past gotchas the fully autonomous mode would get stuck on. I integrated dbt Cloud CI so the agent could validate its own pull requests before human review.

The REPL was genuinely useful. However, I was still maintaining a bespoke agent runtime. Every new failure: rate limits, context window management, tool call validation… was mine to handle. I was building an agent from scratch when Claude Code, the tool I was using every day, already was one. The best one out there, too.

Phase 3: The MCP Server

Then it dawned on me.

In early February I stripped out the agent loop entirely and exposed Jirade’s tools via MCP directly to Claude Code. I replaced the dbt Cloud CI integration with something far more controllable: running a custom-built dbt CI locally against Databricks, with isolated schemas and metadata-only comparisons2. It also produces a helpful diff report comparing the models built in CI with prod equivalents, explaining row count, nullness and schema changes.

Claude Code became the agent. It already had the reasoning, the error recovery, the context management, the ability to recover from mistakes and try alternative approaches. I just needed to give it the right tools: Jira search and transitions, GitHub PR management, dbt local CI on Databricks, deprecation impact analysis. The tool schemas are defined, Claude Code discovers them via MCP, and the rest is its problem rather than mine.

The message crystallised across the weeks working on this project: yes, you can build agents easily now… but you shouldn’t. Give agents better tools instead. It’s a powerful development loop; the agent uses and improves the tools it has as it experiences difficulty.

The Closed Loop

Here’s what Claude Code now does with Jirade’s tools, end to end, without intervention:

It reads the Jira ticket. It explores the dbt project to understand the codebase. It writes the SQL and YAML changes: new models, updated schemas, altered configurations. It creates a pull request. It triggers CI against Databricks, building the changed models in isolated schemas and comparing the results against production using only aggregated metadata: row counts, column types, null rates, value distributions.

It publishes the comparison with a structured diff report in the PR, so that human approvers can approve at a glance without having to run models themselves.

If CI fails or a reviewer leaves comments, it reads the feedback, fixes the code, and pushes again. When all checks pass and the PR is merged, it cleans up the CI schemas and closes the Jira ticket.

Simple to medium complexity tickets… the add-a-column, expose-this-table, fix-this-description variety, it handles with aplomb. Even when the Jira tickets are vague or poorly specified, it infers intent from the codebase context. The constraint that matters most isn’t the model’s reasoning ability; it’s the quality of the tools you give it.

Its only limitation I’ve seen so far, is that when data has to be parsed out of semi-structured data, it can need a few iterations of trying to get it right. One Jira ticket mentioned the names to parse out but stated them in snake_case rather than camelCase, and because the agent isn’t allowed to read raw data in Databricks, it tried them verbatim. Even in this case, it just iterated off the error messages until the local dbt CI run succeeded. So while it doesn’t one-shot these, it does succeed through iteration. The issue with semi-structured data is that it doesn’t have a directly available schema from the data warehouse. I’m sticking to the idea that it shouldn’t read the data to derive it for now, especially as it does eventually succeed here.

The Implications

I wrote previously about Jevons Inversion, the idea that when AI makes a category of work dramatically cheaper, demand for that work explodes while demand for the specialists who used to do it may not. I argued this would happen to software engineers. I didn’t expect to prove the thesis quite this quickly.

Analytics engineering routine work, the tasks that fill backlogs and consume sprints, is exactly what tool-equipped agents handle well. Well-defined inputs, structured outputs, deterministic validation. The work won’t disappear. If anything, organisations will do vastly more of it, because the marginal cost drops toward zero3.

The analytics engineers doing this work will increasingly be agents with good tools, supervised by a smaller number of humans who understand the domain deeply enough to build those tools and handle the genuinely hard problems. Even the hard problems will be gradually chipped away with every new model release, every improvement to the harness and every improvement to the tools given to or built by the agent.

It may no longer be a great time to become an analytics engineer for the first time4. For those already in the role, the ones who understand the stack deeply enough to build the tools that agents need… it’s never been better. The work will multiply. The workers may not.

We’ll have more analytics engineering than ever. We’ll have more analytics engineers than ever. They just won’t be the same engineers, and most of them will live in a terminal window. They won’t eat, they won’t sleep, they won’t dream, they won’t go to lunch, they won’t get coffee, they won’t want a promotion, they don’t need mid-year reviews… they will just crunch through ticket after ticket after ticket.

I’m speaking at AI Skills 2026 tomorrow at 8:50pm GMT / 12:50pm PT tomorrow.

Sign up here for free to catch my talk:

Topics include:
– What are the must-have AI Tools & Skills for Career and Business Growth in 2026?
– What VCs think: Is AI a Bubble? And Which AI Startups They'll Actually Fund in 2026
– How to make 16M views on LinkedIn in 3 months with AI
– MCP, AI Agents, AI Skills, Automations & Prompting: What's Dead and What's Next in 2026

Looks like a good line up of speakers spread across VCs, founders and people deploying AI in industry.

You might say, it’s not been two weeks since I said that AGI would come this year (and not already). I’ll explain why my position has shifted tomorrow. Things are accelerating every day!

The year of narrow AGI

My prediction for this year is that we will see AGI within specific settings.

I think many people get the term AGI confused with ASI. Artificial General Intelligence is not Artificial Super Intelligence. ASI conjures images of an all-powerful, perhaps sentient AI. In my mind, AGI is something quite different. It is a system that can do many different things at least as well as a human. There is no requirement for sentience. It needs to be able to do some things it is asked to do or has a predefined directive for.

What does “at least as well as a human” mean? It does not mean perfectly. I am, by definition, generally intelligent, but there is almost nothing I do perfectly. There is no value in an AGI that can do many things worse than the average human, but there is tremendous value in one that can do many things as well as or better than average. If you have worked in typical workplaces, not elite tech companies, you will know this is a pretty low bar.

I have worked at companies where people do not come back from the pub at lunch. Or worse, they do and work whilst being many times over the limit to drive a car. I have worked at companies where I had to do someone else’s job as well as my own whilst they were on vacation, and I did not even feel the extra load because they did that little, or I was able to automate their work with a VBA macro. I think people doing jobs like these, rather badly, make up a huge percentage of our workforce. Well over 10%.

The ability to learn

What do I mean by “many things”? It is clearly not all things. I am generally intelligent and have limited specific capabilities. What makes me generally intelligent is my ability to learn to do many different things that I cannot do right now, and could not do when I was born. So an AGI system, more than anything, will have to be able to learn to do new things, and retain and maintain the knowledge of how to do those things so it can execute actions later.

With regard to LLMs, some capability comes from pre-training, but I think we are hitting a ceiling with regard to how much ability we can gain from enhancing pre-training alone. Post-training learning is how we will get to AGI.

There has been disagreement on this terminology by some of the biggest names in AI. Whilst I agree with Yann LeCun that ASI will not come from LLMs, I also agree with Demis Hassabis that AGI can come from LLMs. The term “general” is confusing here. We say general and it is easy to think that means anything and everything.

With a human being, general intelligence is a collection of many specific capabilities and the ability to learn more. It is also our ability to make tools to expand our capabilities further than learning alone could take us. 1 describes this ability to make new skills and tools as the “if-and-then” logic of systematising that used to be unique to humans, and is unique to us as an animal species. Most of what we think of as intelligence stems from this systematising ability. Animals do not have it. They cannot experiment or invent like we can.

I can drive a vehicle that is less than 3500kg. I can cook less than 20 dishes without additional guidance, but many more with written recipes, and even more with YouTube videos. I can use a stove, an oven, a knife, a grater, chopsticks, tongs, a steamer, a microwave. I can write in English using a pen, touch-type on a keyboard, or dictate through speech-to-text. I can trim my own beard.

I cannot cut my own hair, but I could learn. I cannot fly a plane, but I could learn. I cannot write music, but I could learn. I cannot play Go, but I could learn. I cannot retain hundreds of objects in short-term memory, and I never will be able to.

Generality and specificity seem at odds with each other as concepts, but generality of intelligence is just multiple specific capabilities plus the flexibility to maintain and create more.

It is not my sentience, nor my initiative, nor my soul, nor my personality that makes me generally intelligent. It is my ability to learn how to solve new problems through experimentation, learning skills, and making tools.

LLM-based AGI and its limits

AGI built on LLMs will not be able to do many things. I believe LLM-based AGI will not be able to drive a car. Does that mean it is not AGI? No. Many humans cannot drive a car. Are we saying they are not generally intelligent? We celebrate the things we each can do. It is not fair to compare AGI to the entire set of capabilities of all humans. It is also not useful. For any given application, there are a limited number of capabilities required. Some are explicit but some are implicit to humans.

There are things humans can do today that an LLM-based AGI will never be able to do, and humans can continue to do these things until we have some other AGI, perhaps based on world models, that can fill those gaps.

Promethian

This is why I have made Promethian, an AI agent that can learn new skills and build new tools for itself, as well as maintain them. It has the potential to become AGI for certain applications. However, I believe that if some of the skill and tool learning/building features I have made were built into Claude Code, then Claude Code would very quickly become AGI.2

Promethian is very much inspired by and built with Claude Code, using the Claude SDK. In all honesty, the confidence I have in its ability to create and maintain useful new tools stems from the release of Claude Opus 4.5. I would not have thought this was possible before November 30th 2025.

Installation is straightforward:

pipx install promethian

run promethian in your terminal to open the REPL

then use it like you would ChatGPT or Claude

The architecture is designed around a simple principle: your data and your API keys stay local, whilst learned knowledge is shared.

What stays on your machine:

- Your Anthropic API key. Every Claude call uses your own key, running on your own machine.

- Tool execution. When Promethian builds or runs a tool, it executes in a subprocess on your computer.

- A local cache for session data.

- Your credentials, stored in ~/.promethian/credentials.json with restrictive file permissions.

What gets shared centrally:

- Skills and tools that work. When Promethian successfully completes a task and learns something generalisable, it contributes that knowledge back to a central database.

- Logs of your session default to being sent to the API server when there is failure in the session, but this can be turned off in settings.

The security model is intentional. Your API keys never leave your machine. The central API uses JWT authentication, rate limiting, query-gated access (you can only retrieve items that appeared in your own searches), and server-side embeddings. You send text queries, not raw vectors, so there is no way to enumerate the database by crafting embedding space queries.

This architecture mirrors how human knowledge works. I learn something, I share it with others who might benefit, but my private notes and personal context stay with me. The knowledge base compounds. Each user’s successful executions make the system slightly better for everyone else.

The path to AGI

If you accept my definition of AGI, the path forward becomes clearer. We do not need a single breakthrough that suddenly makes AI capable of everything. We need systems that can learn, retain what they learn, and build tools to extend their own capabilities. We need the if-and-then logic applied to the agent system itself.

This is not ASI. This is not sentience. This is an AI that gets meaningfully better at specific tasks over time, accumulates those capabilities, and eventually crosses the threshold where it can do “many things at least as well as a human.”

I think this happens within certain settings this year. Not everywhere. Not for everything. But for enough tasks, in enough domains, that the term AGI will start to feel appropriate rather than aspirational.

’s 2026 prediction for LLMs raised something that’s been rattling around my head. He invokes Jevons Paradox—the observation that as something becomes more efficient to produce, we don’t use less of it, we use vastly more. Coal. Compute. Now software.

Simon Willison’s Newsletter

LLM predictions for 2026, shared with Oxide and Friends

In this newsletter…

Read more

2 months ago · 21 likes · 2 comments · Simon Willison

The optimistic case for software engineers is roughly this: coding agents make software cheaper to produce, therefore we’ll want more software, therefore we’ll need more engineers. Jevons saves the profession. I’m not sure that it plays out this cleanly. published a post a couple of years ago suggesting this is how things would work more broadly, and I don’t think this is what we’ve seen.

Marc Andreessen Substack

Why AI Won't Cause Unemployment

Fears about new technology replacing human labor and causing overall unemployment have raged across industrialized societies for hundreds of years, despite a nearly continual rise in both jobs and wages in capitalist economies. The jobs apocalypse is always right around the corner; just ask…

Read more

3 years ago · Marc Andreessen

The paradox, as typically applied, assumes the same people do the work. When coal extraction became efficient, you still needed miners. When compute became cheap, you still needed programmers. But what happens when the efficiency gain comes from mostly removing the need for the specialist? I think we may be about to find out.

There are many software engineers out there who aren’t working on particularly deep technical projects. They aren’t building compilers or high-performance computing systems or databases. They’re application developers, doing fairly similar things at company after company—1the somethingify pattern, the somethingly pattern. The advent of coding agents, from Lovable through to Claude Code, creates a spectrum of tools that turns anyone slightly technically able into something like a software engineer. Anyone who can use Excel competently understands data, logic, conditionals. They can’t write Python, but they can describe what they want, test whether it works, and iterate until it does.

Not good software engineers by 2022 standards, but good enough for what they need. People already used to operate like this… everyone had their trick spreadsheet that had a macro to automate something annoying for them. In a way we’re just expanding this concept.

The most interesting shift to me isn’t what we build, it’s what we throw away. Consider software that runs once. You need to transform some data, validate something against a ruleset, generate a report in a specific format. Previously, you’d either do it manually which is tedious and error-prone or ask engineering, which means backlog prioritisation and weeks of delay. Now you describe it to an agent, it generates the code, you run it, you let it decay in the background of your desktop. This took seven minutes and would have taken two hours manually. Nobody calls this software development, but that’s exactly what it is.

And here’s where it gets interesting: agentic systems have memory. That single-use script you made last Tuesday? The next time you need something similar, the agent knows. Faster, more reliable, each iteration costing less until each use is a low effort one shot. Eventually, generating the code approaches the cost of running something deterministic. At that point, the distinction between “writing software” and “using software” starts to blur in ways I don’t think we’ve fully appreciated.

There’s also something worth considering about the overhead that disappears when users build their own software. Enterprise SaaS carries enormous costs because it has to. It serves thousands of users, so it must scale. It handles sensitive data across organisational boundaries, so security is key. It runs on someone else’s infrastructure, so efficiency matters. It must be sold, which means documentation, support, maintenance, and all the apparatus of a product company.

User-built software has none of this. It runs on your machine, so scalability is irrelevant… there’s one user. You already have access to the data, so security is just your existing boundary. Your laptop sits idle most of the day anyway, so efficiency barely matters. Documentation? You prompted it, so you understand it. All the boilerplate essentials that make SaaS saleable are unnecessary. The software doesn’t need to be good by any conventional standard. It just needs to work for you.2

So what does this mean for demand? I think Jevons Paradox will apply in aggregate. We will have far more software engineering done than ever before. But the composition of who does it may invert in ways that aren’t great for traditional engineers.

The world gains millions of what we might call vibe engineers; people who couldn’t write a function by hand but can orchestrate agents effectively. They’ll handle the long tail of software that was never worth building before: internal tools, one-off automations, personal utilities, departmental solutions that would never have made it through a prioritisation meeting.

The world may lose demand for a specific kind of engineer: the application developer doing similar work at company after company. Those roles existed because building software required the skill. When the skill is substantially automated, the role follows. What remains is complex systems where correctness matters: compilers, databases, security-critical infrastructure, frameworks that the agents themselves rely on. High-performance computing where efficiency isn’t optional. These need engineers who understand what they’re building, not just how to describe it.3

But that’s a smaller number of people than work as software engineers today. We’ll have more software engineering than ever. We’ll have more software engineers than ever. They just won’t be the same engineers, and most of them won’t think of themselves as engineers at all.

Jevons Paradox applies. The demand for software engineering explodes. The demand for software engineers, as we’ve known them, may not.

Happy New Year! 🎉

I’ve been thinking about which jobs are effectively finished because of advances in AI. In short, any work that is repetitive, has abundant public training data, and mostly maps language input to language output is at serious risk.

Law is the clearest example. That does not mean all lawyers are finished, but the impact is already visible: hiring of law graduates into junior roles has dropped sharply. The picture, however, is more nuanced.

Partner-level roles (including public-sector equivalents) will remain essential for as long as legal services are delivered to humans. These roles are fundamentally about sales, judgement, accountability and human interaction—none of which it is reasonable to delegate fully to AI without some implausible humanoid interface.

Even so, partners alone are not enough. Senior lawyers just below partner level do the real orchestration: validating work, making decisions, and ensuring quality. That layer is also essential.

The layers below that—junior and mid-level roles where people are not yet trusted to work independently and whose output requires senior review—are the most exposed. There is little doubt that AI will handle this work in the near future, faster and better than humans. The main reasons it has not yet happened are institutional caution and slow adoption of agent-based systems, both understandable in law. Once secure systems can guarantee confidentiality and a baseline level of quality, this work will move to AI.

It is an ideal use case for agents: contextualising a matter, retrieving minimal relevant statutes and case law, and coordinating specialised sub-agents under human supervision.

So what happens to junior and mid-level lawyers? They do not disappear entirely. Partners and seniors are human: they retire, move on, and occasionally die in post. Organisations therefore need a pipeline to replace them.

Assume a legal organisation loses around 10% of its partners and seniors each year. To replenish that talent, juniors must still be hired and developed, with attrition along the way. If roughly 10% drop out in each of the first three years, and 5% per year over the following seven years to reach senior level, then an organisation needs roughly double its annual senior attrition entering as juniors a decade earlier.

For example, an organisation with 100 senior lawyers might lose or promote 20 each year. To replace them, it would need around 40 juniors entering ten years prior. That implies roughly 300 junior and mid-level lawyers at any given time - this is a 500-person firm with 100 partners and 100 seniors included1.

This structure is far more top-heavy than in the past. Historically, firms needed at least three times as many junior and mid-level staff to grind through work before it was ready for approval. AI removes much of that need.

The implication is clear: we do not need to produce as many law graduates as we once did. Top law schools can continue at current levels, but many second- and third-tier providers are training graduates for roles that will no longer exist, forcing them to compete for a shrinking pool of positions against graduates from more prestigious organisations, yet incurring similar student debt and opportunity cost.

Is this really a disaster? Over a million law graduates are produced annually across the Western world. This was arguably a by-product of an increasingly complex legal system that required ever more human labour - until now.

This pattern will repeat across many industries. Organisations will still need to hire juniors, but primarily to develop future leaders rather than to supply large amounts of labour. Scale will adjust accordingly. The parallel with the industrial revolution is obvious: machines replaced most manual labour, not all of it. AI will do the same for knowledge work.

It’s a much bigger societal change than the move to computers from paper for knowledge work, much bigger than the effect of the internet on work. This is the reason why it may not be a bubble: some investors are counting brass tacks at specific companies… others are thinking bigger, towards the multiplier effect of a knowledge revolution on the economy as a whole and what that’s worth.

Recently, Character.ai faced a lawsuit for failing to provide adequate protections for users.

‘I want them to understand that this is a platform that the designers chose to put out without proper guardrails, safety measures or testing, and it is a product that is designed to keep our kids addicted and to manipulate them,’ Garcia said in an interview with CNN.

Garcia alleges that Character.ai – which markets its technology as ‘AI that feels alive’ – knowingly failed to implement proper safety measures to prevent her son from developing an inappropriate relationship with a chatbot that caused him to withdraw from his family. The lawsuit also claims that the platform did not adequately respond when Setzer began expressing thoughts of self-harm to the bot, according to the complaint filed in federal court in Florida.

The frustrating thing about this is that we have been walking this path for a long time. I am part of the Smartphone Free Childhood movement in my local area, and the primary danger we have focused on is the harm caused by algorithmic feeds in social media that indirectly influence children down darker paths and can lead to humiliation when content about them is shared and spread. Character.ai seems to have taken a similar approach to user engagement using an AI agent – but the danger here is how direct it is. LLMs are trained to please, so if someone asks about suicide, expresses interest in it, and says they want help to do it, LLMs will output what is most likely and relevant to the user’s request – unless you build guardrails.

The flipside of being part of the Smartphone Free Childhood movement is that I am also active in building software with AI and developing agents to benefit professionals. What really frustrates me is that it is actually fairly straightforward to take measures to make products like Character.ai safer and to establish solid guardrails. Nothing involving AI will ever be 100% safe – but very little in life is. What people want is to know that companies offering AI agent products are developing them with genuine consideration for safety.

Character.ai has since said they will not allow under-18s on their platform, but I don’t see how they can enforce this. We’ve already seen, with the UK’s age verification laws coming into effect, that children will just find a way around them. Children have always been better than adults at adopting new technology and using it.

Let’s assume it isn’t possible to stop children accessing the platform and that it makes more sense to give them safe access with parental and platform oversight. What does this look like?

Parental Oversight

The concept of parental control over child accounts already exists in many areas. The Apple ecosystem is well known for offering this, and I use it for my family. My children need to use computers for schoolwork, and they have their own Apple accounts that are part of our family group, where I have oversight of what they see and control over which apps and websites they can access. For Character.ai, it could work much the same way.

The parent’s account could show different levels of detail about the child’s activity. This might be a full audit log of every chat thread, with all messages – but would that encourage the child to use the platform elsewhere, where they aren’t observed? Another option could be to classify common themes of conversation and notify parents about worrying or potentially harmful topics. This is not difficult to build. LLMs can easily perform the classification, as the work is linguistic. LLMs are well suited to this and require minimal prompt engineering or expensive models.

Platform Oversight

From the excerpts of the conversations with the child in the case above, there seems to have been insufficient guidance given to the LLM in its prompt. I have built systems that require guardrails to prevent unsafe responses from a professional accuracy point of view, and they work well. If the prompt is clear about where the LLM should not respond or should provide a warning, it generally works. This should have been the first step.

Secondly, a verification step could briefly use another fast LLM to classify a response from the platform as safe or unsafe in context. If unsafe, a safety message could be sent instead of a direct reply or affirmation. This would protect against jailbreaks in the first LLM and its prompt.

Thirdly, messages and conversation threads can be classified by theme. It’s easy to flag words that indicate high risk and to generate a risk score from these inputs to determine whether a conversation exceeds a tolerable risk threshold. Where it does, there should be a final line of defence: human operators who can review these conversations and intervene if necessary – for example, by alerting parents or prompting the AI agent to guide the user in a healthier direction.

Conclusion

If the guardrails I described above were in place1, I think many people would feel that adequate steps had been taken. The general approach I’ve outlined can be applied to all B2C agentic platforms. The platform oversight guardrails should also apply to adults. Many adults struggle with mental illness and use these platforms as a crutch, and others simply need this level of care. Inevitably, these systems will begin to act in a therapeutic way – and we already have strict rules for how therapists interact with patients. Similar principles could be incorporated into the prompts and platform oversight systems I described above.

Few people expect 100% safety from these platforms – they simply expect a reasonable level of care. This is also why I wouldn’t look to regulate them in a similar way to how actual human therapists are required to have certain qualifications to practice. It’s not reasonable to expect that level of compliance, and the companies haven’t set out to offer a replacement for therapists, but it is reasonable to have used good practices in applying guardrails.

Companies aiming to offer AI Agent experiences for consumers need to decide to prioritise safety; otherwise, they risk becoming the next toxic platform. Social media platforms have always had the indirectness of their algorithmic feeds as cover for the harm they cause. AI agent platforms don’t have that cover, as their interaction with users is direct. Governments around the world will find it difficult to avoid banning platforms that actively guide users towards harm.

When the public becomes fearful of AI systems in general because of a few careless actors, it harms the entire industry.

I was interested to try out ChatGPT Atlas, like many people. I genuinely wasn’t sure of the point of the product, which actually made it more interesting to me, as usually the point of a new product is quite clear.

Upon downloading, installing and opening the macOS app, I was underwhelmed. It’s just a fairly basic browser experience. I don’t see why it would have such a draw that people would switch over, learn new keyboard shortcuts, and move bookmarks and passwords1. Sure, it’s nice to be able to open the panel and use ChatGPT in context, but it’s not that much harder than copying and pasting text or links into the ChatGPT tab I always have open.

Of course, ChatGPT may become more helpful as it observes your browsing habits, but this also has security implications. Perhaps it could discover new and interesting content based on what you’ve been reading and asking it to summarise or interact with. Perhaps it could even identify more interesting material when it notices that you’ve read it yourself rather than asking for a summary. It might eventually offer entirely synthesised content that exists only for you—tailored to your interests but still anchored in the ‘truth’ of existing content2.

It’s like a series of conversion steps of interest: clicked the link, looked at the content, scrolled a bit, asked ChatGPT about it or to summarise it, read it yourself, shared it. The perfect dataset to build a recommender system. Still, I didn’t think it would be that impactful as a launch. I don’t believe the current benefits balance with the drawbacks enough to persuade people to move from their favourite browser. After all, your favourite browser is like your favourite brand of underwear—are you really going to switch if you’re comfy?

Then the other, and perhaps main, purpose of Atlas dawned on me. I wanted ChatGPT to summarise a blog post I couldn’t be bothered to read. When I pasted the link into ChatGPT, it couldn’t open it—probably because of a robots.txt restriction or something else preventing it from consuming the content.

When I pasted the same link into an Atlas tab, it opened immediately because Atlas is a browser. Then, when I used the right-hand panel to ask ChatGPT to summarise it, it was able to do so because it already had the rendered page to look at.

Atlas is a way for OpenAI to gain access to new training material currently unavailable to it—effectively crowdsourcing access to the parts of the internet it isn’t otherwise allowed to use, or which are paywalled. If even one percent of users switch to Atlas, OpenAI will have access to 99 percent of the content it doesn’t have today. From a legal point of view, this doesn’t appear as OpenAI accessing unauthorised content; instead, it’s users feeding content to it, without the system knowing whether it’s allowed to see it or not. It’s equivalent to us copying and pasting the text of an article—whose link ChatGPT wouldn’t be allowed to open—into the chat. OpenAI has simply made this an implicit step: asking the ChatGPT panel anything about an open page effectively copies the page into it. It now holds the URL and its content as a key–value pair, even where it wouldn’t normally be allowed to open the URL directly.

Many have said that OpenAI is running out of high-quality training content for new models. It looks as though they’ve found a solution to that problem. OpenAI gains access to all its users’ paid content subscriptions and any link3 they view—robots.txt or not.

A couple of weeks ago, we were all wondering if a certain insider scoop was for real…

Founders were saying it was, that the source was too well-connected. Others were saying it made sense, Tristan and George are friends, they’re stronger together, Fivetran would then own all the modern data stack transformation tech… and so on.

Well, Day 1 of dbt Coalesce confirmed the rumours - dbt Labs and Fivetran are indeed merging.

Before the Big Data era which preceded the Modern Data Stack era, we had four monolithic data stacks: Teradata, MS SQL Server, Oracle and IBM. They couldn’t handle the size of the post dot.com era clickstream datasets, but they did have the ability to do everything in one stack… even if badly. You could make reports with SSRS, and perhaps their style would now be called ‘retro’. You could run analytical queries with Oracle databases, the one I learned SQL on in 2010. You could ETL using Excel, VBA and SSIS… it was bad and took days to run, but you could do it.

Looking at the stack below, you see all the same pieces save a query engine. Now, with truly decoupled storage and compute with the widespread adoption of Iceberg, it need only be a query engine. It looks very similar to Databricks, but without query engines of course.

I feel like we’re entering a new era of cloud monolithic stacks. Fivetran-dbt, GCP, Microsoft Fabric, Databricks and Snowflake. After all, the only reason the original era of on-prem data platforms ended was because of their inability to handle large datasets and unwillingness to modernise and risk cannibalising their own business models. Those companies had the capital and talent to build cloud data warehouses and use columnar storage, but they didn’t want to upset their business models. Microsoft’s Fabric business line and Oracle’s analytics business line are still probably bigger than all but Databricks and Snowflake in the MDS and Big Data era companies.

Out of every boom and bust in tech, lasting winners emerge. Databricks from the Big Data era. Snowflake and perhaps Fivetran-dbt from the MDS era. The modern data stack really is dead now. I don’t think this large ecosystem with as many companies as pixels in Matt Turck’s face will last - it’s already collapsing towards the bigger gravity wells on the diagram. The time of data folks being able to happily choose from five different SaaS and open-source solutions to do the same thing won’t continue - we will be forced to choose from one of the monoliths and stay on the menu.

If you look at the diagram above, there is no mention of SQLMesh. It’s beginning to look like a plan - to make one single standard for transformation. SQLMesh looks like it’s going to fade away, like some kind of inconvenience1 to this main story. Snowflake and Databricks will invest more in their own transformation offerings to avoid dependence on what is now a most likely a rival.

What is the next era? I genuinely think it could be the year of the duck. DuckDB2 is still going from strength to strength, from extension to extension. I expect that the next dbt-core will be a DuckDB extension, even if I have to build it myself3. Tightly coupled is the new black.

Over the last few years, I have really wanted to have an open standard for semantic layers. Something that would make semantic layer definition code (probably YAML) portable, to be used between BI tools, standalone semantic layers and other data products. In a way, open-source Cube has been this in the past, it is a very well-used open-source project with known users in pretty much all big tech companies. However, it has never had enough support from other BI tools which, along with the drive towards AI, led to Cube pursuing their own agentic BI tool in Cube Cloud.

I have also been critical of newer technologies like Malloy, which have similar aims to semantic layers but seemed less practical. My thinking was that getting users to learn a new DSL when we already have SQL, YAML, MDX, DAX… was a bad idea and doomed to fail. However, with AI, perhaps value can be had. If Malloy is like a tool to be used by AI and core definitions also maintained by AI, then no new DSL needs to be learned by any human.

Out comes a new standard, spearheaded by Snowflake, Salesforce(Tableau) and others - the Open Semantic Interchange. Surely, this is great news. I should be really pleased, right? sent me the article announcing it and asked me if I thought it was a big deal before I had seen it on LinkedIn1 . The thing is, I’m not that bothered, and I had to think for a moment as to why. I’m sure it would have felt like bigger news had I still been at Cube, but even so… Then it dawned on me - this level of standardisation is much more valuable when human beings are having to learn the DSL. It makes them much less worried that they are learning or deploying something that ends up being niche or unadopted.

I don’t really believe that semantic layer code will be managed by humans in the near term. Now that I have great tools like Claude Code and Codex CLI, I don’t really find myself writing semantic layer YAML any more. Even when they make mistakes, I feed the semantic layer compiler errors back in and let them fix the problem.

I recently had to convert some dbt Metricflow YAML to Hex’s new semantic layer YAML standard. Most semantic layer YAML has ended up very similar to LookML, including Cube, Hex, Count, Snowflake, Thoughtspot and Databricks. In fact, Metricflow is one of the more unusual syntaxes out there. So I typed Claude into Ghostty… I showed it the Hex and Metricflow specs, I told it where the files to convert were, and off it went. The first two times, upon compilation in Hex, there were errors but I fed these back into Claude Code and upon the third attempt, generated correct Hex semantic YAML. I then asked Claude Code to make an agent markdown file from what it had learned, so that I could make an agent to do this for me should I need to do it again.

My point is that the cost of translation between different standards, especially when they are so similar, is next to nil. That doesn’t mean there is no value in an open standard that is well-adopted. It’s just that the value is diminished. This is partly why I’m not that excited about it. The driving force behind this new open standard is a desire for increased adoption of semantic layers, driven by the clear demand for AI access to data. However, this very driving force is also why the open standard isn’t as valuable as it could have been in the past.

Enterprise demand for AI capabilities drives the urgency behind OSI. Snowflake reported that nearly half of new customers in Q2 fiscal 2026 chose the platform for AI capabilities, with over 6,100 customers using its AI offerings weekly. - link

For me, the peak moment when an open semantic standard could have been most valuable was soon after Looker got acquired by GCP. Looker was gaining market share fast before the acquisition, and afterwards users were concerned with lock-in. Companies like Lightdash have succeeded, in part, by addressing these concerns. In hindsight, an open-source BI tool that took a LookML repo as-is and functioned fully with its definitions could have been a great idea.

There are also notable exceptions in the launch partners in Databricks, AtScale and Microsoft. Microsoft, through MDX and DAX, have over half of all semantic layer usage easily. They will never sign up to such a standard - it’s not in their interest. I think this is true of GCP too. That doesn’t mean an open standard won’t work without Microsoft, but I would expect that both Databricks and Snowflake would adopt it for it to be meaningful, as they are the two big independent forces in data away from GCP and Microsoft.

I also know that both Snowflake and Databricks expect semantic layer definitions to one day exist as extensions to their warehouse SQL. They may well support a YAML format too, but it shows they are hedging their bets and would rather lock in customers to something specific to their warehouse for retention and performance.

The standard could still be useful if it makes it easy to move definitions between commonly used tools like Hex and dbt, and, indeed, tools commonly used together.

I also doubt that the same YAML in the open standard will be compiled to exactly the same executable code between any given permutation of compiler2 and underlying warehouse. It will probably be the same most of the time and produce the same results most of the time, but not all of the time. I think this inconsistency will feel similar to how adoption of ANSI-SQL varies from database to database and how the same SQL on the same data on different platforms can output slightly different results.

Participant-specific model mapping and read/write code modules: These modules will convert OSI models to participant-specific models/languages and will be part of the Apache open-source project.3 - link

I am hopeful the creation of the standard and adoption of it by vendors will improve things, but to me there is a clear XKCD 927 risk.

As many of you will have heard, the company that looked after SQLGlot and SQLMesh, Tobiko Data, was recently acquired by Fivetran - one of the biggest companies to have come out of the modern data stack era.

Now that the dust has settled - it’s been a couple of weeks since the announcement - I thought it would be good to evaluate what it means for data folks and how I feel about it in general.

There is one sense in which I have no conflict in my thinking. I have got to know the Tobiko team since starting my series on SQLMesh, having since overseen real deployments. I’m very happy for them in the sense that they built something great, and that they have had what I assume is a successful1 exit🫡.

After all, the reality of founding companies, especially in VC, is that the company will one day be sold and investors and founders make money. I know people don’t like to be so explicit about this: they like to talk about the mission and that they’re building a company not to be acquired, but to become a public company… one with its own tower in San Francisco, with its logo lit up for the whole city to see. There are very few such companies… you probably know most of their names. Most VC-backed companies that have a successful exit are acquired. These exits aren’t so glamorous, they don’t get to ring the bell at the stock exchange, the founders end up taking middle-management roles at the acquirer with a length of lock-in… they might get a cool LinkedIn announcement and article in TechCrunch.

So that’s fine, from an economic point of view everything makes sense for Tobiko as a company and that’s why it happened.

What about for us data folks?

So this is where, even with a bit of time passed, I still don’t think it’s good for us. As much as Fivetran are currently saying that the open source SQLMesh and SQLGlot projects will remain and be maintained… I don’t expect this to be the case for that long - all it takes is one difficult quarter and anything unnecessary gets axed. Fundamentally, it is difficult to justify spending expensive engineering time and resource on a free product that could cannibalise the paid one. This is the friction we’ve seen between dbt core and Cloud and we know where that has ended up: a solid enterprise offering with good feature release cadence but with support for open source neglected and now diverged since the dbt Fusion engine.

Learn Analytics Engineering

dbt Fusion Has People Divided- Here's Why

Anything that elicits such strong responses (in both directions) from a community deserves to be talked about further. Based on the title, you probably already know I’m talking about dbt Labs’ new engine called dbt Fusion…

Read more

9 months ago · 5 likes · 1 comment · Madison Mae

This negates the idea that the goodwill from community is valuable enough to support the open source project, because if anyone could have done this, dbt could have. Fivetran started as a profit-making company with a proprietary product, and haven’t been afraid to change prices (to their customer’s annoyance)… there is not much in the way of community love or trust. It’s just an easy to use product that is the right choice in many circumstances.

Let’s assume then that SQLMesh is long-term available inside Fivetran only. A lot of us buy Fivetran2 as part of our data stack, so in that sense it’s great because we get something from a vendor we already work with and don’t have to pass another infosec review etc. Fivetran have also recently bought Census, so they can extract and load data. They were previously using dbt transforms, allowing them to also send transformed data to target systems. They were previously also relying on dbt open source for their transforms, but as I mentioned above, this is now a neglected project. It would be much better for Fivetran to own their own transformation technology, and now they do. As far as I’m concerned, it is a market leading technology, too. So now Fivetran really is the Informatica of this generation. I also think that this makes Fivetran one of dbt Labs’ biggest rivals now.

However, even for those of us who do buy Fivetran, this is not all good news. Fivetran will eventually charge for SQLMesh transformation… otherwise there was no point in buying it. Fivetran need to grow their revenue through cross-selling a new product to the customers they already sell connector services to. So, if you were previously using Fivetran for connectors, and using your orchestrator to run SQLMesh jobs afterwards, you will eventually need to pay Fivetran to run these SQLMesh jobs for you. Now there will certainly be savings to be had through reduced infrastructure work for data and analytics engineers, but it will also be constrained to work inside Fivetran, however this ends up looking… at best it will be like using a CLI (much like the dbt Cloud CLI) and VSCode extension that will run tasks on Fivetran remotely.

For those of us who don’t buy Fivetran, or want to come off it, or wanted to use SQLMesh independently… things become difficult. At the start of last year, we had the choice of SDF, dbt, SQLMesh and new upstarts including Quary. Long-term, we really just have dbt Cloud and Fivetran(SQLMesh)… you could hand-roll your own SQL in your orchestrator or you can pay up or you can fork one of dbt core and SQLMesh and maintain it yourself.

There are also data warehouse/lakehouse transformation methods offered by Databricks, Snowflake and some newer entrants like Bauplan, which we never used to consider because of lock-in. However, now that lock-in of some kind is inevitable, we might as well consider them, too. It feels like there is room for a new challenger, but at the same time I’m getting tired of having to learn new frameworks to achieve the same thing.

Perhaps it’s actually reasonable enough to vibe code your own transformation framework that works for your specific project, and suits your style of writing transformation code. It’s free like a puppy, but at least it’s your dog.

This week, I travelled to Berlin to speak at Data Days Berlin. It was organised by a data consultancy called A11, which has recently spun out of a VC fund called Project A, who had originally built this consultancy for portfolio companies. This is the first year that the conference has been open to people outside of Project A portcos, and it was really great to attend and speak. Everything from the venue to the social events was really enjoyable, too!

The conference audience was curated by the organising team to filter to people accomplished in the data industry, which made it a really great bunch of people to meet and to present to. When I asked: “Who knows what a semantic layer in data is?”, more than half the audience put their hands up, which is unusual. I have spoken to audiences at data events where less than half know what SQL is.

The talks I managed to catch were high quality. They seemed to be split between impact focus and how to operate data in organisations to drive value, alongside technical excellence and innovation. This is logical, because data leaders need to be able to excel both as technologists and business people. Strangely, I feel this AI era means we actually need to be better at both at the same time.

Tools like Claude Code, Cursor etc make us more capable of doing our technical work and allow us to be more ambitious. Vendors we use are rapidly releasing new features for us to, in turn, share with our stakeholders.

Our stakeholders are clear about what they want. They want AI access to accurate, consistent data. They think this will be by MCP in ChatGPT Enterprise/MS Copilot/Claude Desktop. They still want us to be responsible and accountable for the provision of this access and the quality of the outputs. Maybe this means dashboards are dead, but BI just entered beast mode.

There are more semantic layers being heavily invested in by huge tech companies, being built by startups or simply being deployed by startups into other AI applications than ever before. I think even by a factor of 10x than at any time in the past.

Why is this? For the reasons above… Stakeholders want AI access to data, they have made this our top priority and told us to get it done1. I’m working with an organisation that, through their existing vendor relationships, have access to four2 semantic layers and are in the process of trying out three of them, with the aim of making a champion available via MCP in ChatGPT Enterprise as soon as possible. The stakeholders want AI access, the vendors and data teams now both know3 they need a semantic layer to make this work - money, attention, product-focus directs to semantic layers.

With this increased attention on semantic layers and the focus on AI, I feel the era of humans having to create and maintain semantic layers is coming to an end. This was always one of the challenges for semantic layer proliferation. Why do I have to learn another tool? Why do I have to complicate my stack? I don’t have time right now to invest in building the semantic layer. Why can’t we just have a good data model?

If AI looks after the semantic layer, then all of these questions and concerns disappear. The semantic layer is something that AI can create from scratch, from existing metadata or with some limited input from a human in natural language. It can then be maintained through human use and human requests for extension with human approval of changes. All without humans looking after more software, or learning another domain specific language. This isn’t science-fiction - I have already seen tools doing this today, and I predict most vendors who provide a semantic layer will offer this by the end of next year.

Well, I hope to be back in Berlin soon to stay in touch with the friends I made at Data Days and to spend time with even more people from the data community here!

I am co-hosting London Analytics Meetup X with DeepMind on 24th September - if you’re in town for Big Data London, it would be great to see you! Check out the details here.

For the vast majority of human history, the main way to address many people in order to share public information was to stand on a hill or a platform, in a space where as many people as possible could hear you and you could speak to them. There is obvious evidence of this scattered around the world: Red Square, Tiananmen Square, St Peter’s Square, Roman amphitheatres... Part of why this is the case is that for most of human history, whilst we’ve always had language, most humans haven’t been literate. So you had to be heard directly by them if you wanted to share a message, and didn’t want to rely on second hand relaying.

The maximum number of people you can address directly is in the tens of thousands unamplified, which, before the 20th century, was how all addresses happened. In theory, it’s since become possible to fill a giant plain or field with tens of millions of people and, with amplification, address them, but there is a limit to what you could really call ‘direct’. At some number, most people will be seeing the speaker on a screen and hearing through speakers and then it’s functionally the same as watching an address live at the cinema with others.

Television addresses then extended this to be able to address pretty much anyone who is awake to watch, which is dependent on timezone and people having televisions and electricity. The internet then extended this further, to anyone who has an internet connection and can find the address: think YouTube live streams where hundreds of millions can watch big events. Finally, if you think about asynchronous content like blog posts, viral social posts etc, then the whole connected world could see these, and it then comes down to whether they’re interested or not.

The problem with addressing more and more people with the same content is relevance. The more people you address, the less relevant it is to the average person addressed. There are exceptions to this, like for example a presidential address could be considered relevant to the whole country, but vast swathes of the population would still have no interest in hearing from their President.

Marketing has tried to address this problem of relevancy through segmentation. If you have a large potential audience like the internet, who have a near infinite amount of content and streams to ignore, then you have to be as relevant as possible and in the right place at the right time to cut through the noise. This activity, and the mastery of it, is what has made Google so valuable, having been the most valuable company in the world on multiple occasions.

However, even fine segmentation ends up crude. Broad segmentation gives significant sample size, as well as clarity of preference between one segment and another, but with lower average relevance. Fine segmentation can give higher relevance, but less clarity and certainty about preferences and relevance due to disparate segment sizes, with some very small segments. Marketers have had to balance this for a long time and optimise marketing spend in this way. Finding the right segment, channel, time, message, call to action… It’s even been called personalisation, but it’s never been personal. It’s always been about pigeon-holing you in as appropriate a hole as possible.

Now, if you think about why we’ve gone from sharing the same message to as many people as possible to segmentation in the connected world, the reason is that the idea of addressing every single person specifically and individually hasn’t been possible. Until now.

It’s possible that 1 billion people will use something like ChatGPT every day within a few years, and, if you include Google’s new AI search functionality, that may even be next year. With chat-based AI systems like this, you can address everyone personally. People are now regularly asking them questions, correcting them, continuing conversations. You don’t need to segment them to an approximate preference group. You can just know what they are directly. You could even just ask them. You can tailor every address to every single person according to their styles, likes, interests. Every product, service or content can be assessed and addressed personally for relevance and preference to that person.

Leaders, governments, companies, organisations… around the world could become more accessible to the public. Gov.chat. You could canvass voters at a never-before-seen level. Worried that a policy isn’t popular? Ask the public, the whole public, not some biased focus group, about their preference. It’s a two-way conversation too - every member of the public who wants to ask something or say something can do so, and it can be aggregated by similarity or matched against law, policy, content to be answered. The few truly novel questions then become answerable by humans.

Or, would these leaders, governments, companies and organisations learn about your fears, worries, insecurities and weaknesses, and tailor their interactions with you to manipulate you to do what they want? Buy this, vote for this, believe this, hate those people…

As usual, the truth will be in the middle.

Every influencer, thought-leader or blogger could have their own agent: Benn.agent for post-modern data realism, Joe.agent for platform-agnostic data engineering principles, Madison.agent for analytics engineering help, Zach.agent and Ben.agent for data engineering guidance, Jess.agent for SQL and remote work envy, Randy.agent for product analytics, Ananth.agent for data engineering news… David.agent for an esoteric combination of all of these, with sprinklings of AI and semantic layers, and whatever else is distracting me right now. It’s like simulating what they would say to any question or topic in your head1, except with higher RAG-driven accuracy.

An agent can sound like me and say the same things as me, because I have already said a lot of things. I have produced a lot of text. Hundreds of thousands of tokens. Hundreds of vectors to search for relevant topics. An imprint of me, an essence of my thoughts.

Today marks my last day at Cube.

Firstly, I’d like to say thank you to everyone I’ve worked with there and who ultimately provided Michael and I with an exit where we were able to make all our investors whole and to continue to work on applying AI to semantic layers.

I’m lucky enough to be in a position that I am able to make ends meet from my other income. So please don’t take this as one of those posts eliciting sympathy for a difficult situation post-job, this is not the case - I’m just reflecting.

I still believe that Cube has the best universal semantic layer out there, and it is the only fully functional open source one of enough significance to be considered an open standard. Godspeed to the Cube team as they continue on their agentic analytics journey. I truly wish them the best and every success on this journey.

I still believe that semantic layers are important and even more so than when I first started writing about them a few years ago. I still remember the magic of using LookML for the first time in 2019. It’s been a bumpy road for semantic layers in that time, but now that the impetus from agentic analytics is driving our industry forward, this time by stakeholders dragging us forward instead of technologists, I think we’re nearly there. Every cloud data platform provider now except AWS… Databricks, Snowflake, GCP, MSFabric, now have a semantic layer of some form that isn’t just a knowledge graph but also has a compiler.

The question I have for the future is whether the semantic layer needs to be seen or can fade into the background. Semantic layers need to exist and need to be codified and compiled, but does that mean humans need to see it or touch it directly? Can AI maintain semantic layers in an invisible way for normal operation? Sure, if you ask the definition of a metric or how the data model fits together, it can answer you. This doesn’t have to mean that human engineers maintain it as code. This is the way that many BI tools that have semantic layers are going. To start with, they are offering extension and maintenance using AI, then they will offer initial creation, then agents will simply show you the code and explain changes they will make… will they always have to show you the code?

It will feel like the formation of collective neural pathways to use data. The pathways are reused, the pathways provide fast and consistent operation, the pathways slowly evolve as definitions and models change over time. An automatically managed codification of collective truth with data. I’m excited to see who succeeds here first!

There has been a lot of discussion about whether junior engineering roles of all kinds will disappear completely.

You may have read some of my recent posts and thought that my point of view was that they would disappear, but it’s not quite so binary as that. I can see that high-growth early-stage companies may never hire junior engineers again, but they are quite small companies and didn’t really hire juniors much anyway, because they didn’t have the bandwidth to train them.

The other driving force is that large tech companies are laying off and not hiring as many engineers, and they are definitely not hiring juniors in the same way anymore. Previously, graduates from Stanford, Berkeley, MIT, Oxford, Cambridge, Imperial, etc in CompSci didn’t have to look hard for work after graduating, if they had to look at all. The big tech companies would look to hire as many of these graduates as possible to enter their graduate schemes and fill the pipeline of future labour they would need. This is clearly no longer happening, mostly because tech companies don’t believe they will need as many humans in the future.

However, I doubt they aren’t hiring any junior engineers at all... They’re probably still hiring at least 10% of the graduates they used to, and perhaps these are the very best who, during their time in education, had already built a lot of things and contributed meaningfully to open source software, etc. In traditional industries, this reduction in hiring is probably not nearly as severe. I doubt large banks have significantly changed their hiring practices in the past year. In traditional industries, I think at least 50% of junior engineering positions in a given year would still exist.

So, clearly, this is not an extinction. It’s a reduction. One thing that I think we are very close to achieving is having AI-augmented engineers capable of handling a significantly larger volume of work than engineers of 4 years ago.

Others have argued that we’re creating a significant problem for ourselves by not hiring junior engineers. Now, we’re not talking about none at all - let’s say 50% of what we used to across all industries at worst case, which is still a lot, given how many we used to hire across the world. Junior engineers typically spend about 5 years advancing to mid- to senior-level engineers. Five years from now, the level of AI-augmentation in engineering will be inconceivable compared to what we see today with market-leading tools like Claude Code. I think if we even have half the pipeline of engineering talent come through at that time, we will have more than enough human labour to do all the engineering work we need to with AI Assistance.

This also doesn’t mean there is no work at all for graduates who no longer have traditional engineering jobs to pursue. ’s post, which I linked above, shared some ideas about what the new important skills would be, and I agree with them:

Today, companies hire for coding chops, writing skills, or analysis ability. Those roles will shrink and be replaced by people who can become experts at:

• Prompting and directing AI agents precisely

• Clear communication, turning complex ideas into effective prompts

• Multi-tasking expertise, quickly and constantly context-switching and responding to different AIs at their stopping points

• AI orchestration, using different AI agents and having them check each other

• Managing AI workflows and knowing when to intervene

• Native AI intuition, an intuitive understanding of how AI works, where it is likely to go wrong, and how to keep it on track

The skillset that Charlie describes is a mixture of Product Manager, Architect and Engineering Manager in today’s roles, in addition to AI specialism, which will diminish over time as we need to compensate less for AI's rough edges. I also think architecture skills are incredibly useful in this new world, too.

This speed of iteration is something I’ve been thinking about a lot. Right now, if you want a human engineer to make a change, regardless of size, you have to follow a process:

1. Get that engineer’s attention. You might be able to ping them on Slack and get them to drop what they’re doing immediately, but often you need to have what you want prioritised through backlog grooming and scheduled into a sprint sometime this quarter.

2. Then, once you have the engineer’s attention for the task at hand, you would typically discuss it with them on a call or face-to-face to ensure maximum context sharing, and perhaps send at least a few messages over Slack or on your Jira ticket if there is already a lot of shared context.

3. Then the engineer might go home and then to sleep because it’s the end of the working day, and they had meetings and other tasks to attend to before working on what you wanted.

4. Then they’ll spend something like half a day getting their head into the context, asking clarifying questions once they fully understand the situation and any unseen tradeoffs.

5. Then they might spend another half a day making the change, writing tests, etc.

6. Finally, you have something to see in a demo environment.

The day I suggested the engineer would spend on the small change includes all the human-related activities like getting coffee, going to the bathroom, having lunch, chatting with Mike about the upcoming Neuromancer TV adaptation, responding to significant other’s Whatsapp messages, catching up with Substack and HackerNews... It could be a bit shorter or much longer.

If you had asked Claude Code to make the change, it would have made an attempt, and if it was allowed to keep iterating without intervention, would make a “boop” sound from your terminal a few minutes later, in less than the time it took you to read this far in this post.

It may then need you to unblock it by providing an API key or some kind of direction, or allow it to run main.py on your machine. You may need to go through a handful more iterations than this, but within some time that is probably less than half an hour, you will have something that does what you want unless you have been far too ambitious or unclear.

Then you can taste test and iterate. Within a day, you can have what would have taken weeks with other humans. Yes, there still needs to be oversight and strong review processes for merging anything, and maybe a level of rewrite required to meet specific company code standards. This is where you have true production with paying customers - where you don’t yet, you can YOLO and merge. The speed at which new products can be created and released has increased by 10 to 100 times in just three years.

Startups that aim to fail fast can build in a week, attempt to sell the following week, and choose to pivot within a month of product idea inception.

We’re also seeing that the successful products of this generation are not expensive SaaS tools with enterprise sales cycles. They are cheap subscription-based products which cost $10 to $201 per user per month. These products ship updates daily; they aren’t overly concerned with shipping a few bugs because their customers don’t pay enough to complain very loudly. The key is taste - does the product work well enough to please their customer, does the velocity in releases keep the product ahead of the competition sufficiently that customers don’t jump ship2.

I wrote the initial part of this article in June… things move fast in the AI world!

Recently, I heard the news that Anthropic had removed first-party access to Windsurf. Anthropic’s Claude 3.5+ models have been the ones that I have mostly used in Windsurf and Cursor, so this news is somewhat disconcerting. If I wanted to use Claude in proactive AI coding1 workflows, I’ll have to use another tool like Cursor, Void or nao.

I’ve had such good results using these Claude models for this workflow that I haven’t felt the need to try Gemini 2.5 Pro yet, but it looks like I will end up doing that sooner rather than later.

A few weeks ago, I wrote about how I thought that Windsurf joining OpenAI could open a whole raft of possible advantages in terms of better model access, specialised model creation for different Windsurf flow states, and just raw GPU muscle for the Windsurf team to use to build new models of their own - which it turns out they were doing long before the acquisition.

This development reveals the darker and more troubling side of the situation. Despite many thousands or even hundreds of thousands of Windsurf users enjoying Anthropic models in Windsurf, who have no additional affiliation with OpenAI prior to the acquisition, Anthropic (clearly for competitive reasons) has decided to revoke access.

This isn’t unexpected; Windsurf essentially serves as both a training data generator and a tool for coding. It continuously generates context for AI-generated code, including the code that was actually generated, as well as various approximate and direct confirmations of quality. It’s very easy to generate a huge training set where Anthropic’s models have generated the code, and it has been confirmed to be good. This training set is then used to build Windsurf’s own models. Clearly, this was tolerable to Anthropic while Windsurf was independent, but now, faced with the possibility of enhancing their largest competitor’s models, too… a bridge too far.

While the advantages I discussed above and in my previous post are clear for Windsurf within OpenAI, there are also clear disadvantages. If Cursor remains independent, it is possible that they will continue to enjoy being able to use any model they like, whereas Windsurf is being restricted to fewer. If GCP decide also to remove access to Gemini models, then Windsurf becomes very restricted indeed.

It would seem very unlikely that OpenAI would go tit for tat and restrict use of its models in Cursor in order to counter the disadvantage now felt by Windsurf, as Cursor’s use of OpenAI models generates a very valuable training dataset for OpenAI.

As I said above, I wrote the first part of this post in June and then published some posts related to other ideas instead. Some unexpected events occurred after this!

The OpenAI deal suddenly falls apart, and the first we hear about it is that the founders and core AI engineers at Windsurf are moving to GCP, seemingly leaving the rest of the company behind. The GCP deal is a HALO agreement, where they have a non-exclusive license for Windsurf’s IP, for which they paid $ 2.4 B.

You’d imagine that with this much money going round, the investors in Windsurf and the remaining staff are made whole. After all, many members of the Windsurf team would have incurred significant opportunity costs to join a high-growth organisation with no reason to believe it would soon cease to be an independent company. However, we don’t know the details, and we probably never will. By the time we might have the information, our attention will have moved on, and we won’t take the time to find it.

The reason the OpenAI deal fell apart seems to be that OpenAI didn’t want the intellectual property acquired with Windsurf to be accessible to Microsoft, but they couldn’t get this to work legally so they pulled out of the deal. This is a worrying sign for OpenAI; clearly, they felt it was worth a lot of value to acquire Windsurf, and they had looked at Cursor before, but the price was too steep.

AI-powered IDEs are one of the clearest winning use cases for LLMs, which also have a flywheel effect in generating high-quality training data to then improve LLMs’ ability to serve the use case. OpenAI took the time to announce the deal to great fanfare and then had to pull out, which is frankly pretty embarrassing. I’m sure there will be other tales about what happened in order to soften the impact, but fundamentally, if you’re going to announce something like an acquisition, it doesn’t look good if you’re forced to back out.

I think this effect of the investment from Microsoft and OpenAI’s legal structure could make OpenAI less able to compete against its rivals who don’t have the same encumbrance. If Microsoft had access to the IP, then OpenAI would strengthen Microsoft through their acquisition and wouldn’t gain any IP that was uniquely theirs, eliminating the point of acquiring it in the first place. The more I think about it, the more this feels like a noose.

Then as a final twist, the remainder of Windsurf gets acquired by Cognition, who are the makers of Devin. I really think this is a great fit2. There is a continuum of how AI can be involved with software engineering, with Windsurf on the left (pretty close to how SWE is done now, but with copilot and IDE agent) and Devin on the right (about as far away from how SWE is done now as is possible3). The activity on Windsurf produces the perfect training data and subagents to then improve Devin.

You can envisage land and expand happening, initially with engineers at a company having access to Windsurf as the first product offering in a deal with Cognition, and then gradually transferring more and more of the process until they are using Devin, with the engineers supervising and designing instead of actually building.

The first steps would be using Devin in CI to perform linting, document changes, adding test coverage, and implementing telemetry coverage. This would also involve enforcing code standards, adhering to package update policies, and handling DevOps tasks, including penetration tests, minor bug fixes, and investigating and resolving medium to major bugs. Then, once Devin was trusted to do these things, you’d start to use it with Jira to complete tasks of a small t-shirt size, which are well-documented and described by a product manager. The product managers begin to see the point in finally writing good PRDs with clear requirements, and writing bigger epochs, with the assistance of AI, that get split into many smaller tasks that can be worked on in parallel by many agents. I think where you go beyond this point, you’re in Loveable and Bolt territory.

Working with Claude Code in recent days has made me feel like the progression I described above is possible and even probable, when I didn’t feel like that before. It’s made me that much more capable than I was with Windsurf (in fact, I’ve begun to use Claude Code in Windsurf, and it’s a pretty great experience, especially where you know the space very well).

Now that Windsurf are part of Cognition, they have been allowed to offer all Anthropic models again, so we’re back to where we started at the beginning of this post… but a lot has changed, too.

There are lot of people out there saying that this is the end of software and data engineering, and that these jobs will not exist in the near future. I’m not sure that this will be the case. I think what is more likely is that we will use fewer humans to do more work and after this progresses to a certain point, the cost savings from having fewer humans diminishes. Imagine having one staff/principal engineer working with AI/agents or whatever the next thing will be, doing the work of 10 or more engineers in the pre-AI era.

This kind of force multiplier is almost certainly possible. There are huge benefits in only having one engineer in an engineering team. One engineer can essentially move at whatever speed they like, they don’t have to bring everyone else with them. They don’t have to spend loads of time on documentation and meetings. They don’t have to share context. They don’t have to train up junior engineers1.

Having this one staff/principal engineer will not cost anything like having the 10 engineer team with management costs. It will most likely cost less than 10% of the old-style team. Largely, this could translate to it costing less than one tenth of what it used to, to build the product. Making this kind of saving in operating cost is too attractive for any company to miss and we are seeing companies around the world already start to move this way. However, trying to have another order of magnitude of savings is much less appealing. You then only save 90% of the cost of one engineer or maybe a bit less, as the engineer doing the equivalent of a 100 person pre-AI engineering team can ask for a fortune in package that the engineer doing the equivalent of 10 can’t.

It starts to get perilous, too. Many companies don’t have 100 engineers. If you only have one engineer, what happens when they leave? AI is not in a place to be entirely responsible for engineering at companies yet, nor will it be for some time. However, having 10 engineers instead of 100 seems much less problematic to me.

One thing that I do believe will disappear entirely is off-shoring. At many of the companies I have worked at or worked with, it was common to have a huge number of engineers in Asia or Eastern Europe. It had become difficult and expensive to get the right talent in the West, and large companies especially relied on huge engineering workforces in these regions. You would typically have some level of engineering resource remain at head office to oversee the off-shore work being done. Sometimes this might only have been a technical product manager or an architect.

If you look back to my assertion above that we’ll commonly have 10x engineers, empowered with AI tooling then both of the reasons for off-shoring disappear. You don’t have a talent shortage, as the engineers we already have in the West can now do much more work than before. The cost-savings also greatly diminish due to a much lower headcount. Off-shoring always has a level of overhead due to context and language barriers, plus HR and legal work to maintain a presence overseas. You wouldn’t do it for just a handful of staff - it has to be a really big number to make sense.

There are also questions around the efficacy of off-shoring. I have worked with successful off-shore teams who were well thought of by head office, but, to be honest, this was often where head office weren’t overly high-performing. In the tech industry, it is very rare for off-shoring to happen at all outside of listed companies. It goes against the Silicon Valley mantra to off-shore. With good reason, too - the language, timezone, culture and context barriers to having effective off-shore teams makes it hard for them to be as successful and rapid as on-shore teams who have shared culture, context, timezone and language. I don’t think the tradeoff is worthwhile any more2.

There are even multi-nationals who hire in countries with excessively3 strong labour protections. In the past, they have accepted this as a trade-off because the labour is cheaper than in the US or UK. In the context of engineers who will be able to do the work of a whole team on their own, the difference between paying a European engineer 100k vs a US one 200k isn’t that important, because you employ so many fewer of them. It therefore makes sense from a business perspective to hire locally for more pay and be able to change things up quickly if they’re going wrong. The impact of poor performance is amplified, as the individual now has much higher responsibility and expectations.

In the past, local engineers and product managers would write complex requirements and project plans for off-shore engineering teams to then go and execute. There would be a constant back and forth to clarify context and details. I would expect this to now happen in Jira/Linear and GitHub. The local product manager or engineer will write a ticket, probably a pretty short and terse one. An AI application may change what they’ve written into a more optimal set of instructions to then pass on to an AI engineer agent, which will then attempt to execute. The feedback cycle will occur within minutes, allowing the product manager to taste-test the output and the engineer to quickly review and suggest changes or approve the code the AI engineer has produced.

The future of off-shoring isn’t off-shoring at all; it’s agents operating between Jira and CI.

What about where the company doesn’t have the experience or know-how to lead AI-assisted development internally? I think if they are at this scale and maturity, then tools like Replit and Loveable can probably build to the level required by these companies.

By no means am I saying that there is no value to the talent in places where engineering is typically off-shored today. This talent probably needs to come a bit closer to the consumer and build the things that the companies they used to work for would offer to these same consumers. They effectively need to compete with the companies they used to provide services for…

In December, when I worked on my SQLMesh advent series, I used Windsurf as an IDE, but within Windsurf was Cascade. I didn’t think about Cascade as an agent too much but it clearly is! You proactively ask it to achieve something and then it goes and does it, and it might require multiple steps, multiple files to be made, multiple dependencies to be handled and multiple errors to be overcome… but it tries to build something that works.

It was able to build a fairly complicated data pipeline, a transformation project in SQLMesh1, and then assist me in developing software to generate a semantic layer using AI from the gold layer tables within the transformation project. My inclination was to build software to do this at the time and use AI to help me build software that was able to repeatedly perform the same task.

However, even this software wasn’t deterministic; it depended on LLM use. What if I didn’t try to generate code at all and just tried to get to the output? Just ask the agent for what you want.

Recently, I had an experience of trying something like this that made me think this is now feasible. Warp is an AI-first terminal that recently released V2 of their product to much fanfare, and the core of the new functionality is the ability to build agents. In this instance, I used Warp to build my agent.

asked me to produce some content about recent releases to Cube’s new agentic analytics product - D3. However, one problem with a product that is moving fast is a lack of documentation. We have the code in Github and merged commits that show what changes have made it into prod, we have tickets in Linear that are pretty sparse on detail… we have some element of high-level strategy but not much else. Initially, we thought it would be best if Artyom filled in a Notion document with new releases that have been merged on any given day, and perhaps create a rough Loom or have the engineer who built it do so for a specific feature.

My first thought when Artyom wanted this, and knowing the sources of information available, was to build something that harvested the information from Github and Linear. Initially, I was going to try using my trusty AI IDE of choice, Windsurf, to do this, just as I have done a few other times on this Substack. However, as someone who has been using Warp for a while to speed up using Shell and CLIs, I saw an opportunity to use their new agent features as a potential shortcut.

Reading just the merged commit names for the repo and the ticket contents wouldn’t have been enough to really know what changes have been made in any detail; you need to be able to read the code in the context of the overall repository and understand what functionality changes they make to do this. Until this AI era, trying to do this in an automated way wasn’t really feasible. But LLMs are great at reading code2, and new systems like Warp and Cascade are pretty great at indexing a whole complex repository to understand the context of the code changes, too.

I made a new agent tab in Warp and checked out the repo. As it turns out, I didn’t need to do this with Warp like I do with Windsurf/Cascade - it only needs the URL of the repo. I then asked it to summarise recent changes - it did a decent job but had more than just the D3 changes. So I asked it to filter to just the D3 changes - and it was able to do that well. I only wanted the last week’s releases, so again I asked it to filter to just these and it did it. This is about 10 minutes in.

Given how easy everything was with Github, I thought I would try using the information in Linear too, but I thought I would hit a snag here with more complexity. I asked the agent also to take information from our Linear project to blend with the information from Github to create the summary. It did some research for a while and found a Linear API which wasn’t rich enough, leading it to find the Linear CLI which was able to pull the information from our tickets. All it needed was for me to generate an API key which I duly did and it gave me a Shell command to store the key as an appropriately named environment variable, that I assume the Linear CLI expects. Just like that, it had got the information, found the Linear tickets referenced in the Github commits and taken the information specifically for them. Then it blended the information from Github and Linear to produce something pretty rich.

All in all, I spent half an hour making this agent. It will now run every Friday to find the last week’s releases in the same way, or when I ask it to. The half an hour included me showing Artyom how good it was and then copy pasting the output to Slack etc. This is the kind of use case that could have been a startup in the pre-AI era3. Now it’s just an agent someone made in half an hour.

I think there should be huge scrutiny of whether software needs to be built for a given use case or if an agent can be made in less than 1% of the time and cost. VCs should look at every pitch and ask themselves whether the idea needs to be software or could just be a cheap and cheerful agent. I don’t think it’s reasonable to invest in a business whose product is an agent that can be built very quickly4. There is no moat. Every single customer or user is a potential competitor - who is better-placed than a customer to build their own agent tailored to their own minimal set of needs?

A lot of supposedly advanced features for agents, like tool use and memory etc, are just one advancement in LLM tech away from being baked into the LLM and becoming standard agent capabilities. You could see this with tool use in the example above, where the agent just picked up the Linear CLI and started using it. I didn’t even see the Linear CLI commands it ran - I probably could have if I wanted to, but I didn’t. The output tasted good. I showed it to Artyom, and he said it was right.

People used to make handy little Excel sheets that could do things for them, limited to what Excel could handle. Agents are going to work in the same way, just with a massively broader application surface area. I only see deeper tech - like databases, frameworks, compilers, etc, which aren’t feasible for an agent to build on the fly or simulate - being software we need to build.

I also think that rather than selling software, we will be selling services which may encompass software and agents together. Customers will expect things that are easy to use and highly effective. They will shirk products with long, complicated onboarding processes and which have complex dashboards and settings to navigate unaided.

I thought I’d try very quickly to make an agent that built a semantic layer, after locating a gold layer style table from a transformation repo like the SQLMesh one I made in December.

Here is my instruction for the agent:

SQLMesh is a data transformation framework used to transform data from raw to usable analytical datasets. It produces a directed acyclic graph of transformation models which are SQL queries. Some of these models are appropriate to be parsed and used to create a semantic layer. The models which are like this are often the right hand leaves of the DAG with no children and which join tables together and aggregate numeric columns to calculate metrics.

The user using this agent will provide a github repository which will contain a SQLMesh project with such models.

Automatically locate one or more appropriate models from the repository to convert into a semantic layer. Use Cube’s semantic layer YAML standard. Here are docs on SQLMesh and Cube:

https://sqlmesh.readthedocs.io/en/stable/concepts/models/sql_models/

https://sqlmesh.readthedocs.io/en/stable/

https://cube.dev/docs/product/introduction

https://cube.dev/docs/product/data-modeling/syntax

Then output the semantic layer using the joined tables from the models selected as Cubes. Create Cubes with measures, dimensions and joins. Generate descriptions and types as per the docs.

Initially, it didn’t split these gold style queries into different Cubes which joined to each other, presented in a star schema. So I shared the docs on Cube Views with it and gave it a bit more guidance:

use views as per https://cube.dev/docs/product/data-modeling/reference/view to make a view per query chosen, where the cubes are the tables joined in the query rather than just using the final tables. The idea is not to rely on the joins happening in the query but to express them in the Cube semantic layer and arrange them using views.

It then did this well but seemed to have hallucinated a “where” property that Views do not have for filtering.

are you sure views can have "where" parameters?

Then it got some of the dot notation for expressing join paths in Cube Views wrong.

some of the join paths are incorrect in the views as they should take the form of core_cube.other_cube apart from the core_cube which is alone

Then it got the names of the possible joins in Cube wrong. If you remember in my original series building this, the same thing happened because of legacy Cube functionality and old docs that have clearly ended up in pre-training material. It may be the case that these names would work but anyhow:

cubes have the following parameters for joins https://cube.dev/docs/product/data-modeling/reference/joins have you got this right in your output?

At this point, I can’t really see anything particularly wrong with the complete semantic layer it generated. The Views, Cubes with their dimensions, measures and joins look good…. again, building this agent took about half an hour5. This time I had to correct it a bit, but this is a more complicated task that requires more precision in output. However, these instructions are now stored within the agent. It won’t have the same problems next time. Another thing to note is that this time, I got the agent to automatically pick the tables to convert from the project, which adds complexity6.

I can see the cost of migration between analytical tools that have proprietary semantic layer code go to zero. Every tool will offer agents that can translate the code from other formats to their own. Their ability to use tools means that users won’t even have to copy/paste anything - the agents will copy the code themselves, translate and then store using an API or CLI in the new tool.

The semantic layer came of age over the course of two weeks at the Moscone Center. Both Snowflake, with semantic views, and Databricks, with metrics views, have essentially implemented a semantic layer with a compiler, which I predicted (around this time last year) that they would do before the end of 2025.

Back then, both Snowflake and Databricks had implemented ways of codifying a knowledge graph, which looked very much like semantic layer YAML, except that this YAML was not compiled in the same way as with a semantic layer1. It was provided as context in the prompt so that the text-to-SQL methods they were employing could perform better. They did indeed perform better, but as I wrote about before, they still didn’t come close to the text-to-semantic layer method I had proposed and that has been implemented at Delphi and Cube. They never will come close to the text-to-semantic layer method and, as a result, will never have high enough accuracy to succeed. This is why I predicted that Snowflake and Databricks would change tack in 2025, and indeed why they have done so.

The driver for this change is agentic analytics. When the idea of headless BI, or a universal semantic layer, first made its way into the zeitgeist of data folks, it was meant for use by BI tools and data applications. It may have originated in natural language, like with Cube’s precursors Statsbot, Metabase, Thoughtspot, Veezoo…, where strict syntax requests disguised API requests as natural language. However, the destination was all of the other BI tools and data apps out there. A single source of truth, governance, performance… not specifically AI, as AI was still a dream in this pre-GPT-3 era.

As AI has captured a greater and greater mindshare, till the point where we are now where it’s nearly at 100%, any delays to making data agents can no longer be tolerated. It’s not a case of will they or won’t they have a semantic layer - any company that wants to offer agentic analytics must have one. Databricks, Snowflake, GCP and Microsoft all now have at least the rudiments of a semantic layer with a compiler. Text-to-SQL is dead - dead on arrival. No-one is better placed than a data warehouse vendor to make a success of text-to-SQL as I have explained before, and even they have all given up on the idea and moved to having a semantic layer with compiler. It’s fundamentally not viable, because LLMs aren’t magic.

If a really smart person can’t just take a data model with context only and deliver consistent and accurate results, we won’t get LLMs to, even with GPT-5 level of power. It’s not a computational problem; it’s a metadata and guardrails problem. You don’t leave things to chance when you know how they should be. You force the system to conform.

However, one consequence of all this is that headless BI is also dead. Agentic analytics is seen as the new BI, the successor to BI, the BI we always wanted. If every headless BI offering also includes agentic analytics, and they will do so by the end of this year2, then are they really headless? Surely it could be correctly argued that they now have a very smart head! Maybe it’s only connected by a thin MCP sinew, and you can still flip it off to connect to other things like Tableau, PowerBI and Chart.js… but that still doesn’t let it join the headless hunt.

In all honesty, BI tool vendors have been terrible partners to headless BI vendors. They haven’t had much incentive to integrate well… it makes them more replaceable. So I guess it’s the end of the period of headless BI, and the beginning of the era of agentic analytics. Where the previous headless BI vendors have a big product and technology advantage through their semantic layers, and BI vendors have an advantage in their advanced commercialisation and existing relationships to leverage. Let’s see who prevails… perhaps this increases the gravity of the data warehouse further if they can offer agentic analytics directly and bypass the consumption layer entirely.

Gartner is even preparing the way for an agentic analytics quadrant to exist:

BI has never been more competitive. Every data tool really is becoming a BI tool. That includes data warehouses in this new agentic analytics era.

Recently, I’ve been hearing that information security teams, who already typically conduct a vendor evaluation before onboarding and granting access to company data, have started requesting a second review when a vendor also offers AI functionality. Every vendor will eventually have AI functionality by the end of this year! Having two security evaluations is very inefficient in a world where every vendor will need it. A year or two ago, you may have been able to say that only a minority of vendors have AI features… not today and not ever again.

One interesting example was of a company where at least 20%1 of the company used Grammarly. Now, Grammarly isn’t some unheard-of vendor; it's well-known by nearly all information workers and used by a vast number of them, too. The company recently asked all workers who had Grammarly installed to uninstall it, because they realised that Grammarly has AI features… If you consider what the company is trying to protect itself from, it is attempting to avoid liability for a data breach by Grammarly, where it lacks adequate liability protection because employees are using the free tier of Grammarly and are not on an enterprise plan.

I understand why the information security team felt the need to tell employees to stop using Grammarly here. It’s not really going to secure data very much; the data has already bolted through years of use by employees. It is primarily a liability shift; the employees have been instructed not to use Grammarly, and therefore, the company has likely taken reasonable steps to avoid invalidating their insurance policy should a data breach occur.

However, my main problem is the reactive nature of the information security team here. Of course, an information security team cannot preempt every possible vendor use by employees, especially when it is a tool choice made by engineering, who will know their tools better than the information security team. Where tools are general tools used by all employees, then I think we should expect information security to become more proactive. For example, it is becoming common for employers to provide employees with enterprise ChatGPT accounts, as the level of unofficial usage occurring was so high that it is almost certain that there would be inappropriate data leakage. This is the type of tool that an information security team should proactively offer employees to prevent data leakage to a free-tier or non-corporate account.

If you look at the tools a typical employee uses —office suite, operating system, browser, email, and calendar —all of these will soon have AI features or integrations. It makes more sense for information security to be opinionated about which of these it considers secure from both a software and AI architecture perspective, and to propose which ones to use for procurement. Going halfway doesn’t make sense.

For example, imagine if your company used Google Workspace for email, calendar, office applications, and more. Enterprise Google Workspace accounts have Gemini built into nearly every app, and they come with a Gemini-specific app to use like ChatGPT, and NotebookLM - one of the most advanced AI tools available. It’s not good enough for an infosec team to say that they disapprove of the use of the AI features or AI applications that are available and accessible through workspace accounts. If they are available, then employees will use them, at least in the minority. Even where the majority tries to stay in line with the infosec policy, it would probably still happen accidentally.

Clearly, tools like Grammarly are widely used by employees, probably in all companies. It would make sense to get an enterprise account with pro features for all employees to use, instead of waiting for someone to ask for an infosec review when they may not have even realised it needed one.

The way employees are working is undergoing a change like we haven’t seen since the dawn of office computing. Whole tool categories are being upended or transformed with AI. The best employees want to maximise their capabilities with AI and make their teams lean in the same way. Information security teams are at risk of being an obstacle. Yes, they should be some of the time, but they could also do with being proactive and opinionated, especially during this era of rapid change.

If you think Anthropic fits your security profile better than OpenAI, consider purchasing a Claude enterprise subscription for your company to use. Give everyone access and instruct them to stop using ChatGPT, having provided them with an alternative. You can’t simply say no and offer no alternative; it won’t work. I also think that where vendors have already been given access to sensitive data, being concerned about the use of their new AI features is pointless. The vendors will already be ensuring that liability and risk do not materially increase from offering AI features, such as BYOLLM, and that they have the appropriate commercial licenses and insurance. Verify that vendors are incorporating these measures as part of their standard information security approval process, rather than having a separate one.

I learned during this process that I have relatively short little fingers compared to my ring fingers, which actually dictates needing a different type of keyboard layout, where the columns of keys for my little fingers need to be much further down than my ring and middle fingers. Rule of thumb: if the ends of your little fingers don’t extend past the top knuckle of your ring fingers, then you are probably in the same boat as me2.

These kinds of keyboards are customisable using a firmware called QMK, which has a CLI that you use to manage your keyboard layouts and flash it with new ones. The CLI, over time, has become reasonably complicated, and there is additional complexity from the sheer number of possible keyboards, modifications and chipsets you can have. I could have spent some time figuring out how to adjust my keymap files manually by Googling and asking the QMK community3, but the year isn’t 2021.

I used Windsurf to change or create the files I needed to change my keymap; it did it in one shot with no issues. The repo comes with a bunch of default keymaps, which act as easy examples to learn from for Cascade. However, in order to actually flash your keyboard, you need to both install the CLI successfully, which has a lot of dependencies, and use the correct commands to compile and then flash your keyboard.

I initially tried using the CLI manually, as I’m fairly proficient using shells and CLIs. However, I came across some issues. I probably could have figured them out, but after a few tries and making new Python environments, I gave up and decided to try Warp, which is an AI-first terminal. Warp was able to read the error messages output, mostly due to incorrect or missing dependencies4, and resolve them in a couple of tries. Staying on a roll, I got it to generate the QMK commands to compile and then flash my keyboard and it got those right first time. My chipset is a bit new and undocumented, and has an unusual flashing process, which makes things more interesting for someone new to this kind of thing!

Feeling somewhat happy to have solved this problem, I thought I would document it and share it in one of the subreddits. Oh wow, I wasn’t expecting how hostile people would be to the idea of using AI to solve this problem. People said I could have just read the docs, Googled or asked the community, but I had done this and not succeeded. The main thing they thought about was how much energy5 I would have consumed to use AI to solve this supposedly basic problem. At the time, I thought… sure, pre-training LLMs is expensive, but inference doesn’t use that much energy.

I recently read this post by Juho Snellman that explores the cost of using LLMs vs web search, and it not only confirmed what I thought about inference being cheap, but also that it is cheaper on average than using web search!

Juho’s post has a fun calculator to test out your own specific assumptions. I used Google Search, as I never really use any other web search providers. I used a relatively expensive LLM in Claude 3.7 Sonnet, as this is fairly representative of an LLM I would use for a coding problem. I assumed some level of margin and pre-training amortisation so that it’s fair. I used a very generous amount of tokens - as you can imagine, generating a CLI command would likely only have 20 to 40 output tokens. My keymap files would be more, but very unlikely to be more than 1000.

On this basis, it would have been cheaper to have gone straight to using an LLM and not wasted the energy on the initial web searches I did.

Web search returns results 20x-100x faster than an LLM finishes the query, how could it be more expensive? - Search latency can be improved by parallelizing the problem, while LLM inference is (for now) serial in nature. The task of predicting a single token can be parallelized, but the you can't predict all the output tokens at once.

I thought this was a very interesting point - many people would think that just the wait time for LLM results shows it is using more compute and therefore energy. However, your web search could trigger thousands of parallel subprocesses consuming more energy in total, but running much faster and looking cheaper to the eye.

Maybe we should actually be talking about the energy costs of using “traditional” web search and not LLM inference. It seems as though we now have a cheaper, more energy-efficient6, more effective alternative.

Especially if you think about how many web searches we chain together to find something out. We often don’t know what the best API to find specific information will be when we begin. In the future, LLM systems/agents will have catalogs of well-described APIs to collect context and answer a request. Using an LLM system here to find something out in one shot, rather than multiple web searches, could be one or two orders of magnitude more energy-efficient.