Why AI-Native Companies Are Deleting Software You're Still Paying For (The $56K Lesson)

In last week's executive briefing, I argued that most enterprise agents are sophisticated amnesiacs. The models are capable, but without domain memory, explicit goals, progress tracking, operating procedures, well, multi session work just turns into a lot of thrash, and you don't get very far. This week is the uncomfortable followon. Even if you solve for memory, most companies still won't get agent leverage because they haven't taught the organization to work in primitives. Not prompting, not

tooling, but primitives. The shared building blocks that let humans and agents reliably ship work without heroics. The real failure mode that I want to talk about this week is that AI agents run into walls even with memory because the work that you have is usually stuck in 20th century work patterns. Most agent deployments are going to stall at a similar place where the agent can write a plausible draft, the agent can summarize a meeting, the agent can generate options, propose

plans, and and it just can't get farther. The wall is your operating environment. In most Fortune 500 companies and even most smallmedium businesses, important work lives inside opaque workflows. Let me give you some examples. Maybe it's behind the click pads in business software like behind an admin portal, behind a ticketing tool, behind a CMS screen, behind a dashboard. Maybe it's trapped in a hidden state somewhere. It's in draft mode. It's in an unpublished version. It's in

permission rules that aren't visible until you hit them. Maybe it's encoded as tribal knowledge. Ask Sarah. Actually, finance owns that. You know what? We don't touch that system. An agent cannot reliably operate inside that environment. It cannot advise. It cannot draft. And most important, it cannot ship with you. So, you can't accelerate. So, the company that buys agents is actually buying a conversation layered on top of those same bottlenecks. Now I want to give you a

case study around how you can unlock this and think differently. Lee Robinson is a longtime builder and writer. He was previously at Versell. He now works at Curser teaching about AI. Curser is obviously one of the breakout companies in AI assisted coding. The product is an IDE designed around AI agents. If anybody is AI native, you'd think it would be Cursor. And in this case, that's true. Just a few days ago, Lee published an essay that reads like a weekend project, but we should treat it

as more of a strategic signal. I think it's a fantastic case study in how we can make AI agents native in non- tech organizations. Lee was able to migrate cursor.com from a headless CMS or content management system right back to raw code and markdown. Now, for decades, we would say that was regressing capability. we would say we need marketers to have a CMS so they can reliably make changes. Well, Lee didn't think that was true anymore and we'll get into why. He estimated it would take

weeks and maybe an agency and this is a guy at an AI native organization, right? He estimated it would take weeks. He himself was surprised because he finished the job in three days over a weekend using about $260 in tokens and hundreds of agents. That is hundreds of agent pull requests and calls. I think 300 and some before it was all done. The headline is not AI agents can code nor is it AI agents are fast. What I noticed is that they used to be able to ask the

agent to modify the website directly and then when they introduced a CMS in the middle which was a change cursor made as a way of trying to become a grown-up marketing organization, suddenly they were back to clicking through UI menus instead of just delegating work to agents. And so what Lee realized is that there is a larger lesson here with AI and coding agents. The cost of an abstraction has never been higher. An abstraction is just a layer that hides the underlying work behind a simplified

interface. We needed it for a long time because most organizations are mostly not technical. A CMS is an abstraction, right? It hides the messy parts. It hides the files, the structure, the deployment, the version controls, and gives humans a nice friendly screen that says edit, page, and publish. For decades, that's been a good trade. And even AI native organizations like cursor think in those terms, which I guess should be encouraging to us because if cursor thinks that way, we we can take

interface. We needed it for a long time because most organizations are mostly not technical. A CMS is an abstraction, right? It hides the messy parts. It hides the files, the structure, the deployment, the version controls, and gives humans a nice friendly screen that says edit, page, and publish. For decades, that's been a good trade. And even AI native organizations like cursor think in those terms, which I guess should be encouraging to us because if cursor thinks that way, we we can take

some comfort in taking a minute to get AI native here. But the the thing that you need to realize is the minute you want agents, all that stuff that you hid becomes really expensive. That was Lee's core insight is that before they actually added in their CMS at cursor, it was actually easier to update the site. You just said at cursor and you changed your marketing copy. And that's as simple as you want it to be. Look, agents don't thrive in clicky environments where state is scattered

across different screens, different permissions, different draft modes, hidden dependencies, different roles. Agents thrive in environments where the underlying work is visible and editable. So the CMS stopped being a helpful tool as agents gained a capability. Instead, it became a wall between the agent and the work. And that is why this story matters. It's not really about a website. It's not about CMS. It's not even about cursor. It's about the new economics of complexity. So Lee's essay

