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.
The usual "the models will improve a lot" narrative that I've seen in the majority of companies calling themselves an "AI company".
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.
But what's the financial incentive to make it DRY? The LLM services your company pays for are incentivized to ensure the output is as long and verbose as possible because they can charge more. And from an engineers perspective it does not matter because no one is reading said code, or they're just asking the same LLM to tell you what the code does. And obviously more lines of code looks better to your execs.
There are a bunch of anti-patterns both in how these services are used and sold to you.
You seem to have missed a core point. I, as a developer, do not have the ability to make that change for whatever company I work for. Otherwise I would've canned shit like JIRA and Confluence instantly.
The 'competing' LLM providers does not matter. Companies will sign on with the big players.
> The LLM services your company pays for are incentivized to ensure the output is as long and verbose as possible because they can charge more.
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>
1/ this requires AGI not stochastic parrot - as the training dataset does not contain any successful instances of obtaining actual DRY at scale, so the agent will need to contribute novel research and essentially solve software engineering. It’s not 2-3 years out. And why should any result be aligned to how things work today, why not start over from the qbits and work our way up?
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.
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.