I spent the last two to three years building an automation platform for legal-medical professionals, trying to eliminate the hours paralegals and nurses burn copy-pasting between systems. Summarizing medical records. Extracting data from dense PDFs. Cross-referencing documents. Precision work that requires more patience than most humans can sustain.

Last week, I did the same task in five minutes using CoWork.

Five minutes.

I’m still processing that. Years of building tooling and process, reduced to a folder permission and a prompt. The efficiency isn’t incremental. It’s categorical. It’s the kind of gap that makes you question what you’ve been doing with your time.

And yes, it’s not perfect. But here’s the thing: neither are we.

When you’re copying data between files, reformatting spreadsheets, summarizing documents manually, the error rate is real. Typos. Missed rows. Wrong cell references. The human error surface in repetitive knowledge work is enormous, and we’ve just normalized it. We call it “being careful.” We call it “double-checking.” We call it “Friday afternoon syndrome.”

CoWork doesn’t get tired. It doesn’t lose focus. It doesn’t paste into the wrong column because Slack pinged at the wrong moment.

I challenge anyone to prove otherwise.

This is the true beginning of work in the AI age.

Not chatbots answering questions. Not copilots suggesting code. An agent that operates in your actual environment, on your actual files, completing actual tasks while you do something else.

Think about what we do every day. Every interaction involves data. Every task involves information. Reading emails. Writing emails. Opening documents. Creating documents. Moving data from one place to another. Summarizing. Formatting. Organizing.

This is what knowledge work is. Legal professionals. Medical professionals. Finance.. Anyone whose job involves looking at a screen and manipulating information.

All of it is now table stakes for automation.

There are no ifs. There are no buts.

I’m having this argument with my wife as I write this.

She recently joined hospitality finance. The entire team lives in headless Excel mode. Sheets referencing sheets referencing sheets. Manual data entry from PDFs. Reconciliation by eyeball. Formulas held together with good intentions and prayer.

It’s painful to hear about. I can only imagine it’s demoralizing to actually do.

This isn’t a criticism of her or her colleagues. They’re smart, capable people doing their jobs the way they’ve always been done. But that’s exactly the point. The way it’s always been done is no longer the only option.

CoWork doesn’t replace the judgment. It doesn’t replace the expertise. It replaces the drudgery. The copying. The pasting. The reformatting. The “I need to pull this data from six different sources and put it into this report” work that eats hours and creates zero value.

What CoWork actually is

For those who haven’t tried it yet: CoWork is Anthropic’s new desktop agent, launched January 12th. It’s built on the same foundation as Claude Code but designed for non-technical users.

You give it access to a folder. You tell it what you want done. It reads your files, edits them, creates new ones, and executes multi-step workflows autonomously.

Want to turn a folder of receipt screenshots into an expense spreadsheet? Done.

Want to organize your chaotic downloads folder into something coherent? Done.

Want to synthesize a report from scattered notes across multiple documents? Done.

It’s less like chatting with an AI and more like leaving a task for a coworker who actually follows through.

The security caveats are real

Anthropic is upfront about the risks. Prompt injection is a real attack vector. Giving AI access to your file system means being thoughtful about what you expose. The research preview label exists for a reason.

But the direction is clear. This is where everything is heading.

And tools like OpenClaw (formerly Clawd) are taking similar approaches in specialized domains. The pattern is the same: give AI agents access to your actual working environment, let them operate with autonomy, and watch the efficiency gains compound.

The uncomfortable truth

If your job is primarily moving data between applications, reformatting documents, or manually synthesizing information from multiple sources, the clock is ticking.

Not because AI will replace you overnight. But because the person next to you who learns to work with these tools will operate at 10x your output. And eventually, someone will notice.

This isn’t fear-mongering. It’s observation. I’ve seen the gap firsthand. Five minutes versus years of process. That’s not a difference in degree. That’s a difference in kind.

What to do about it

The answer isn’t to panic. The answer is to get curious.

Try CoWork. Try Claude Code. Try the tools that are emerging in your specific domain. Understand what they can and can’t do. Learn where the edges are.

The judgment, the expertise, the domain knowledge you’ve built over years? That’s still yours. That’s still valuable. Maybe more valuable than ever, because now you can apply it at scale instead of burning it on data entry.

But the manual work? The copying and pasting and reformatting and reconciling?

That’s table stakes now. And table stakes don’t win games.

What’s your experience with CoWork or similar tools? I’d love to hear how others are navigating this shift.

This isn’t doom and gloom. It’s just the new landscape. The question isn’t whether AI will take over routine tasks. It already is. The real question is: what’s left for us?

It comes down to four skills. Critical thinking. First-principles thinking. Judgment. And taste.

But here’s the thing: these skills aren’t new. They’re not some invention of the AI era. They’re lifelong human capabilities we already have and use every day.

Critical thinking gets taught in schools, even if it’s not always labelled that way. Every time a kid is asked “but why do you think that?” they’re building this muscle.

First-principles thinking has been around forever, though Elon made it mainstream when he explained how SpaceX rethought rocket costs from scratch instead of accepting industry assumptions.

Judgment? That’s just decision-making, and we do it constantly. Some choices land well, others don’t. The desire to make better calls, to develop sounder judgment, that’s deeply human.

And taste. We all have it. It shifts over time. What you thought was good at 20 probably makes you cringe at 50. Taste evolves because we evolve.

So these aren’t skills you need to learn from scratch. They’re skills you already have. The difference now is that they’re essential.

So why do these four matter more than ever?

Critical thinking. AI is great at gathering and organizing information. Knowing whether that information is right for your context? That takes domain expertise. Spotting the flawed assumption buried in your prompt that’s leading you down the wrong path? That’s still on you.

First-principles thinking. AI is great at executing tasks, not defining them. The skill is decomposition and composition: breaking a problem into its core components, letting AI handle each piece, then putting it back together. Most people try to one-shot it. The best builders think in composable parts.

Judgment. You’ve broken down the problem, AI has done the work on the pieces. Now you’ve got options. Which one do you ship? AI can’t answer that. It doesn’t know what you can live with, what your customer actually needs, or what risk you’re willing to carry. That’s judgment.

Taste. What’s good versus what’s just technically correct? AI can generate a thousand variations. It can’t tell you which one actually resonates, which one feels right, which one has that ineffable quality that makes people pay attention. Taste is the filter.

These aren’t soft skills. They’re the hard skills now.

AI handles the production. Humans handle the direction.

That’s the new division of labor. The question is: are you developing the skills to direct? Or just getting faster at tasks AI will do better anyway?

Anthropic IPO

No official date announced. Will it happen? My prediction: no, not this year. And look, this isn’t like waiting for the Coinbase IPO. I don’t think anyone should put AI in the same category as crypto. Not financial advice, obviously.

