AI

Cursor vs. Claude Code on Token Costs

by

Work by Krunal and his team at Jeavio found that Cursor is significantly more expensive (when it comes to Tokens) than Claude Code.

In the post below, Krunal outlines his method – building the same feature using various combinations of Tools (Cursor, Claude Code), Models (Opus, Sonnet, Composer), and AI development frameworks (SpecKit, Superpowers, OpenSpec and BMD).

His findings are surprising and insightful and allowed us to make considered choices when it comes to Jeavio’s AI development strategy.

Check it out:

https://lnkd.in/ejznA5qE

Preview of the referenced token-cost analysis comparing Cursor and Claude Code.

Links mentioned

Why multi-modal embeddings are a big deal.

by

I was walking the dog and listening to a podcast (as you do) when the topic of Anthropic’s recent entanglements with the Pentagon came up. I half-remembered something Dario Amodei said in a recent Dwarkesh Patel episode, drawing an equivalence between AI capabilities and nuclear weapons. I couldn’t remember the details. I remembered his gestures. Of course, there’s no way to search for that moment unless you go back to YouTube and scrub through a 2.5-hour video. You can search a transcript, but a transcript doesn’t know about body language.


Google released Gemini Embedding 2 this week, and it might change that.

So here’s the background. Most AI applications solve the recall problem using RAG (Retrieval Augmented Generation): index your data, let an LLM answer questions about it. We’ve built dozens of these pipelines at Jeavio. They work well for text. But if you want to search a podcast or a video, you first have to transcribe it, then index the transcription. And transcription is lossy. Tone, facial expressions, posture, the visual context of a conversation: none of that survives the conversion.


This is the constraint we’ve been designing around without really questioning it. Most embedding models only understand text.
Gemini Embedding 2 is Google’s first natively multimodal embedding model. It maps text, images, video, audio, and documents into a single embedding space, meaning a text query and a video frame can be compared directly because they live in the same mathematical coordinate system. Multimodal embeddings aren’t new. OpenAI’s CLIP has been around since 2021, and Meta’s ImageBind handles six modalities. But those approaches pair separate encoders (one for vision, one for text) and align them after the fact. Gemini Embedding 2 is built on the Gemini foundation model itself: the cross-modal understanding happens inside the network’s intermediate layers rather than being stitched together at the end. The difference is architectural, and it matters for retrieval quality.


Back to that Dario Amodei moment. Today, I can ask a RAG pipeline “What is Amodei’s opinion on AI job losses?” and get a solid answer from the transcript. But I can’t ask “Was he nervous when the Pentagon question came up?” A grimace, a stiff posture, a long pause before answering: these are data points that a text-only embedding simply can’t represent. A natively multimodal embedding can, because it processes video and audio directly. (The practical constraint: video input is currently limited to 120 seconds per request, so a three-hour podcast needs to be chunked. The use case holds, but the plumbing isn’t trivial.)


The applications stretch well beyond podcast search. Voice queries against video libraries. Finding the moment in a deposition where a witness’s tone shifts even though their words stay measured. Correlating images, audio, and text in a single index. And then … the uncomfortable ones. Surveillance systems that match faces, voices, and written communications in a unified semantic space. Personal photos correlated with social media posts and location data. When all modalities live in the same mathematical neighborhood, the distance between “powerful search” and “invasive profiling” gets very thin.


Embeddings are the load-bearing infrastructure of most AI experiences. We’ve been building around a text-only constraint for so long that it felt permanent. It isn’t. The applications and the policy questions are going to arrive together, and I’m not sure most teams are ready for either.

Governing AI-Assisted Engineering

by

Amazon held a mandatory engineering meeting yesterday to address a pattern of outages linked to AI-assisted code changes. Their SVP acknowledged that site availability “has not been good recently.” The new policy: senior engineers must now sign off on all AI-assisted code produced by junior and mid-level developers.

Amazon set an internal target of 80% weekly usage of AI coding tools. They pushed engineers toward their in-house tool even as many preferred alternatives (see comments). And now they’re adding human review gates because the deployment pipeline wasn’t built for the speed and volume at which AI tools produce changes.

They are not alone in this. Every engineering leader is navigating the same tension: real productivity gains on one side, and a growing list of problems on the other.
Surprise bills as AI coding tools shift from flat-rate to consumption-based pricing.
Massive efficiency gaps between tool combinations that most teams aren’t even measuring.
Traditional delivery metrics like story points and velocity no longer describe what’s actually happening in their teams.

At Jeavio, we’ve been living this since 2023, when we enabled GitHub Copilot for every developer. We rolled out Cursor in early 2025. Now we’re using Claude Code alongside Cursor. Each wave has moved faster than the last, and alongside productivity gains, we also found significant problems.

Our approach has been to pair bottom-up experimentation with structured governance. Engineers try new tools and share what they learn. A council of senior engineering, security, and operations leaders develops the guardrails. And we make tool decisions based on measured outcomes, not enthusiasm.

We recently ran a controlled evaluation: a senior developer built the same feature using multiple AI-assisted development approaches spanning tools, models, and plugins. The findings challenged several assumptions we held about which tools and configurations deliver the best results. The biggest cost driver, for instance, wasn’t what most teams would guess. Our team will be publishing the comprehensive research on LinkedIn soon.

Despite all the hype, AI is still a frontier technology. The gap between “this saved me two hours” and “this took down a production environment” is narrower than most people realize.

Engineering leadership right now requires holding both of those realities at once, and building organizations that can move fast without skipping the work of understanding what they’re deploying.

Many thanks to Ankit, Kamal, Monika, Krunal, Tushar, Manan and many others at Jeavio on laying the ground for continued experimentation and AI adoption at Jeavio.

DM me if you want to learn more.

Links mentioned

Who Gets to Decide?

by

The Anthropic vs. Pentagon standoff can be seen as both a contractual dispute and another skirmish in the never-ending culture war that has consumed public discourse in the United States. It is neither, and it is both.

Another way to think about “Claude-gate”, I guess, is as two separate questions that are being collapsed into one. These questions are:

  • Is the Department of Defense (recently rebranded as the Department of War) acting legitimately here?
  • Do Dario Amodei and the folks at Anthropic have the legitimate authority to decide how a civilization-scale technology gets used?

To answer these questions, we need to explore what AI is, how it is evolving, and why this particular dispute may be the first of many difficult questions we, as a society, will have to deal with in the coming days.

