abalashov

Not in security, but "vibe coding remediation"--that's the best way I can think to describe it--has been a booming business in my line of work (SIP/VoIP infrastructure engineering) as well.

How long it'll last, I can't say, only that before LLMs, the industry entered a phase of consolidation and quiescence that had me seriously worried about a fade into irrelevance. The delusions of businesspeople and the managerial class about what LLMs can do has fueled a very nice business renaissance, as they run into the limits but have committed to contracts, business models, etc.

> nowhere in all of this has AI threatened to make my life more convenient by doing the chores for me, it just takes away fun creative tasks that I can get paid for.

And this is, of course, the bitter irony. As that meme goes, I don't want it to write my prose so I can do the dishes, I want it to do the dishes so I can write prose.

Yes, but that other role is a change of career.

Yes, but in some fashion, all the outputs are mathematical convolutions of the training, plus whatever is packed into context.

No, but I think you could tell a sufficiently compelling allegorical / metaphorical story about how farm tractors, in destroying the livelihood of farmhands, might as well have pried their muscle fibres out of their live bodies.

> It seems in our profession there might be less satisfaction from work, but if it leaves me with more space to accomplish things in my own time, I think I prefer it.

I wonder why you expect to have more space to accomplish it. What happens when the managers realise that they can get more 3x, 5x, 10x, whatever x more software?

Also, let's briefly revisit the source of all economic value: scarcity. If you can kick your feet up more, you can't expect to be paid as much for it.

I think you're right. And no, it's not just you. You've tapped into something very central and animating about software as a craft, and the cognitive and psychological feedback that got most of those who are really good at it to be interested in it in the first place. I share your sense that we'll probably not be arounds to see what "better" looks like, if it ever even happens.

Francis Fukuyama's "megalothymia" seems relevant here, too.

Yes, but in terms of your marketability--even in a world with LLMs--it seems to me that learning React or whatever is popular and trendy is quite vital. You can't propose good architectures in /plan or review slop PRs in React without knowing React to a level of depth that could only come from having toyed with it, and thought in code.

It wasn't programmers who brought us the idea that all problems, obstacles and goals can be conceptualised as an insufficiency of code, apps or gadgets, without any thought to politics, negative externalities, institutions, or philosophy.

That came from SV technocrats and associated capital owners.

> But it isn't a lot of work, it's effectively free. All this is just living in inertia right now.

... but it isn't free. You're introducing a certain amount of entropy and drift every time you let the coding agent loose on it. There's a hidden cost of loss of cohesion that comes with changing anything and then changing it back, and while that cost exists with human developers, too, the pace at which they work and think limits the damage and the risks. LLMs just compound them, but the consequences are long-term, while the incentives are to do the thing now.

> But I still fear that I'm going to be obsolete as soon as it figures out what questions to ask.

Code and business requirements, outside of maybe very pedestrian CRUD apps, is diverse enough that I don't see that to be a realistic concern. A far bigger concern is that it may not matter whether they're asking the right questions, and that sufficient brute force can overcome any objections like 92% of the time--good enough for government work, good enough for the MBA frat boy who lords over you and always saw you as a needlessly expensive typist anyway...

No, indeed. They rely on LLMs to do that, and that necessarily adds a degree of entropy that will eventually cause the thing to vibrate apart, but much later, in the future. Meanwhile, the incentives are to fix (or "fix") the bug now.

> We're all going to have to cope with the fact that LLMs are now better at programming than us. It is professional irresponsibility to not use an LLM in 2026.

As a categorical generalisation, this is absurd. Much depends on much, and the devil is in the details. In certain domains, this might be true, though the word "better" is doing a lot of work there. It is certainly not true in all domains; my consulting practice, where code is written by hand, is thriving, and my clients are mostly AI companies who have discovered the limits of "vibe coding" in this particular area.

> I think I’ve leaned too far into AI, partly because I’m a lazybones and am kind of burned out already.

I've been doing systems / backend programming since I was 10 (in C in those days), so I was burned out by the time I was 20, and I'm now 40. The temptation to trade on that knowledge in a very short-term way is strong, but I know where it leads -- to the rot you describe.

Indeed. In much the same vein, I simultaneously accept that:

1. I loathe video with the white-hot glow of a thousand angry suns, and loathe LLM slop-digests of things more still.

2. I spend tremendous amounts of time in situations where I can listen but not read, whether driving or on my bike, and this is a legitimately useful way to catch up on HN in those situations.

