We’ve all seen AI Slop—the generic, low-effort filler text and hallucinated code generated by LLMs. But slop is passive. Slop is just low-quality output sitting quietly in a corner.
There’s a much more specific, active form of chaos happening in engineering workflows right now: AI Tadka.
When we try to improve a workflow using AI but end up with a hot mess, we call it AI Tadka
While AI Slop describes low-quality output, AI Tadka describes the organizational friction created when that output is unnecessarily applied to functional, real-world engineering work. It’s a 3-page design document swelling into a 30-page monster. It’s writing tests that test absolutely nothing. It’s PR reviews judging code against non-existent requirements, causing developers to fight over ghost issues.
LLMs don’t care about writing or reading 30 pages. But human engineering teams don’t operate on unlimited context windows—we operate on cognitive bandwidth.
I coined the term AI Tadka to give this exact workflow friction a name.
What is AI Tadka?
In Indian cooking, tadka (tempering) is the technique of adding hot oil and spices at the end of a dish to elevate its flavor. Done right, it adds precision and aroma. Done wrong, someone dumps a frying pan of burning oil into a delicate soup, overpowering every real ingredient and leaving behind an inedible, greasy mess.
AI Tadka (noun)
The unnecessary complexity, noise, and organizational friction introduced when AI-generated additions are applied to otherwise functional engineering work—a design doc, a PR, a test suite, or an architecture plan—without sufficient judgment or context.
The Core Dimensions of AI Tadka
AI Tadka sneaks into every stage of a sprint. Here is how it actively corrodes engineering velocity:
1. Old Wine in a New Bottle (Resurrecting Dead Debates)
AI frequently ignores your team’s established design language and prior consensus. Because LLM generation is probabilistic, it rephrases old concepts with shiny new terminology. Settled debates are dragged back into the light, forcing the team to waste hours re-arguing topics they resolved months ago simply because the AI packaged old ideas in new words.
2. Erasing Implicit Context & “30-Page Swell”
AI doesn’t understand the tacit agreements you share with your teammates. If your team knows a service uses a standard Strategy Pattern, you don’t need five pages explaining basic Object-Oriented principles. AI doesn’t know what not to write. It spells out the blindingly obvious, swelling a 3-page RFC into a 30-page slog that everyone must now read just to ensure no critical requirements were altered.
3. Tests That Test Nothing
One of the worst manifestations of AI Tadka is test suite pollution. AI generates dozens of boilerplate unit tests that assert trivial truths, mock away actual logic, or test implementation details rather than behavior. These tests test nothing, but they eat up the mental bandwidth of maintainers, slow down PR reviewers, and burn CI/CD test runner build time.
4. Fabricated PR Friction & Ghost Requirements
When AI is used to review PRs or generate feedback, it frequently invents standards that were never required, raises non-existent edge cases, and flags “bugs” that cannot mathematically exist in your runtime. Developers end up fighting over comments generated by a model that doesn’t understand the system’s actual constraints.
5. Premature Optimization Over Business Impact
An AI reviewing a design doc might spot a non-critical utility and suggest optimizing it. Because generating text for that optimization costs the prompt author zero effort, it gets tacked onto the spec. A low-value task enters the official sprint plan, completely detached from actual business impact.
6. The Illusion of Competence (Stunted Developer Growth)
AI Tadka creates a dangerous psychological trap where volume and polish are mistaken for understanding. It leads engineers to believe they deeply understand a topic simply because an LLM generated 20 pages of authoritative-sounding prose on it. By outsourcing critical thinking, architectural trade-offs, and original problem-solving, developers skip the uncomfortable learning phase—quietly robbing themselves of the growth opportunities that build true technical seniority.
AI Slop vs. AI Tadka
| Feature | AI Slop | AI Tadka |
|---|---|---|
| Focus | The bad output itself | The downstream workflow friction |
| Origin | Generated from scratch | Applied as “seasoning” to existing work |
| Intent | Low-effort content creation | Attempting to “polish,” “test,” or “improve” |
| Manifestation | Text fluff, raw hallucinations | Bloated docs, useless tests, pedantic PR comments |
| Primary Victim | The reader’s patience | Team bandwidth, CI runners, and sprint velocity |
The Silent Tax
The true cost of AI Tadka is paid in human energy: the mental capacity of developers, tech leads, and reviewers who are forced to filter signal from noise, run bloated CI pipelines, and defend valid code against hallucinated critiques.
The Golden Rule to Avoid AI Tadka
Before hitting “Generate,” asking an AI to “add unit tests,” or asking it to “make this RFC more thorough,” ask yourself:
Am I adding actual value, or am I just dumping hot oil on a clean dish?
If a three-paragraph explanation works, keep it at three paragraphs. If five meaningful tests cover the logic, don’t generate fifty. Don’t let AI Tadka ruin good engineering work.