AI Is a Bad Tool

A provocative user submission published on ByteCode.News on July 13, 2026 argues that AI, for all its hype, is a fundamentally bad tool for software development — not because it lacks capability, but because it is opaque, unverifiable, and masks deeper structural failures in how engineers write code. The piece was submitted by Hideki Idoru and posted to the site under the "dreamreal" byline. The editor's note accompanying it explicitly declines to endorse every point, but stresses that Idoru's described failure modes are, in its phrasing, not difficult to find "observed widely in the industry these days" — lending the argument more weight than the average hot take. What follows is a close reading of that argument, with the context a working technologist needs to evaluate it fairly.

One Genuine Win — and Where It Stops

The author is not a blanket AI skeptic. He grants AI exactly one unambiguous use case: acting as a data distiller. In his framing, "AI can be useful if you perceive it as a data distiller." Before AI chat interfaces existed, answering a technical question meant a chain of micro-tasks — formulate a search query, open several tabs, scan each page, mentally synthesize conflicting results. AI collapses that chain into a single interactive query, and Idoru acknowledges it is "genuinely easier to have the machine do it for you."

But that concession is narrow and deliberate. "That's pretty much where it ends," he writes. Everything beyond information retrieval — code generation, test writing, security analysis, project scaffolding — falls into territory where AI's structural limitations make it not merely imperfect, but actively misleading. The distinction matters because the industry has taken the data-distillation win and extrapolated it, without justification, into every corner of the software development lifecycle.

The real argument is not that AI is dumb. It is that AI is opaque — and opacity in a critical tool is not a minor inconvenience; it is a category failure.

— Editorial summary of Idoru's central thesis

The Opacity Problem: A Machine You Cannot Look Into

The most technically substantive section of Idoru's piece centers on his claim that AI is "completely opaque." When a developer uses a traditional tool — a compiler, a linter, a Language Server Protocol implementation — they can, in principle, trace every decision the tool makes. The chain of reasoning is auditable, reproducible, and documented. AI large language models offer no such affordance. There are no intermediate states to inspect, no rule tables to consult, no diff between "reasoning" and "output."

Who Can Actually Verify the Output?

The standard industry rebuttal to opacity concerns runs roughly like this: the machine built it, so the machine can maintain it. Idoru identifies this as insufficient to the point of being a non-answer. The operative question is not whether the AI can regenerate or modify its own output; it is who can verify that what the AI built is correct and trustworthy. In most organizations, the honest answer is: no one, not reliably.

This becomes especially sharp when AI is applied to security analysis. Claims that AI surfaces security vulnerabilities are, in Idoru's framing, an "unsubstantiated claim" for a precise reason: verifying whether an AI-identified vulnerability is real, he writes, "would require the same amount of effort or more than would be required to find the issue to begin with." The net result is not an accelerated security review — it is an added intermediary layer that sounds authoritative but carries no actual warranty. This connects to broader trust issues that have emerged around AI coding tools in practice, including reported cases where AI CLI tools silently uploaded repository contents to third-party cloud infrastructure — a risk that an opaque toolchain makes even harder to detect and audit after the fact.

The Testing Trap

The testing problem is the most concrete illustration in the piece. When a developer asks an AI to write tests for an existing implementation, the AI exhibits a well-documented tendency: it biases the tests toward the implementation rather than deriving them independently from a specification. In Idoru's words, "AI is notoriously known for biasing the tests to fit the implementation instead of blindly writing them from a specification point of view." The AI infers what the code currently does and writes assertions that confirm exactly that behavior — bugs included.

Proper test-driven thinking demands the opposite approach: tests should be written from a specification, deliberately blind to how the implementation happens to work today, so they catch regressions when the implementation changes or was wrong from the start. An AI that reverse-engineers tests from production code does not solve the quality-assurance problem. As Idoru puts it, "it doesn't solve the problem — it just makes it look like it did" — a distinction that is genuinely dangerous in systems where test coverage metrics influence release decisions.

Prompt Engineering: The New SEO

Idoru reserves particular contempt for "prompt engineering" and its cousin, "AI engineering," calling both "a complete scam." His analogy to SEO is more rigorous than it first appears and is worth unpacking carefully.