OpenAI x Jony Ive Device

Sorry, not this year either. We’ll probably see some kind of always-present voice device, but creating a second iPhone moment? You can’t win the lottery twice.

Image Generation Goes Mainstream

This is my nano banana prediction. Image generation becomes a primary medium for communication. Nothing has made me happier than generating images, because I’m no longer speaking gobbledygook. I can actually explain fairly complex technical concepts to my wife now. Take that into education, any type of education, and this is going to be massive.

ChatGPT Pricing Tiers

I expect more subscription levels. Something between the $20 a month tier and the $200 Pro tier, maybe family plans. But honestly? That $200 price that had people questioning their sanity doesn’t feel expensive anymore. We have multiple ChatGPT subscriptions in the household, plus I’m maxing out Claude, Perplexity, Gemini, and Grok. When you have too many subscriptions, the answer is always another subscription.

Claude Code Evolution

My hope: Anthropic switches to agents.md and deprecates claude.md. Please. But if they don’t, progressive disclosure techniques and approaches like RPI (research, plan, implement) will gain traction. I’ve recently found some incredible resources around these that have been game changers. I’ll share more on this soon.

Apple Intelligence x Gemini

I hope this happens, and for Marc Benioff’s sake too. Foldable iPhone? Nah.

Salesforce Name Change

Speaking of Benioff, here’s a spicy one: Salesforce rebrands fully around Agentforce. Think Meta, think Alphabet. It might just be a genius move if they do.

Wishing all a very Happy New Year (2026)

Voice starts to mainstream

Voice is finally growing up.

Input and output via voice are maturing fast, and for the first time this feels inevitable rather than “just around the corner”. Voice is a more expressive, higher-bandwidth medium than typing. It lets you think out loud, interrupt yourself, correct course, and stay in flow. Chat UI is starting to feel like a temporary compromise, not the end state.

Engineers are already voting with their behaviour. More of us are switching to voice input for real work, not just dictation. Typing is slower. Context switching is worse. And now that models can clearly articulate what they’re doing and why, talking to them feels natural rather than awkward.

I’m using tools like Wispr Flow and Super Whisper daily across knowledge work, creation, and software engineering. That pattern is spreading. Creator workflows and developer workflows are leading, but this won’t stay niche for long.

Output matters just as much as input. Voice as a default response channel is rising fast. I’m perfectly happy engaging with Grok from xAI via voice, strange banter and all. The same exchange would feel tedious as text. Companion-style interactions work far better when spoken.

The irony is that while AI voice is accelerating, mainstream assistants are standing still. In 2026, we’ll be more frustrated with Alexa and Siri than ever. The gap between what’s possible and what they deliver will feel increasingly hard to excuse.

Voice won’t replace screens overnight. But it is becoming the primary interface for thinking, creating, and collaborating with machines.

And yes, the world will continue to wait for Sir Jony Ive to show up and make it all feel obvious.

The next frontier in AI engineering: memory

As AI tools become stable and ingrained in daily life, something subtle but important is happening.

They’re starting to remember us.

Not just our last prompt, but our preferences. What we like. What we ignore. How we work. That’s not a nice-to-have. That’s part of being human. And it’s where the next real shift in AI engineering sits.

We started with prompt engineering. That was the first discipline to emerge once large language models went mainstream. How you asked mattered more than what you asked.

Then came the inevitable realisation that prompts alone weren’t enough. People needed more context. More grounding. More data. Knowledge bases, vector databases, and retrieval-augmented generation followed. Those techniques hardened into what we now call context engineering.

Today, prompt engineering is mature. Context engineering is getting there. We can inject large volumes of data, shape task-specific context, and guide models with reasonable precision.

But something is still missing.

In real life, intelligence is shaped by three things:

what you’re doing now, the context you’re doing it in, and your memory of past experience. AI has the first two increasingly well covered. Memory is the gap.

That’s why the next frontier is memory engineering.

Not just “saving chats”, but frameworks, techniques, and best practices for how AI systems remember over time. What they retain. What they forget. How memory is scoped, updated, weighted, and trusted. How it influences behaviour without becoming creepy or brittle.

You can already see the direction of travel. Mainstream models now remember preferences across sessions. They adapt. They personalise. And once that door is open, it doesn’t close again.

In 2026, expect memory engineering to solidify as a real discipline. Not hype. Not branding. Actual engineering decisions that separate useful AI systems from ones that constantly need re-explaining.

Prompt gives AI a voice.

Context gives it understanding.

Memory gives it continuity.

And continuity is what makes intelligence feel real.

Enterprise AI finds more value

For much of the last 18 months, enterprise AI has been defined by noise.

Headlines about failed pilots.

Claims that AI delivered no real business value.

Staggering failure rates, often quoted north of 90%.

None of this was surprising.

Poor data led to poor outputs. Enterprise application sprawl made it almost impossible to surface meaningful context. And in many cases, AI tools were simply forced into organisations by vendors and enthusiastic CxOs, with little clarity on purpose or fit.

AI didn’t fail. The way it was introduced did.

I expect 2026 to mark the start of the swing back.

One clear signal is the momentum behind Anthropic. Claude models now run across all major cloud platforms, and they’ve quietly become the default choice for a large percentage of professional software engineers. Claude Code has earned trust where it matters: day-to-day work.

That adoption won’t stay limited to engineers. Finance, operations, legal, and marketing teams are already following. This hasn’t gone unnoticed. OpenAI and Sam Altman clearly see the shift. ChatGPT remains excellent for consumers, but enterprise is a different beast, and it’s one they’re still catching up with.

At the same time, we’re seeing the rise of “build your own”, often labelled Vibe Coding. Employees, and sometimes CEOs, are quite literally talking enterprise apps into existence. It’s fun. It’s powerful. And right now, it’s mostly unsustainable.

The result is more sprawl, not less.

This is where enterprise AI either stabilises or collapses under its own weight.

As app sprawl accelerates, the only place AI can safely sit is between systems, not inside every one of them. The integration layer becomes the control plane for context, permissions, and execution.

That’s why iPaaS platforms matter more than copilots. If you’re already wiring APIs, events, and data together, you’re in the best position to introduce AI in a governed, observable way. Moves like MCP in platforms such as Workato point to where this is heading — AI that operates through enterprise workflows, not around them.

AI without purpose, context, and awareness doesn’t fail quietly.

It fails expensively.

The difference in 2026 will be that enterprises finally understand where AI belongs.

What all of this means for AI engineering (and knowledge work)

Humans are no longer writing all the code.

Whether you’re comfortable with that is a separate question.