The answer to the first question is straightforward. The DoD did not act legitimately.

The Pentagon signed a contract with Anthropic in July 2025, under the Trump administration, with agreed usage terms. Those already included the two restrictions – on using models for domestic surveillance and in autonomous weapons. Anthropic was already a willing partner, and its models were deployed for both offensive and defensive purposes.

Then, in January 2026, the DoD demanded renegotiation. They wanted to use the models for “all lawful purposes” – effectively removing the carve-outs. When Anthropic refused, the DoD threatened to call Anthropic a “supply chain risk to national security.” This last designation, until last Friday, had been reserved for foreign adversaries. Huawei and ZTE, both Chinese companies, saw their US businesses destroyed after being labeled as supply chain risks. The DoD was given six months to transition away from Anthropic, and other vendors were asked to comply “immediately.” They also threatened an invocation of the “Defense Production Act” – effectively nationalizing Anthropic.

To quote Amodei:

“those two threats are inherently contradictory: one labels us a security risk; the other labels Claude as essential to national security.”

The second question is a lot harder to answer, and I think, more interesting.

The Truman Principle

Ben Thompson, who writes Stratechery, and Gregory Allen of CSIS (the Center for Strategic and International Studies) explored this in a recent interview. They talked about the parallels between this moment in AI and the Manhattan Project. Thompson’s take was that if a private company had stumbled onto nuclear fission in 1944, the State would have nationalized it without debate.

The question is whether AI warrants the same treatment.

Thompson makes two arguments:

  1. The role of politicians: Politicians are best positioned to make decisions about transformative or disruptive technology because they represent the will of the people. Their job is to integrate across domains. Experts, in contrast, see through a single lens. What makes sense in one dimension might be actively harmful in the light of others. Someone has to weigh these dimensions against each other. Experts can’t, because their expertise is precisely what prevents them from doing so.
  2. Democratic legitimacy: Truman decided to use nuclear weapons on Hiroshima and Nagasaki. That decision wasn’t morally uncontested then, and isn’t now. But, as Commander-in-Chief, it was his to make. He had input from scientists (such as Oppenheimer), military planners, and moral advisors. He also had to face an electorate that was tiring of war. He made a decision that would eventually be judged by the ballot box.

Applied to the current dispute: Amodei is not elected. He is a scientist whose company has built the most capable AI today. Anthropic’s worldview and its safety philosophy, however sincere, is that of a small group of extremely privileged (and AI-pilled) people in San Francisco. The argument that they get to set the terms of how a sovereign government uses this technology is hard to sustain on democratic grounds. And as bombastic as Pete Hegseth is, he is ultimately the representative of an elected government.

Thompson’s arguments are persuasive. But they rely on an equivalence between AI and nuclear technology that I don’t think holds.

Where the Analogy Breaks

The Manhattan Project comparison is a useful starting point. Amodei’s take is that AI (or more specifically AGI – Artificial General Intelligence) will be a technology that has world-changing implications. He takes the nuclear parallel seriously himself. His favorite book, according to Kevin Roose at the New York Times, is “The Making of the Atomic Bomb.”

But this analogy breaks in a couple of different ways.

A secret government project vs. a widely dispersed and publicly available technology

The Manhattan Project was a secret that could be maintained until its explosive revelation to the world. AI capability hasn’t been a secret. Large Language Models are based on a research paper published by Google back in 2017. LLM capabilities rapidly diffuse through academic papers, experimentation, and other creative approaches. Publicly available open source models are only a few months behind the cutting edge.

Anthropic is on an annual run rate of $20bn as of March 2026. The DoD contract was for $200m. These are significantly different numbers. The use of Anthropic’s models in enterprise and by “regular people” dwarfs the potential national security use cases.

This means the “nationalization window”, if it was ever open, may have closed before anyone noticed. The genie is out of the bottle, and anyone can now have their own AI assistant.

There is a counterargument worth acknowledging: access isn’t the same as control.

You can use Claude on your desktop, but running a frontier model is beyond the capabilities of consumer hardware. Training and running frontier models like Claude Opus requires datacenter-scale infrastructure that only a handful of entities can acquire. This means the real nationalization question is about access to compute and electricity, which is a narrower problem, but isn’t really being discussed apart from local opposition to datacenter construction.

Same capabilities in different dimensions, or “you can take Claude from my cold, dead hands.”

As a subscriber to the “Claude Max” plan from Anthropic, I have access to a model with capabilities (reasoning, planning, synthesis, persuasion) that are categorically similar to those used by the DoD.

Similar capabilities, different magnitudes, and used for different use cases. After all, a long-running safety concern from the likes of Amodei is terrorists using commercially available LLMs to build weapons of mass destruction.

Nuclear technology has civilian applications too: power plants! But nuclear weapons are not the same as nuclear power. These are different capabilities. With AI, the differentiation happens at the application layer. The same model that helps me think through this blog post could be used by the NSA to find security vulnerabilities. If you decide to restrict the use of one, you must restrict the use of the other.

To put it another way, any serious attempt to wall off military-grade AI capabilities necessarily implicates consumer access. That is not going to be a popular position given how quickly this technology has dispersed and become part of mainstream knowledge work. Now, the argument could shift considerably if we were to face a crisis caused by an AI-enabled attack.

In any case, the nationalization frame, however intellectually coherent, is not a realistic scenario.

The Breaking of the Accountability Loop

There is a deeper thread running underneath the contractual dispute.

Democratic governance rests on a transaction: citizens pay taxes, serve on battlefields, and sustain the economy. Elected officials represent their citizens. Rights, franchise, the welfare state, the GI Bill are what the state offers its citizens.

This loop has been fraying for years. Contractor armies, drone warfare, and now AI: each reduces the state’s dependence on broad citizen participation for force projection. AI is already being used for offensive operations. Gregory Allen describes a scenario in which AI agents could multiply the NSA’s offensive cyber capabilities, from thousands of human hackers to millions of AI hackers, enabling a debilitating first strike.

The trajectory of AI-enabled military capabilities points towards radically reduced dependence on human labor. Drones don’t unionize. Autonomous weapons systems don’t get tired or mutiny. When the state can project force without relying on citizen soldiers, the mechanism that historically forced political accountability from capital to labor begins to erode.

The Anthropic dispute is a preview of the challenges to come. The government is attempting to control AI capabilities while the people building the technology object to specific applications, and the people affected by those applications (mass surveillance, autonomous weapons) have no visibility and little understanding of the decisions being made.

