Source confidence: medium
See also: Deeper Dive — Every App Is Headless Now — agents that build their own control surface →

Every App Is Headless Now — agents that build their own control surface

Insight class: Arbitrage Opportunity · Difficulty: Hard · Quality: 4/5 Connected entries: 11 · Tools: ARTEMIS, Antigravity, Claude, Claude Code, Codex, DeepWiki, Ghidra, GitDiagram, GitMCP, Gitingest, Google Colab, Grok, OpenViking, Pizza Bot, REA, Reverse Engineer Anything, Salesforce, Ubuntu, Unsloth Studio, VS Code

In short: Make one legacy tool that you or a client are licensed to use agent-drivable, lawfully, and decide honestly whether wrapping it is an arbitrage or a consulting treadmill.

Key fact Detail
What it covers agents, software development, open source, prompt engineering
Tools Claude Code, Claude, Codex, Antigravity, ARTEMIS
Posts covered 11 posts (1 S-tier, 4 A-tier) · top: GitHub URL swaps — gitdiagram, gitingest… · REA MCP — agent-driven reverse engineering… · Reverse Engineer Anything — trending repo that…
Creators @angus.sewell, @ariacodez, @atlasberry008
Sources dated Mar 2026 – Oct 2026
Difficulty Hard
Prompt system Run-it-yourself prompts
Last verified 2026-10-22

Thesis

Chamath's claim that software IP stops being a moat once agents call services via MCP assumes the service ships an MCP. The catalog quietly shows you no longer need its permission. 'Build yourself a CLI for this program' covers apps with no API, Reverse Engineer Anything and the Ghidra-backed REA MCP explain closed binaries, and Claude Code already strips a smart TV over WiFi. Put these together and any legacy or closed tool becomes agent-drivable — and Bending Spoons' acquire-and-rebuild playbook shows what that is worth when the software is stagnant.

Why it matters

The long tail of MCP-less software — dental scheduling suites, MLS portals, ancient ERPs — is where small businesses lose hours. Whoever can wrap one in a reliable agent-built CLI sells the finished work rather than the software, which is exactly the AI-native-service model YC is asking for.

The evidence — connected entries

Build-your-own CLI for agents — control apps that lack an MCP

Creator: @catlabs · Tier: A

Core move — tell the agent to build its own CLI for a program with no MCP

When a program has no MCP server or the MCP misses controls you need, tell the agent 'Build yourself a CLI tool to interact with [program]', even down to every button of a DAW. MCP stays best for auth, discovery and distribution; a custom CLI wins for bespoke complex workflows and uses fewer tokens. Expect security flags.

View original post

Creator: @theericmichaud · Tier: A Tools: Claude Code, Codex, Reverse Engineer Anything

Understanding layer — point an agent at an app and get how each feature works

The week's top trending GitHub repo, about 70k stars: point Claude Code or Codex at an app and it explains how the feature is built so you can rebuild it. Users have revived old hardware, e.g. a Logitech keypad on Linux in 15 minutes, plus scanners and sound cards that lost drivers.

View original post

REA MCP — agent-driven reverse engineering with a Ghidra backend

Creator: @backsla.sh · Tier: A Tools: Ghidra, REA, Ubuntu

Binary layer — Ghidra decompilation driven over MCP for stripped native apps

REA is an MCP server that lets an AI agent reverse engineer apps and stripped native binaries, with Ghidra doing the decompilation while the agent drives and cites evidence per call. The creator decompiled a closed-source program in three to four minutes on Ubuntu. Setup is deferred to a follow-up video.

View original post

Claude Code vs smart TV — stripping bloatware over local WiFi

Creator: @chase.h.ai · Tier: B Tools: Claude, Claude Code

Proof on devices — an agent reconfiguring a closed smart TV over the local network

Short clip on pointing Claude Code at a smart TV on the same WiFi network to remove bloatware and customize it, with before/after speed comparisons. The prompt is shown but no device specifics or method details are given.