The trend is unmistakable. Software engineers are using AI to write, refactor, review, and explain code at an accelerating rate. It’s up and to the right, and there’s no meaningful reversal coming. Bubble or no bubble, this one sticks.

What’s changed isn’t just speed. It’s authorship.

Code is no longer a purely human artefact. It’s becoming a collaborative output between humans and machines, with humans shifting from “typing” to “directing”. That’s uncomfortable for a profession built on craftsmanship, but history isn’t sympathetic to discomfort.

Every major shift in knowledge work follows the same pattern. Early resistance. Moral panic. Arguments about quality. Then quiet adoption. Then inevitability.

The mistake many organisations are making is trying to bolt AI onto old ways of working. Old review processes. Old definitions of productivity. Old assumptions about where value comes from. That doesn’t scale, and it doesn’t hold.

We need to actively deprecate parts of the past.

Not everything. But enough to make room for new defaults. New workflows. New expectations of what a “good” engineer or knowledge worker looks like in practice. Someone who can reason, validate, and steer systems — not just produce output line by line.

The debate about the “right” or “wrong” way to use AI will rage on. It will fill conference agendas and LinkedIn feeds for years.

But it’s already the wrong question.

The real question is whether you’re redesigning your work for a world where AI is always present, or pretending it’s a temporary assist that can be neatly ignored.

One path compounds.

The other quietly falls behind.

And 2026 is where that gap starts to become obvious.

“Which framework do I actually bet on?”

In early 2024, that question didn’t have a sensible answer. AI frameworks were exploding, everything felt half-finished, and certainty was mostly performative. Best practice barely survived a tweet cycle. If you wanted momentum, you grabbed whatever got you into production fastest.

For most people, that was LangChain. It showed up in search results, demos worked, and you could glue together a prototype without thinking too hard. I used it for exactly that reason. Python, AWS Lambda, something real running by the end of the week.

What’s amusing now is hearing LangChain described as legacy. I heard that recently and had to pause. Legacy. For a framework born in late 2023. That’s not a critique of LangChain. It’s a signal of how fast this space eats its own history.

As prototypes matured, the limits became obvious. Prompting alone wasn’t enough. Context windows were finite. Models forgot things. Hallucinations crept in. That’s when Retrieval-Augmented Generation stopped being a buzzword.

The problem shifted. Not how do I prompt better? but how do I get the right context into the model, reliably?

That’s what led me to LlamaIndex. It treated data seriously. Ingesting messy, complex sources. Structuring them. Indexing them. And building RAG pipelines that didn’t collapse the moment you pointed them at real-world data.

For medical and legal work, that mattered. These industries aren’t short on information. They’re buried under it. PDFs, scans, fragmented records, and decades of accumulated noise. LlamaIndex was the first framework that felt designed to deal with that reality.

Looking back, there’s a clear progression path. We started with simple prompts. That quickly turned into prompt engineering. Then prompt orchestration. Before long, orchestration wasn’t the hard part anymore. Context was. Prompt engineering expanded and split into context engineering.

Prompts and context eventually merged. And once they did, everything became agentic. Agents, agent workflows, agent platforms. Nearly every framework and app now wears the label, whether it represents real capability or just a rename.ing.

Agents weren’t necessarily a breakthrough. They’re the natural consequence of better prompting, better context, and better orchestration finally colliding.

At this point in my own projects, the complexity of all the frameworks was taking its toll. What started simple was now overly complex. This led me to PydanticAI, a child of Pydantic, built by the Pydantic team. Pydantic itself surfaces in nearly every Python framework, including LangChain and LlamaIndex.

Being the newest of the three, it was born agentic, for better or worse. PydanticAI is a deliberately simple, low-ceremony abstraction for rapid development, built by people who clearly expect things to break.

As I was evolving our own platform to support “agents” (though in reality these were workflows), the architecture pattern became obvious: LlamaIndex for the knowledge, PydanticAI for the brains.

LangChain didn’t disappear. It just moved to the edges. Useful glue when needed, not the centre of gravity.

A notable mention here is Mirascope. I spent some time evaluating it, and its ecosystem was one of the friendliest and most engaged I came across. It didn’t suffer from the overly saturated, noisy communities that have grown up around LangChain and LlamaIndex.

At the time, the Mirascope framework positioned itself as the FastAPI of LLM frameworks: opinionated where it mattered, lightweight by default, and designed to get something clean into production without dragging in unnecessary abstraction.

The mistake people make

Choosing one.

In reality:

• LlamaIndex feeds the model

• LangChain coordinates behaviour

• PydanticAI keeps everyone honest

The real architectural shift isn’t agents.

It’s accepting that LLMs are probabilistic dependencies, not application logic.

PydanticAI understands that.

LlamaIndex respects it.

LangChain sometimes forgets.

In 2026, the winners won’t be the teams with the cleverest agents.

They’ll be the ones who:

• Constrained outputs early

• Treated context as infrastructure

• Designed for failure, retries, and audits

• Didn’t confuse demos with systems

If you’re building toys, pick one.

If you’re building products, compose them intentionally.

And if a framework promises magic with no trade-offs, it’s lying.

Obviously, there are far more frameworks than just these three. The ecosystem keeps expanding, and it’s still evolving fast. Even now, I’m actively looking at a few more that shall remain nameless, at least until they’ve earned their place in production.

HIPAA Privacy and Security Rules What HIPAA actually requires.

HIPAA sounds scarier than it actually is. Strip away the jargon and you’re left with a handful of clear obligations. The real work is stitching those obligations into your architecture, your vendor choices, and your operational habits.

The Privacy Rule controls what data you’re allowed to use and disclose.

The Security Rule controls how you protect it.

If you remember nothing else, remember this: HIPAA is about controls, not checklists. Anyone can say they’re compliant. Far fewer can prove it when something goes wrong.

Privacy Rule: The practical version

You’re responsible for making sure PHI is only accessed, used, or shared for legitimate reasons. If the system doesn’t enforce it, you’re out of compliance.

Things that actually matter when you’re building:

Minimum Necessary Don’t spray PHI everywhere. Limit fields, rows, logs, exports, embeddings, prompts, Slack messages, CSV downloads. If it’s not needed, don’t collect it and don’t store it.

Role-based access Real RBAC is non-negotiable. “Everyone is an admin” is a HIPAA horror story waiting to happen. Make roles meaningful and auditable.

Patient rights Patients can request their data, ask for corrections, and get an audit trail of disclosures. If your system can’t produce these quickly, you have technical debt.

Authorized use cases If you’re training an AI model, or using PHI for operational analytics, you need explicit policies and BAAs covering it. “But we anonymized it” is not a free pass unless you truly applied de-identification standards.