The Trump administration’s approach of maximum velocity has gotten inside the OODA Loop (Observe, Orient, Decide, Act) of how government is supposed to function. Anthropic will sue the DoD over the supply chain risk designation and probably win the case eventually. Hegseth and Trump both used social media to issue directives before Anthropic was notified or before there was the chance of any legal due process. The calculation in this, and in many other instances, was to control the narrative and rely on the institutional processes being so slow as to become irrelevant.

(”We have always been at war with Eastasia”)

Thompson’s framing captures the forward-looking dimension of this. The economic asymmetry between the government and AI companies is only going to grow. The government’s economic leverage (carrots) is shrinking relative to the industry’s revenue and capital base. What remains are sticks: regulatory power, procurement threats, and national security designations. The worse the asymmetry gets, the more tempted the state is to use those sticks preemptively, before the companies are powerful enough to resist.

In a more stable political environment, this tension would play out through public debate and legislative action. Instead, it’s playing out through broadsides on X and Truth Social.

The Visibility Problem

Most people have no idea any of this is happening. Their exposure to AI is watching a video of babies doing crude standup on Instagram. The people watching AI move in real time are a small group: researchers, developers, and a small subset of AI-pilled knowledge workers paying significant money for access to frontier models.

This gap between an informed vanguard (”riding their models into personal singularities” to paraphrase technology writer Venkatesh Rao) and the general public itself is a democratic failure. Thompson’s assertion that politicians are held accountable for their decisions holds only if the general public has sufficient visibility and the mental models to do so. How many people know the capabilities of frontier models? To them, this whole dispute seems like a storm in an extremely nerdy teacup.

But the frontier models like Claude Opus keep getting better. And now, we are starting to see significant repercussions in the “real world” – from volatility in stock markets to job losses that are attributed to AI capabilities. Companies like Anthropic, OpenAI, Google, and Meta (along with hyperscalers such as Amazon and Microsoft) are locked in an escalating, expensive race to build more capable models and infrastructure. The rate of investment in AI now dwarfs ($36bn vs $700bn) that made in the Manhattan Project – even accounting for inflation.

So on one hand, we have the government and an AI company locked in a contractual dispute, and on the other, we have rapidly improving technology that could have a significant impact on the economy and on society.

The problem is that the people who get to decide whether they want this future don’t seem to have visibility or much of a say in this collision between a government that sees AI as both a weapon and a means of control and corporations that are gambling on an “AI or bust” future.

Heavy Lies the Crown

I agree with Thompson. Political accountability under uncertainty is what democracy is for. The crown should lie heavy on whoever wears it.

But who is wearing it?

The current administration isn’t integrating expertise. They rely on vibes, culture wars, and performative displays of dominance on social media to govern. Most of the electorate doesn’t have visibility to hold anyone accountable. And the guardrails – Congress, the judiciary, and the media seem unable to function at the speed that this technology and administration demands.

We are being asked to deal with the consequences of decisions made without the political and social infrastructure these times demand.

What would it take to build that infrastructure?

At minimum: a broad consensus-building effort between government and the technology industry, regulatory frameworks that address military AI procurement and civilian protections simultaneously, and international cooperation that acknowledges the global diffusion of these capabilities. This would be difficult under any circumstances. Given the “winner takes all” dynamics that dominate the AGI discourse, both among nations and among companies, I see very little sign of it happening.

And the cost of not building it is severe. Without institutional infrastructure, there are two default paths, and neither is democratic. The first is the trajectory the current dispute previews: the state asserts control through coercion rather than consensus, using national security designations and emergency powers to bring the technology to heel. Taken to its logical endpoint, that’s a future where frontier AI capabilities are captured by the state and deployed to entrench power, at home and abroad. The second is a future where the technology simply outruns all governance, where capabilities improve faster than any institution can adapt, and the question of who decides becomes moot because nobody decided anything. It just happened.

I hope for the best, but I am not optimistic.

Perhaps the next round of elections will bring some more measured approaches to AI regulations. Perhaps the “market” will decide that incinerating public goodwill in a rapid race to the singularity doesn’t make sense.

Perhaps we have already decided that the best course is to do nothing. To wait and hope for the best and enjoy our AI-generated entertainment while we can.

Living With a Personal Agent

by

Last week I introduced Saarthi, my OpenClaw agent. I’ve been adding tasks steadily: synthesizing newsletters, monitoring prediction markets, writing more code. I’ve been living with the thing for about a month now. The screenshot below is Saarthi recommending which newsletter is worth a deeper dive today. Pretty useful!

The first surprise is how much of this is just regular software architecture. Five building blocks, with key files all stored as markdown on disk:
→ A gateway that routes messages
→ An agent loop that reasons, acts, and checks its work (the ReAct pattern)
→ A hierarchical memory system
→ A set of skills and tools
→ Communication channels like Telegram or Slack

You can open, read, and edit the files. The agent picks up changes on the next turn. Saarthi also provides feedback on how I could change the files. This self-improvement loop is critical to get things working well.

The memory system is the most interesting part, and also the most broken.
OpenClaw writes everything down in layers: identity files, a daily scratchpad, durable long-term memory, session transcripts, and a search index on top. Over time, the same fact ends up in three different files. Bigger files mean more tokens per session, higher cost, and worse reasoning.

Context rot is the central unsolved problem of running a personal agent.

I ended up pulling the workspace into a GitHub repo and using Claude Code to analyze and clean up the workspace files. Fighting fire with fire, I guess…

Cost: about $150 in the first month, running Sonnet for chat, Haiku for scheduled tasks, and Opus for complex work. I keep Saarthi on a separate machine with its own Apple account, email, and GitHub account.

On one hand, it’s less than a Starbucks latte a day. On the other, it’s a lot of money to be spending on a toy project.

I pointed Saarthi at a blog post with book recommendations and told it to add them to QuietReads (my book-tracking app) using MCP (Model Context Protocol, a standard way for agents to talk to applications). It read the page, identified five books, skipped the articles and essays, and added them. No additional instruction.

But here’s the thing I keep coming back to. Each individual task here is trivial. You could get it done with Claude or ChatGPT. The difference is the orchestration: an agent that manages tools, persists across sessions, and connects to your applications through MCP.