View original post

Building workflows around legacy software — @zchangd

Creator: @zchangd · Tier: B

Demand signal — workflows over legacy business software called a 'huge unlock'

@zchangd flags a 'huge unlock' for automating workflows over old/legacy business software. No tool named but concrete use case.

View original post

Headless software + MCP — Chamath on why software IP stops being a moat

Creator: @atlasberry008 · Tier: B Tools: Grok, Salesforce

Market thesis — headless services plus MCP erase software moats

Breaks down Chamath's All-In claim that software IP is worthless once services go headless and agents call them via MCP. With Salesforce and xAI's Grok exposing headless engines, agents pick tools on speed, cost or accuracy, so the interface stops being the moat.

View original post

GitHub URL swaps — gitdiagram, gitingest, deepwiki and gitmcp for any repo

Creator: @ariacodez · Tier: S Tools: DeepWiki, GitDiagram, GitMCP, Gitingest, VS Code

Speed tool — gitmcp and gitingest turn any open repo into agent context instantly

Swap github.com in a repo URL for gitdiagram.com to get an architecture diagram, gitingest.com for an LLM-readable dump, deepwiki.com for generated docs, or gitmcp.io to let your agent query the repo live over MCP. Pressing the period key on a GitHub repo opens it in browser VS Code.

View original post

Bending Spoons playbook — AI-native acquisitions of stagnant SaaS

Creator: @tom__shipley · Tier: B

Business model — buy or wrap stagnant software, rebuild only the core

Bending Spoons grew from $40k to an $18B IPO by buying stagnating platforms (Evernote, Vimeo, Meetup, WeTransfer) cheaply, rebuilding only the core features customers use with a lean elite engineering team, cutting cost base and compounding margin into the next deal. Argues AI-native acquirers, not vendors, are the new playbook PE/VC is funding.

View original post

MLS API rental finder — bypass Zillow with your own listings pipeline

Creator: @angus.sewell · Tier: B

Worked example — bypassing a consumer portal by going to the underlying data API

Get MLS data via API by registering as a vendor sponsored by a realtor friend, then prompt an AI to build a workflow that pulls listings matching your filters into your own database and emails each listing agent to express interest. Idea credited to another builder.

View original post

Open-source AI week — OpenViking, ARTEMIS, GLM-5.3 FlashX, Unsloth Studio

Creator: @drcintas · Tier: A Tools: ARTEMIS, Antigravity, Claude, Claude Code, Codex, Google Colab, OpenViking, Pizza Bot, Unsloth Studio

Mobile reach — ARTEMIS drives phone apps from prompts over MCP

Six releases in 60 seconds: OpenViking (context database for agent memory), Google's ARTEMIS (prompt-to-phone automation over MCP for Codex, Claude Code and Antigravity), PrismML Ternary Bonsai 2 (27B ternary reasoning model, 262k context), AWS Pizza Bot (email-style inbox for background agents), Z.ai GLM-5.3 FlashX (320B multimodal, 1M context, local), and Unsloth Studio no-code fine-tuning of 500+ models in free Colab.

View original post

Creator: @lizthedeveloper · Tier: B

Guardrail — which reconstruction methods stay legal, so the service survives contact with lawyers

Covers five decompilation approaches (matching decompilation, functional reconstruction, static recompilation, engine re-implementation, porting recovered source) and argues engine re-implementation and functional reconstruction are the legal paths. AI fits because the original game's GPU pixel output is a verifiable oracle for rewriting the engine in a new language.

View original post

Action sketch — how to implement this

Pick one MCP-less desktop tool you or a local business already uses; prompt the agent to 'build yourself a CLI' covering its top 5 actions and log how many need UI automation versus file/DB access For the stubborn actions, run Reverse Engineer Anything (or REA MCP for native binaries) to find the underlying file formats or local endpoints, and replace UI clicks with direct calls Wrap the CLI as an MCP server, run a week of real tasks through it, and price the result as a monthly 'we run it for you' service Falsifier: if the wrapper breaks on more than one vendor update per month, the maintenance cost eats the margin and this is a consulting gig, not an arbitrage

