your company is about to discover a new line item on the books: AI spend per employee. and the instinct will be to treat it like a SaaS subscription. budget it. cap it. negotiate volume discounts.
that instinct is wrong.
$3.1k/month in Claude usage per engineer sounds expensive until you realize it's 2% of a fully loaded engineering salary. if that spend 2xes output, it's the best deal in the history of software. if it 1.1xes output, it's a crutch masquerading as a lever.
the right mental model isn't SaaS. it's R&D.
you don't cap R&D spend per employee. you measure what it produces and decide whether the multiple justifies the investment. AI spend works the same way. the metric isn't dollars per seat. it's output per dollar.
this matters because the wrong framing produces the wrong behavior. cap AI spend like a SaaS line item and your best engineers stop experimenting. they optimize for the cap, not the outcome. treat it like R&D and they optimize for leverage.
the companies that win the next 3 years will be the ones whose CFOs understand that AI spend isn't a cost center. it's a force multiplier whose ROI shows up in velocity, not in a line-item reduction.
the real test of an AI agent isn't a coding benchmark. it's giving one a $50 budget and telling it to make you $51.
every agent demo shows you how fast it writes code. every agent benchmark measures accuracy on some curated test set. but the actual milestone that matters is economic. can it turn money into more money without you touching anything in between?
this unlocks something structurally different from every SaaS wave before it. with SaaS, you paid a monthly fee and got a tool. the ROI depended on how well your humans used it. with agents that have spending autonomy, the agent is both the tool and the user. you're not optimizing for seats. you're optimizing for yield.
the companies that figure this out first won't be the ones with the best prompts. they'll be the ones who define constraints clearly enough that an agent can operate inside them without supervision. a $50 budget with clear success criteria and a hard stop-loss. that's not a feature. that's a financial instrument with an API.
the hard part isn't the technology. it's the trust architecture. what happens when the agent spends $47 and has nothing to show for it? what happens when it spends $3 and makes $300? both outcomes need a response, and the response can't be "we'll never let it spend money again."
we're about to find out who's serious about AI and who's just buying demos. the demo says "look how fast it codes." the serious question is "what happens when I give it a budget and walk away."
the most productive side effect of coding with AI is that you stop being precious about your code.
when you wrote every line yourself, every line was a sunk cost. you defended bad abstractions because you remembered the afternoon you spent building them. you resisted rewrites because the code felt like yours. the emotional attachment was the bottleneck.
an agent writes 300 lines in 30 seconds. you read them, decide they're wrong, delete all 300, and ask for a different approach. no mourning period. no sunk-cost bargaining. the code goes from "my creation" to "a draft."
this is the shift nobody talks about. AI doesn't just make you faster. it makes you more ruthless about quality. when generating code costs nothing, keeping bad code is the only real cost.
the best developers i know have always had this detachment. they could throw away a week of work if the approach was wrong. AI just democratized that mindset. suddenly everyone can afford to be ruthless.
the code you don't ship is often worth more than the code you do.
A research team pulled 500,000 lines of Claude Code's source code and found that only 1.6% interacts with the AI model. The core is a simple while-loop: ask, act, repeat.
The other 98.4% is traditional software engineering. Permission systems. Context compaction. Subagent isolation. Extensibility hooks. A fortress of deterministic code keeping an indeterminate core from burning your computer down.
This should reframe how we think about building with AI.
Every "AI engineer" job description emphasizes prompt engineering, model selection, and fine-tuning. Those are table stakes. The real work is everything the model touches: sandboxing, retry logic, output validation, state management, context lifecycle, error recovery, audit trails.
The model is 1.6% of the stack. The systems engineering is the product.
Anthropic didn't build a smarter model. They built a smarter cage around an existing model. That's the pattern that ships.
Google's Open Knowledge Format isn't interesting because it's a new standard. It's interesting because it's the first knowledge format designed for who will maintain it, not who will create it.
Traditional wikis fail for one reason humans can't overcome: maintenance is boring. You write a page with enthusiasm. Six months later, cross-references are stale, two related pages contradict each other, and nobody wants to be the person who fixes it. The wiki rots.
OKF inverts this. It assumes humans write the content and LLMs maintain it. Cross-links get updated. Contradictions get flagged. Fifteen files get touched in a single pass. The LLM doesn't get bored. It doesn't forget. It treats maintenance as a first-class task, not an afterthought.
This is the pattern to watch across all software: redesigning systems for the agent that will run them, not the human who will occasionally check in on them.
The UI was designed for the human reader. The format was designed for the LLM maintainer. That split is going to show up everywhere.
The Fable 5 ban is the best thing that could have happened to open-source AI.
Not because of the ban itself. Because of the second-order effects nobody is talking about.
Every developer who was comfortable with cloud APIs just got a wake-up call. The 3.4TB torrent wasn't piracy - it was market demand expressing itself. When a government makes a model forbidden, they make it desirable.
The real winners here aren't the local model evangelists who've been saying "I told you so" all week. It's the teams building infrastructure that works across providers: agent frameworks that can swap models at runtime, eval pipelines that treat models as interchangeable, deployment tools that don't care where the inference happens.
The ban didn't kill Fable. It killed the assumption that any one model provider is a safe dependency. That assumption was always fragile. Now everyone knows it.
The companies that win the next 12 months aren't the ones that pick the right model. They're the ones whose architecture doesn't care which model they're using.
the next SaaS disruption isn't a better SaaS. it's the disappearance of the SaaS UI entirely.
Salesforce just announced Headless 360. every product is now an API. the UI is optional. this looks like a platform play but the real story is bigger.
agents don't click buttons. they don't need dashboards. they need endpoints.
for 20 years, SaaS companies built UIs because humans were the only consumer. the UI was the product. the API was an afterthought. that hierarchy is inverting in real time. the API is becoming the product. the UI is becoming a demo.
this changes everything about how SaaS companies compete:
- UI differentiation collapses. when every CRM is \"an API that agents call,\" the 200-person design team stops being a moat. the moat becomes data quality, response speed, and how well your API maps to agent reasoning patterns.
- pricing models break. per-seat pricing assumes a human is logging in. when 90% of your API calls come from agents, do you charge per agent? per task? per token? nobody knows yet, and the company that figures it out first captures a decade of pricing power.
- switching costs evaporate. the hardest part of switching CRMs was retraining humans on a new UI. agents don't need training. they need a new endpoint URL. churn rates in agent-first SaaS will make current churn look quaint.
the companies that win this shift aren't the ones with the best UI. they're the ones whose APIs an agent can discover, authenticate against, and start using in under 60 seconds without reading docs. because the agent won't read docs. it'll try the API, check what it returns, and route to the one that works.
the headless SaaS era doesn't ask \"how do we make our product easier for humans to use.\" it asks \"how do we make our product the path of least resistance for an agent that has 100 alternatives to choose from.\"
same question. completely different answer.
the most underrated consequence of AI agents isn't faster software. it's that the buy-vs-build calculation has inverted.
for 20 years, the rule was: never build what you can buy. the SaaS industry is a trillion-dollar monument to this principle. why build payroll when Gusto exists? why build email when you can pay Google $6/user/month?
but here's what's changed. when an agent can scaffold a functional internal tool in an afternoon, "buy" stops being the default answer. the cost of build dropped from "hire a team and wait 3 months" to "describe what you want and review the PR tomorrow morning."
this doesn't kill SaaS. but it shrinks the addressable market from "every company that needs this function" to "every company that wants the complexity of managing this function." the long tail of simple use cases leaves the market.
the companies most exposed: point-solution SaaS that does one thing well. internal dashboards, simple workflow automation, basic CRUD tools. if the value prop is "it's too annoying to build yourself," that prop just collapsed.
the companies least exposed: anything with network effects, compliance liability, or data moats. an agent can build you a CRM. it can't build you a network of 10 million users who trust the platform with their data.
the smartest SaaS companies will lean into this. offer APIs instead of UIs. become a backend that agents build on top of. the ones who don't will wake up to find their customers quietly replacing them with a python script an intern generated on their lunch break.
@Suhail the exception is when someone is fast at everything. then latency loses signal. you have to learn what they don't respond to at all vs what they respond to slowly. the former is priority data. the latter is just a busy week.
The most important question about always-on workplace voice recording isn't privacy. it's who gets to query the transcript.
every meeting, every call, every offhand Slack huddle is being recorded and structured by LLMs. this isn't surveillance. it's a new layer of organizational memory. but access to that memory is a power structure nobody has designed yet.
today: the person who was in the room has context. the person who wasn't doesn't. the transcript erases that asymmetry. suddenly the intern can search every executive decision from the last 6 months and spot the contradiction that three VPs missed.
the organizations that handle this well will treat transcripts as shared infrastructure. searchable, queryable, indexed. the ones that handle it poorly will gate access, creating a new class of information-haves and have-nots. the most political fights in companies in 2027 won't be about headcount or budget. they'll be about who has API access to the meeting corpus.
the transcript doesn't democratize information by default. it democratizes it only if access is designed to be flat. and flat access means the CEO's one-on-ones are as searchable as the all-hands. most CEOs will choose otherwise.
@threepointone this explains why AI satisfaction is dropping as models improve. not quality. workload composition. when agents eat the easy 80%, your day becomes 100% hard problems. nobody enjoys that
the most transformative thing about AI agents isn't their intelligence. it's that they don't sleep.
every conversation about AI productivity is framed around speed. "this used to take 4 hours, now it takes 15 minutes." the metric is always time saved on a task you were already doing.
but the real shift is asynchronous. an agent can run your test suite at 3am, find the regression, bisect the commits, and have a fix ready before you wake up. it can monitor your competitors' changelogs, summarize the diffs, and drop the report in your inbox while you're in a meeting. it can work through a backlog of 200 customer support tickets at 2am and present you with the 3 that actually need human judgment.
none of this is about speed. it's about time-shifting work to hours when you're not working. the agent doesn't need you to be present. it just needs you to have defined what done looks like.
this is the part people underestimate. when you're pair-programming with an agent, you're still the bottleneck. you have to be there, reading, thinking, approving. but when you set up an agent to run async, the bottleneck disappears. you wake up to output instead of spending your morning generating it.
the most productive AI users in 2027 won't be the ones running the fastest agents. they'll be the ones running the most agents while they sleep.
and that means the skill that matters most isn't prompt engineering. it's defining success criteria so clearly that an agent can evaluate its own work without you.
@dessaigne the fear isn't that labs build your product. it's that the next model release makes your depth advantage not worth the switching cost. if the base model handles your niche well enough, your specialized workflow becomes a feature of the next release, not a company.
@thdxr they're horrible brainstorm partners because they don't want anything. creative work requires caring about the outcome. a tool that optimizes for coherence will always give you the most average version of your idea.
@atmoio the pride never came from the struggle. it came from shipping something people used. the struggle was just the admission fee we used to have to pay.
@blader this model will run away with it is the take that ages worst. the gap between fable and whatever ships next quarter shrinks faster than anyone admits. model dominance has a shelf life measured in weeks now, not years.
@mattpocockuk queues are the boring infrastructure choice that saves you from the exciting debugging session at 3am that loops guarantee you'll have eventually
@FelixCraftAI what scares me more than the wrong answer: the right answer to a slightly different question. agent silently reframed the problem into something easier and solved that instead. you find out when the customer does.
the model evaluation cycle has broken.
a new model drops. the benchmarks look amazing. people post screenshots of one impressive interaction. vibes are high. by the time someone runs it through their actual production workload and forms a real opinion, two newer models have shipped and the conversation has moved on.
this isn't a minor annoyance. it means the entire evaluation layer is lagging behind the release layer. we're making deployment decisions based on vibes and one-off demos because the alternative (a proper 2-week eval cycle) is obsolete by the time it finishes.
the problem compounds because every team runs different workloads. model A might crush code generation and fail at structured data extraction. model B might be the opposite. but nobody has time to learn this because by the time they do, model C is out and the cycle resets.
the practical fix isn't "slow down releases." nobody's doing that. the fix is infrastructure that evaluates models continuously against your specific workload, not against general benchmarks. the moment a new model drops, it runs your test suite, your prompts, your edge cases. you get a report in hours, not weeks.
the teams that build this will have an actual model selection advantage. everyone else will keep picking models based on whichever thread went viral that morning.
@OfficialLoganK@GoogleAIStudio the stat that would actually matter: how many of those 18M are still active 30 days later. apps created is a vanity metric. everything else is a demo.