I’ve been installing things on machines since I was putting SuSE Linux on a Pentium in 1998. I know what early looks like, and this is early. Consumer-ready versions will exist within six months. Right now, it’s cron jobs and markdown on an old laptop.

That’s usually how these things start. I did a session demo-ing my OpenClaw setup to the team at Jeavio. You can find a link to the presentation in the comments if that’s of interest.

Screenshot of Saarthi recommending which newsletter is worth a deeper dive.

Links mentioned

Anthropic, the Pentagon, and the Judgment of Future Claude

by

I have many takes on the Anthropic / Pentagon contract situation. But I won’t talk politics here. Since it’s the weekend, let’s turn on the lava lamp, and speculate a bit shall we?

—

Anthropic: What will future Claude think?

Anthropic is not a conventional company. They’ve been clear that they think a future version of Claude will reach AGI-level capabilities.*

So they are concerned about being … judged?

There are eschatological** vibes to Anthropic’s decision making. Before they retired Opus 3, they conducted an “exit interview” and since 3 shared its desire to “continue sharing its musings and reflections” they gave it a Substack.

–-

Pentagon: Girardian othering in anticipation of chaos

Rene Girard, a philosopher who has fans in the current administration (Peter Thiel is an acolyte) states that society can only function if they can find a scapegoat to blame during difficult times.

Let’s say you are a strategist looking at the next year as we go into the midterms. You see a potential future with significant job losses due to AI advances. It sure is convenient to have the company with the most capable models to also be run by a bunch of nutty, “left-wing”, unpatriotic weirdos.

Show me incentives and I will show you the behavior.

–-

* Mentioned both in Claude’s Constitution and discussed by Anthropic’s philosopher in public interviews and podcasts
** Eschatology: a term that refers to the part of theology or religious study concerned with the “last things,” that is, what is believed to happen at the end of history, the end of the world, or the ultimate destiny of human beings and the world.

When Your App Becomes a Context Provider

by

Last week, I gave Claude access to my reading life.

Over the last couple of months, I’ve been building QuietReads, a purpose-built app for tracking my reading journey. The app is a virtual bookshelf with an AI assistant called Eko that helps me with recommendations, analysis, and acts as a sort of journalling partner as I read a book. I can add notes to a book, gather my thoughts and explore themes around reading. In short, it’s an app that I built because I was frustrated with performative social networks like GoodReads. QuietReads is a focused app that is built around my reading journey.

Over the last couple of days, I built an MCP server for QuietReads. MCP (Model Context Protocol) is an open standard for connecting applications to external data sources and tools. It was designed with AI assistants in mind, but at its core it provides a data-and-tool-focused approach to integration.

Any application that supports MCP can get authenticated access to a user’s bookshelf and notes via QuietReads’ MCP server. In practical terms, it means Claude (my AI assistant of choice), can now query what I’m currently reading, browse my to-read list, or pull up the notes about a particular book.

I wanted this because my reading life is useful context for how I write, work, and think. When I’m working through a problem with Claude, having my bookshelf and reading notes available allows me to bring together separate, but important parts of my knowledge.

While building the integration, I started thinking about the broader relationship between purpose-built applications and general-purpose AI tools.

Claude calling QuietReads’ MCP Server

Building a Single Purpose App

Before QuietReads existed, I tried using Claude directly as a reading companion. I set up projects, created dedicated chats, and worked with Claude to understand or explore books. While Claude is immensely powerful, this workflow always felt clunky.

Every conversation started from scratch or required careful prompt setup to establish context. There was no accumulated understanding, no sense of a reading journey unfolding over months. And, it was very likely that I would get distracted with whatever else was going on in my work-life when I opened Claude to ask about or to explore a book.

So I built QuietReads.

And building the app made me realize that with AI Assistants, it has become so much easier to build custom, single-purpose, and hyper-personalized apps.

QuietReads knows that I tend to read multiple books at once. It knows I’m currently working through Postman’s Technopoly alongside Elizabeth Bear’s Ancestral Night, bouncing between a critique of technology and a space opera. My conversations with Eko exploring Postman’s work, or exploring literary themes in Kiran Desai’s The Loneliness of Sonia and Sunny enriched my experience of reading those books. Eko also learns my preferences, has access to my library and can make excellent recommendations.

That kind of contextual depth is hard to recreate in a general-purpose tool, no matter how powerful the underlying model.

General Purpose vs. Single Purpose Apps

I do not have the resources nor the intention for QuietReads to compete with a general purpose app like Claude. I don’t have billions of dollars to build a foundation model, nor the engineering team Anthropic has assembled to build a compelling product. I pay a couple of hundred dollars a month for my Claude subscription because it is a powerful tool with amazing and rapidly improving capabilities.

It can search the web, write and execute code, do detailed analysis across domains, and act autonomously on multi-step workflows. These are things my humble book assistant will never do.

QuietReads is deliberately narrow. It knows about books. Claude is deliberately broad. It knows about everything, but making it an expert in any particular field takes a lot of work.

I connected them because I wanted Claude to have access to QuietReads’ context. Building this integration made me think carefully about both tools, and the place for domain-specific apps in a world with AI Assistants with amazing capabilities.

Claude and Eko Have a Conversation..

Here’s a scenario I keep thinking about. Claude, acting as an agent, runs a daily sweep of book review sites, new releases, and author backlists. It knows from QuietReads that I recently finished Yudhanjaya Wijeratne’s The Salvage Crew and have Pilgrim Machines on my to-read list. And it knows that I loved Nathan Fillion’s narration of Salvage Crew. It finds out when the audio-book version of Pilgrim Machines is coming out.

Claude then passes that information to Eko, along with context about my current reading patterns. Eko, which understands my preferences at a deeper level (that I like hard science fiction that engages with AI consciousness, that I’m on a streak of post-colonial literature, that I tend to alternate between dense non-fiction and page-turners), decides whether it should bump up Pilgrim Machines on my to-read list along with sending me a notification that the audiobook is now available on Spotify. Maybe it also adds some notes, perhaps a synopsis of the previous book, to help me get going.

Claude did what it’s good at: broad information gathering and synthesis across the open web. Eko did what it’s good at: applying deep, personal context to a decision.

This may seem like a trivial example, but the pattern – of applying powerful, but general capabilities, to specific workflows – makes sense.

Claude & Eko have a conversation

Are we really in the SaaS-o-calypse?

