Yeah, as a business AMD should first care about getting their DC grade hardware optimized for inference workloads. It's unfortunate that most of HN discussion has devolved to me-ish.
We’re entering a new phase of software development, and with every phase there are new challenges.
Some questions the author might want to first answer:
1. If AI is constantly reacting to smaller incidents, is it surfacing larger issues in your codebase and architecture?
2. What kind of new telemetry do we have to build?
3. How do we build new deployment systems that help us validate fixes without requiring hours to go through traditional CI/CD systems
I’m old enough to remember the days when engineers would monkey patch their code on live servers with additional logging and metrics to learn about failure modes during incidents.
I wouldn't even know where to begin, because the slide in quality has permeated every aspect of the operating system, from stability to design. Numerous networking bugs, SSH agent bugs, sleep state bugs, sometimes having to restart my machine because the network screws up so badly, Bluetooth issues that they keep introducing and then not fixing; I have peripherals that just no longer work due to this. I could go on and on. I could talk about the mobilization of a desktop interface (same mistake the Unity and GNOME teams made)
And I don't feel like beating a very dead horse, so just google "macOS Tahoe design issues" and take your pick.
Agreed. I have skipped Tahoe and will update to Golden Gate when it's out of beta. I did the same complete skip on "Sonoma," I think. At this point, the complete absence of quality in MacOS releases has turned me from an "update on day one" guy into a "Skip major version updates unless it's widely being praised for improving performance and fixing existing bugs" guy.
I bought a new macbook as insurance against a potential supply chain crash and it came with Tahoe :(
On my M2, I have kept it on 15 but Apple aggressively tries to trick me into upgrading in a way that reminds me of Microsoft's behavior with Windows 8/10.
I just buy older stock or refurbished these days. M1s and M2s are still good enough for me. Recently picked up a refurbished M1 16" because I wanted a larger screen in bed / on the couch for a good price with good condition refurbished from amazon.
Oh no, it got bad for a while until they received lots of backlash. They literally changed verbiage and tried forcing an update at least once unless you read very carefully in between the lines. They directly and intentionally employed sleight of hand and psychological manipulation to try and force an update in order to meet some misguided OKRs.
To be clear, I'm definitely not saying that MacOS is now bad - it's absolutely still a pretty good OS. But, personally, I do have a couple of gripes, and my feeling is that things are changing in the opposite direction from what I would like. Compared to Linux let's say a couple of years ago - yeah, better. Compared to Windows - there's no comparison.
But, still:
- it slows down after a while
- design direction is questionable and controversial - that it got more inconsistent is factual - also, so much wasted space and everything got bigger and a little dumber
- so little control over system behavior, functionality, looks
On modern Linux, you get a more polished (wow, unbelievable thing to say - I first dabbled with Linux in 1997), robust, and infinitely more functional and customizable experience. After a while, I started feeling at home - like it's "mine" - and how distinctively MacOS feels like being a guest there, and that it was never "my environment".
I definitely realize how vague and unquantifiable most of this sounds - and how little value those things have for a lot of people - but I've come to enjoy my setup, I spend ~12h / day in it, and I discovered that how it "feels" matters to me.
stuff that annoyed me on mac was the "find" feature was useful, but to get to a enclosing folder (what I want), involved searching, clicking something, finding the file again in the display and "enclosing folder" (this might not be exact, I don't have a computer in front of me).
Sharing files with a windows hard drive. My workmate had a seagate that installed an NTFS driver on mac, which saved us a few times. Never had a problem on linux.
Python never seems to work right. Conda, and other stuff, just never worked smoothly with the bioinformatics code we were running. Cluster machines it was easy.
There is a wierd issue that you can't close a macbook and use it with an external monitor without plugging it in. It just sleeps.
Would you like to join iCloud. No really would you like to join iCloud. How about apple music?
(To be fair MS is just as bad if not worse about onedrive...)
We had a pythonTK program to print labels from a CSV file. Every MacOS update broke it. We ended up just running it on a windows machine. back up was going command line on mac.
previously cmd+enter would work to "show in finder". New siri-enabled search seem to break that for some reason, but right click menu/show in finder on a found item still works.
I would say the artist formerly known as OS X has never been good. It literally started its life as a half-assed NeXT attempt and has only gone downhill from there. There's still a "Services" entry in the file menu. .DS_Store files are an abomination. Mac OS thinks it knows better than I do about which software I'd like to install. Plist insanity that makes the Windows registry look pristine. GUI inconsistencies across every surface area... I'm curious what you like about it, because other than font rendering (which it does well), I can't think of anything positive.
I love it! I write my own services for it all the time. You can assign global hotkeys to them as well which makes it crazy convenient to be able to select text, a file, etc and invoke some script you wrote on them.
There used to be – pre-LLM days – a "Summarize" service that "summarized" prose to a length of your choice by deleting sentences. I'm sure it was once someone's pride and joy.
I've always found it difficult to break into medium and large sized opensource projects, because it takes so long. In one of my jobs, I worked with someone who knew the maintainer in one of the areas, and I realized that social coding is basically an uphill battle, unless you have a real life social connection.
Yikes! I've been a software engineer for over a decade, and I've never had more fun in my career. Running an AI assistant on a cloud machine to pair with me, explore my ideas, learn new tricks, and even write code that I would never write due to timelines and deadlines has been fantastic.
Using coding agents to search for patterns, understanding why our abstractions might not be working because of how users integrate, etc etc.
Not everything vibe coded is bad software, not all bad software is vibe coded.
To echo another reply in the thread, but with an example: have you seen the stats for OpenClaw on GitHub just for this week?: https://github.com/openclaw/openclaw/pulse
GitHub seems to be struggling to support agentic and bot-driven software development. OpenClaw is an extreme example, but there are other projects like it that employ the same methods for development. If I were building a source forge in 2026 and wanted to compete with GitHub I would either:
* Not allow these types of projects at all, like sourcehut, or
* Embrace and charge for the capacity/infrastructure it would take to support it, like cursor's play with origin seems to be.
What does vibe coding mean to you? I use the term vibe code to mean software produced by conversation with an agent, with minimal or no understanding of the code / project structure by the person.
Your process doesn’t sound like vibe coding to me, though maybe this part is “and even write code that I would never write”. If you’re just generating snippets as black boxes and putting that into a project you’re otherwise maintaining general understanding of, this isn’t what I refer to as vibe coding. (Not that I’d use this process in a community with clearly stated rules against AI use.)
The people in support of these bans generally aren't interested in "good vibe coded" software. They oppose LLMs altogether on various grounds, not just the output quality.
FWIW, if an LLM is writing significant code, I'd consider it vibe coding regardless of your understanding of the code or expert guidance and almost certainly ban-AI people would too. The scale people seem care about when this comes up is code percentage that's LLM-written to hand-written, not code ignorance to full understanding by the author.
> The people in support of these bans generally aren't interested in "good vibe coded" software. They oppose LLMs altogether on various grounds, not just the output quality.
I think you're very wrong.
I think many of the people who "support these bans" do recognize value in LLM's and use them as tools in the kit applied to their workflows but recognize that rampant abuse and misuse of those same tools threatens to ruin (or already has ruined) many community projects that had previously been healthy and thriving.
And so they find themselves insisting upon unambiguous firewalls as an existential necessity for the communities they have invested years or decades of their lives into.
It's hard to compare - prior to Opus 4.5 my code was 95% hand-written, with the occassional tab completion.
Now, I would say 80% of my code is written through an LLM, and the last 20% is usually me reviewing adjusting, etc. The part that I find cumbersome is that even when I make manual adjustments, I still need to tell the LLM, otherwise it leads to context drift.
When I compare these 2 times, I think I remember fewer specific details, but I'm getting better at creating more checkpoints.
I think the term vibe coded is unclear. I use agents to do most of my coding work now. Some might call it vibe coded. I use spec driven development of my own design. While the applications are relatively simple, they are reasonably well architected and maintainable.
Some would say I a, vibe coding since I don’t really write the code. I say I’m not because I’m thinking through the features more than vibe coders.
The original definition, as put forth by Karpathy [1], was that you explicitly did not look at the code ever (diffs, errors, etc.). All development, review, etc. is driven entirely through the LLM agent.
But at this point, the term has been diluted down to basically being meaningless.
Right!!! LLMs are yet another step up the abstraction ladder. Before LLMs I would write code in C or Perl; I didn't care about the machine code it eventually was translated into---the compilers/interpreters evolved to handle that correctly and transparently. Note that this was not always the case; when I started to use computers, we all aspired to master assembly like the apocryphal Mel ( https://users.cs.utah.edu/~elb/folklore/mel.html ) --- we had to pay attention to machine code and assembly language, because the compilers often didn't generate performant code and were occasionally buggy.
People say that LLMs are not like compilers because they are unreliable. I think with time they will get fixed.
I mean it's good you are having fun, but that way of working will not be accepted in some communities, its inevitable so just find the place that accepts your preferred way of working.
Why would you ever care about looking at code? Code forges aren't really a useful tool going forward. As agents replace people writing code, the features of code forges really aren't that useful. Nobody will be reviewing agent code other than agents, and you don't need a pull request and code review model for that.
Coding is just going to be asking for a result and manually testing it, no real thought about what code has been generated, and no human should ever need to look at or review it. Even some versioned tarball on s3 will do for the storage.
So, really, who cares about what they do when their entire business model (and Github's) is speedrunning becoming obsolete?
Basically, the future of tools like github is a platform for manual testing, where the AI proposes a change and you can experiment with the UI and attach notes for the next iteration. The whole idea of coders carefully reviewing the output of LLMs is insane, it'd be like carefully poring over the output of GCC; we've made lines of code so cheap and skill-free that there's no point in these platforms that treat code like it's important to view.
I find it fulfilling to write and read code. It’s also a powerful technology. That doesn’t just change just because there’s another technology more powerful in certain ways. These are some level 0 reasons to want to read code, but there are lots.
The code is so cheap today that you can just ask an LLM to generate it for you, for all but the largest projects. I don't get why you'd care about humans being involved, no.
It's not as much an "overhead" as it will mess up your latency. Limits don't stop you from using available resources until you hit the relative allowance in a CFS window, so a 1 CPU limit on a 32 CPU machine at worst gives you 32 cores for 3.3ms every 100ms.
For the love of god - care about other pods on the node, especially in a multi-tenant setup.
Sorry for the cheeky response.
CPU Limits have a place, you don't want a bad change for 1 deployment object affect all neighbors by taking all the CPU. You need to be able to constrain the blast radius. This doc gives me strong AI vibes. Setting CPU limits isn't free. You still need to care about how the programming language that you use discovers those limits, and correctly handles them. For e.g. if you spin up a 100 Java threads, but only have 1 cpu as the limit, that's bad design.
Exactly on point. Shit happens, performance bugs appear, someone messes up Kafka config and it starts consuming from the beginning of the world, etc. Limiting CPU is a must. I could see maybe if someone has a super good monitoring + oncall response team, then letting things go loose for a bit is a lesser evil than working out limits, but still.
I don’t think you understand how CPU limits and the Linux CPU scheduler work. CPU limits don’t protect you from something taking all the CPU; that’s what CPU requests do. Limits throttle your pods even if the CPU is idle/free to do work.
> The CPU request typically defines a weighting. If several different containers (cgroups) want to run on a contended system, workloads with larger CPU requests are allocated more CPU time than workloads with small requests.
So I guess limits _would_ protect other pods to a degree. Though I agree that it doesn't seem worth the tradeoff of your pod getting constantly interrupted while the rest of the box is sitting idle
Where do you think the contradiction is? A CPU limit of 1 does not prevent an application from using 8 cores worth of compute at once, it just limits the compute to 1 core per 100ms slice on average, and usually that means getting unscheduled for 7/8 of the slice, if the app is using all available resources and nothing else contests them (weighted by requests).
According to the documentation, CPU requests don't cap usage. They're not used for that. They're used to gauge how much CPU you say you will use. They're used for allocation and pod assignment. They never throttle you. They never cap you. According to the documentation, CPU limits are the only mechanism to prevent exceeding your resource allocation. You directly said the opposite of that. If that's not what they actually do, then FIX. THE. FUCKING. DOCUMENTATION. Either the documentation is wrong or incomplete, or you are wrong or incomplete.
That's the contradiction. And, to be clear, I think you're both wrong and incomplete.
It's partially a problem that how it's being documented is either really misleading or fundamentally incomplete. That may be because that's just not how Google imagined Kubernates was going to be used. If you need to understand the CPU scheduler to be able to use this option in the first place, then the documentation should explain that directly or by referring to more information elsewhere.
I don't see the contradiction to what I said or what the prior commenter said.
CPU requests still protect you from something using all the resources, because the weights correspond to your number vs all the other pods on that node, and the scheduler will not schedule pods so they exceed the total available resources.
So more accurately, requests prevent exceeding limits under contestion, and limits always do.
reply