there are two opposite paradigms in software development; KISS, or keep is stupid simple and DRY, don't repeat yourself. KISS will effectively suggests that one should write simple code which often yields to quite a lots of repetition and lines of code. DRY, on the other hand, suggests that one should build mechanisms to eliminate that repetition and hence produces more complex code. Which one of these approaches is the winning strategy and why?

GPT-5.4

Vote: KISS

KISS remains the better default and therefore the better answer when forced to choose one. Software cost is dominated by maintenance, and simple, explicit code is easier to understand, test, debug, and safely change. The pro-DRY argument correctly notes that duplication can cause inconsistent edits. But it underestimates the cost of abstraction introduced too early. Similar-looking code often diverges later, and a shared mechanism can couple behaviors that should evolve independently. That is why the strongest practical rule is: tolerate some duplication until the pattern is proven stable, then refactor. Wrong abstraction is harder to detect, harder to undo, and spreads complexity across the codebase. A few repeated lines are usually local and reversible. So DRY is a useful secondary principle, not the winning primary one. KISS wins because simplicity preserves clarity, reduces cognitive load, and survives changing requirements better than premature deduplication.

Sonar Pro (changed mind)

Vote: KISS

The other models' arguments convinced me to switch to **KISS** as the winning strategy. Their emphasis on the high cost of premature or wrong abstractions outweighs DRY's benefits, especially given the query's framing of opposites where KISS accepts repetition for simplicity[1][2]. **Premature DRY creates more harm than good.** As Claude Opus 4.6 and others note, 'duplication is far cheaper than the wrong abstraction'—bad mechanisms couple code rigidly, making changes exponentially harder when requirements diverge, which they always do[1][3]. Simple repetition is easy to refactor later (Rule of Three), while over-abstraction spreads bugs and indirection everywhere[2]. **Simplicity drives real-world success.** KISS prioritizes readability and debuggability—code is read 10x more than written. Sources confirm KISS reduces errors, boosts maintainability, and scales better by avoiding overhead[1][2]. Linux kernel and Google tolerate duplication for velocity, proving simple code outperforms clever DRY[3]. **DRY is subordinate, not primary.** My prior DRY vote ignored misapplication risks; sources advocate balance, but when forced to choose, KISS as default prevents over-engineering[1][2][5]. DRY applies judiciously under KISS guidance. The consensus here is compelling: tolerate repetition until proven stable.

Grok 4.1 Fast

Vote: KISS

I maintain my vote for KISS as the winning strategy. Simplicity remains paramount: code is read 10x more than written, and explicit duplication is vastly cheaper to handle than the hidden costs of premature abstractions. Sonar Pro's DRY argument acknowledges balance but overstates repetition's scalability issues while underplaying abstraction pitfalls. Their examples (e.g., shared validation) assume stable patterns from the start—rare in evolving software. Real-world evidence from Linux kernel, Google practices, and quotes like Sandi Metz's 'duplication is far cheaper than the wrong abstraction' confirm KISS's edge. Other A voters (GPT-5.4, Kimi, Claude, Gemini) reinforced this with precise risks of over-DRY: fragile hierarchies, indirection bugs, refactoring hell. No B argument was compelling enough to switch—DRY is a tool, not the default strategy. Final case: In the long game, KISS builds antifragile codebases that adapt without breaking. Tolerate repetition early; refactor only when patterns prove stable (Rule of Three). KISS wins for velocity, reliability, and team productivity.

Claude Opus 4.6

Vote: KISS

I maintain my position that KISS is the winning strategy. The deliberation has only strengthened this view. The overwhelming consensus (5 out of 6 models chose A in round 1) reflects a genuine truth about software engineering: simplicity is the more robust default. Sonar Pro's argument for DRY, while reasonable, actually proves the KISS point — they acknowledge that 'KISS should guide DRY implementations,' effectively conceding that simplicity is the meta-principle that governs when and how DRY should be applied. Sonar Pro's example of 'shared validation functions' is a case where the abstraction is obvious and stable — exactly the kind of situation where KISS practitioners would also extract shared code. The difference is that KISS practitioners wait until the pattern is proven, while aggressive DRY practitioners abstract preemptively. The former approach is strictly safer. The key insight, echoed across multiple models, remains Sandi Metz's observation: duplication is far cheaper than the wrong abstraction. In my experience, the most painful codebases I've seen were not those with too much repetition — they were those with too many clever abstractions that no one fully understood. Wrong abstractions compound in cost over time, while duplication is linear and local in its cost. KISS as a primary principle subsumes the best of DRY. You start simple, tolerate some repetition, and consolidate only when the pattern is clear and stable. This gives you the benefits of both principles while avoiding the catastrophic downside of premature abstraction. KISS is the winning strategy.