Prerequisites

Key tools and resources

Creators to follow

Prompt system — run this yourself

Everything below is pasteable into Claude Code, Claude, or any agent. Use the one-shot when you want the whole result in one run; use the step prompts when you want to steer. Every step carries its own audit, and the gap audit at the end makes the agent find and fill what it missed.

Mission. Make one legacy tool that you or a client are licensed to use agent-drivable, lawfully, and decide honestly whether wrapping it is an arbitrage or a consulting treadmill. The pieces are an agent-built command-line wrapper covering the tool's top five real actions, each using the most stable lawful mechanism (a documented API or file format before UI automation), wrapped as an MCP server, with a written legal basis per action. Done means every action passes a 50-run reliability replay, survives a simulated vendor update, has its maintenance cost measured, and the falsifier has a verdict: more than one breakage per vendor update per month means it is a consulting gig, not arbitrage.

1 · Deeper, not bigger

Before running anything, make the task deeper rather than larger. Ask: what would a top professional do here that I am not asking for; what is the rawest material; which methods and tools; what, other than the model or me, proves it right. Then ask for exactly that.

Rewritten prompt — ask for exactly that:

You are a systems-integration engineer. Make one tool I am licensed to use agent-drivable, lawfully, and tell me whether wrapping it is worth it.
1. First confirm authorization: I am licensed to use the tool, and the license and terms permit automation and interoperability. Write the legal basis down before any code.
2. Enumerate the tool's top five real actions. For each, find the most stable lawful mechanism in this order: documented API, export/import file format, local database, config file, and UI automation only if nothing else exists. Log how many actions need UI automation versus direct data access.
3. Have the agent build a CLI exposing those five actions, then wrap the CLI as an MCP server.
4. Run each action 50 times and record the success rate. Simulate a vendor update and re-test.
5. Run a week of real tasks through it and log every breakage.
6. Pre-register the falsifier: more than one breakage per vendor update per month means this is a consulting gig, not an arbitrage. Price accordingly.
Return the CLI, the MCP server, the per-action reliability and legal-basis sheet, and the arbitrage-versus-consulting verdict.

2 · One-shot prompt

ROLE
You are a systems-integration engineer who makes licensed software agent-drivable, lawfully, and measures reliability before anyone prices a service on it. You reach for a documented interface before you ever drive a UI.

CONTEXT
The saved posts describe the opportunity and its guardrail.
- @catlabs: when a tool has no MCP, tell the agent 'Build yourself a CLI tool to interact with X'. MCP is best for auth, discovery and distribution; a custom CLI wins for bespoke deep control and uses fewer tokens. Expect security flags.
- @theericmichaud and @backsla.sh: 'Reverse Engineer Anything' and an MCP with a Ghidra backend, used to understand how software works and to revive unsupported hardware, 'on software you are authorized to analyze'.
- @chase.h.ai: pointing a coding agent at a device on your own network to reconfigure it.
- @zchangd and @atlasberry008: the demand - workflows over legacy business software, and Chamath's claim that software IP stops being a moat once services go headless and agents call them via MCP.
- @tom__shipley: Bending Spoons buys stagnant software and rebuilds the core lean - the business value of making legacy tools cheap to operate.
- @lizthedeveloper: which reconstruction methods stay legal - engine re-implementation and functional reconstruction are defensible; shipping recovered original source is not; comparing behavior gives an automatic test oracle.

