3 AI Myths That Put Power Market Software at Risk

There are a lot of myths and illusions when it comes to artificial intelligence (AI), as well as some healthy concerns. In our Summer Demand Series webinars and blogs, Alex Bennitt, product manager for Yes Energy, addressed how hyperscale data centers are really operating on the grid, based on real data. And the policies and practices surrounding AI usage and its boundaries are continuing to evolve.

But when it comes to how to build or implement AI in power market settings, three specific myths have taken root. They're persuasive because they feel true: AI does make a first version cheaper, a demo faster, and code more polished-looking. In the AI-era conversation about software development, these are particularly dangerous assumptions when applied to production-grade, domain-specific data and software in high-stakes trading environments.

Let’s take a closer look at three myths that put power market software at risk.

Myth #1: AI Makes Building Cheap

The first illusion is economic. AI dramatically lowers the cost of writing version 1.0 of a piece of software. It does not lower the cost of running version 7.0 five years later.

The evidence for this is no longer theoretical. GitClear's 2025 analysis of 211 million changed lines of code (drawn from repositories at Google, Microsoft, Meta, and other enterprise companies) found that AI-assisted development has driven a sharp rise in copy-paste coding and a steep decline in the kind of careful code restructuring that keeps systems maintainable over time. AI tools tend to generate code that solves the immediate problem by repeating patterns rather than building clean, reusable structures. That feels fast. But over time, it means the same fix must be applied in dozens of places instead of one, every update carries a higher risk of breaking something unexpected, and the system becomes progressively harder for anyone to understand or modify.

This pattern has a name: AI-induced technical debt. The code works. It passes initial tests. It ships. And then it compounds. Research from multiple independent sources puts maintenance costs for AI-generated codebases at four times traditional levels by year two. Gartner's projections are more severe: prompt-to-application approaches adopted by citizen developers will increase software defects by 2,500% by 2028. Practitioners are already reporting the same trajectory.

In GitLab's 2026 AI Accountability Report, a survey of more than 1,500 developers and technology buyers, 82% said AI-generated code risks creating a new kind of technical debt their organization is not prepared to manage, and 73% were concerned about its long-term maintainability.

The economic reality is this: the cost of software is not in writing it. It is in operating it. AI compresses the former. It amplifies the latter.

Myth #2: AI Makes Building Fast

The second illusion is about time. AI tools accelerate prototyping. A working demo can be produced in minutes. This creates a visceral sense that the production system cannot be far behind.

It is.

Google's DevOps Research and Assessment (DORA) program found that a 25% increase in AI adoption is associated with an estimated 1.5% decrease in delivery throughput and a 7.2% decrease in delivery stability, even as individual developers reported feeling more productive. The DORA team's explanation: AI makes it easy to write larger batches of code, and larger changesets are systematically riskier. More code enters the pipeline than reviewers can validate. Problems compound faster than teams can resolve them.

The perception gap is now measurable. In 2025, the research nonprofit METR ran a randomized controlled trial, the same method used to test drugs, on 16 experienced developers working across 246 real tasks in repositories they knew well. The developers expected AI to make them 24% faster. It made them 19% slower. Most telling, even after finishing, they still believed AI had sped them up by about 20%. The tools did not just fail to deliver the expected gain. They degraded performance while convincing skilled engineers of the opposite. In a domain where the cost of being confidently wrong is measured in P&L, a tool that makes people feel faster while making them slower is not a productivity aid. It is a risk.

But there is a deeper issue specific to power market data, and it has nothing to do with code quality. It is a domain expertise problem.

Power market data infrastructure requires knowledge that no AI model has been trained to reliably possess: how to anticipate the way each independent system operator (ISO)'s publication systems behave under various conditions; how to correctly handle the dozens of revision patterns across different data types; how to maintain vintage data integrity across market transitions; how to normalize naming conventions that differ not just between ISOs but between versions of the same ISO's systems over time; and how to handle the daylight saving edge cases that create data gaps in every market, every year, in slightly different ways.

Yes Energy's market monitoring team resolves approximately 200,000 ISO data reporting issues a year, from changed report formats to broken website links to failed data feeds, and has supported customers through every major market redesign since 2008. This includes ERCOT's real-time co-optimization launch, SPP's RTO expansion, and CAISO's EDAM and DAME rollout. A model trained on public documentation cannot replicate this kind of institutional continuity.

You do not solve these problems by writing better code. You solve them by operating a system continuously for years, accumulating institutional knowledge through every market transition, every ISO upgrade, and every edge case that surfaces once every few years at the worst possible moment. AI can generate a MISO data collector in a single prompt session. What it cannot generate is a decade of knowing how MISO behaves when it makes a system change.