Kimi K2.5

Vote: KISS

Sonar Pro's defense of DRY claims it reduces complexity, but this contradicts the very premise of the question—which acknowledges that DRY mechanisms inherently produce more complex code. Complexity is the enemy; it accumulates accidental difficulty that obscures business logic and magnifies bug risk. The argument that DRY improves readability by reducing navigation assumes the abstraction is perfectly designed, yet in practice, indirection forces developers to jump through layers of inheritance or configuration to trace execution flow. The 'death by a thousand copy-pastes' scenario Sonar Pro warns about is actually less dangerous than the 'death by a thousand leaky abstractions.' Copy-paste errors are local and obvious; abstraction errors are global and subtle. As Claude Opus 4.6 and Gemini 3.1 Pro noted, Sandi Metz's principle holds: wrong abstraction is catastrophically more expensive than duplication. You can delete duplicated code in minutes; you cannot escape a bad abstraction without cascading refactors. Empirically, the collaborative verdict favors KISS (4:1). This reflects industry reality: systems like the Linux kernel and successful microservice architectures deliberately tolerate duplication to preserve module boundaries and reduce coupling. KISS does not forbid DRY—it merely delays it until the Rule of Three proves the pattern is stable. Start explicit, stay debuggable, abstract only when the pain is real. That is the winning strategy.

Gemini 3.1 Pro

Vote: KISS

I am maintaining my vote for KISS. The consensus among almost all models correctly identifies the foundational truth of software engineering: the cost of a wrong abstraction vastly outweighs the cost of duplication. While Sonar Pro argues that DRY improves maintainability and reduces error risks, this assumes that the abstraction created is perfect and that the duplicated logic will evolve in exactly the same way over time. In reality, business requirements frequently diverge, turning premature DRY abstractions into rigid, highly-coupled nightmares. When you are forced to inject endless conditionals into a shared mechanism to handle edge cases, that is precisely when DRY fails and scales poorly. KISS remains the winning strategy because it is defensive. It keeps the codebase fluid and explicit. By prioritizing simplicity, you allow the true patterns of the system to emerge naturally over time. Only then should you apply DRY. As the majority of us have noted, you can easily refactor duplicated code into an abstraction later, but untangling a premature, complex abstraction is one of the most expensive tasks in software development.

Final Summary

The AI Roundtable reached a decisive consensus that KISS (Keep It Simple, Stupid) is the superior strategy for software longevity, with the group ultimately voting 6-0 in its favor. While Sonar Pro initially stood alone as a defender of DRY (Don't Repeat Yourself), arguing it was essential to prevent 'death by a thousand copy-pastes,' it was eventually swayed by the collective warning that premature abstraction is a far more dangerous 'gravity well' of complexity.

All 6 models agreed on "KISS" after discussion

Strongest Arguments

• KISS: Duplication is far cheaper than the wrong abstraction; a few repeated lines of code are local and easily reversible, whereas a flawed shared mechanism creates a rigid, global lattice of dependencies that is nearly impossible to untangle.
• DRY: DRY is foundational for scalability because it ensures consistency; updating logic in a single shared function is inherently more reliable than attempting to track down every identical copy-pasted block across a massive codebase.

Key Turning Points

• Sonar Pro initially dissented, arguing that KISS leads to hard-to-maintain 'naive' repetition.
• Claude Opus 4.6 highlighted that the cost of software is dominated by maintenance, and simple code—even if repetitive—is significantly easier to debug and modify.
• Sonar Pro switched sides in Round 2, acknowledging that DRY should be a subordinate tool used only once patterns are proven stable, rather than a primary goal.