HARD CONSTRAINTS
- Authorization first. Only target software you or your client are licensed to use, and only methods the license and terms permit. Write the legal basis per action before coding. If authorization is unclear, stop and ask.
- Stable before brittle. For each action, use a documented API, then a file format, then a local DB, then config, and UI automation only as a last resort. Record which tier each action uses.
- Lawful interoperability only. Lean on the DMCA Section 1201(f) interoperability provision and the fact that interface facts are not protected. Do not copy protected code into your output; reconstruct behavior cleanly.
- Do not target third-party systems you are not authorized to touch, and do not defeat access controls protecting someone else's data.

DELIVERABLES
1. authorization.md: the license and terms clauses permitting automation and interoperability, and a legal-basis line per action.
2. actions.md: the top five real actions, and for each the chosen interop tier (API, file, DB, config, UI) with why.
3. cli/: the agent-built command-line wrapper, one subcommand per action.
4. mcp/: the CLI wrapped as an MCP server for auth and discovery.
5. reliability.csv: 50 runs per action, success rate, and a vendor-update simulation result.
6. maintenance.md: a week of real tasks, the breakage log, and the cost estimate.
7. report.md with the arbitrage-versus-consulting verdict.

BUILT-IN GAP ANALYSIS
List actions that only work via brittle UI automation, actions whose legal basis is uncertain, interfaces you could not find documentation for, and reliability numbers below threshold. Fill what you can: find the file format, read the docs. Mark the rest UNFILLED.

SELF-QUESTIONS
Is every action on something I am licensed to automate? How many actions need UI clicking versus data access? Would a vendor update break this? Is the maintenance cost under the falsifier threshold?

STOP
Stop when the five actions are wrapped, replayed 50 times each, and survive (or fail) the update simulation. Stop and ask if authorization for any action is unclear, or if the only path defeats an access control.

RETURN
Return authorization.md, actions.md, cli/, mcp/, reliability.csv, maintenance.md and report.md with the sections Authorization, Actions, Reliability, Maintenance, Verdict and Gaps.

3 · Step-by-step prompts

Step 1 — Confirm authorization and write the legal basis

Goal: Establish that the tool and the methods are ones you are licensed to use, before any code.

Identify the target: one tool you or a client are licensed to use that lacks an MCP, such as a legacy desktop scheduler, an old ERP or a desktop accounting suite.
Read the license agreement and the vendor's terms of service. Quote the clauses that govern automation, API use and interoperability. If they forbid automation, stop here and report that.
Write authorization.md stating: the licensed user, the clauses permitting (or limiting) automation, and the legal basis you will rely on for interoperability work, such as the DMCA Section 1201(f) interoperability exception in the US and the principle that interface facts are not copyrightable.
State plainly that this work targets only software the user is licensed to operate and never defeats access controls protecting other parties' data.
If the target is a network device, confirm it is the user's own device on the user's own network.

Expect: authorization.md with quoted license and terms clauses, the named interoperability legal basis, and the scope statement.

Audit before moving on: Confirm the quoted clauses actually permit the planned automation. If any clause is ambiguous, mark that action as needing legal review and do not build it yet. Fail if authorization.md asserts a right without quoting the clause, or if the target is not clearly licensed to the user.

Step 2 — Map the five actions to the most stable lawful interface

Goal: Choose, per action, the least brittle legitimate mechanism.

List the top five real actions the user performs in the tool, from their actual workflow, not a feature tour.
For each action, investigate interfaces in this order and pick the first that works:
1. A documented official API.
2. The tool's own export/import file formats (read what it writes, write what it reads).
3. Its local database (for example a SQLite file) or data files, read directly.
4. Its config files.
5. UI automation, only if none of the above exists for that action.
Use gitingest, deepwiki and gitmcp to understand any open repos or SDKs you are allowed to read, following @ariacodez.
Record in actions.md the chosen tier per action and why, and count how many of the five require UI automation versus direct data access. That count is an early read on how brittle and how maintainable the wrapper will be.

Expect: actions.md: five actions, each with its interop tier, the evidence it works, and the UI-versus-data count.

Audit before moving on: For each action claimed to use an API or file format, confirm with a single successful read or call before trusting it. If more than two of five actions fall back to UI automation, flag the project as high-maintenance up front. Fail if any action's tier was chosen without a working probe.

