Vibe coding for teams, thoughts to date
laughingmeme.org
laughingmeme.org
Vibe coding is going to exacerbate this - the growth can come faster, but the collapse point is accelerated correspondingly. If you plot this complexity out like we were taught in CS 101, lines of code will grow linearly, proportionate to the number of agents/devs, but the interconnectedness and therefore state space will explode polynomially without applying encapsulation and local reasoning techniques like functional programming. But we’ve aligned the models to use imperative languages (TS, Python, Java), essentially constraining the code models to specifically prevent the best code scaling techniques! And guaranteeing the emergent “spooky action at a distance” that is inherent to the computational structure of imperative languages.
And note that most companies don’t take flight like Google, instead they seek acquisition, and a lot of those acquisitions fail to integrate and get swimming, they are perhaps underwhelming compared to the sales pitch, to the extent that many start to look like a form of securities fraud? Tech debt is real, it’s just invisible to the balance sheet and therefore to boards and buyers. If it were properly accounted for, the entire IT sector would be revealed as completely underwater.
How does HN think these factors will balance?
We often get distracted by benefits and forget to look at the costs. And we often overdo things to a degree where previous wisdom has to be re-discovered again and again.
Having experienced a couple of hype cycles, I learned that the sensible thing is to narrow down what the new thing is useful for specifically.
And all that's assuming that the prediction holds. I don't see any clear signs of whether the usefulness and precision is primarily a quantitative or qualitative issue.
I wish the complexity demon was this gentle. It's exponential generally – a single boolean flag can double the test/state space.
The only thing that really matters long term is taming complexity. Humans fail at this and that’s why large companies need to hire armies of big fixers and QA to play whack-a-mole with the symptoms rather than the causes.
LLMs make both tasks faster, but it also changes the balance between them. I would be wary of replacing a company of 5 wizards, 20 seniors and 100 juniors with 10000 juniors overnight.
> Lowering the cost of writing code was the thing that no engineering leader asked for, but it’s the thing we got.
Code review is even more crucial with LLMs writing code. Don’t merge until you fully understand the PR and what it’s doing.
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>
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.
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.
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.