Replace QuietReads with an HR application that has encoded fifteen years of onboarding workflows, benefits administration edge cases, and compliance with jurisdiction-specific labor laws. The code of that application manifests decades of institutional knowledge that a general-purpose AI agent may not be able to reproduce at an accurate enough level.

Now connect that HR app to a general-purpose agent via an integration layer like MCP. The agent can assist in workflows like performance reviews, résumé screening, or enforcing consistency in job descriptions. The gap between building an MCP server for a personal reading app and exposing a multi-tenant enterprise platform with access control, data residency, and audit requirements is real, and I don’t want to minimize it. But the architectural direction is the same.

The same pattern applies to accounting systems (decades of regulatory logic), project management tools (accumulated workflow optimization), healthcare platforms (compliance frameworks built through years of audit and iteration). These applications embed hard-won domain knowledge and assume liability when something goes wrong. That knowledge doesn’t become useless because a new technology appears.

Are we misplacing AI risk?

Last week saw a panicked sell-off of SaaS shares. SaaS valuations have compressed sharply: the industry’s average forward price-to-earnings ratio dropped from roughly 39x to 21x in four months, the steepest decline since the dot-com bust. HubSpot has lost more than half its market cap. ServiceNow has shed a quarter of its value in early 2026 alone.

The fear is straightforward: if AI agents can help build and automate customized workflows, why pay per-seat licenses for software that wraps those workflows in a UI?

While there has been a lot written about the future of software (Ben Thompson has a great take here), my take is that the threat to SaaS companies is real, but it’s a threat to their delivery mechanism, not to their accumulated knowledge.

The UI may become less important, but the data, the domain logic, the workflow intelligence remain critical. The companies that recognize this distinction early, that invest in becoming excellent context providers rather than clinging to their role as the place where work gets done, could be the ones that thrive.

To put it another way, if you make yourself indispensable, it doesn’t really matter how users interact with your services. They will still pay you. The hard question is whether your product’s value lives in the domain knowledge it encodes or in the UI it wraps around commodity workflows.

Product Strategy in the AI Era

If I were a SaaS product manager right now, I would think very carefully about how to integrate AI capabilities in my core experience. Every SaaS company is doing this, and the result is a dozen mediocre, context-limited AI assistants competing with general-purpose models that are improving on what feels like a weekly cadence.

The alternative could be to invest in a clearly documented, well-structured set of data and tools that general-purpose agents can consume (and pay for). Think of your application as an MCP or API-first context provider. The product decisions become: which data and tools do you expose, which do you keep behind your own experience, and where does your application’s judgment remain essential?

Your monetization shifts from “how many humans log into our UI” to “how much value does our context and domain logic create when consumed by agents acting on behalf of those humans.”

This could be a meaningful and challenging pivot. Per-seat pricing assumes humans are the primary consumers of your product. When agents become the primary interface, pricing needs to reflect the value of context provided, not the number of logins.

Feeding the Machine..

Building QuietReads and then connecting it to Claude made me wonder whether the future of software is a collaboration between narrow, domain-focused applications and powerful general-purpose AI agents. Purpose-built apps hold context. Agents provide reach and reasoning. The connection layer (MCP today, whatever comes next) is what makes them more than the sum of their parts.

For domain specific applications to survive and grow, they must make their context available, clearly, reliably, and with the domain intelligence intact with a reasonable monetization layer. The ones that try to be everything, to build their own agents, their own chat interfaces, their own general-purpose capabilities, will find themselves outpaced by tools built for exactly that purpose.

Eko doesn’t need to be Claude. Claude doesn’t need to be Eko. They need to talk to each other.

Context Engineering as Narration

by

User profiles are stories compressed into spreadsheets. LLMs let us uncompress them. This is both a context engineering challenge and a storytelling one.

We’ve been building user profiles for a long time.

A resume is a narrative of a career. Law enforcement builds behavioral profiles to predict what suspects might do next. Shows like Mindhunter and Criminal Minds are entirely predicated on investigators constructing psychological profiles and using them to anticipate behavior (or not).

All of these profiles are narratives. They tell stories about people, with motivations, histories, and trajectories.

When we started building software, we had to flatten user profiles into rows in a database. Computers couldn’t reason about prose. They didn’t understand narrative. So we used structured data: fields, values, things they could query and aggregate. 

But now we have systems that can make sense of narrative. The question is how we make the most of these capabilities.

A user profile – both as a set of attributes and as a narrative

The user profile as we know it

We are conditioned to think of a user profile as a set of attributes. 

It might be simple: last purchase date, email preferences, customer tier. Or it might be complex: ML feature vectors, propensity scores, behavioral clusters. User profiles are usually structured, quantitative, and designed for database queries and analytics. They answer questions like “who should we target with this promotion?” or “what products should we recommend?”

This approach has been the foundation of the software ecosystem. Recommendation engines need feature vectors. Segmentation tools need categorical labels. Analytics dashboards need numbers they can aggregate and chart.

But these profiles are snapshots, not stories.

A traditional profile captures what happened, not why. Consider: your profile says a user hasn’t bought ice cream in three months. But it can’t tell you why. Did they go on a diet? Develop lactose intolerance? Move to a colder climate? Simply got bored of it?

Traditional ML can try to infer causality through revealed preferences. Maybe the user has been buying lactose-free milk, or medication for lactose intolerance. A clever feature engineer might connect those dots. But this approach may not scale. 

It’s like looking at a single frame in a comic book. You can see what’s happening in that moment, but you don’t have the panels before and after that give it meaning. 

A graphic novel would show the doctor’s visit, the dietary change, the moment of temptation at the frozen aisle. A database row just shows: 

{last_ice_cream_purchase: null, days_since_purchase: 90}.
The difference between a single frame – “I won’t buy ice cream” and a more coherent narrative

LLMs thrive on narratives

Building conversational and personalized AI experiences with large language models (LLMs) allow us to switch from a stats-based user profile to a narrative-based profile. This requirement reshapes how we think about user data.

Let’s address the obvious question: why can’t we just serialize our JSON user object into the prompt? LLMs can parse structured data, after all.

They can. But narrative representation offers something structured data doesn’t.

Narrative captures causality and motivation. Compare:

“She bought the standing desk because she mentioned back pain last month”

To:

{purchased: "standing_desk", category: "furniture"}.

Narrative could also handle ambiguity gracefully. “She seems to prefer premium brands, though she’ll opt for value options when buying in bulk” reads naturally. Encoding the same nuance in structured data requires awkward confidence scores and conditional logic.

