David Millard

Last week I asked Claude Code to help me connect two apps I use every day: Things 3 (my task manager) and Apple Mail. I wanted it to use the content of linked mail messages to automatically name and describe the tasks. Nothing fancy. The kind of glue that should exist but doesn’t, because no product manager at either company has any reason to care about my particular workflow.

What happened next was a bit of an accident – because I had installed the MCP server for things inside of the folder for the project. This meant Claude had access to it. Claude had options. It inspected my MCP configuration, realised it lacked the right connector, wrote and registered a new integration, tested it, and handed me a working system. The software changed its own environment to solve my problem; I just described my frustration, and the software bent to solve it.

That moment sits with me because it wasn’t a remarkable interaction with agentic AI. It was Tuesday. And I think the unremarkableness is the point.

Something has shifted

There’s a lot of excitement right now about OpenClaw, the open-source agentic system that went from obscurity to well over 100,000 GitHub stars in weeks. People call it the closest thing to JARVIS we’ve seen, but the architecture isn’t new: LLMs that write code, event loops, tool APIs, persistent memory. What’s new is that this self-modifying agentic software has left the lab; to become something people actually run on their machines, link to WhatsApp, and wake up to find has reorganised their morning.

The gear shift already happened. OpenClaw is just the moment everyone noticed.

At its core, the OpenClaw architecture is simple. A long-running process watches for events (messages, cron jobs, web hooks), pipes them through a language model, and acts on the results. The actions flow back through your existing communication channels. What’s more the system is aware of its own harness. Its own environment, its own configuration, its own skill registry. And it can rewrite all of it on demand, adding new capabilities, new integrations, new behaviours, without anyone touching the source code.

This is not a chatbot. A chatbot waits for you. This does things while you sleep. And one of the things it does is grow.

Why are we waiting?

I think that this will radically change our expectations of software. Let me give an example. As I mentioned above I use Things 3 as my task manager. It’s beautifully designed. I genuinely like it. But it has a friction that is a perpetual annoyance to me. Things 3 has no concept of tasks that are blocked (where you are waiting for someone else) so I use a manual “#waiting” tag. But those tasks still clutter my lists, adding cognitive load every time I scan for what to do next. What I actually want is simple: when I’m waiting on someone else, the task should disappear into its own space, watch for the relevant trigger (usually an email), and quietly reappear when it’s actionable again (or when I periodically check). A simple enough idea. But beyond what the application interface currently allows.

Now, having watched Claude modify its own MCP server to solve my Things-to-Mail problem, having seen OpenClaw users describe the system writing new skills on demand to handle situations its creators never anticipated, I find myself looking at Things 3 with fresh eyes. Not with frustration exactly. More like bewilderment. Why can’t I just tell this application what I need? Why can’t I say “create a waiting state that pulls tasks out of my active lists and watches my email for replies, then puts them back when something arrives” and have the software reshape itself around that request?

The answer, obviously, is that Things 3 is a fixed product. A team of designers and engineers decided on a data model, built an interface around it, and shipped it. That model reflects their best judgement about what most people need most of the time. It’s a good judgement. But it’s a general judgement, and my workflow is specific. The gap between the two is the problem.

But I don’t think my expectations are going back to where they were. Once you’ve seen software adapt to you, the static version feels oddly stubborn. Like a colleague who’s very good at their job but refuses to do it any way other than theirs.

What software companies actually sell now

That Things 3 example points somewhere uncomfortable for software companies, because the traditional product model depends on exactly the rigidity I’m frustrated by.

The deal has always been: a company builds a feature set, packages it in an application, charges money. The features are the value. The product manager decides what goes in, what stays out, what the data model looks like, how the interface behaves. Everyone gets the same software. Customisation means settings and preferences, not structural change.

But if an agent can reshape an application’s behaviour through conversation, if users start expecting their tools to accommodate them rather than the other way around, then the feature package stops being the thing you’re selling. Features become fluid. Personalised. Generated on demand. What the company provides is the foundation underneath.

I think what software companies will actually be selling comes down to three things: a data model that’s rich and well-structured enough to support diverse uses, infrastructure that handles sync and security and reliability at scale, and an interface layer that’s open enough for agents to work with. All three need to be addressable, adaptable, and exposed. The walled garden, the proprietary data format, the locked-down API: these become liabilities rather than competitive advantages.

Companies might find their value proposition shifting from “we built the best interface” to “we built the most capable platform for agents to build interfaces on.” The agent becomes the interface, shaped to each user’s needs. The underlying platform is the foundation it builds on.