is unusually valuable because he doesn't just say the CMS is bad. He actually lays out the hidden tax that we don't realize we're paying by using these abstractions. If you strip away the webdev details, the list looks like a kind of familiar executive pattern. You have multiple identity systems. Some people are in GitHub and and in the CMS. Someone always needs to be added for permissions. There's operational drag. There's permissions risk. There's preview complexity, right? Draft content

requires special access paths and brittle preview logic. Sharing what we're about to ship becomes a friction point in and of itself. And more moving parts are required to keep everything fast and reliable. The site wants to be simple and it wants to be stable and it wants to be pre-built. The CMS introduces additional uptime dependencies, additional special modes, and so there's a legitimate cost markup to this that the organization pays even if you're not thinking about the agent

side. Spent and lease shares this cursor spent $56,000 on CMS usage since September, which is a really hefty markup for the convenience of a graphical user interface. It also introduced hidden dependencies. When pieces of the site come from network fetches or humans can't easily answer where does this piece of the site come from, Lee points out that that inability to completely and clearly explain what is going on the site that introduces additional costs in time and knowledge

side. Spent and lease shares this cursor spent $56,000 on CMS usage since September, which is a really hefty markup for the convenience of a graphical user interface. It also introduced hidden dependencies. When pieces of the site come from network fetches or humans can't easily answer where does this piece of the site come from, Lee points out that that inability to completely and clearly explain what is going on the site that introduces additional costs in time and knowledge

and maintaining hidden state in our heads that is really expensive. So this is the actual state most of us face with graphical user interfaces. This is the size of the tax that we have been paying for non-technical people to use non-technical tools that are abstractions over a technical workflow. What has changed is that it is now absolutely possible for non-technical people to drive technical agents directly against the workflow code itself. And so why would you pay the tax

on the abstraction anymore? Why not move back to the work surface that is legible to both humans and agents, raw code and marked outdown? That's what Lee did. And that move collapsed all of the complexity of cursor's website into a single inspectable place. So if you're not technical, what you need to understand is that the work moved from state that was hidden inside of a tool to artifacts everybody, including agents can see, review, and undo. And that's what really matters here. So Curser's

advantage isn't really AI agents. Everyone's going to make a big deal out of the fact that Lee used 300 some agent pull requests. That's not really it. It's that the whole company is technical by default. Because when I ask myself what is stopping other companies from doing this, the thing that I come up against over and over again is that cursor is building a culture where technical is not a department. It's a default posture. And Lee describes this explicitly when describing user

management. He says designers are developers. This is absolutely the case at OpenAI as well. And it's absolutely the case at AI native organizations that I have run into all over the world in the last year. It can sound radical if you're in a traditional business, but at Kurser and other companies, it's really just normal. It does not mean that you don't have non-technical staff. It means that everybody is semi-technical. And when you talk to folks like designers,

management. He says designers are developers. This is absolutely the case at OpenAI as well. And it's absolutely the case at AI native organizations that I have run into all over the world in the last year. It can sound radical if you're in a traditional business, but at Kurser and other companies, it's really just normal. It does not mean that you don't have non-technical staff. It means that everybody is semi-technical. And when you talk to folks like designers,

which I've done, who are also committing code, they're surprisingly open-minded about it. They say, you know what, I don't worry a lot about exactly where my job family ends up. I'm interested in solving problems. I bring a design mindset to solving problems. I happen to have a tool set that allows me to iterate really quickly with code, which keeps me closer to the problem space, and I love that. That is the kind of attitude that we need across the board in our organizations. By the way, this

is not just Lee's personal vibe or take. Colossus has actually written up a comprehensive profile on Cursor's go to market team and noted that they're surprisingly technical and they use Cursor itself for website updates, for dashboards, for internal tooling and they ship that work directly. They do not route everything through engineering. And so if you think about it, that mindset of getting as close to the code as you can and allowing the code to establish primitives that agents

can build against, that is scalable and that leads to surprisingly efficient thinking because you're thinking in terms of the core artifacts that everybody can see and work against. And so internal debates at Cursor look like the kinds of debates we all dream about as leader. People talk about whether something gets used and if not they proactively move to kill it. There's a culture of dog fooding and testing that keeps the defaults continuing to evolve as we try stuff. Cursor has a pre-hip

ritual called a fuzz where everyone tries to break the release and then fixes land fast because everyone has actually tried the new thing. This is not startup chaos. This is not something that's impossible to copy at a larger scale. It's actually a very coherent operating model. is just foreign to the way we've worked before because 20th century defaults are stuck in the age of the graphical user interface. So this model emphasizes shared agency. It emphasizes a shared substrate of