Security Rule: The practical version

You need to prove you’re protecting PHI with administrative, physical, and technical controls. In practice this means:

Encryption in transit and at rest TLS everywhere, modern cipher suites, no excuses. Storage encrypted with managed keys unless you have a reason not to.

Identity and access management MFA on everything. No shared logins. No root access in daily use. Rotation of secrets, ephemeral credentials, short-lived tokens.

Audit trails You must know who touched what, when, and from where. Logs must be immutable and retained.

Incident response You need a real plan, not a PDF. A process that’s rehearsed, timed, and ready to execute across your stack.

Business Associate Agreements (BAAs) No BAA, no PHI. Your vendors either sign one or they’re out.

Here’s what that looks like across common platforms.

This is where teams slip. They assume the vendor is “compliant” and forget that compliance is shared responsibility. Here’s the practical read per platform.

Building & Running Apps

These are the platforms you’ll use to build and deploy. They can all support HIPAA, but none of them do it by default. Your architecture decisions matter more than your vendor choices.

AWS

AWS makes HIPAA possible. It doesn’t make it automatic.

What AWS provides A free BAA, clear list of HIPAA-eligible services, encryption, auditing, IAM, VPC isolation, Shield, GuardDuty, CloudTrail, KMS, Config, Security Hub. They give you the building blocks but not the architecture.

Your responsibilities Network design, access control, monitoring, log retention, patching policies, bucket permissions, key rotation, PHI minimization, and ensuring no data leaks into non-HIPAA services.

Common mistakes S3 buckets with broad access. Lambda functions dumping PHI into CloudWatch logs. Root user still active. Developers using prod creds locally.

Rule of thumb If you can’t map a control back to a specific AWS service or config, you don’t actually have the control.

Vercel

Vercel can be HIPAA-compatible if you’re careful, but it’s not the default choice for PHI-heavy systems.

What Vercel provides BAA available on Pro (as a paid add-on) and Enterprise plans. Strong tooling for frontend hosting and edge compute.

Your responsibilities Avoid PHI on the edge. Use serverless functions with isolated environments. Ensure logs never capture PHI (headers, payloads, URLs). Proxy PHI workloads into a HIPAA-ready backend like AWS.

Rule of thumb Vercel can host the app shell. AWS should host the PHI.

Neon

Neon is HIPAA-compliant and pairs well with Vercel for serverless Postgres.

What Neon provides Self-serve BAA available on the Scale plan and above. HIPAA adds a 15% usage surcharge once billing is finalized. Encryption at rest and in transit, role-based access controls, audit logging, and per-project isolation for multi-tenant setups.

Your responsibilities PHI must only be stored in data rows, not in logs, schema descriptions, or metadata. Enable HIPAA at the organization level first, then per project. Ensure your Vercel layer doesn’t log or cache PHI in transit.

Common mistakes Logging query parameters that contain PHI. Storing health data in column names or schema comments. Assuming the BAA covers non-HIPAA-enabled projects.

Rule of thumb Neon handles the database. You handle what flows through Vercel to get there.

Running Enterprise Apps

Enterprise platforms can get you to HIPAA-ready faster, but expect to pay for it. For companies moving upmarket into healthcare or legal, it’s part of the growth playbook. The compliance burden shifts to how you configure, integrate, and govern these tools. Most breaches in enterprise environments aren’t platform failures. They’re workflow failures.

Salesforce

Salesforce Health Cloud and Shield give you a strong HIPAA baseline.

What Salesforce provides BAA, Shield Encryption, Field Audit Trail, Event Monitoring, platform security, granular RBAC, secure integrations.

Your responsibilities No exporting PHI into ungoverned systems. No using unmanaged packages that log or store data offshore. Ensure your integration middleware is also covered by a BAA. Use Shield properly. Many orgs pay for it and never configure it.

Common mistakes Syncing PHI into Slack, Gmail, spreadsheets, or marketing tools.

Box

Box is one of the cleanest HIPAA-aligned document systems.

What Box provides BAA, full encryption, granular access controls, retention, legal holds, governance add-ons.

Your responsibilities Folder structure governs PHI flow. Avoid local sync clients for PHI. Ensure users don’t download locally then reupload to unapproved tools. Control public link sharing policies.

Rule of thumb Box is safe. Humans using Box are not.

Workato

Workato is increasingly used for HIPAA contexts but requires discipline.

What Workato provides BAA on enterprise plans. Secure vault for credentials. Strong audit logs.

Your responsibilities Never log PHI in recipes. Mask input fields. Use data pills carefully. Decide what transformations happen inside Workato vs downstream. Ensure connectors do not forward PHI into non-compliant endpoints.

Common mistakes Recipes that accidentally dump payloads into logs. Workspaces with too many admins. Using personal OAuth connections or shadow IT apps for integrations.

Bringing it all together

A simple architecture mindset

Compliance isn’t a feature you add at the end. If you’re dealing with PHI:

1. Keep the PHI surface area small — Only collect and store the PHI you actually need; less data means less risk.

2. Segment infrastructure — Isolate PHI workloads from non-PHI systems so a breach in one doesn’t expose the other.

3. Centralize identity — Use a single identity provider so you can control and audit access from one place.

4. Enforce least privilege everywhere — Give users and systems only the minimum access they need to do their job.

5. Encrypt everything — Protect data at rest and in transit so it’s useless if intercepted or stolen.

6. Log everything — Record who accessed what, when, and from where so you can prove compliance and investigate incidents.

7. Only process PHI inside HIPAA-ready zones — Keep PHI processing within services and regions covered by BAAs and proper controls.

8. Assume every integration is a potential disclosure — Treat every data handoff as a risk point that needs a BAA and safeguards.

9. Automate controls — Use IaC and policy-as-code to enforce rules in Terraform, CDK, or policy engines instead of manual config.

10. Plan for breach, not just prevention — Have an incident response plan that’s tested, timed, and ready to execute. Assume something will go wrong.

The bigger point:

Even if a BAA isn’t required, the principles in this post still apply. Minimizing data exposure, encrypting everything, logging access, enforcing least privilege: these aren’t just HIPAA requirements. They’re how you build systems that scale without creating liability. Whether you’re handling PHI or not, these patterns protect your users and your business.

Even without a legal HIPAA obligation, treat medical records as if HIPAA applies. Encrypt everything, limit access, log activity, vet vendors, and have a breach plan. The discipline protects you regardless of whether the law requires it.

HIPAA isn’t about paperwork. It’s a design discipline. In 2026, the companies that win in healthcare, legal, fintech, or anywhere trust matters will be the ones that build compliance into the foundation. These aren’t just HIPAA principles. They’re how serious teams build systems that scale.