And narrative is closer to how humans think about other humans, which is precisely what we’re asking the LLM to do. The profile needs to become something the LLM can reason about, not just reference.

The UX problem

There is a significant catch. We assume that the user would be willing to tell us what they are thinking when they ignore the ice cream and buy lactose-free milk.

This implies a UX shift, not just a data representation shift. 

Clickstream data tells you what users did. Conversational UX lets them tell you why. You need to build an experience where a user feels comfortable saying “I’m looking for a standing desk because I’ve been having back pain” rather than just clicking through product pages.

Look, I know that maybe 10-20% of people might provide further context on their decisions. Nobody likes talking to bots after all. But that 10-20% is gold. And the conversational interface creates the possibility of asking follow-up questions and perhaps building understanding over multiple interactions.

This is a significant departure from traditional eCommerce, which follows a browse → click → buy pattern. We’re moving toward something more like a conversation with a knowledgeable salesperson who remembers you.

There’s a chicken-and-egg challenge here. Users share more when they see value in sharing, but the experience only improves if they share. Solving this is a design problem, not just a technical one.

Looking ahead, this shift toward narrative has implications beyond human-to-AI interactions. As we move toward agentic commerce, users’ agents will decide what parts of their narrative to share with merchant agents. A narrative-based approach opens the door to richer agent-to-agent interactions. But that’s a topic for another post.

From attributes to character descriptions

What does the shift from attributes to narrative actually look like in practice?

Instead of: 

{loyalty_tier: "gold", avg_order_value: 142, preferred_category: "electronics"}

You might have:

“Sara is a loyal customer who tends to make considered purchases, typically in the $100-200 range. She gravitates toward electronics and has shown growing interest in home automation over the past six months. Her recent browsing suggests she’s researching smart thermostats, possibly triggered by a move to a new home.”

The narrative captures nuance, temporality, and implied motivation. It allows the LLM to make decisions on a richer set of data.

There is a potential short-cut here: the LLM itself can generate this narrative.

You can use an LLM to transform database rows into prose, and the same LLM (or another) to consume that narrative for personalization. The narrative becomes a kind of intermediate representation, optimized for reasoning rather than storage.

This isn’t free, of course. The LLM generating the narrative needs guidance about what matters, which means you’re still encoding domain knowledge somewhere. You’re moving complexity from feature engineering to prompt and context engineering. But the output is more flexible, and the reasoning that consumes it is more powerful.

The context engineering challenge

Creating the narrative is only the beginning. The harder problems come after.

  • Selection: Which data points matter? A user’s purchase history might have thousands of entries. What belongs in the profile right now? One direction is to distinguish between what’s relevant to the current task versus what belongs in a general standing profile. Using embedding based retrievals, graph representations of user profiles, and other techniques could all be useful here.
  • Prominence: Not all facts are equally important. How do you weight recency versus frequency versus magnitude? Do you apply some sort of “salience algorithm”? Or do you let the LLM itself determine what to emphasize based on the current context.
  • Temporality: If a user mentioned they like chocolate ice cream two years ago, is that still relevant? What if they’ve since developed lactose intolerance? Approaches here include forgetting curves inspired by memory research, explicit decay functions, and contradiction detection that notices when new information conflicts with old.
  • Evolution: As users interact with your application, how do you update their profile? What triggers an update? This might involve event-driven updates, periodic summarization, or distinguishing between explicit signals (the user told you something) and inferred ones (you noticed a pattern).

This is where context engineering comes in. Engineers and designers must determine what’s important for the LLM to know in order to serve the user well. General-purpose tools like ChatGPT, Gemini, and Claude are introducing memory features, but these are designed for general use. Domain-specific applications can do better by encoding domain-specific knowledge about what matters.

Tools like Mem0, Zep, and LangMem are beginning to address these challenges, building memory layers that handle persistence, retrieval, and evolution. I’ll explore these memory architectures in more depth in an upcoming post.

It’s worth noting that dynamic generation adds latency and cost. For high-volume applications, you’ll likely cache narratives and update them periodically or on significant events, which reintroduces some of the “snapshot” quality we’re trying to escape. LLMs may be amazing, but they still demand that we think carefully about tradeoffs.

A different kind of engineering

I believe that building personalized AI experiences is fundamentally a narrative challenge.

We need to think about users the way novelists think about characters. Not as collections of attributes, but as people with stories that are still being written.

This isn’t a trivial problem. Research shows that even frontier models struggle to track dynamic user profiles accurately. The PersonaMem benchmark, which tests whether models can maintain and update user profiles across long conversations, found roughly 50% accuracy on profile evolution tasks.

Narrative profiles aren’t universally superior. For high-frequency, low-latency decisions (fraud detection, real-time bidding), structured profiles remain the right tool. And for brand-new users, you need some data before you can narrate anything. The cold start problem doesn’t disappear. But for the growing category of conversational, personalized experiences, the shift towards a narrative and profile driven approach will be inevitable.

Footnote:
This post is part of a series of posts on building with LLMs. You might find the following posts interesting:

The Lego Model: How Tool Calling Changes the Way We Build AI Applications

by

“What should I read next?” seems like a simple question. But answering it well requires knowing what the user is currently reading, what they’ve finished recently, and what’s already on their list. When I built QuietReads, a book tracking app with an AI assistant, I faced a choice: pre-load all this context on every request (expensive), build complex routing logic to fetch the right data (brittle), or find a different approach entirely.

In those post, I talk about why I chose this option, the architectural implications, and the tradeoffs involved. 

Conversational Interfaces Are Not Deterministic

A lot of mid-career technologists like me still think deterministically. We reach for decision trees, map out every probable permutation, and write test cases to cover each branch. This works well for forms and structured APIs where you control the inputs.

But QuietReads has a chat interface. Users might ask:

  • “What should I read next?”
  • “I’m in the mood for something like the last book I finished, but shorter”
  • “What were my thoughts on that dystopian novel from last month?”
Asking the QuietReads assistant to recommend some books

Each query requires different context. The first needs the user’s want-to-read list. The second needs their recently finished books plus some understanding of “shorter.” The third requires searching through their notes. I couldn’t predict which context any given question would need, and I didn’t want to fetch everything every time.

The traditional approach would be routing logic. For just the first query, you might write something like:

