The moment generative AI showed it could write code, and then write it better with each release, a quiet question started forming under all the excitement: if a model can produce the code, what happens to the software we used to write by hand?

That question got sharper with agents. An agent does not just autocomplete a function. It writes its own code to accomplish a task, runs it, reads the result, and calls tools when it needs them. Give an agent a REPL and an internet connection and it can investigate at runtime, hit APIs directly, and assemble an ad hoc solution on the spot. Once that became normal, the speculation turned concrete. People started asking, only half rhetorically, what software actually survives in a world where the main consumer is no longer a human clicking a UI but an agent deciding whether to use your tool or just do the job itself.

Two questions fall out of that, and they are not the same:

1. Will this thing survive? Given an existing tool, SaaS, or technology, what are its odds in the agentic era?
2. How do I build for it? If I am designing a product now, what makes an agent discover it, use it, and prefer it over doing the work alone?

I have packaged two skills that answer these, each from a different angle. They are now open source, and this post explains what each is for.

Skill 1: Software Survival Analyzer (the diagnostic lens)

The first skill answers question one. It is an implementation of Steve Yegge's survival framework from his essay Software Survival 3.0, and the core idea is brutally simple: tokens cost energy and money, so an agent will prefer tools that save it cognition over tools it has to think around. If using your software costs the agent less than re-deriving the functionality from scratch, it survives. If not, the agent routes around it and eventually forgets it exists.

The skill turns that into a structured assessment. It can start with a quick research pass when the target is moving fast, and then two binary gut-checks before any numbers: would it be absurd for an agent to re-synthesize this from scratch (the way re-deriving PostgreSQL or Git would be absurd), and does the software merely sit between humans and a task the AI will soon do on its own? It then scores a handful of variables (how much cognition the tool saves, how broadly it is used, how easily an agent can know about it and use it without friction) and a separate human-preference factor for things that survive because people want them, not because they are efficient. The output is a survival forecast, a trajectory (improving or eroding), the competitive picture, and concrete levers to pull.

Use it when you want to look at something that already exists and ask, honestly, how exposed it is. It works on infrastructure (Git, Stripe, Docker all score very high), on SaaS, and on the regional, GUI-first tools that look healthy in their local market but are nearly invisible to a global agent. The uncomfortable cases are the most useful ones.

Skill 2: Agent-First Readiness Assessment (the design lens)

The second skill answers question two. Where the survival analyzer is diagnostic, this one is prescriptive. It is an original framework that synthesizes ideas from several people thinking about this shift (Yegge on desire paths, Karpathy on building for agents, Alex Zhang on language models as scaffolds, and others), and it evaluates whether a product is actually built to be consumed by agents rather than just by humans.

It scores a product across six dimensions: whether an agent can discover it at all (is the code public, is there a SKILL.md, is it in the registries agents actually search), whether an agent can consume it without friction (clean CLI with machine-readable output, informative errors, low token cost per operation), whether it offers real value versus the alternative of the agent doing it itself, whether its open source strategy opens what teaches the agent and closes what makes it necessary, whether it is defensible as agents get more capable, and whether it is operationally reliable enough to serve bursty agentic traffic. Each dimension gets a score, the gaps get concrete actions, and the actions get sorted by impact over effort so you know what to fix first.

Use it when you are designing or auditing a product, API, or service and you want to know whether an agent would find it, choose it, and keep choosing it. It is the difference between a beautiful dashboard no agent can see and a product that shows up exactly where the agent is already looking.

Two faces of the same shift

The two skills are deliberately complementary. One is diagnosis, the other is design. The survival analyzer asks "will it last?" and is most useful pointed at things that already exist, including your competitors. The readiness assessment asks "how do I make it last, and get used?" and is most useful pointed at what you are building next. Run the first and you understand the pressure. Run the second and you do something about it.

Neither tries to predict the future with false precision. They are structured ways to ask better questions in a landscape that is still moving, and to replace hand-wavy intuition ("agents will probably change everything") with something you can actually score, compare, and act on.

Where to find them

Both are open source under the MIT license, with full attribution to the thinkers whose ideas they build on. You can find them, along with the rest, at github.com/lesmes/skills.

↗View on GitHub

If you only take one thing from this: the question is no longer whether your software is good. It is whether an agent would stop to use it instead of doing the job itself. That is a different bar, and these two skills are built to help you clear it.

Sources and further reading

• Steve Yegge, Software Survival 3.0. The survival framework the first skill implements.
• Alex Zhang, Language Models will be Scaffolds. Scaffold-LMs and the closing time window.
• Andrej Karpathy, thread on X on the new agentic abstraction layer (agents, skills, tools, MCP, hooks, and the pitfalls of building on stochastic entities).
• Andrew Ng, Context Hub (chub), an open-source tool for giving agents up-to-date documentation and feedback loops.
• Danila Poyarkov, figma-use, an agent-facing CLI for Figma (single operation, token efficiency, dual workflows).