You absolutely know there is one of those AI bros out there in social media posting on how they feel euphoric because their agents don't speak git anymore and just pass a zip with the source code around to other agents as handoffs.
1,150 karma · joined October 29, 2025
I'd wage that volume of changes is not leading to forward progress, but is a clear sign of code churn.
This in turn is a clear tell they are dealing with spaghetti code.
If your code changes are all over the place, touching half the repo and stepping on everyone's toes, your problem is not the version control system. Your problem is your changes, and the mess you are leaving in your wake.
To this I'll add companies who don't mind paying for a non-US service provider to deliver the compute required to run local models.
Just like some users are happy to run GPT6 Luna, some users are happy to run gemma4 et al.
Mind you, some local models run on 16GB of RAM, with some headroom to do development work.
That's not the problem anyone is facing, and analysis anyone is doing. At all.
The problem is the huge AI-related budget that companies who dove head first onto AI are facing.
Therefore the problem everyone is faced with boils down to whether they keep paying the likes of OpenAI a de-facto business tax, or they replace that tax with a one-off CapEx invoice followed by a utilities bill.
And you don't need a frontier model to do most things. In fact, the biggest challenge in using local models in agentic coding is the models supporting these agent-based tools.
> It's going to be many years before hardware to run medium size local models is widely available.
Nonsense. Speaking for myself, my employer already introduced a hard cap on AI credits while rolling out hardware support for local models, and even went to the extents of rolling out workstations with 64GB of RAM as a baseline. Consequently, we are using the likes of gemma4 for a fair share of everyday tasks. This has a transformative effect on your workflows because suddenly you don't ration tokens, and agent orchestration doesn't become a cash guzzler. So far the only constraints are tool support and token throughput, but that's not a concern.
Aren't you describing how a business operates?
I mean, doesn't Intel already hire people for those tasks? Unless you are worried about a specific bottleneck, increasing headcount and production output is what businesses do.
This is exactly why I interpret the aggressive price cutting by OpenAI on their Luna model line as a clear sign they are scared shitless of local models, and how they can trigger a "the king has no clothes" moment for AI companies like OpenAI.
I wonder what kind of fluctuation we will see in these bots traffic.
Google Maps on Gaza does shows a biblical scene. I'm sure everyone who ever perpetrated a massacre would argue they were doing gods work.
I recall tales and legends of consulting firms, whose consultants would parachute into any project, put together in record time the deliverable that met all requirements, and say goodbye until a new expensive contract was drawn. And then internal teams would spend an eternity fixing the ungodly mess of testless spaghetti code.
That has been the reality for over a decade. How come this is a concern with AI code assistants?
I'm not sure you're you're being serious. It feels you're desperately trying to be disingenuous to avoid addressing the elephant in the room.
Listen: this discussion is on how Bun's release cycle stalled due to the rewrite and after the rewrite.
I repeat: Bun 1.4 was released way back in August. Since the rewrite the project barely managed to release two patch releases,and one of them is a hotfix mere hours after the first patch release. Being able to put together at best two patch releases in two months, specially after a major rewrite that is renowned for failing to follow idiomatic Rust practices and in spite of a bottomless AI budget and a militant attitude towards AI, is a colossal red flag. There is no way around it.
You know you're putting up bullshit metrics, not much different than counting lines of code touched by commits.
If you were forthcoming and showed relevant metrics such as release cadence (i.e., what projects declare to be relevant units of work to be delivered to their userbase) you'd be faced with the realization that since march (bun v1.13.14) Bun only managed to put together 4 meager releases:
* Bun v1.14.0 - Aug 20 (first release in 5 whopping months?)
* Bun v1.14.1 - Sep 4
* Bun v1.14.2 - Sep 5 (emergency regression fix)
* Bun v1.14.3 - Oct 10 (just a few hours ago)
This means in the last half year, following the rewrite the project barely managed to put together 3 patch releases. In semver terms this means no feature work, mind you.
Is this what you call productive.
The repetitive nature of these jobs is a red herring, because people are not paid for ticking boxes. They are paid for being held accountable for the implications of the checks not being done.
For example, some roles are restricted to professional engineers and involve basically going to places, doing checks, and ticking boxes in a form. Other roles require a far greater specialization and complexity, but they don't require a professional engineer. Why? Because if your game server crashes no one dies, whereas if an office building falls down them the guys checking boxes will find themselves in a courtroom.
I wonder how many of these posts are astroturfed.
I hate to cite xkcd 2347, but if those many companies are using a FLOSS project without contributing anything back them they need to put on their big boy pants and stop expecting others to do their work for free.
Isn't that what FLOSS is all about?
Nonsense. If that was remotely true we would have seen a wealth of maintenance releases immediately following the rewrite, along with feature work.
However, development completely stalled, even though they can throw ungodly amounts of AI compute at the problem.
Don't you notice an incongruence in your remarks?
Nonsense. They paused releases to get the rewrite out, and following the rewrite it was rather obvious they lost the ability to release production-grade software.
It would have been trivial to release patch versions with little cleanup work, but evidently the project isn't even able to put that together.
You guys should stop to hear yourselves talking about these vibecoded projects. How come they can simultaneously do major rewrites but be completely useless at refactoring and maintaining their own code?
Bun's release cadence dropped like a rock after the rewrite, in spite of the radical AI militancy and virtually infinite AI budget.
Your comment is baffling. Either you lost track of the story or you've opted to post a very simplistic take on the whole Bun fiasco. Bun's ill-advised rewrite had zero technical grounds and the radical drop in release cadence in spite of all the AI backing suggests the project's foundation lays on shaky ground.
My company didn't took away any expensive model, but it did imposed a tight budget and gave my team hardware to run local models. The budget works mainly as an influence on the decision process of which model to run. We can still run expensive budget-burning models if we really want to, but there is a clear incentive to use options that allow us to save our token budget for a rainy prompt.
Surprisingly, I feel this had a positive impact on results. Instead of succumbing to extremely expensive one-shot prompts with the most expensive model in the news, chaining agents running cheap models equiped with context and specialized skills and scripts ends up having a better and more reliable output. And faster too.
I think there is a lot of propaganda, perhaps even astroturfing, on how only the most expensive models churned out by US companies are worth using. Nowadays the cheapest models get the job done, and local models can already handle most tasks as well specially as part of orchestration chains.
Is security no longer a concern?
When you are using a third party model, you are literally feeding it not only your current software but also all the context and work fronts under development.
This is way more than granting a third party access to your internals. This is feeding it in advance updates on all their operations in real time.
I don't think any vague claim of "speed" has anything to do with fatigue.
I do think the parallel world monitoring and validating N work fronts, followed by rounds of fixes where you lay there waiting for the agents to converge, is the defining factor.
Instead of you hunkering down and hammering out a single task where your full attention can be focused 100% on a problem, your mindset is a kin to juggling N balls and hoping to not let any of which to fall.
So it's not really about speed but throughput, and keeping up with the throughout rate is mentally taxing.
Microsoft's MAI-Code-1.1-Flash is on par with OpenAI's Luna line of models. If not for OpenAI's recent radical change of heart on Luna's pricing to hastily slap a 50% discount, MAI-Code-1.1-Flash could very well be the dominant cheap model.
Chinese companies also managed to put together their models with relatively small clusters.
Perhaps US companies are desperately trying to brute force their way into workable models?
Mistral is also an European company. As we live in a time where the US regime is engaged in pyrrhic geopolitical tactics, it's good to know that it can't threaten to cut access to models during s period where everyone is rushing to incorporate them more and more in our life.
Any open weights model that Chinese companies are releasing for free are allowing everyone in the world to have access to high quality realizations of these tools without the risk of the US regime arbitrarily cutting you off.
Also, it's funny how all the neoliberal mantras of how free market drives progress through competition stops when it's a US company that's being challenged.
US companies are burning colossal piles of cash in ways that makes it unclear if it qualifies as dumping, not to mention their deep ties with the country's regime.
Claiming that companies from a country have ties to the regime and burn through cash is a very miopic accusation.
"Why does the page fail to work with this browser?"
That's rather obvious, isn't it?
> Again, this is only subjective reasoning without evidence.
It really isn't. While systems are designed around this problem. Even UI test matrices. How come are you spending so much time discussing an issue you're not aware?