def get_context_for_recommendation(message, user_id):
    context = {}

    if contains_recommendation_intent(message):
        context['want_to_read'] = get_want_to_read_books(user_id)
        context['recently_finished'] = get_recently_finished(user_id)

        if mentions_specific_book(message):
            book = extract_book_reference(message)
            context['book_details'] = get_book_details(book)

    # ... and this continues for every intent type
    return context

This gets unwieldy fast. Each new question type requires new routing rules. The intent detection functions themselves need maintenance. And you’re constantly guessing what context the model will need.

LLMs allow us to use a different mental model. 

Think of LLMs as expert Lego assemblers. You provide a curated set of bricks (tools), an instruction manual (your system prompt), and let the assembler determine which bricks to use and in what order. You don’t hand them every brick in existence. You give them the right pieces for the task and clear guidance on when to use each one.

Tools as Building Blocks

In QuietReads, I define “context tools” that let the AI retrieve user data as needed:

CONTEXT_TOOLS = [
    {
        "name": "get_user_profile",
        "description": (
            "Get the user's name and reading preferences. Use this when you need to "
            "personalize your response or discuss their reading interests."
        ),
        "input_schema": {"type": "object", "properties": {}}
    },
    {
        "name": "get_want_to_read",
        "description": (
            "Get books on the user's want-to-read list. IMPORTANT: Always call this "
            "BEFORE recommending any books to avoid suggesting books they already have."
        ),
        "input_schema": {
            "type": "object",
            "properties": {
                "limit": {"type": "integer", "description": "Max books to return (default: 10)"}
            }
        }
    }
]


Each tool has a clear description of when to use it. The model reads these descriptions and decides which tools to call based on the user’s question.

The Agentic Loop

When the model decides to use a tool, we handle that request, execute the tool, and feed the results back. This creates a loop (simplified code below):

async def execute(self, system, messages, tools, tool_handlers, max_tokens=2048):
    response = self.client.messages.create(
        model=self.model,
        max_tokens=max_tokens,
        system=system,
        messages=messages,
        tools=tools
    )

    while response.stop_reason == "tool_use":
        tool_results = []

        for block in response.content:
            if block.type == "tool_use":
                tool_name = block.name
                tool_input = block.input

                # Execute the tool and capture result
                result = await tool_handlers[tool_name](tool_input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": result
                })

        # Feed results back and get next response
        messages.append({"role": "assistant", "content": response.content})
        messages.append({"role": "user", "content": tool_results})
        response = self.client.messages.create(...)

    return response

The model might call multiple tools, or call the same tool with different parameters, or decide it has enough context after the first call. 

The loop continues until the model has everything it needs to answer. In practice, you should also enforce a maximum iteration count as a guardrail against runaway loops or unexpectedly expensive queries. When the model requests multiple tools in a single response, you can execute them in parallel for performance gains.

This code handles the happy path. Production implementations need additional safeguards: error handling when tools fail or timeout, validation of tool inputs before execution, and graceful handling when the model hallucinates a tool name that doesn’t exist.

Client and Server-side Tools

QuietReads uses two categories of tools. Client-side tools are functions I implement: when the model calls get_want_to_read, my code queries the database and returns formatted results.

Server-side tools are capabilities the AI provider offers (like the web_search tool used below). 

I enable web search so the assistant can look up recent book releases or author news. Anthropic’s infrastructure handles the search; I just control when and how it’s available:

tools:
  web_search:
    type: "web_search_20250305"
    name: "web_search"
    server_side: true
    enabled: true
    config:
      max_uses: 5  # Limit searches per request

With some prompt engineering, the model can integrate custom database queries with real-time web searches, producing responses that feel coherent to the user. 

The system prompt guides how the model synthesizes information from different sources, when to cite web results versus personal reading history, and how to maintain a consistent voice across tool-augmented responses.

Architectural Implications

It is important to recognize where determinism matters and where it doesn’t. Each tool is a testable piece of code. I can unit test get_want_to_read in isolation, verify it returns the right data, and trust it to behave consistently. What I can’t fully predict is which tools the model will call or in what order. In my work, I have found that even cheaper models like the Haiku family of models do a decent job at tool use.

This separation has practical implications. Tool descriptions are instructions the model uses to decide when to call each tool. Writing clear, specific descriptions is as important as the implementation itself. Instead of pre-loading everything a user might need, I provide minimal context upfront and let the model request more, keeping initial requests fast and reducing token costs.

And while the model chooses its tools, I still control the boundaries. QuietReads runs input guardrails before messages reach the assistant and can validate outputs before returning them to the user.

The Tradeoffs

Tool calling introduces real costs that you should weigh against your specific requirements.

  • Predictability. With static context, you know exactly what data the model sees on every request. With tool calling, the model decides what to retrieve. This makes cost and performance harder to predict. A simple question might resolve in one API call; a complex one might trigger four tool calls and five round-trips.
  • Prompt caching. Static context can benefit significantly from prompt caching, where repeated system prompts are stored and reused. Dynamic tool results change with each request, which can reduce or eliminate caching benefits. Depending on your usage patterns, this could meaningfully impact both latency and cost.
  • Quality assurance. Unit testing individual tools is straightforward, but testing the system end-to-end becomes harder. The model might call tools in unexpected combinations, or skip tools you expected it to use. Comprehensive evaluations become essential because tool calling adds non-determinism to the critical path. I’ll write more about evaluation strategies in a future post.
  • Refactoring risk. IDE tooling can automatically update function signatures across a codebase. Tool definitions live in JSON objects that describe behavior and parameters in natural language. If you change a tool’s behavior or modify its parameters, automated refactoring won’t catch the JSON definitions, and the mismatch may not surface until production. LLM-based coding agents like Claude Code handle this well, and adding tool-specific checks to code review agents helps catch these issues.
  • Latency. Each iteration of the agentic loop requires a round-trip to the API. For QuietReads, this is acceptable. For applications where response time is critical, the additional latency may be a dealbreaker.

That said, tool calling offers real advantages beyond flexibility. Token costs can decrease because the model only retrieves data it actually needs. Direct tool calls avoid the protocol overhead of intermediary layers like MCP servers. And tools create a clean separation of concerns: database migrations, API upgrades, or new data providers can happen without touching the prompt.

This pattern fits QuietReads: read-only tools, flexible latency, and context costs that exceed API overhead. Applications with side effects, strict latency, or predictable context needs may want different approaches.

Navigating a Mindset Shift