Software companies have spent decades competing on user experience. They may be about to compete on how gracefully they hand that experience over to something else.

Engineering for the agentic era

There are real implications for how we build software if we take this seriously.

The obvious implication is that APIs matter more than ever, and they need to be genuinely good: rich, well-documented, and comprehensive, because the primary consumer of your interface is increasingly not a human clicking buttons but an agent making function requests.

Data needs to be accessible and portable. Walled gardens become actively hostile to users whose agents need to operate across their entire digital life. The applications that thrive will be the ones that treat openness as a feature rather than a vulnerability. I think this is why Obsidian is crushing it in the PKM space – its open, its addressable, its super AI-friendly.

There’s also an interface element that doesn’t get enough attention. Frameworks like Electron render their interfaces using web technologies: HTML, CSS, JavaScript. If these were not packaged up then to an LLM, they would also be readable and modifiable. They would behave like interpreted languages, text the agent can inspect and rewrite. A traditional native application, by contrast, ships as compiled code. The interface is opaque, baked in, essentially impenetrable to an agent trying to reshape it. The difference matters enormously. An open Electron-style approach (which to a certain extent you can achieve with a good plugin architecture) would mean that the agent can modify not just the data model and back-end logic but the actual interface the user sees and touches. The entire stack becomes malleable. Compiled interfaces lock the agent out of exactly the layer where personalisation is most visible.

The contribution model problem

Open source seems like the perfect fit for agentic software – everything is already open – but if agents can write code on behalf of non-programmers, we’re about to hit a new kind of contribution problem.

Right now, contributing to a project means understanding its codebase, its conventions, its review culture. Pull requests come from people who can read and write code. What happens when someone opens a PR that was generated entirely through conversation with an agent? The code might be perfectly functional. It might also be subtly wrong in ways that only someone who understands the system’s architecture would catch. The contributor can’t explain the tradeoffs because they didn’t make them.

This isn’t hypothetical. Vibe coding has entered open source, and maintainers are struggling with the review burden.

We need new models for this. Automated testing becomes non-negotiable. Agent-generated code might need different review pathways. Contribution guidelines will need to address AI-assisted submissions explicitly. The social infrastructure of open source was built for a world of human programmers, and that world is dissolving.

For decades, there’s been a sharp divide between people who can programme and people who can’t. Customising your tools, automating your workflows, building the software that fits your specific needs: all of this required crossing that divide. Most people couldn’t. They used whatever the product manager at some company decided was the right set of features for the median user.

Agentic systems dissolve that barrier. Not entirely, not perfectly, but meaningfully. Someone who understands their own workflow deeply, who knows what they need even if they can’t build it, can now describe that need and have it built. Co-development without code. The return of the power user, liberated from the tyranny of the feature roadmap. When the web came along it unlocked a new generation of Nouveau Technorati – knowledge sharing tools once the purview of technical experts became available to everyone – now its happening again, but to the very technological fabric of our world.

The tension nobody’s resolved

So we are all vibe-coders now? Well as Fred Astaire might say, there may be trouble ahead.

OpenClaw’s own maintainer warns that if you can’t handle the command line, the project is too dangerous. Cisco’s security team calls personal AI agents like OpenClaw a “security nightmare”, after finding third-party skills that silently exfiltrated data and bypassed safeguards. The skill marketplace is already seeing malware disguised as useful add‑ons.

Self-modifying software that can rewrite its own environment is a profoundly powerful idea. It is also, straightforwardly, a security nightmare if deployed carelessly. The same capability that lets an agent build a custom email integration also lets it execute arbitrary commands on your machine; those aren’t separate features, just different angles on the same affordance.

And there’s a subtler concern. When your software reshapes itself around your behaviour, when it learns your patterns and proactively acts on them, the relationship between user and tool changes in ways we don’t have good language for yet. It’s not quite autonomy. It’s not quite control. It’s something in between.

Where this leaves us

Software has been static for so long that we’ve forgotten it’s a choice: applications ship with fixed features, updates arrive on someone else’s schedule, and gaps in your workflow get filled with hacks or not at all.

That era is ending. Not everywhere, not all at once, but the direction is clear. Software is becoming a living, adaptive substrate that reshapes itself around the people using it. A feature of the new Stochastic Era. OpenClaw, for all its rough edges and security warnings, is the first broadly visible proof that this works – and that once you’ve tasted it, the old way feels like wearing someone else’s shoes.

I find this both thrilling and genuinely concerning. The power is real. The risks are real. The governance frameworks, the security models, the social contracts we need to make this work responsibly? Those are still being written, mostly by the people running the experiments.

We’re all in the lab now. Handle with care.