Agent-Native Design

Designing tools, docs, APIs and platforms with AI agents as first-class consumers — scriptable, deterministic, token-lean, machine-readable.

Also known as: agent-native, agent-friendly, Agent-friendly, agent experience, developer experience / agent experience, Agentic Engine Optimization (AEO), AEO, llms.txt, machine-friendly interface, AI agent readiness, capability signaling, Agentic IDE, programming language for agents, programmable environment, first-class surface

Agent-Oriented Programming Languages

How authors use it

Oldest first (extraction date when no publication date is known).

AuthorTheir termTheir meaning
10 Things Developers Want from their Agentic IDEs in 2025
Kate Holterhoff (RedMonk) · 2025-12-22		Agentic IDEAn environment (not merely an assistant) in which agents reason about an entire codebase, modify multiple files, run terminal commands, execute tests, and iterate on feedback — while the developer works on something else entirely. The author's deliberate replacement for her prior term 'AI Code Assistants,' marking a shift from passive suggestion to autonomous execution.
The Future Of Software Engineering
Thoughtworks · 2026-02		agent experienceA deliberate reframing of 'developer experience' — investing in conditions that help agents perform well, which largely overlap with conditions that help humans perform well, but with better budget justification
GitHub Copilot CLI Reaches General Availability
Mark Silvester · 2026-04		first-class surfaceThe terminal treated as a primary venue for AI-assisted development, not a secondary integration point.
Martin Fowler & Kent Beck: Frameworks for reinventing software, again and again
The Pragmatic Engineer · 2026-04-07		developer experience / agent experienceFowler's claim that what makes code good for human developers (modular, well-tested, clear domain language) is exactly what makes it good for AI agents — the two are a single circle, not two overlapping ones
Agentic Engine Optimization (AEO)
Addy Osmani · 2026-04-10		Agentic Engine Optimization (AEO)The discipline of structuring, formatting, and serving technical content so AI coding agents can discover, parse, and reason over it effectively.
Agentic Engine Optimization (AEO)
Addy Osmani · 2026-04-10		llms.txtA Markdown-formatted sitemap hosted at a domain root that provides AI agents with a structured, token-efficient index of documentation.
Agentic Engine Optimization (AEO)
Addy Osmani · 2026-04-10		capability signalingDocumentation that tells agents what an API does and can accomplish, as opposed to merely how to call it.
Google Brings MCP Support to Colab, Enabling Cloud Execution for AI Agents
Robert Krzaczyński · 2026-04-15		programmable environmentColab exposed not as a UI for humans but as an API surface for agents — notebooks as programmatic artifacts rather than interactive documents
Generative AI in the Real World: Aishwarya Naresh Reganti on Making AI Work in Production
Ben Lorica and Aishwarya Naresh Reganti · 2026-04-16		agent-native
Hugging Face's Clem Delangue: Stop Comparing Engines to Cars
Turing Post (Ksenia Se interviewing Clem Delangue) · 2026-05-02		agent-nativeDesigned from the ground up for AI agents as first-class users, not just humans. Implies CLIs, clean APIs, efficient docs, low token overhead.
With Android CLI, Google is Making the Android Toolchain Agent-Friendly
Sergio De Simone · 2026-05-21		Agent-friendlyA toolchain surface designed for an LLM agent to consume as its primary user — scriptable, deterministic, low-token, machine-readable — as opposed to a GUI optimized for a human
With Android CLI, Google is Making the Android Toolchain Agent-Friendly
Sergio De Simone · 2026-05-21		Machine-friendly interfaceAn interface whose output is structured and stable enough that an LLM does not have to spend tokens parsing it
This Week's Best Developer Tools & Betas
Console · 2026-05-21		Agentic IDEAn IDE that combines a code editor with a CLI and an explicit 'agent management console' for tracking multiple concurrent agent sessions and subagents, plus support for skills, MCPs, hooks, and scheduled tasks (e.g. dependency updates).
This Week's Best Developer Tools & Betas
Console · 2026-05-21		Programming language for agentsA language whose primary design target is code that LLM-based agents write or execute, not human authors (Zero).
This Week's Best Developer Tools & Betas
Console · 2026-05-21		AI agent readinessA property of a website (per AgentGrade) measuring how well it can be navigated or consumed by AI agents acting on a user's behalf, summarized as a gradeable score.
How we Claude Code
Claude · 2026-05-22		Agent-native (make it available to the agent first)Designing an artifact (here, a UI component) so its state is directly machine-readable — published into the DOM as data attributes — rather than requiring an agent to infer state by scraping the rendered UI or reaching into framework internals.
Finding Comfort in the Uncertainty
Annie Vella · 2026-07-07		Agent ExperienceInvestment in the conditions that make agents effective (clear standards, good documentation, well-structured code) — the same conditions that made developers effective, hence possibly 'the new DevEx'