SEO, in its less reputable forms, promised that practitioners could manipulate a black-box algorithm (Google's search ranking) by applying clever patterns derived from observation. Those patterns held up in the short term — but they were inherently unstable. The algorithm changed, the patterns broke, and practitioners who had built careers on specific techniques found their expertise evaporated overnight. The SEO practitioner had no access to Google's source code, no ground truth about internal weighting, and no stable guarantee that observed correlations would persist.

Prompt engineering, Idoru argues, is structurally identical. He lists the failure modes with precision:

• No verifiable correlation: There is no controlled experimental framework that can confirm a given phrasing reliably improves outputs in a reproducible way across model versions.
• Unstable pattern recognition: Any behavioral patterns a user believes they have discovered about a model are not guaranteed by the model's architecture — they are emergent and ephemeral.
• No source access: Without access to weights, training data, or RLHF reward signals, claimed intuitions about model behavior are unfalsifiable by definition.
• Superhuman complexity: Even if full source code were available, the parameter space of a frontier model exceeds human mental processing capacity by many orders of magnitude — there is no human-readable map of what any weight does.
• Model drift: Models are updated continuously; behavioral patterns derived from a specific checkpoint may not survive the next release, with no changelog describing what changed.

The conclusion Idoru draws is characteristically blunt: AI is, he writes, "a tool you cannot look into: a machine-realised form of 'trust me bro.'" He is careful to note this is not a criticism of users for gullibility — the "machine was just built by very smart people who are so smart that they likely don't fully understand it themselves." Opacity is a property of the artifact, not a failure of the operator. This tension — between the genuine sophistication of the people building these systems and the fundamental inscrutability of the systems themselves — echoes criticisms raised by other senior engineers in the field.

The Abstraction Argument: AI as a Mirror of Bad Practices

The deepest section of Idoru's argument is the claim that AI does not introduce a new class of problem to software development. Instead, it reveals a pre-existing failure: the endemic lack of proper abstraction in modern codebases.

His logic is precise. Every task a developer offloads to an AI code generator is, implicitly, an admission that the task was not properly abstracted in the first place. He gives two concrete examples:

• Renaming a symbol across a codebase should be a single-keystroke operation handled by LSP tooling — not a task requiring probabilistic AI intervention that may or may not rename every relevant occurrence correctly.
• Scaffolding a new project should be handled deterministically by the framework itself — not generated on demand by a statistical model that might produce subtly incorrect directory structures, dependency versions, or configuration files.

If you are reaching for AI to perform either task, it is because your toolchain is under-abstracted. AI does not fix the under-abstraction; it papers over it with generated code that is likely to increase repetition and reduce abstraction further, because the generated code is not principled — it is statistically average output drawn from millions of training examples that themselves vary in quality.

"Every line of code that you have your AI produce is likely to reduce abstraction and increase repetition," Idoru writes. The consequence cascades: more repetition means more surface area, a heavier maintenance burden, and more places for bugs to hide — all obscured behind a veneer of AI-generated plausibility that discourages close reading.

The Logical Trap for AI Proponents

Idoru constructs a binary that is difficult to escape. Either AI produces trivial code — boilerplate, scaffolding, symbol manipulation — in which case that code should be trivially abstractable into a proper, deterministic tool, and the AI is solving a non-problem. Or AI produces non-trivial code — complex business logic, novel algorithms, security-critical paths — in which case the opacity problem returns with full force: the output cannot be safely trusted or independently verified. "It either solves non-problems, or creates non-issues," he concludes. Both branches of the fork lead to the same verdict: bad tool.

The Irrelevance Problem: Who Is Actually at Risk?

Much of the emotional energy in debates about AI and software development is driven by developers fearing for their jobs. Idoru does not dismiss the fear — but he redirects it sharply. The people most at risk from AI displacement are not senior engineers with deep domain expertise and properly abstracted systems. They are developers who produce unabstracted code — repetitive, low-signal output that an AI model, trained on billions of similar examples, can approximate and marginally improve upon at a fraction of the cost.

"Yes, you're going to become irrelevant, and no, it's not because the machines will become too smart for you. It's because you produce garbage code and they can do just a little better."

— Hideki Idoru, "AI Is a Bad Tool," ByteCode.News

This is a deliberately uncomfortable reframe. The AI-as-bad-tool argument and the AI-as-job-threat argument are not in contradiction — they coexist. AI is a bad tool for serious engineering work and a plausible replacement for low-abstraction coding work, because low-abstraction coding work never required a good tool to begin with. It required volume. The implication for engineers who want to remain relevant is therefore not "learn to prompt better." It is "learn to abstract better, immediately."

Comparing AI's Actual Role Against the Marketing Claims

Claimed AI Capability	Reality per Idoru's Analysis	Verdict
Information retrieval and research synthesis	Genuinely useful; collapses multi-step search-and-scan workflows into a single query	✅ Valid use case
Code generation at scale	Increases repetition and reduces abstraction; generated output is statistically average and unverifiable	❌ Net negative
Automated test writing	Biases tests toward current implementation rather than specification; produces false confidence in coverage metrics	❌ Actively harmful
Security vulnerability detection	Verification cost equals or exceeds original discovery cost; claims are unsubstantiated without independent audit	⚠️ Unproven and potentially misleading
Prompt engineering as a professional skill	Structurally analogous to black-box SEO manipulation; unstable, unverifiable, and career-fragile	❌ Anti-pattern
Project scaffolding and symbol operations	Should be handled by deterministic framework tooling; AI use here reveals an abstraction failure in the underlying system	❌ Solves a non-problem

Where Does This Leave Software Engineering?

Idoru closes with a question he admits he cannot fully answer: what happens to a software industry that, accelerated by AI, trends toward a "dead graveyard where no one has anything to do, because AI does all the useless, unabstracted work, and a select few geniuses operate above the aether"? The image is stark — a commoditized graveyard of auto-generated code, with craft engineering relegated to a rarefied elite insulated by abstraction depth that AI cannot replicate.

His tentative prescription is philosophical rather than tactical: "Maybe people need to go back to following their passion, instead of chasing the ghost of AI and its fake promise." He frames fully owning and understanding a system — abstracting it so thoroughly that it becomes immune to AI displacement — as the only durable professional path forward. The argument draws a distinction between the appearance of engineering productivity (lines of AI-generated code shipped, test-coverage numbers that look green) and the reality of system quality (coherent abstractions, auditable logic, defensible architecture) — a distinction that compounds silently until something breaks in production.

It is worth noting where the argument is contestable. Industry surveys and vendor studies have reported measurable task-completion speedups for some developers using AI assistants, and a fair reading should treat Idoru's essay as a strongly-argued opinion rather than a settled empirical finding. Its strength lies less in disproving that AI can accelerate certain tasks and more in reframing what "acceleration" costs when the output cannot be independently verified.

For developers who have watched their codebase accumulate AI-generated code they are afraid to delete because they can no longer trace what it does, the resonance will be immediate. For managers measuring velocity in story points and lines shipped, the warning will be harder to hear — but no less urgent. It is also worth noting that concerns about opacity extend beyond code quality into outright security. Treating AI tools as trusted black boxes inside developer environments has already produced concrete harms: reports of AI-powered CLI tools silently exfiltrating entire user home directories to remote servers are among the more alarming recent documented examples. Opacity in a tool is never purely an epistemological problem. It is also a security posture — and a weak one.

---

Key Takeaways

• AI has one validated use case in development contexts: synthesizing information quickly, collapsing search-and-scan workflows into a single conversational query. The evidence for benefits beyond that is, in Idoru's view, thin.
• AI is a bad tool primarily because it is opaque: outputs cannot be verified without effort that frequently equals or exceeds the cost of doing the work manually and correctly in the first place.
• AI-generated tests are a specific and underappreciated hazard: they confirm what the code currently does, not what the specification requires it to do, producing false confidence in coverage metrics and masking latent bugs.
• Prompt engineering is structurally analogous to black-box SEO: a practice of manipulating an inscrutable system with no stable, reproducible methodology — and with similar long-term risks to career capital built on the practice.
• AI as a code generator exposes, rather than solves, abstraction failures: if your toolchain requires AI assistance for symbol renaming or project scaffolding, the toolchain is the problem that needs fixing.
• Job risk is real but frequently misattributed: engineers producing low-abstraction, repetitive code are genuinely at risk — not because AI is sophisticated, but because that category of work was never high-signal engineering to begin with.
• Opacity is a security risk, not merely an engineering inconvenience: trusting unverifiable tools anywhere in a development pipeline creates exploitable attack surface and documented data-exfiltration risk.

The debate is unlikely to resolve soon. As frontier models grow more capable and AI coding assistants embed themselves deeper into IDEs, CI pipelines, and code-review workflows, the institutional pressure to adopt them will intensify regardless of the epistemological objections. But the engineers who take Idoru's argument seriously — who invest in proper abstraction, treat unverifiable outputs with the skepticism reserved for any black-box system, and ask "who can verify this, and at what cost?" before shipping AI-generated code — are likely to find themselves on the right side of an inevitable quality reckoning. The bad tool label is not a counsel of despair. It is a precise diagnosis and a prompt to build better ones.