The old compliance playbook worked when releases were quarterly: build fast, hire auditors, patch frantically.

When you ship constantly, “we’ll fix it in the audit” isn’t a strategy. It’s technical debt waiting for a legal bill.

And now engineers are building faster than ever. AI assisted coding, automated pull request reviews, and AI first tooling mean velocity has gone through the roof. Which makes the gap between what teams do and what they can prove even more obvious.

“Compliance by Design” still gets eye rolls. Too slow. Too heavy. Too much process for a world where Claude Code can refactor a service in minutes.

But here’s the point. The same practices that let you move quickly like Infrastructure as Code, automated testing, and observability matter even more when AI helps write half your code. These foundations give you something AI can’t create: a verifiable trail of what changed, why it changed, and who approved it. You’re already most of the way there. You’re just not treating it as compliance.

Let’s fix that.

Infrastructure as Code is an audit trail

Define your stack in CDK, Terraform, CloudFormation, or Pulumi and every change lands in Git with a PR, reviewer, and timestamp. Even if an AI generated the code, the approval flow is human. That’s what auditors care about.

They want to see consistent environments and tracked changes. Infrastructure as Code already gives them that. You don’t need a separate process. You just need to point to it.

Your CI/CD pipeline is continuous control validation

Every commit triggers automated tests and security scans. AI-generated code doesn’t skip the pipeline. It passes through the same gates. That alone satisfies a chunk of most frameworks.

Auditors want evidence that vulnerabilities are caught and controls run every time. Your pipeline logs show this. You’ve been producing compliance artefacts with every merge.

Observability is audit logging

Logs, metrics, traces, alerts. You’ve got the tooling. Whether humans or AI wrote the feature, the behaviour still runs through the same telemetry.

Auditors want audit logs, anomaly detection, and incident response capability. You have it. You just need to map it to the compliance language.

The gap isn’t capability, it’s documentation

Most teams do the work but can’t easily demonstrate it. They scramble before audits, digging through Jira tickets, GitHub issues, commit histories, and screenshots to rebuild the narrative at the last minute.

That’s the waste. Not the engineering. The translation.

Compliance by Design in the AI era isn’t about slowing teams down. It’s about capturing the evidence you already generate, especially now that AI accelerates the pace of change.

Where this breaks down

This works when teams already have solid engineering habits. If you’re still deploying manually, testing by clicking around, or logging to a box in a cupboard, AI won’t save you. It just helps you generate changes faster than your process can cope with.

At that point the problem isn’t compliance. It’s everything underneath it.

What’s next

Next I’m doing a deeper dive into the HIPAA Privacy and Security Rules and how they actually translate into day to day engineering. Not theory. Practical guidance, real patterns, and the bits teams usually get wrong. Think access controls, audit logging, data handling, environment separation, and what “good” really looks like when AI is just another tool in the stack.

For now, look at your last PR and your last pipeline run. Count how much compliance evidence you generated without even trying.

You’re closer than you think.

Except everyone didn’t move on. Within two months, ChatGPT had 100 million users. Within six months, every company on earth was scrambling to figure out their “AI strategy.” Within a year, the entire software industry had reorganised itself around a technology that most executives still couldn’t properly explain.

What made it matter wasn’t the underlying technology — transformers had been around for years, and GPT-3 already existed. The breakthrough was simpler: ordinary people got to talk to something that felt intelligent. Not developers. Not researchers. Everyone. Your colleagues. Your parents. The person who still can’t set up their own printer.

That feeling — even if the reality was autocomplete with an attitude — changed behaviour at a scale and speed we’ve rarely seen.

The Human Shift

The lazy narrative is that humans became dependent on AI. I don’t buy it.

What actually happened is that humans became multiplied. The person with ideas but no writing skills could suddenly produce readable prose. The expert who spent half their time on administrative grunt work could reclaim those hours for actual expertise. The small team that couldn’t afford specialists could access specialist-level capabilities on demand.

Within months of ChatGPT’s launch, not using AI assistance started to feel inefficient in a way that was hard to ignore. Like choosing to hand-write letters when email exists. You could do it. But why would you?

The “copilot mentality” emerged almost overnight. Rather than AI replacing human work, it became the obvious starting point. Draft with AI, refine with human judgment. Query first, verify second. Let the machine handle the parts that don’t require genuine thought.

Gatekeepers to knowledge felt this shift first. Legal research. Medical literature reviews. Technical documentation. All of it suddenly accessible to anyone willing to ask the right questions. The credentialed experts didn’t vanish — but their monopoly on access did. The smart ones pivoted quickly to emphasising judgment over access. The others are still writing anxious thought pieces about why AI will never truly understand their domain.

Perhaps most surprising: basic functional writing became a solved problem. Not good writing — the craft of genuinely connecting with readers remains stubbornly human. But competent, serviceable prose? The kind that fills corporate communications and internal reports? That became trivially cheap to produce.

The psychological shift underneath all of this is what will interest historians. Humans became comfortable co-thinking with machines. Not trusting them blindly — the hallucination problem cured most people of that quickly enough — but treating AI output as a legitimate starting point for their own reasoning.

The Technology Shockwave

The technical community spent 2023 scrambling to understand what had happened and what to build on top of it.

Embeddings went mainstream. Vector databases became essential infrastructure. RAG — retrieval-augmented generation — became the new answer to every knowledge management problem. Instead of building elaborate systems and hoping users would navigate them correctly, teams started building systems that simply found relevant information and synthesised it on demand.

Every VC deck that year had “AI-powered” somewhere on it. Most of those companies are dead now, or soon will be. The ones that survived had something beyond a thin wrapper around OpenAI’s API — proprietary data, genuine distribution, domain expertise that couldn’t be replicated by a better prompt.

I’ve spent much of the last two years building AI systems for clients in legal and healthcare. The interesting lesson: what matters in production isn’t model selection or clever prompt engineering. It’s data quality. Audit trails. Explainability. Compliance frameworks that satisfy regulators who couldn’t care less how elegant your architecture is. The unsexy work, as usual, is where value concentrates.

The real innovation wasn’t the models themselves. It was the democratisation of intelligence workflows. Before November 2022, building anything resembling AI required specialist teams and substantial budgets. After, a competent developer could prototype genuine intelligence in a weekend.

Software engineering became leverage on a scale we hadn’t seen before. The gap between “idea” and “working prototype” collapsed to hours. The gap between “working prototype” and “production system” remained wide — but that first gap was where most innovation had always been bottlenecked.

The Job Market Reality

The predictions about AI and employment were almost perfectly backwards.

Conventional wisdom said automation would come for factory workers and truck drivers. Physical jobs. The robots-on-assembly-lines vision of technological displacement. Instead, AI went after the educated first.