primitives and it emphasized shared responsibility. And that brings me to the deeper thesis that we've been circling around in this conversation. The real thesis is that code wins is not about engineers. It's about how you extend legibility, investment, and leverage across your entire organizations. When executives hear code wins, it's often translated as an engineering slogan that means engineers win versus design versus product versus business because they can actually put

the product out there. In the agentic era, it's different. It becomes more of a strategic law for how we operate our businesses. Work that can be expressed in codelike form gets a fast track to agents because the entire industry is investing its best models, its best tools, its best safety investments and mechanisms and every evaluation discipline they can find all into the code pathway. And you can see this clearly in anthropics own engineering guidance on longrunning agents. They

describe the core long-running problem the same way. Agents work in discrete sessions and every new session begins with no memory. We talked about this last week. Their solution is not magical AI memory. It's a disciplined harness. Right? Remember we talked about an initializer agent, a coding agent and clear artifacts for the next session. So the key thing to remember is that those artifacts are not just for agents. The world is being built where artifacts are

already native. The world is being built now around code and repos and tests and logs and markdown files. So if a workflow resolves to artifacts plus validation and checks, it's likely that agents can participate in execution today. But if a workflow lives inside a tool user interface state and a graphical clicky based software that humans have to operate and humans have to remember how to adjust and it's all dependent on human memory plus that GUI agents at best remain advisers and this

already native. The world is being built now around code and repos and tests and logs and markdown files. So if a workflow resolves to artifacts plus validation and checks, it's likely that agents can participate in execution today. But if a workflow lives inside a tool user interface state and a graphical clicky based software that humans have to operate and humans have to remember how to adjust and it's all dependent on human memory plus that GUI agents at best remain advisers and this

is why software is winning first. It's not because engineers are better people or are more deserving. It's because software is already built around the infrastructure of legibility. It's built around version history and diffs and tests and rollbacks and audit trails. So fundamentally when you are looking at composable workflows, those are the primitives you build around. And that's what Lee saw. Lee saw you didn't need the graphical user interface. You could have all the muscle and power of the

software just by tagging cursor in the command line. And why did you need to do anything else if you actually decompose the workflow down? And so I got to thinking, how do we as enterprise leaders start to teach our teams to think this way? First, I think we need to really emphasize an understanding of primitives as places where work lives. A primitive is not complicated. It's just a small stable building block that stays useful even when tools change. There are

a couple of basic primitive stacks out there that I think I want to emphasize. You need a clear definition of done. You need a persistent record of state or domain memory. I talked about that. You need a process for how work progresses and how it's validated. Without those three things, it's hard to make an agent reliable. But beyond that, you also need to understand how work gets done across the organization. And most enterprises never define this explicitly. And I

think we're paying for that lack of definition. We've been paying for it through graphical user interfaces where humans use tribal knowledge to accomplish workflows by clicking things. That's no longer needed really. And so we need to start to ask ourselves harder questions. What are the work primitives that drive operational change for us? For example, where's the thing that we change? That would be the system of record. How do we see that it changed? That's a readable before after state.

How do we approve it? That's a defined gate. How do we prove that it worked? That's a check. How do we undo it? That's a roll back. How do we know who did what and why? That's traceability. All of those questions are questions business stakeholders ask all the time when vetting software. And really, they're coding questions. Lee's CMS is really a story about work primitives being extended across a technically fluent company. He replaced a UI state workflow with an artifact workflow

because artifact workflows have natural review, roll back, and traceability and they just make sense when that's how agents are being built. Enthropic's longrunning harness is the same work primitive story. They made progress reliable by insisting on artifact, state, and incremental steps. and they were fluent enough to build the business around that. Domain memory is not just an agent technique. It's really one of several work primitives. It's the written state of the project. And so if

your organization doesn't know how to write state down in canonical places, memory itself won't save you because the work is still not legible. So the cultural pattern that we're seeing at cursor and openai that enables this and at anthropic and at other major studios is that non-technical people are learning the substrate of code and they're learning it well enough that they can commit code. They're learning it well enough that they can be fluent in understanding how code drives

workflows and they're learning it well enough that they can operate against the code with the help of agents. By the way, this does not mean they learn it well enough to authentically correctly write JavaScript without help from an AI agent. I'm not saying they do. I'm not saying they ever will. I know lots of design engineers who cannot do that, but who nonetheless commit pull requests. So, the reason cursor can kill a CMS is not because they have this bias against

graphical user interfaces. Don't hear that. It's that their people understand that they can operate on one simple underlying workflow substrate of code and common primitives and that's enough and they can do that with agents. And the reason I'm calling this out today is that I have a strong conviction that simple wins. If if you are working in a world where you could have a more complex graphical user interface or a simpler substrate that gets closer to the code, especially given the pace of