Documents (26)

Propositions touching this concept (10)

By publication month, oldest first (extraction month when no publication date is known).

2026-02

2026-04

2026-05

2026-07

Tensions

How much of the build pipeline should run with no human reading the code (the 'dark factory')?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: Not simple optimism vs pessimism but a disagreement about preconditions and hidden costs. Ocytko's is a projection of where tooling is heading; Bangser and Verraes both supply reasons the projection is unsafe by default — learning-loss and missing prerequisites. Bangser has the stronger argument that the loss is structural (you cannot buy back organisational learning), which even an improving platform does not address.
How far can day-2 operations be handed to self-healing / autonomous remediation?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: Ruby's report is descriptive (where practice actually stands) and Ocytko's is aspirational (where platforms could go); the gap between 'remediation is withheld' and 'failure modes disappear' is precisely the distance the optimists are projecting across. Bangser supplies the reason the gap may not close on efficiency grounds alone — the withheld human step is also the learning step.
Is the value question genuinely settled by evidence, or does uncertainty and sampling bias still dominate?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: The single sharpest divergence, and it sits directly under the headline whether-to-how convergence: they narrate the same shift but disagree on what it establishes. Edwards-Alexander and Herlein read the room's confidence as evidence; Vella and Ruby read the same room as a self-selected in-group. Ruby has the better of it methodologically — he is the only one to interrogate the sample and to notice the evidence is asymmetric (upside anecdotal, downside studied), which is uncomfortable precisely because the cohort's confidence is built on the weaker side.
If code is no longer the bottleneck, what is the new binding constraint?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: They agree code/delivery has ceased to be the constraint but name three different successors, with different investment implications — expand decision-making capacity (Vella), optimise for learning (Edwards-Alexander), or capture tacit knowledge (Herlein). These are complementary in principle but rivalrous for attention and budget; the disagreement matters because each implies a different 'first thing to fix.'
Where is the locus of safety for non-engineers / citizen developers building software?
from: What did the participants of the Thoughtworks 'Future of Software Engineering' Europe retreat (mid-2026) conclude about how agentic AI is reshaping software engineering?
Assessment: Four different answers to the same governance question: the platform (Ocytko), the director's discipline (Ruby), the tooling interface (Bangser), or nobody-knows-yet (Ördög). Ruby and Ocytko are the true opposites — Ruby puts the burden on a human management skill, Ocytko designs the human out by making failure modes disappear in the platform. That both are held by attendees of one retreat is a measure of how unsettled the citizen-developer problem is.
Is the model a swappable, commoditized component (so selection is a cost decision), or is model choice load-bearing (so selection is a capability decision)?
from: When working with AI coding agents, how should you select the model, its reasoning/effort level, and its context size for a given task?
Assessment: Both camps are right about different task strata, and the tie is broken by the routing camp's own artifact. Commoditization holds on the bulk/background tier (musistudio and the Pragmatic Engineer are correct that a cheap or open model suffices for a large share of tokens), but model choice is load-bearing exactly on the hard tier — the 'hardest 40%' the routing camp routes AWAY (the Pragmatic Engineer's own gap notes 60%-of-token-spend is not 60%-of-value). nrehiew's 6.5x over-editing spread and stellaraccident's collapse are measured on precisely that hard tier. The clincher the swap camp does not concede: musistudio's OWN per-model transformers (tooluse, enhancetool, reasoning, deepseek, gemini) prove the harness is NOT model-agnostic — every model needs bespoke request/response rewriting just to work behind Claude Code, so the 'any model' artifact self-refutes. Delangue even concedes the frontier gap himself. Verdict: select cheap-and-swappable for bulk, and treat the model as a load-bearing capability decision for the hardest slice — the two positions are not competitors but a partition of the task distribution.
Where does the non-delegable human asset now live — the harness/platform, the oracle, the fundamentals, or the developer's understanding?
from: What is the future of software development in the agentic/AI age?
Assessment: This is the deepest structural disagreement — every author agrees a human residue remains but nominates a different residue, and the choice determines what to invest in and what to teach. The harness-centric (Edwards-Alexander), oracle-centric (Ruby), fundamentals-centric (Nilsson/Bangser), and understanding-centric (Fowler) camps are not merely emphases: they imply different career ladders, different hiring, and different failure modes. Ruby's oracle and Bangser's operational-learning are the most operationally concrete; Nilsson's is the least argued. The absence in the corpus of anyone who holds 'nothing is non-delegable' is itself telling (see unexamined assumptions).
Should the harness/platform and its safety be centralized or left distributed across teams?
from: What is the future of software development in the agentic/AI age?
Assessment: A real operating-model split. Edwards-Alexander's distributed stance rests almost entirely on the DevOps-team analogy (his own extraction flags it as asserted-on-intuition, not argued), whereas the platform camp has the stronger concrete case for the citizen-developer safety problem — you cannot distribute production-data guardrails to non-engineers. The tension is partly reconcilable: Ocytko himself concedes a platform tight enough for non-engineers may be too constraining for expert engineers' identity and innovation, which is exactly the freedom Edwards-Alexander is protecting. The unresolved question is whether one platform can be both.
How far should software be automated — toward the fully-autonomous dark/software factory, or held back to bounded autonomy with humans in the loop?
from: What is the future of software development in the agentic/AI age?
Assessment: The spectrum runs from Ördög/Ocytko (full automation is arriving and desirable) to Bangser/Ruby/Verraes (deliberately withhold the last step). The decelerationists have the better of the safety argument today — Ruby's 'nobody will cede the blast radius' and Bangser's 'removing humans removes learning' identify concrete, unmet prerequisites — but Ördög's context-dependence (backends, COBOL) shows the boundary is domain-specific, not absolute. The real disagreement is less about capability than about who absorbs the blast radius when an autonomous fix goes wrong.
Does the current evidence favor optimism or doubt about agentic engineering's payoff?
from: What is the future of software development in the agentic/AI age?
Assessment: The sharpest divergence in the corpus, because it is about the epistemic ground of every other claim. Nilsson's optimism is explicitly consensus-of-the-in-group and self-flagged as biased; Ruby and the Thoughtworks report both bring the only genuinely external evidence (DORA reversal, HBR intensification, outside surveys) — and it points the other way. On the current record, the skeptics have the stronger footing precisely because the optimistic case is methodologically weakest (a 'sample of one,' as Ruby says of his own best data). The whole cohort's cautious optimism may be an artifact of who was in the room.
Does AI adoption improve output and developer experience together, or do they decouple — with more output bought at the cost of the developers?
from: What is the future of software development in the agentic/AI age?
Assessment: This is the specific, evidence-bearing form of the optimism/pessimism split, and it cuts directly against any simple reading of 'DevEx = AgentEx' as good news. The harmony camp (Nilsson, Ördög) speaks from felt experience and in-group mood; the decoupling camp (Thoughtworks, Vella) and Fowler's own cited HBR study bring the harder data, and it shows output and wellbeing pulling apart. Notably Fowler holds both 'same-size teams do much more' and the burnout finding without resolving them — the single clearest internal contradiction in the corpus, and a sign the harmony framing is doing more reassuring than the evidence supports.
If code was never the bottleneck, what is the binding constraint now?
from: What is the future of software development in the agentic/AI age?
Assessment: A productive three-way split downstream of the shared 'code was never the bottleneck' finding. They are not incompatible so much as differently located — decision capacity (Vella) is organisational, learning (Edwards-Alexander) is about the team's rate of understanding the problem, and knowledge (Herlein) is about capturing rationale. But they imply different investments: expand downstream absorption, restructure around learning, or build knowledge-capture pipelines. The corpus has not reconciled which is the true binding constraint, and each author generalizes from a different vantage (a retreat-floor convergence, an org-design frame, a knowledge-engineering frame).
How should newly-empowered citizen developers be made safe — constrained platform, human stewardship, or supported API-first tooling?
from: What is the future of software development in the agentic/AI age?
Assessment: All three agree citizen developers are inevitable and must not be blocked, but the safety mechanism differs — encode it in a constraining platform (Ocytko), transfer it through human relationships (Laycock), or expose it as consumable interfaces (Bangser). Ocytko's platform-first case is strongest on the specific failure mode both he and Ördög name (non-engineers leaking or bypassing production-data access), which stewardship alone cannot prevent at scale. Laycock's stewardship answers a different problem — sustaining the junior-to-senior pipeline — that a platform does not. The positions are complementary in principle but compete for the same finite investment, and none supplies a concrete governance model for vibe-coded shadow IT.

Open gaps (66)