Junior roles compressed or vanished. Entry-level analysts, first-year copywriters, associate consultants — anyone whose core job was “produce the first draft” discovered that first drafts had become essentially free. The humans who thrived were those who could evaluate whether the free drafts were any good.

Mid-level roles transformed into AI-supervisor positions. Senior people became force multipliers. The dynamic shifted from “how much can you produce” to “how well can you judge what the machine produces.”

Entire industries reshaped: copywriting, research, analysis, customer support. All still employ humans — but fewer humans doing more work, augmented by systems that handle the portions requiring no judgment.

Here’s the distinction most organisations still haven’t internalised: AI didn’t kill jobs. It killed tasks. A job is a bundle of tasks wrapped in a salary. When AI automated specific tasks within that bundle, the job changed — but most companies are still structured around the old bundles, either overstaffed and inefficient or cut too deep and missing the judgment they actually need.

The Bubble Question

Yes, we’re in an AI bubble. But probably the right kind.

Bubbles are how society reallocates resources at speed. Railways, internet, smartphones — stupid money funded infrastructure that outlasted the stupid companies. Same pattern here. Some startups will fail spectacularly. Some investors will lose fortunes. The underlying shift won’t reverse.

The bubble isn’t in foundation models. That’s a small club with genuine technical differentiation. The bubble is in AI startups without data moats, distribution advantages, or domain expertise — companies that raised on enthusiasm and a ChatGPT wrapper, now discovering that enthusiasm doesn’t convert to revenue.

The winners won’t be the most “AI-native.” They’ll be the most useful. Real problems solved, sustainable economics, defensible positioning. Same as every other technology transition, just with better marketing.

Where This Goes

I don’t know. Neither does anyone else, despite the confident predictions filling your feed.

The legitimate concern is what you might call epistemic outsourcing — gradually losing the ability to evaluate claims without AI assistance. That fragility will bite us, and we won’t see it coming until it does.

The legitimate excitement is that capable individuals have never had more leverage. Small teams can compete with large organisations in ways that weren’t possible before. The playing field didn’t level — in many ways, it inverted.

We’re not heading to utopia or dystopia. We’re heading somewhere messier: unevenly distributed, wonderful and terrible depending on where you’re standing and what you’re trying to do. The technology is a capability. What we do with it remains up to us.

November 30th, 2022 was a line in the sand.

Three years on, the shockwaves are still propagating. We’re still figuring out what changed and what it means. That uncertainty isn’t a bug — it’s the honest state of affairs.

Everything before that date was the old world. Everything after is whatever we decide to build.

Every week someone slaps “semantic search” into a product update and quietly hopes no one asks what it means. The reality is more interesting. Search is evolving fast. The definitions are blurring. But if you’re building anything with retrieval — legal, medical, education — you need to understand the difference.

So here’s the no-nonsense version.

The short explanation

Similarity search finds things that look like the item you provided.

Semantic search finds things that match what you meant.

Both often start with the same embeddings. The difference is what the system layers on top.

The comparison

Hybrid search (the real world)

Most modern systems blend both. Vectors give fast recall. Context layers make results relevant.

If you’re reading vendor docs in 2025, assume “semantic” actually means semantic reasoning layered on top of vector search.

Why this matters

If you’re building AI products, retrieval ends up being half the job.

Similarity search gives you discovery. Semantic search makes the system actually useful. Neither is enough on its own.

Together, they’re how you get from “closest entry” to “right answer”.

The practical reality

The industry isn’t confused. It’s evolving.

Semantic capabilities are being layered onto the same vector foundations that power similarity search. The embedding isn’t the magic. The context, structure, and domain logic wrapped around it are what make retrieval work.

That’s why the definitions feel like they’re collapsing. They are. But for good reason.

Where modern APIs actually sit

Two examples show how things are converging.

Google File Search API (Gemini)

Hybrid leaning semantic. It uses vectors for speed but adds semantic ranking, optimised chunking, and context assembly. You query with natural language; it returns meaning, not just closeness.

Pinecone Assistants

Hybrid but designed to feel fully semantic. Pinecone handles the vector heavy lifting while the assistant logic interprets intent, reshapes queries, reranks, and orchestrates responses.

Both are hybrid. The difference is how much semantic reasoning sits on top.

So how do you choose?

Don’t pick a technique. Pick the pattern of query your users actually ask.

If they give you examples: similarity. If they ask questions: semantic. If they do both — welcome to reality — you’re building hybrid.

Actionable takeaway

Stop debating which approach is better. Start designing around user intent.

Similarity search is the engine. Semantic search is the steering. Hybrid is the car people actually drive.

The search world isn’t splitting into camps. It’s converging. Most modern systems quietly blend similarity and semantic techniques because that’s what real users need. You can ignore the jargon and focus on the query patterns — it’s a much saner way to design.

Software engineering is rapidly evolving into AI-assisted software engineering—and these three features sit at the heart of that transformation.

Skills, Slash Commands, and Subagents might feel like magic at first glance. But strip away the novelty, and they’re something more pragmatic: a sensible attempt to make AI behave less like a chatbot and more like a proper engineering tool

Skills

Skills are essentially reusable functions. You teach Claude how to do a job once, then reuse it everywhere.

They’re ideal for repetitive engineering tasks: generating database migration scripts, reviewing pull requests for style consistency, validating API responses against schemas, creating accessibility audit checklists.

Think of them as the AI equivalent of utility functions—boring, predictable, and exactly what you want in production.

The pitfall: Everyone will try to cram entire workflows into a single Skill. Don’t. Keep them short. Keep them stupid. That’s the point.

Slash Commands

Keyboard shortcuts dressed up as innovation. Useful, though.

Slashes accelerate everyday workflow: drafting Git commit messages, running Next.js builds, formatting code blocks—all without breaking stride.

They’re excellent for speed, but they won’t save a broken process. If your workflow is already chaos, Slash Commands will just help you produce chaos faster.

Subagents

Subagents let you spin up specialised workers with their own rules and memory. Instead of one giant “do everything” model, you get a crew of agents that can hand off tasks between them.

Claude ships with standard subagents for research and analysis. But the real power is in custom ones: a Frontend Designer that critiques accessibility and suggests component improvements, a Code Reviewer that audits PRs against your team’s style guide, a Bug Fixer that reproduces issues and proposes patches.

Perfect for workflows with genuine stages—where one agent gathers context, another executes, and a third validates the output.

But let’s be honest: Most teams will overdo it and end up with a matryoshka doll of confused agents talking in circles. Boundaries matter. Start with two agents, not twenty.

So what’s actually happening here?

