Why Standard Software Still Matters in the AI Era | ECI Research

/ AI, Application Development, Automation, DevOps, Platform Engineering

The News

In a recent long-form essay, anynines CEO Julian Fischer makes the case that AI-generated software will not displace standard software products but will instead expose which ones contain genuine accumulated domain knowledge and which ones do not. Fischer argues that large language models produce plausible code by compressing patterns already created by human expertise, product teams, and open-source communities, meaning AI is a consumer of the software knowledge ecosystem rather than a replacement for it. The essay uses anynines’ own transition from Cloud Foundry-based managed data services toward Kubernetes-native offerings like Klutch and a9s Hub as a concrete illustration of how responsible software stewardship works in practice.

Analyst Take

Fischer’s argument deserves a serious read, not because anynines is a household name, but because the structural logic holds up under pressure. The core claim is this: what looks like a product is actually a body of judgment. The login screen and the API are the visible layer. The real value is underneath, in the failure modes that have been discovered, the defaults that have been shaped by hundreds of production deployments, the upgrade paths that don’t corrupt data, and the commercial accountability that exists when something breaks at 3am. That is what AI cannot yet regenerate from a prompt, and it is the right frame for evaluating which software categories are genuinely threatened by AI-assisted development and which are not.

The Innovation Time Problem

The practical tension Fischer identifies maps cleanly onto something ECI Research has measured directly. According to ECI Research’s 2026 Application Development survey, 65.2% of respondents selected “0–20” when asked what percentage of engineering time is spent on net-new innovation. Most engineering capacity is consumed by maintenance, toil, and operational overhead, not by building new things. This is precisely the environment in which the promise of AI-generated software is most seductive: if your team is buried in keeping the lights on, the idea of prompting a working prototype into existence sounds like relief. But Fischer’s point is that building a prototype is not the same as running a production system. The prototype doesn’t come with a restore procedure, a compliance audit trail, or a support contract. The relief is real but partial, and organizations that mistake the prototype for the product will eventually discover the rest of the iceberg.

The Governance Signal

The broader market data supports Fischer’s framing on the demand side, too. ECI Research’s 2026 Application Development survey found that 47.4% of respondents selected “Software supply chain security” as a top investment priority for the next 12 months, placing it second only to AI-enabled development tools. That’s a striking juxtaposition: organizations are simultaneously excited about AI-assisted development and worried about the security implications of the code it produces. In fact, ECI Research also found that 45.3% of respondents said AI-assisted development has “increased risk moderately,” with another 17.2% saying it has “increased risk significantly.” When you add those figures together, nearly two-thirds of practitioners believe AI coding tools have made their security posture worse or meaningfully more complicated. That finding directly validates Fischer’s argument that AI does not eliminate the need for productized security discipline; it increases it.

What This Means for ITDMs and Developers Alike

For IT decision-makers, the implication is straightforward. The right question to ask about any AI-generated or AI-assisted solution is not “can it be built?” but “who is accountable for running it, securing it, upgrading it, and remediating it when it fails?” Standard software from a mature vendor answers those questions through commercial structure. An internally generated tool typically does not, and the hidden cost of that gap tends to surface at the worst possible moment. For developers, Fischer’s essay is a useful corrective to the framing that “vibe coding” is a complete substitute for production engineering. Generating a working prototype proves a concept; it does not prove an operating model. The Klutch and a9s Hub story is instructive here: the product value is not the YAML abstraction or the control-plane scaffold. It’s the governance layer that lets application teams move fast without platform teams losing visibility or control. That is a harder problem than generating the scaffold, and it is still a human problem.

Looking Ahead

The software market is about to undergo a meaningful sorting. Products with thin domain value, poor APIs, and weak operational depth will face genuine pressure from AI-assisted alternatives, and they should. Fischer is right that AI will raise the bar for standard software, not lower the demand for it. Vendors that can demonstrate accumulated knowledge, production-grade lifecycle management, and genuine commercial accountability will find their differentiation easier to articulate, not harder. Those that cannot will increasingly struggle to justify their pricing against what a capable team with good AI tooling can generate in a week.

The deeper risk Fischer identifies, the cannibalization of the knowledge ecosystem that AI depends on, is a longer-cycle problem but not a distant one. If commercial software companies cannot fund deep productization work, and if open-source maintainers cannot sustain communities, the training inputs that make AI useful begin to thin. That’s a systemic risk that no single vendor can solve, but the industry should watch it carefully. anynines’ posture, building products that reduce duplication, preserve operational truth, and keep accountability clear, is not a niche philosophy. In an AI-saturated market, it may turn out to be the most defensible product strategy available.

Author