Fire with fire means doing a control burn wide enough that when the uncontrolled fire comes, there’s nothing for it to devour and keep expanding.

It works unless the wind speeds are too high and then embers can cross the burnt section and start a new fire. Some emebrs are known to fly 100s of meters and that’s a dangerous distance to maintain a control fire for

Use automation checks. Most platforms allow adding tests for every small thing.

We have post commit hooks for agents as well as merge protection based on stuff like what you said

🦋

The last item is really important to show the management. We vibecoded a ticket cataloguing script to show that infinite speedup in codegen will bring only x% speedup overall

As for tech debt, it has 2 components: figuring out what to do, and actually doing it. I’ve often found that sometimes there’s no time because the proper fix would need weeks of work. LLM have helped reduce that to a few days of work, including reviewing the PRs.

If your colleagues are low tech, I really feel for you. This will make them feel really productive but essentially pile on shit

Use the AI to fix technical debt. A lot of the changes needed to make codebase good were just humanly not possible (given the priority and urgency), but now you have a stochastic parrot to do the grunt work.

Setup CI, align docs to actual code, improve interfaces, refactor for the long term and not just what the next ticket needed. Treat it like free labour for some easy but time consuming stuff aka intern.

Using it per ticket without removing old debt will incur more debt. Once you are happy enough with the codebase that giving a ticket to a really capable but still stupid intern isn’t gonna result in unmanageable shit, then you can start tackling tickets with LLM harness like: adding a MCVE or checking if a ticket has enough info.

Outright solving tickets with AI will result in the team getting increasingly unfamiliar with their own codebase making. That will have similar effect has hiring a new senior engineer to any project with no team and only interns (LLM): lots of ideas and capabilities but almost all of the time is spent in understanding the effing codebase.

Using random ass scripts to make certain ticket managers happy will ‘help now’, but it’ll be really bad for a team of 10. Increasing velocity needs a large magnitude (ticket size * ticket count) as well as the right direction (based on codebase) so the mgmt strategy is bonkers.

Also the reason Giraffes eat from down-wind, so that nearby plants do not deploy (evolved over a long timescale) self-defense mechanisms

So far left, they have come a full circle are kissing thr far right

Simply lovely. There long names are for mounting since they are persistent w ross reboots.

The short ones can change of there are no mounting options or more or fewer devices than before.

PS: even the networking devices have this funky naming

Worst comes to worst: print a few pages of instructions, laminate them and now you can get it done on-site

Sims has such low bar, that EA might make it full slop

Leading questions are good though. Otherwise these studies would tell the truth and be a waste of money /s

Once a model knows python 3.14 there’s little need to update it until 3.14 is EOL. Most professional settings pin dependencies and runtimes and only move them for security issues or planned migrations.

Several embedded platform only support C++14 as the latest target. That’s a lag of 10 or more years. This is similar to how the calculator chips are redone once a decade or so depending on new fab process giving enough benefits. Once something gets used for years, a large investment makes more sense than the current senseless frontier models every month or two.

A calculator hasn’t changed much since 1990s. The world has moved on, but it still does the one thing cheaply and reliably. We had hiccups in beginning (expense, limited precision, etc.) and now we have phones and computers to eclipse it, but we still have calculators being produced, sold and used. Once you found a model to fit a use case, it can freeze till you can justify the expense of upgrading the processes around it.

Wrt your questions: I love that you are asking the right ones. You can delve into deep infer for more details on diff tradeoffs between batching and latency for the specific DeepSeek case. In general, more users allow larger batches and higher efficiency as well as better amortization.

S curves are genuine problems, though engineers are pretty good at finding something else to offset the slowdown. Computer chips, batteries, solar panels, fiber optics have been pretty good examples of scaling in hardware space. Signalling (Mobile LTE, WiFi, optical trancievers), games, etc. have shown scaling in mixed hw and SW space.

Scaling might stop for one thing, but then people focus on a diff item to still continue the forward progress. What would that look for models? I don’t have a strong idea, but we have already seen MoE, KV Cache quantization, RL Post Training, etc. as major knobs beyond just scaling model size, with each new knob showcasing the same logistics curve behavior. From HW front, there has been incessant march since 70s, where we have seen multiple plateaus and the engineers still moving the frontier ahead. Freq Wall was hit at 2GHz and we have 6 GHz chips now, at a slower pace but still. Memory Wall was hit and yet HAMR and multi level cells have given us densities like never before.

More than mass surveillance, they are pedalling for decision making via AI. Running detection via vision models 24x7 is super cheap, most of them can run on the camera chip itself.

It’s the larger models that are supposed to turn govt into the biggest sucker of SaaS (surveillance as a subscription :( ). They lower the morality bar (by hiding details. Just ask a model and it’ll find data so you dont feel guilty of trawling through people lives) as well as intelligence bar (fewer vocal employees who could raise a voice)

A lot of local models are already at a place where we don’t need them to be better, they are doing 90% of what’s needed to significantly change the landscape. Continual growth is not required. This is delusional to think otherwise.

Local AI HW seems to be roughly 2x perf in 3 years. In 10 years, we should be running at roughly a magnitude more, either same model faster or larger models at same rate.

DeepSeek has shown that with the right inference machinery, they make more than 35$/hour/gpu, so even non local models can be profitable since renting a GPU is cheaper than this. The main moat is the inference kernels: more efficient= more profit.

Inference HW seems to be improving roughly 2x in 2 years or faster. In 10 years, that’s be 32x faster, roughly the gap between a rack vs a single GPU.

Training isn’t that expensive for smaller models. For frontier model, Xiaomi live trained one in a couple million dollars. That’s expensive but not impossible for a company to do one frontier model a year, or a few smaller ones per year. Beyond all this LLM hype, the older CNN are still living a good life as experts in their small domain.

What’s not profitable is doing frontier models every month (like a dick measuring contest), or giving inference for free (via free plan or subsidized subscriptions) or spending on marketing and Superbowl ads or booking gpus to scale by 10x each year or quarter (spot prices are roughly 2x more than pre booked at this scale).

This is something people aren’t seeing. The Internet bubble burst as well, and we alwere using more internet by Y2k than ever.

Even if AI bubble bursts, say in 2027, I’d wager that we’d be using more LLM on 2037 than ever

Having lived in both, I’d like to talk to the Managers please

I’d add TS to the dumpster fire. It’s a gilded pile of poop

The only good thing that came of these copyright laundering machines is that everyone can see the systemic hypocrisy.

AI bots downloads pay walled articles and copies pirates hooks? It’s for AI… No sue Common people like Aaron Swartz do it, sent to jail or exiled (sci hub)

They need a fucking chipko aandolan

https://en.wikipedia.org/wiki/Chipko_movement