AI agent change, I would opt for the simpler solution. Simple is going to win when AI agents change fast. Simple is going to win when LLMs change fast. If you can get to a a block of stable basic work primitives, if you can help your people understand that they need to have mental models of workflows and code and how code operates to get work done through read write on databases, through approvals, etc. Even if they can never write that code individually themselves,

you are going to be in a position where you can ask them to operate agents and that's going to give you a tremendous amount of freedom to delete abstraction layers from your business that are extremely expensive like the CMS cursor. So code wins becomes an operating model for the business as a whole and it allows us to extend the premise that simplicity is what wins in the age of AI. The organization needs to train more people to think and act in artifact-based workflows because that's

where agents are strongest and that's where they're safest. And this is the piece that most enterprise leaders are not really ready to hear. If you keep your workforce in the 20th century, if you keep them graphical user interface native because your security department, your IT department tells you this is what we should do because it's safe and only the engineers should commit code. your agents are going to be stuck as drafting assistants. You're not going to

unlock the kind of velocity that you see and want from these AI native companies. Whereas, if you teach your workforce to be artifact native, your agents can then become operators and collaborators with your teams. And so, this has some profound implications for training. It has profound implications for our security policies. If the strategic claim is that codelike work wins because it's agentable, then the logical conclusion is that enterprise AI training must transform into something

like code concept training for non-engineers. Not learn Python, not become an engineer, but learn the concepts that make work legible to agents. Because the goal is not to turn everybody into programmers. The goal is to turn more of the company into people who can express work in a form that agents can safely act against. So things like state, what is the current status of your work? Where is that written down? The artifact, what is your system of record? What is the real thing we

ship and maintain? Is it a document, a data set, a configuration, a product catalog, a policy? If the truth lives in a hidden state in the UI, your agent can't reliably operate. Another example, what's a change record? Can we see what changed without an argument? Software has diffs. Enterprises need the equivalent. Checks. Who proves this is correct? It looks good is not the check. A check is something objective, a test, a reconciliation, a policy rule, a validation script. Roll backs. How do we

undo what we've done? Agents increase throughput. Roll back is how you keep that throughput from becoming a risk. Traceability. Who changed what? When? Why? When your AI workforce grows, this stops being a compliance nicity. It becomes existential as you get lots and lots of agents. If you can teach these kinds of ideas broadly, you create the precondition for real agent adoption because your organization stops treating tools themselves as sacred. Oh, I'm a

Salesforce guy, right? Because everyone understands what must stay true underneath. It's not Salesforce that's the thing. It is the workflow that's the thing. And that's why cursor can ask do we really need a CMS and actually execute the deletion. They weren't being reckless. They understood what it would replace. They understood they could replace it with a simpler substrate with a stronger core primitive set that both agents and humans could operate against. So if you're a Fortune 500 exec, if

you're a small business leader, the mistake would be to interpret this as let's copy cursor and put marketing into GitHub. I don't mean do that exactly. That is not the point. The point is that there is an underlying competitive advantage in the age of AI. Primitive primitive fluency diffuses power. When teams share a mental model of state of artifacts of checks, roll back, traceability, the company gains a new superpower because people can see that a standard tool is just a convenience

layer with a measurable tax. People can propose a simplification without triggering fear because they can articulate what stays safe and everyone's technically fluent enough to follow. Work can be recomposed into forms agents can operate against instead of being trapped in process. That is what moving fast looks like in a mature agentic organization. It's not speed for its own sake. It's just simpler, less hidden state, fewer brittle handoffs, and more of the company able to safely

ship changes. Last week, I called out that agents fail because they don't remember. And you can fix that with domain memory, but it's not enough. This week, I want to remind you that organizations fail because they don't write work down in agent legible forms. You fix that by teaching primitive fluency, which is really code concept fluency, across your entire organization. Agent strategy is not really a procurement decision. It's a literacy decision. The winners won't be

ship changes. Last week, I called out that agents fail because they don't remember. And you can fix that with domain memory, but it's not enough. This week, I want to remind you that organizations fail because they don't write work down in agent legible forms. You fix that by teaching primitive fluency, which is really code concept fluency, across your entire organization. Agent strategy is not really a procurement decision. It's a literacy decision. The winners won't be

the companies that have agents. They'll be the companies where enough people understand the primitives that they can delete sacred workflows and frankly notice where they're incorrect. And that will allow them to move work into more legible artifacts for agents. And that will allow them to unlock agents actually operating. And that's what unlocks 10x speed. Good luck with your primitives. Good luck with your AI agents.