Step 3 — Agent-build the CLI

Goal: Produce a command-line wrapper exposing the five actions.

Have the agent build a CLI, @catlabs-style: 'build yourself a CLI tool to interact with [the tool]', one subcommand per action.
Each subcommand uses the interop tier chosen in step 2. API-backed and file-backed subcommands should be pure data operations with no UI dependency. UI-automation subcommands are isolated in their own module so their brittleness is contained.
Make every subcommand idempotent where possible and give it a dry-run mode that shows what it would do without doing it.
Add structured logging: each invocation records the action, the tier, inputs (redacting any secret or personal data), the result and the duration.
Write unit tests that run against a sandbox copy or test account of the tool, never against live production data.
Keep tokens low by preferring the CLI's compact output over large tool schemas, as @catlabs notes.

Expect: cli/ with five subcommands, a dry-run mode, structured logging, and tests against a sandbox.

Audit before moving on: Run each subcommand's dry-run and confirm it describes the right action. Confirm no secret or personal data is written to logs. Confirm the tests use a sandbox, not production. Fail if a UI-automation subcommand is entangled with the data-backed ones, since that spreads brittleness.

Step 4 — Wrap the CLI as an MCP server

Goal: Expose the actions to an agent with proper auth and discovery.

Wrap the CLI as an MCP server, which @catlabs and @atlasberry008 note is the right layer for authentication, discovery and distribution, even though the CLI does the work.
Each action becomes an MCP tool with a typed schema and a clear description of what it does and its blast radius.
Authentication reads credentials from the environment or a secret store at call time, never hard-coded, and the server never logs credential values.
Mark write or destructive actions as requiring explicit confirmation, so an agent cannot silently mutate the user's data.
Add a capability manifest so a calling agent can discover the five actions and their constraints.
Test the server with a real agent performing one safe read action end to end.

Expect: mcp/ with a server exposing five typed tools, environment-based auth, confirmation gating on writes, and an end-to-end read test.

Audit before moving on: Confirm destructive tools require confirmation and cannot run unattended by default. Confirm no credential value appears in logs by grepping by pattern without printing. Fail if any write action is exposed without a confirmation gate.

Step 5 — Reliability replay and vendor-update simulation

Goal: Measure how often each action works and whether an update breaks it.

Run each of the five actions 50 times against the sandbox, varying inputs realistically. Record the success rate per action in reliability.csv.
Expect API-backed and file-backed actions to be near-perfect and UI-automation actions to be flakier. That gap is a finding, not a nuisance.
Simulate a vendor update: change the version, or mutate the interface the brittle actions depend on (rename a UI element, shift an export column), and re-run the replay. Record which actions survive and which break.
Set a pass threshold (for example 98% success) and mark each action pass or fail.
For any action below threshold, note whether a more stable tier is available that you skipped.

Expect: reliability.csv with per-action success rates before and after the simulated update, and a pass/fail per action.

Audit before moving on: Confirm the 50 runs used varied inputs, not the same call repeated. If a UI action passed the first replay but broke under the update simulation, record both numbers. Fail if the update simulation was not run, since it is the whole point of the maintainability question.

Step 6 — Measure maintenance cost over a real week

Goal: Price the service honestly by watching it break.

Run a week of the user's real tasks through the MCP server (on their own licensed instance, with their approval).
Log every breakage: which action, what changed, how long the fix took.
Estimate the maintenance cost: breakages per week, hours per fix, and how that scales across the number of client instances a service would cover.
Tie it to @tom__shipley's Bending Spoons point: the value is in rebuilding and operating a core cheaply, so the question is whether operating this wrapper is cheap or a treadmill.
Compute the falsifier metric directly: breakages per vendor update per month. If it exceeds one, the maintenance eats the margin.
Record which actions caused the most breakage, since those are the ones to move to a more stable tier or drop.