Anthropic has quietly built a primitive distributed compute model for reasoning. It’s not shiny enough for X, but it’s genuinely useful.

This pushes AI away from prompting theatre and closer to real systems engineering.

Map it to actual architecture:

• Skills = stateless functions

• Subagents = worker processes

• Slash Commands = task automation layer

• Main agent = orchestrator

This looks far more like designing a system on AWS than how most people currently “design” AI products—which is to say, they don’t. They just prompt and pray.

The reality check

Everyone will gush about agents managing agents. Most of them will never ship anything with it.

The real pain points remain: mis-scoped tasks, bad handoffs, loops that never end, jobs that time out. Skills, Slashes, and Subagents don’t solve those problems—they just stop the tooling from actively fighting you.

This isn’t a revolution. It’s the first time the plumbing doesn’t leak.

What to actually do:

• Build two Subagents first, not fifteen

• Let Claude help you create the Skills (it’s faster than you think)

• Use Slash Commands for speed, not architecture

• Log everything—you’ll need it when things go sideways

• Treat this as plumbing, not magic

If you’re already thinking in systems—functions, workers, orchestration—you’ll find this oddly familiar. Which is exactly the point.

OpenAI DevDay dominated my feeds this week. Developers, developers, developers!
Sound familiar? Steve Ballmer made the phrase legendary, shouting it from the Microsoft stage to rally the software world.

This week felt like we were back in that kind of moment again.
The announcements. The energy. The buzz.

Something actually felt new in tech.

I haven’t been to a conference in years — partly family life, mostly because most events feel stuck on repeat. As my son’s football coach says, they’ve become well-oiled machines — focused, disciplined, and running the same playbook year after year.

Apple. AWS re:Invent. Salesforce’s Dreamforce.
All smooth, all predictable. The magic’s gone.

Apple’s “one more thing” is history, and Dreamforce applause now sounds more rehearsed than real.
Credit where it’s due — they’re the old guard now. But in maturing, they lost their spark.

⚙️ The Apps SDK

OpenAI’s new Apps SDK lets developers build apps on top of ChatGPT — and honestly, it’s a much better name than “GPTs.”

Custom GPTs were a great experiment, but the Apps SDK feels like the real platform move.

“This is now the bare minimum requirement for any platform company.”

The playbook dates back to Steve Jobs, who inspired Marc Benioff to create Salesforce’s AppExchange. OpenAI is following that lineage — and it makes total sense.

The launch lineup says it all: Booking.com, Canva, Coursera, Expedia, Figma, Spotify, and Zillow.
A perfect mix of learn, chill, create, and travel — all to the right tunes in your ears.

The question:
Will this be OpenAI’s App Store moment, or more of an AppExchange evolution?

Approval looks controlled for now (“Apps SDK is available in preview today…”), but monetization is where the real play lies — usage, ads, affiliate revenue, maybe something brand new.

Here’s the clever part:
These apps don’t run on OpenAI’s infrastructure — they run on yours.
Through MCP and iframes, your app appears directly inside the ChatGPT UI.

That’s powerful. Whether you’re a big brand or part of the growing army of vibe coders, there’s plenty to be optimistic about.

🤖 The Agent SDK

Before diving in, quick refresher:

An AI Agent is a program that can think and act on its own to complete a task.
It takes a goal, looks at the tools or data it has, and decides what to do next.

Over the past year, I’ve built workflow engines for legal professionals using frameworks like Mirascope, LangChain, LlamaIndex, and Pydantic AI — all heading deep into the agentic frontier.

Now OpenAI joins the mix with the Agent SDK, and yes, it looks familiar.

Rather than dissecting every difference, here’s the key:
it’s a deep, native integration into OpenAI’s ecosystem — not just another framework.

One thing that jumped out: Guardrails.
They’re similar in spirit to Pydantic validation, but tuned for real-time agent safety and control.
If you work in Legal or Medical, that’s a big deal.

📘 platform.openai.com/docs/guides/agents-sdk

🧩 The Agent Builder (and the n8n Panic)

Then came the memes. Social feeds lit up with “RIP n8n” jokes the moment Agent Builder was rumored:

“OpenAI just killed n8n.”
“Is this the death of Zapier?”
“OpenAI changed automation forever.”

Let’s be real — n8n isn’t going anywhere.
It’s open source, runs anywhere, and has a loyal community.

Sure, there are similarities, but that’s true for nearly every automation platform.
Remember Salesforce’s Process Builder? It evolved into Flow, arguably their best product in a decade.
History repeats.

For OpenAI, this move makes perfect sense.
A platform without developer engagement stagnates.

And with hundreds of millions of users (soon billions), they’re building the nutrient cycle that keeps the forest alive.

I’ve only skimmed Agent Builder so far — more testing ahead — but the intent is clear:
make Agents and Apps first-class citizens of the ecosystem.

🚀 Takeaways

• FOMO is real.

• Developers are back at the center.

• If AI can enhance your product, define the problem first — or risk joining the crowd still searching for value.

• Oh, and n8n is not dead.

OpenAI just reminded us why developers matter again.

So I imagined a world where the UI is created for me just-in-time when I need it, begging the question: would software-as-a-service eventually, on some level, be replaced with software-as-needed?

https://www.anthropic.com/news/claude-sonnet-4-5

This is a little glimpse into the future of working with software where UIs are generated on demand when the user needs them, tailored to the specific user task at the time. Software that exists only as long as you need it, then vanishes. Ephemeral by design.

The Middleware That Never Was

Anthropic’s pitch is deceptively simple: instead of writing code to describe a text box, Claude just makes a text box. No React components. No state management. No wrestling with CSS. Just intent to interface, instantly.

But here’s where it gets interesting. Some will point out that Claude Artifacts, Gemini Canvas, and even existing Tools already do this on some level. Fair point. Except there’s a critical problem: determinism.

In the unpredictable world of generative AI, ask twice and you’ll get two different implementations. Perfectly fine for prototyping. Absolutely catastrophic for production software. You can’t run a business on interfaces that might render differently each time you load them.

This appears to be addressed by a library of constrained tools which the AI has access to, allowing it to construct software much faster and more reliably than if you were describing what you want in natural language. Think of it less as freeform code generation and more as an expert system with remarkably good taste, assembling pre-vetted components into reliable patterns.

The AI becomes a compiler, not a creative writer. And that changes everything.

The Salesforce Question

Here’s an interesting thought experiment: would the likes of Salesforce be playing with UI generative frameworks where AI assembles Lightning pages on the fly? It could certainly help keep the low-code momentum going and shorten implementation timelines dramatically.

Imagine: a sales manager describes their pipeline view requirements in plain English. Claude assembles the Lightning page—fields, workflows, reports—in real-time. No Trailhead courses. No consultant retainer. No three-month implementation cycle.