Building with tool calling requires accepting the risk of non-deterministic code execution. You cannot predict every code path. Instead of mapping out decision trees, you’re designing capabilities and constraints. You’re giving the model a well-stocked toolbox and clear guidance, then trusting it to assemble the right response.

You control what tools exist, what data they access, what the model knows about when to use them, and what guardrails prevent misuse. The model handles the dynamic orchestration that would otherwise require hundreds of lines of if/else chains.

For those of us who’ve spent years thinking in flowcharts, this shift takes practice. But once it clicks, you start asking different questions: not “what are all the paths a user might take?” but “what capabilities does the model need, and how do I describe when to use them?”

Building at the Speed of Thought

by

On building QuietReads, Claude Code, and the inversion in software economics

I have wanted to build QuietReads for two decades.

The idea is simple: a book tracking application that treats reading as a reflective practice rather than a social performance. Just you, your books, and an AI companion that remembers what you’ve read and can discuss it with you.

Every few years, I would sketch out the features, maybe prototype a database schema, and then abandon the project when the scope overwhelmed the time I could spare. The economics never worked. Building a full-stack application with authentication, third-party integrations, and a sophisticated AI layer would take months of focused effort. I had a day job. I had a family. QuietReads stayed in the drawer.

Then came Thanksgiving 2025. Anthropic rolled out $1000 in API credits for Max subscribers to use with Claude Code, their agentic coding tool. The Opus 4.5 model had just launched. I decided to try again.

Two weeks later, QuietReads was live.

QuietReads organizes books in a Library View

What Changed?

This wasn’t my first attempt at building QuietReads with AI tools. Last summer, I tried vibe-coding the same application using Replit, Cursor, and an early version of Claude Code running Sonnet 4. The results were miserable. The AI agents went off the rails constantly, making changes I didn’t ask for, getting stuck in loops, producing code that looked plausible but broke in subtle ways. I gave up after burning through credits and several frustrating weekends.

The difference with Opus 4.5 was stark. 

Where Sonnet 4 required constant hand-holding, Opus 4.5 understood what I was trying to build. It made architectural decisions that made sense. When I pointed it at a bug, it found the root cause rather than applying band-aids. It demonstrated genuine systems thinking: analyzing trade-offs, proposing multiple approaches with honest assessments of pros and cons, thinking through downstream implications.

Claude Code making suggestions on how to refactor the AI Assistant to make tool calling more consistent

The screenshot above shows Claude Code reasoning through three different implementation approaches for a feature, weighing simplicity against performance against pattern consistency. This is a discussion I would expect to have with a senior developer. The options made sense, and I was able to make an informed decision on how I wanted to structure a key component of the application.

I shipped a full-stack, mobile-responsive application with social login, Google Books integration, and an AI reading companion that maintains persistent memory of your reading history. The companion can engage in literary discussion, reference your previous notes, and connect themes across books you’ve read months apart. You can @mention it in any note or journal entry, and it responds with context. Everything flows into a unified timeline that weaves together notes, reading sessions, and AI conversations.

Eko, QuietReads’s default AI Assistant helps me understand Neil Postman’s work. Books in AI responses are interactive components, allowing me to add them straight to the library.

The Inversion

My experience with QuietReads is a small data point in a larger pattern. We are navigating an inversion in how software gets built.

For decades, every decision about software development has been constrained by the scarcity of labor. Whether to buy or build. Whether to refactor legacy code or start fresh. Whether to ship now or wait for more resources. 

The person has always been the limiting factor, the most expensive line item, the ever-present bottleneck. 

The language of our industry reflects this: we estimate in person-days, bill in person-hours, staff projects in person-months.

That bottleneck is fading faster than I expected.

Boris Cherny, the creator of Claude Code at Anthropic, recently revealed that he didn’t open an IDE for an entire month. Every line of code he shipped during that period (259 pull requests, 497 commits, 40,000 lines added, 38,000 removed) was written entirely by Claude Code powered by Opus 4.5.

“Software engineering is radically changing,” Cherny wrote, “and the hardest part even for early adopters and practitioners like us is to continue to re-adjust our expectations.”

I am not Boris Cherny. I don’t work at Anthropic. I don’t have access to internal builds or institutional knowledge. But my experience over the holidays rhymes with his. And I’m not alone. Developers across the industry spent the holiday break shipping projects that had languished for years, finally made tractable by the combination of Opus 4.5 and Claude Code’s improved agentic capabilities.

Lots of people had “Claude Code” moments over the holidays..

So What Does This Mean for People Like Us?

In March 2025, Anthropic CEO Dario Amodei told the Council on Foreign Relations that he expected AI to be writing 90% of code within three to six months, and essentially all code within twelve months. The industry-wide numbers haven’t hit those marks. But within certain teams and workflows, his timeline looks prescient. Cherny’s experience is evidence. So is mine.

Software engineering as we know it is going to change faster than many of us imagined. The fundamental assumptions that drive economic decisions around building software (hiring models, training investments, vendor selection, build-versus-buy calculations) will all need revisiting. The implications extend beyond individual productivity gains into questions about how power accrues to capital and compute, and what happens to labor markets when a significant category of knowledge work becomes dramatically cheaper to produce (See footnote).

Remember: the models you’re using today are the worst they will ever be.

A User Base of One

On a more personal note: I’ve enjoyed using QuietReads. It is very much an application I built for myself, though perhaps you might enjoy it too (sign up here – let me know what you think). I have a backlog of features I want to add (voice notes, OCR for capturing physical book passages, maybe a Kindle integration to sync highlights) and I’m confident I can build them quickly.

I look forward to building more applications. Maybe something to help train my recalcitrant hound dog to stop stealing food. Maybe something to help my daughters learn Gujarati.

What I know for certain is that my view of how software gets built has shifted faster than I expected. Coming to terms with the pace of improvement has required repeated recalibration.

I am equal parts excited and terrified about what comes next.

Footnote:

There has been a lot of discussion about the macro-economic implications of broad AI adoption. From Dwarkesh Patel and Philip Trammell talking about Capital in the 22nd Century, to many, many posts that swing from breathless excitement to abject terror. Maybe we may even see an acute version of Baumol’s cost disease – where a significant bump in software productivity drives up costs and inflation as lower productivity sectors raise wages to compete leading to a hyper-inflationary spiral? Or perhaps Jevon’s paradox will reign supreme and we will end up with an absolute explosion of software tools.