Sadly, a great deal of applied business programming in modern capitalism doesn't give you the option of enjoying the creative process.

In effect, everything is classified as: "low value work with dead lines, where the customers don't really care about the result either."

I've found it helpful to think of models as precisely what they are: bundles of probabilistic textual associations, convolutions of their training, more search engine than "intelligence".

Just having that mental paradigm will lead to more correct uses, and avoid a lot of the most ones most likely to lead one down the primrose path. This cultural moment of SF AI psychosis will pass, but we'll be stuck with the resulting code for a long time.

Also, +1 to the folks saying that code is a liability. More is almost never better. Aim for succinctness and brevity. That cuts directly against the thrust of LLMs' tendency, but will give you plenty to curate.

> which AWS supports, and doesn't share any data with Anthropic

Ah... oh.

Well, it's a nice thought.

Yup. This was my main takeaway from vaping in the 2010s, after I 'quit' smoking.

However, the vast majority of my nicotine usage after quitting was chewing nicotine gum -- for 11 years! It also has the qualities you mention. You can be chewing all the time, anywhere, everywhere, and without any of the vaping restrictions places have.

Nicotine gum isn't for everyone, but if you're one of the people for whom it really takes as an addiction of its own, it's that much more difficult to quit because it's discreet, there's essentially no stigma, and you can do chew absolutely anywhere, doing practically anything.

Yeah, that's broadly accurate, although details matter and local models are surprisingly capable. Local models are viable for a lot of small use-cases, but no, there's no deluding oneself that frontier quality doesn't require frontier size. However, everyone who thinks they need frontier "intelligence" for internal CRUD type tasks should look in the mirror and ask themselves if that's really true.

Still, even if you need other people's industrial-class hardware, open models offer a lot more freedom and options. They allow you to use GPU capacity from entities who are not themselves building or training models and are ostensibly disinterested.

There's a big range of possibilities here in terms of data sovereignty and so forth.

1) You can use OpenRouter to route your open model requests to US-based inference providers with ZDR (zero data retention), as far as you can believe anything in this world. If you look at who actually serves open Chinese models on OpenRouter, you'll see a lot of folks like Digital Ocean, etc. I suppose I can't vouch for their purity, no, but I'd much rather send data there than send it to Dario.

2) Or, you can rent GPUs from companies like Runpod or Vast.ai and serve some very sizable models to yourself (e.g. using their pre-built vLLM images). You can't serve a model like Kimi K3 to yourself that way, at least not in any economically reasonable way. However, a private H100SXM or B200 can go a long way. You could serve the big Qwens, or DeepSeek-V4-Flash--you could do a lot if you're willing to spend on a rented GPU with sizable VRAM.

3) Finally, if you have and want to spend $750K-$1MM+ (I suspect I'm low-balling at this point), and if you can get them in the current demand climate, you can absolutely buy 16 x H200SXMs, with the appropriate boards to take them, pay for 20-25 kW of cooling, etc., and run one of these models yourself, on your kitchen floor if you like. You simply cannot do that with Anthropic or OpenAI.

Data points from my own usage, for whatever they're worth[1]. I'm just an individual contributor and hardly represent enterprise or large orgs:

I've been on Kimi, with a little DeepSeek-V4-Pro, GLM 5.2/5.3, and MiMo thrown in, for probably about a year now. It's great here!

1) For DeepSeek, I recommend their Reasonix harness strongly, due to its alignment to DeepSeek's prefix cache. It means mostly (95%+) cache hit input tokens, so very cheap large-scale code analyses and things that require mega context windows (at the cost of some attentional drift, yes). Reasonix does require that you send data to China. This is fine. I mostly use this for big, expansive ingestion of open-source codebases to figure out how something really works, usually something that documentation doesn't quite reach.

The economy of doing it this way versus American frontier model companies' token pricing cannot be overstated. I think I topped up $10 in June (2.5 months ago) and have still not burned through it, despite cycling untold tens of millions of tokens through it.

My biggest annoyance is that DeepSeek does seem to be considerably rate-limited of late, at least during working hours in Beijing, which is a range that I gather to be quite expansive there. I'm not blasting it with anything, I'm just noting that the agent takes 10-20 minutes to do stuff that takes much less time if I'm willing to pay the OpenRouter premium.

2) For most everyday stuff outside of where Reasonix + DeepSeek just makes overwhelming sense, I use OpenCode/Maki/Pi/whatever harness I feel like using today with Kimi K3, via OpenRouter. This does not require sending data to China.