The technical feasibility is almost certainly there. The business implications are thornier.

What Salesforce gains: Acceleration of their low-code promise. Democratisation of customisation. Reduced implementation friction that’s always been a barrier to adoption.

What Salesforce risks: Obsolescence of their professional services ecosystem. Commoditisation of the configuration expertise that forms part of their moat. A fundamental question about what customers are actually paying for.

And Salesforce is just the canary. Any platform built on configuration over code faces the same reckoning.

Software-as-Needed: Not Just Faster, Different

Strip away the hype and what we’re really discussing is a category shift in how software exists.

Traditional SaaS: Persistent applications you subscribe to, learn, maintain, and pay for continuously whether you’re using them or not. Feature bloat is a business model—you’re paying for optionality.

Software-as-Needed: Purpose-built interfaces that exist in response to specific tasks, then gracefully cease. No onboarding. No unused features. No long-term relationship with a vendor.

Consider a practical example: You need to reconcile invoice discrepancies between your accounting system and payment processor.

Today: You open your SaaS accounting platform (which you pay £50/month for), navigate through menus you’ve memorised, export two CSV files, open Excel (another subscription), build a VLOOKUP formula (which you’ll have to remember or Google again next month), manually identify discrepancies, and email the results.

Tomorrow: You describe the problem to Claude. It generates a purpose-built interface—upload forms for both sources, an intelligent diff table that highlights discrepancies, export options, even suggested resolution actions. You use it for 20 minutes. When you’re done, it evaporates. Next month, when you need it again, it reappears—but potentially evolved based on what you actually did last time.

The cost isn’t zero, but it’s not £50/month either. It’s £2 for compute. Or £0 if the AI provider is loss-leading for market share.

Who Wins, Who Loses

Winners:

• Anyone building complex, bespoke workflows where existing SaaS is overkill: Legal document assembly. Medical triage interfaces. Educational adaptive content. Niche industry tools with small addressable markets that could never justify traditional software development.

• Infrastructure providers: AWS, Google Cloud, and anyone providing the compute and orchestration layer for ephemeral software. They’ll own this the way they own compute today.

• Component library creators: The Tailwind and shadcn/ui of the world. Ephemeral software still needs building blocks.

Losers:

• Generic SaaS with interchangeable features. If your value proposition is “we have a dashboard with charts,” you’re in immediate danger.

• Implementation consultants: When configuration becomes conversational, specialised knowledge becomes less defensible.

• Feature-bloated platforms: Paying for 42 capabilities you never use becomes obviously ridiculous when you can summon exactly what you need.

Wild Cards:

• Platforms like AWS that provide the infrastructure for this shift, but don’t control the interface layer.

• Apple and Google: Do ephemeral apps live in browsers, or do they need new OS primitives? Who controls distribution?

• Regulatory bodies: How do you audit software that doesn’t persist? Who’s liable when an ephemeral interface causes financial or medical harm?

The Bit Nobody’s Saying Aloud

Anthropic isn’t trying to build better software. They’re trying to make the concept of “software” as we know it obsolete.

Applications as persistent artefacts you install, learn, update, and maintain? That’s a historical accident of compute scarcity and distribution constraints. We accepted the burden of learning software because we had no choice.

But if interfaces can be generated on-demand, perfectly tailored to immediate needs, why would we tolerate the cognitive overhead of mastering someone else’s abstraction?

This is where it gets uncomfortable for the entire software industry. Ephemeral software doesn’t just threaten SaaS business models—it threatens the very idea that software is a product to be bought and sold. It becomes a utility, like electricity. You don’t have a “relationship” with your power company. You flip a switch, consume what you need, and stop thinking about it.

What You Should Actually Do

If you’re building software: Ask yourself honestly whether your product is a destination or a job-to-be-done. If users come to you because they have to, not because they want to, start experimenting with how your core value could be delivered ephemerally. The build vs. buy calculus is shifting to “build vs. summon.”

If you’re buying software: Start experimenting with AI-generated interfaces now, even if just to understand their failure modes. Spin up Claude Sonnet 4.5 and try “Imagine” yourself. Build something trivial. Then ask: “Could this replace a tool I currently pay for?” If the answer isn’t an immediate “no,” it’s time to rethink your stack.

If you’re investing: Watch for the picks-and-shovels play. The component libraries, the rendering engines, the orchestration layers that make ephemeral software possible. The real money won’t be in ephemeral applications themselves—it’ll be in the infrastructure that makes them reliable, secure, and scalable.

The Honest Limitation

Let’s be clear about what this doesn’t solve yet: trust.

Would you run payroll through a UI that didn’t exist an hour ago? Would you manage patient records in an interface with no audit trail? Would you sign a contract through an ephemeral app with no terms of service?

For software to be truly ephemeral, we need:

• Provenance tracking (who generated this interface, from what prompt, at what time?)

• Deterministic reproducibility (can this exact interface be recreated if needed?)

• Liability frameworks (who’s responsible when ephemeral software fails?)

• Security models (how do you pen-test something that doesn’t persist?)

These aren’t small problems. But they’re solvable problems. And the moment they’re solved, the entire SaaS industry has about 18 months before the disruption becomes existential.

What Comes Next

Anthropic is probing. Testing. Seeing what breaks. This is research, not a product launch. But research has a funny way of becoming reality when the economics are undeniable.

The middleware is dying. What replaces it will be strange, powerful, and probably infuriating in entirely new ways. Software that blooms into existence when summoned and evaporates when the job is done.

Whether that’s liberating or dystopian depends largely on who controls the summoning mechanism. But that’s a discussion for the next newsletter.

For now, just know: the era of ephemeral applications may have just begun. And it won’t wait for permission.

Covering AI, Software & Tech, unfiltered.

Unfiltered means zero fluff and a hit of British wit. If you’re sick of hearing that AI is replacing jobs, SaaS is dead, or we’re all just living in a simulation, you’re in the right place.

• 🤖 AI → Beyond the hype, where every breakthrough carries equal doses of disappointment.

• 💻 Software → Code, culture, and the frameworks that make or break people, teams, and companies.

• 📈 Tech → The business end of innovation: what sticks, what’s noise, and who’s really cashing in.

Why Agentgill? Well, by popular demand, it’s not what you think.

It’s not some AI-powered alter ego, nor a nod to secret intelligence. The name started as a bit of fun between my wife and me, and somehow it stuck.

Expect one brief a week: sharp analysis, contrarian views, and practical takeaways. No jargon, no BS. Just blunt takes on AI, software, and tech—the wins, the failures, and the nonsense in between. If you want the brief, not the brochure, subscribe.

Subscribe now