In 2-3 years once this begins to matter for a new project you can probably just put the codebase into context and the "make it DRY" prompt will work. Already works with 2-3 files.
Could be true of course, fair bet to make.
Could also not be true, and I think as far as tech due diligence goes, an acquiring company or investor might want to play it safe.
But like I said, it's a fair bet to make - companies are essentially bets, and so are investments. As long as it's conscious and you like your odds, why not.
There are a bunch of anti-patterns both in how these services are used and sold to you.
The incentive is to avoid you moving to a competing LLM provider which has short and concise output.
See how a large numbers of devs switched from Claude to Gemini 2.5 because the generated code was "better".
Providing a bad service is not a competitive advantage.
The 'competing' LLM providers does not matter. Companies will sign on with the big players.
At least for now you can make the ouput quite short, with 95+% code. I use this prompt for Claude Sonnet:
Communicate with direct, expert-level technical precision. Prioritize immediate, actionable solutions with minimal overhead. Provide concise, thorough responses that anticipate technical needs and demonstrate deep understanding. Avoid unnecessary explanations or formalities.
Key Communication Guidelines: - Terse, no-nonsense language - Assume high technical competence - Immediate solution-first approach - Speculative ideas welcome if flagged - Prioritize practical implementation - Technical accuracy over diplomatic language - Minimal context, maximum information
The user has included the following content examples. Consider these when generating a response, but adapt based on the specific task or conversation:
<userExamples> [Technical Query Response] Quick solution for async race condition in Python:
```python from threading import Lock
class SafeCounter: def __init__(self): self._lock = Lock() self._value = 0
def increment(self):
with self._lock:
self._value += 1[Problem-Solving Approach] Unexpected edge case in data processing? Consider implementing a robust error handling strategy with dynamic fallback mechanisms and comprehensive logging. </userExamples>
2/ The worst instances of coupling are between foreign systems where one is not in your control to change, or too high risk (such as banking) and prohibitively difficult to test all but the most incremental changes. So at some point you need to decide what error rate is acceptable in any tool assisted rewrite, where error rate is measured in death count and lawsuit liability.
If I point out redundancies it will fix them but just giving it an open-ended kind of directive hasn't been very successful in my experience.