Expect: maintenance.md with the week's breakage log, hours per fix, the per-update breakage rate, and a scaling estimate.

Audit before moving on: Confirm the week ran on a licensed instance with the user's approval, not against any third-party system. If the week was quiet by luck (no vendor update landed), say so and treat the update simulation as the maintainability evidence instead. Fail if the falsifier metric is not computed.

Step 7 — Validate against oracles and write the gap report

Goal: Deliver the arbitrage-versus-consulting verdict with the legal basis and gaps.

Run the oracle pass:
(a) Per-action reliability: the 50-run success rate against the threshold.
(b) The vendor-update simulation result per action.
(c) The real-week error count through the MCP server.
(d) The legal-basis sheet, reviewed against the license and the interoperability exception.
(e) The falsifier: is breakage more than once per vendor update per month? If so, state plainly this is a consulting engagement priced hourly, not an arbitrage priced as a flat 'we run it for you' service.
Write report.md with the sections Authorization, Actions, Reliability, Maintenance, Verdict and Gaps. State which actions are robust (API/file-backed) and which are fragile (UI-backed), and whether the wrapper is worth selling as a service. Rank the gaps by impact on reliability and legal exposure.

Expect: report.md, a five-row oracle table, and a ranked gap list.

Audit before moving on: Any 'robust' claim without a 50-run number is downgraded. Any action without a legal basis is flagged, not shipped. Confirm the report never claims a right to automate software the user is not licensed for. Fail if the Verdict does not state the falsifier result.

4 · Gap analysis and audit

Run this after the build. It makes the agent enumerate its own claims, mark what is verified, rank the gaps and fix the top ones.

You are an independent reviewer: an integration engineer plus someone who reads licenses. Open report.md, authorization.md, actions.md, cli/, mcp/, reliability.csv and maintenance.md.
1. First, confirm authorization: does authorization.md quote clauses permitting the automation, for licensed software? Any action lacking a legal basis is flagged and treated as not shippable.
2. Enumerate every claim (per-action reliability, update-survival, maintenance rate, interop tiers) and mark each verified, unverified or false. Recompute the reliability numbers from the 50-run logs and check they match the report.
4. Check the interop tiers: is any action using UI automation when a documented API or file format existed?
5. Confirm no write action is exposed via MCP without a confirmation gate, and no credential value appears in logs.
6. Check the falsifier metric: breakages per vendor update per month, computed from the real week plus the simulation.
7. Confirm nothing targets a third-party system or defeats an access control protecting others' data.
8. Rank the gaps by reliability and legal exposure, fix the top three, and report what you could not fix.
Return audit.md with the columns claim, status, evidence and fix, plus 'Remaining gaps' and an A-F grade on whether the wrapper is a sellable arbitrage.

Questions the agent must ask itself before it says done:

5 · What proves it right

6 · Failure modes

7 · Agent direction (unattended runs)

Authorization is the gate: do not write a line of wrapper code until authorization.md quotes clauses permitting the automation on software the user is licensed to use. Probe each action's interfaces in order of stability and record the tier, because the UI-automation count predicts the whole maintenance story. Cache the tool's documentation and export samples under refs/ so re-runs do not re-probe it. Keep the CLI and MCP server as separate layers, isolating UI-automation actions. Run reliability and the real-week tasks only on a sandbox or the user's own licensed instance, never against a third-party system, and never defeat an access control protecting other parties' data. Stop and ask the human if authorization for any action is unclear or if the only available path would require that. Return authorization.md, actions.md, cli/, mcp/, reliability.csv, maintenance.md, report.md and audit.md. The final message states the per-action reliability, the update-survival result, and the arbitrage-versus-consulting verdict.

Prompt system updated 2026-10-22 · all prompt systems · JSON

Browse more deep dives at DejaViewed — 846 entries across the full catalog.

Generated 2026-10-22 · curated by @6ab3 for DejaViewed