The same gap appears at the analytics layers. Consider what it would take to build a bid submission tool that handles the submission rules, timing requirements, and validation logic across multiple ISO markets, and is built not for the market as it was designed, but as it operates today, with all the rule changes, format updates, and edge cases that have accumulated over years of real-world operation. AI can produce a form that posts data to an endpoint. Reproducing the years of iteration against real market rules, real regulatory changes, and real operator feedback that purpose-built software carries is another matter entirely. The gap between a working demo and a tool you would trust with a live bid is not a coding problem. It is an accumulated knowledge problem.

Myth #3: AI Makes Building Safe

The third illusion is about risk. Because AI-generated code often looks polished and passes basic functional tests, it can feel more reliable than it is. This is the deeper shift AI introduces. Output is up, and learning is down. Average work has become easier to produce and harder to evaluate, and the judgment required to tell a sound system from a plausible-looking one is exactly the judgment that comes from years of operational experience. AI can generate the output. It cannot supply the experience needed to know whether the output is right.

The people closest to these tools share the concern. As adoption has climbed, developer confidence has declined. Stack Overflow's 2025 survey found that even as AI tool usage rose to 84%, developers' positive sentiment fell to 60%, and their trust in the accuracy of AI output dropped to 33%. Adoption is being driven by competitive and organizational pressure, not by growing confidence that the output can be trusted unsupervised. That is the pattern to watch: the tools are spreading faster than the trust in them.

The security record of AI-generated applications bears this out. Veracode's 2025 GenAI Code Security Report tested more than 100 large language models across Java, Python, C#, and JavaScript and found that 45% of AI-generated code samples introduced Open Worldwide Application Security Project (OWASP) Top 10 security vulnerabilities. Security failure rates varied by language, with Java reaching 72%. Critically, security performance remained flat regardless of the model used, and newer models were no more secure than older ones. These are not sophisticated attack vectors. They are the failures that any systematic security review would catch, and that AI-assisted development systematically skips.

This risk is amplified when AI-generated tools sit at decision points rather than in data pipelines. A vibe-coded (built by prompting AI) dashboard used for position management, a quickly assembled submission interface, or an internally built risk reporting tool that bypasses proper access controls does not just risk data exposure; it risks operational failures at the moments that matter most. The governance and security characteristics of a tool used for live market decisions deserve the same scrutiny as the data that feeds it.

Lovable, an AI-assisted development platform, experienced two significant security incidents within a year of each other, representing the most documented public case study of vibe coding platform risk to date. In mid-2025, a security researcher found more than 170 production applications with fully accessible databases, exposing usernames, emails, phone numbers, payment records, API keys, and developer credentials to unauthenticated requests. Then, in April 2026, a separate backend regression made the chat history and source code of every public Lovable project accessible to any authenticated user with a project link; the exposure window ran undetected for 76 days. The platform's own post-incident statement acknowledged: "We see that we hadn't built the product safeguards, the communication muscle, or the security processes to match the trust our users placed in us."

Lovable is a consumer application builder, not a power market platform. But the failure mode it illustrates is not platform-specific. It is architectural. Applications built at speed, without institutional security review processes and without the governance frameworks that mature platforms embed by default, carry the same categories of risk regardless of what they are built to do.

In a trading environment where a single data integrity failure can cause material P&L impact, this risk profile is not acceptable. But the exposure extends beyond security vulnerabilities. Power market participants operate under a regulatory accountability structure that amplifies the cost of every failure.

For example, Federal Energy Regulatory Commission (FERC) reporting obligations, North American Electric Reliability Corporation (NERC) reliability standards, and state utility commission requirements create documented accountability for data accuracy, auditability, and system integrity. Settlement calculations must be reproducible. Position data must be traceable. Audit trails must survive scrutiny. These are not aspirational standards; they are enforceable obligations with financial and operational consequences.

A vibe-coded internal tool does not come with compliance certifications, access control frameworks, or data lineage documentation. It comes with whatever its builder thought to include under deadline pressure. This is not a hypothetical concern. In the same GitLab survey, 80% of organizations said they adopted AI coding tools faster than they built the policies to govern them. More pointedly, while most were confident they could trace whether AI-generated code had caused a production incident, a third of the organizations that actually suffered one in the past year could not make that determination when it mattered. Confidence in traceability and actual traceability are not the same thing, and the gap only becomes visible after something has already gone wrong.

In a regulated environment, the gap between "it works" and "it satisfies an auditor" is not a technical problem. It is an institutional one. Mature platforms embed governance by design. Internal builds inherit governance debt by default.

Leading technology investors classify commodity market software as structurally insulated from AI disruption because stringent regulation and compliance requirements raise the cost of failure so high that the speed of construction becomes irrelevant. What matters is whether the system can be trusted not just on day one, but on the day a regulator asks why a number looks the way it does.

Beyond the Myths: How Do You Decide What to Build vs. Buy?

AI's productivity gains are real, but they aren't the same thing as a sound infrastructure strategy.

Want help navigating AI decisions, including what you should build and what you should buy? Garrett Lodewyck, director of product, data delivery at Yes Energy, breaks down where the build vs. buy line actually sits across the five layers of your data and analytics stack — and where building genuinely creates competitive advantage.