What happens when your AI coding assistant can write the exact SQL query you need, injection-safe and parameterized, in seconds? Developer Maho Pacheco argues you stop reaching for an ORM - and that this pattern is quietly making a whole category of software libraries irrelevant.
The argument is straightforward: general-purpose libraries exist because writing things from scratch is slow and error-prone. ORMs (tools that translate between your code and database queries) save you from writing raw SQL. CSS frameworks like Bootstrap give you pre-built styles so you don't start from zero. Wrapper libraries smooth over clunky APIs. But AI coding agents like Claude and Copilot can now generate exactly the code you need for your specific situation, with no unused bloat tagging along.
The ORM Example
Pacheco's strongest case is against ORMs. These libraries have been a staple of web development for over a decade, abstracting away database queries behind object-oriented code. The tradeoff was always: you get convenience, but you lose control and carry the weight of a large dependency. Now, he argues, an AI agent writes the exact parameterized SQL you need without the abstraction layer. No learning curve for the ORM's API. No debugging the ORM's query optimizer. Just the query you actually wanted.
The same logic extends to CSS frameworks. Instead of importing all of Bootstrap and using 5% of it, an agent generates the minimal CSS for your specific layout. No unused classes. No framework upgrade headaches.
Where This Gets Interesting - MCP vs. CLI
Pacheco makes a more provocative claim about MCP (Model Context Protocol, the standard Anthropic created for connecting AI agents to external tools). He argues that CLI tools like GitHub's gh and Azure's az already have well-documented interfaces through their help pages and man pages. AI agents can read those docs and use the CLI directly, making dedicated MCP wrapper tools redundant.
This is a spicier take. MCP wrappers do add structured input/output that makes agent interactions more reliable. But his point stands that many MCP servers are thin wrappers around CLIs that agents could call directly. Microsoft's own dotnet/skills project uses plain-text prompts instead of protocol overhead, which lends some weight to the argument.
The Accountability Gap Nobody Wants to Talk About
To his credit, Pacheco doesn't just wave away the downsides. When a library breaks, there's a maintainer, an issue tracker, a community. When AI-generated code breaks, who's responsible? The person who prompted it? The model provider? The developer who shipped it without fully reviewing it?
This is the real tension. Libraries aren't just code bundles - they're maintained by humans who fix bugs, patch security holes, and handle edge cases you haven't thought of yet. AI-generated code gives you exactly what you asked for, but "what you asked for" and "what you actually need" aren't always the same thing.
Pacheco's blog post reads like it was written by someone who's genuinely building this way - he rebuilt his own blog from Hugo to .NET specifically to have full control over AI-generated code. That's conviction. But the argument works best for experienced developers who can review what the AI produces. A junior developer replacing a battle-tested ORM with AI-generated SQL is a different risk profile entirely.
The trend is real, though. Libraries aren't disappearing tomorrow, but the calculus of "build vs. import" is shifting. When generating custom code takes 30 seconds instead of 30 minutes, a lot of convenience libraries lose their reason to exist.