I also use Kimi K3 in Zed via OpenRouter quite a bit, but sometimes like to mix it up with the other models.

3) Because I have the most experience with it, I can say with confidence that I would generally consider the SWE capabilities of Kimi to be on par with Claude, at least for the bottom 99% of purposes--and certainly, any routine business programming.

I think this has been true for a long time, well before K3. I've been using Kimi since K2.5.

4) For local hardware experiments on my MacBook Pro (M4 Max, 128 GB unified memory), Qwen3.6-35B-A3B (speed) and Qwen3.8-27B (intelligence, but slow). As has been widely noted, this amount of unified memory isn't as useful as it seems, due to memory bandwidth and decoding constraints, lack of tensor cores (on the M4 Max, anyway), etc.

A giant bag of memory isn't fast, but it'll let you load some impressively big models.

The future M5 Studio Macs will continue in this general vein, but will of course be somewhat faster, particularly due to the apparition of tensor cores in the M5 -- excuse me, "Neural Accelerators".

Still, if you really want to cook, get a real GPU. Real GPU running quantisations is still a lot better than a big slow bag of unified memory.

5) Overall, the Chinese models are simply excellent, and cater to lots of use-cases and tastes. However, I'll still tend to use Claude ($20/mo subscription) for general Q&A, whether of a technical nature or otherwise, particularly where web research and worldly knowledge is required.

[1] Disclaimer: this comment is an elaboration of https://news.ycombinator.com/item?id=49809605, which is not something I'd normally do. However, it seems a lot more relevant here than where I had originally posted it, in an article about gauging MiMo Pro v2.6 capabilities.

Welcome to the dark side. I've been on Kimi, with a little DeepSeek-V4-Pro, GLM 5.2/5.3, and MiMo thrown in, for probably about a year now. It's great here!

For DeepSeek, I recommend their Reasonix harness strongly, due to its alignment to DeepSeek's prefix cache. It means mostly (95%+) cache hit input tokens, so very cheap large-scale code analyses and things that require mega context windows (at the cost of some attentional drift, yes). Reasonix does require that you send data to China.

For most everyday stuff outside of where Reasonix + DeepSeek just makes overwhelming sense, I use OpenCode/Maki/Pi/whatever harness I feel like using today with Kimi K3, via OpenRouter. This does not require sending data to China.

I also use Kimi K3 in Zed via OpenRouter quite a bit, but sometimes like to mix it up with the other models.

For local hardware experiments on my MacBook (128 GB unified memory), Qwen3.6-35B-A3B (speed) and Qwen3.8-27B (intelligence, but slow). As has been widely noted, this amount of unified memory isn't as useful as it seems, due to memory bandwidth and decoding constraints, lack of tensor cores (on the M4 Max, anyway), etc. A giant bag of memory isn't fast, but it'll let you load some impressively big models. The future M5 Studio Macs will continue in this general vein, but will of course be somewhat faster, particularly due to the apparition of tensor cores in the M5 -- Neural whateverApplecallsthem.

The Chinese models are simply _excellent_, and cater to lots of use-cases and tastes.

I'm not sure how literally you mean "most people". This might be true in a purely volumetric sense, but that's not really the bar around these parts...

> I know my codebase well

I'll bet you know it because you wrote and/or worked on it manually, likely over a period of years. The odds of you knowing a slop codebase that well, or even particularly at all, are much lower.

It seems to me if you're thinking about this for more than 500 milliseconds, maybe you should just write it yourself.

Ah, an ngrok competitor. It's what we elderly (~40 myself), yelling-at-clouds types call "reverse SSH tunnels", but this is an anachronism from the era of knowing how to do things rather than paying for managed SaaS products to do them. Don't mind me, just yelling at clouds...

> It’s a beautiful Saturday morning with my family here in the East Bay - I don’t know how many more Saturdays I’ll be able to play outside with my kids in the sunshine so I’m going to make the most of the time we have.

I don't know how else to say this. Put... the... peace pipe... down!

Allow me to recommend switching to Kimi K3 / GLM 5.3 / DeepSeek. I use all three for the better part of a year now (DeepSeek via the Reasonix harness) and haven't touched Claude Code in at least as long.

The best take is, of course, from Jason Gorman, who, when the fearsome "capabilities" of Mythos originally dropped, said this:

"Claude Mythos is that guy down the pub who is so good at karate that if he used it on you, you'd die instantly, and that's why you'll never see him using karate.”

In this case, it's more: "I'm having to act with great restraint because my karate is so good. Everyone should do likewise."