AM5 is 3600MT/s for 4 sticks; check the specification of a CPU of interest to you, expand the Connectivity section. For 2 sticks it's 5600MT/s. The Ryzen 9 9950x3d officially only supports 5600 or 3600.
Obviously, you can run memory faster than the officially supported speed, including 4 DIMMS, but the Zen 5 architecture has a reputation for being finicky trying to run 4 DIMMs at higher speeds and you need a bit of care in what you pick and how you tune it.
Ahaha we're going to re-learn a lot of the hard-won lessons of development over the next few years. Just because AI will tackle any job doesn't mean bad choices made now won't lead to time and cost blow-outs down the line. It'll just be token spend blow-outs instead of programmer hours.
On the bright side, since every LLM is completely ignorant of your project's history and minutiae, the "mythical man month" doesn't have an AI equivalent and you can slap on more and more agents to convert time blow-outs to cost blow-outs.
Business who fire entire teams and hire new replacements have much more costs and failure than people who keep the teams going and slowly rotate them yes.
Messy, fragile codebases have a greater cost of change and a greater likelihood of errors with every change. AI tokens might be cheaper than developer hours but you'll still burn more of them working on a messy code base, and still have the reputational impacts of a high error rate.
If "fast" and "cheap" are the main drivers, you'll get "bad". And I think it's a great deal easier for developers to follow the path of least resistance and allow "bad" to deliver faster and cheaper when it's AI that's reading the code.
Of course it changes. Compare clothing before and after the industrial revolution. We definitely have good, fast, cheap clothes now, to the point where the second hand market for clothes is pretty much dead and clothes are seen as disposable objects. The same can happen to software. There is nothing preventing disposable software, indeed the number of one-of Python scripts that I use and discard has exploded. With further cost reductions I can totally see the disposability barrier to climb to larger software systems.
Tailored suits vs. off the shelf ones? Cheap imports that fall apart after a few dozen wash cycles? You absolutely still pick two (at most) for clothing.
The industrial revolution may have changed the bounds, but it didn't change the relationship.
Your one-off Python scripts are a bit like handkerchiefs. You can make a one-off hanky by cutting a square off an old sheet, fast and cheap, but it's clearly not as good as a re-usable one and you'll throw it out after using it once or twice. That sort of idea simply doesn't scale with complexity. A "good enough" pair of pants needs a lot more than just snipping out a shape. Even a one-off pair of pants, like for a costume, requires time and effort. So too with larger programs. They require more time and effort.
AI changes the bounds: it's cheaper and faster to produce software than it was, but it's not cheaper or faster to make something good than it was, not by an appreciable amount. It remains to be seen if software turns into cheap clothing advertised on buses that is barely fit for purpose... but the industry's track record isn't anything to praise, so probably, it will.
For an hour at minimum wage I can buy a t shirt that lasts a year or two before it needs mending. That’s ridiculously cheap compared to pre industrial garments, which is why mending rarely happens. Even tailored clothes are extremely cheap because machines weave the cloth and machines do the sewing. Imagine you had to pay minimum wage to cotton pickers, people operating a manual loom and people sewing by hand.
But I think it does. For instance your comment is not all that different than ones I read, what feels like not 'that' long ago, back when hand-crafted assembly was often still significantly better than compiler produced code in many cases. I'd point there not only to the eventual outcome, but also the fact that we're having this debate when there's every reason to expect LLMs to continue significantly improving, much in the same way that these debates of the past were also being held at a time when compilers were still rapidly improving.
Better tools doesn't change the relationship between time, quality and cost. It just changes the bounds on those values. You can use a compiler to compile shoddily written high-level code just as easily as you can use it to compile well-written high-level code. The cost of writing the high-level code is cheaper than the cost of writing equivalent assembly, but the time and cost of writing good code remains higher than the time and cost of writing bad code.
Then, too, hand-crafted assembly still beats compiled output, if you consider the only upper limit on quality. The gap in quality is much, much smaller, and the gap in time and cost is much, much bigger, though, so it's almost never worth the trade-off.
Let's say that AI-generated software eventually (or already, if you like) produces better quality software than people can produce, given the same time and cost restrictions. You can still spend more time and cost to get a better result, or accept a worse result to save time and cost. Or take more time to get a good result but more cheaply using off-peak pricing (tokens or power, take your pick). Or throw more parallel agents at the problem to get a good result faster, but at higher cost.
Upper limits don't matter when humans can't realistically achieve them. There are exactly 0 humans alive today who can write better assembly for any complete program, of a minimum complexity, than a compiler.
I hit a corner case yesterday in which assembly would give me a better result than compiled code. Emulating an eZ80 ALU on an x86_64 platform means doing a simple operation like add then taking something like 26 more instructions to sort out the flags. Or you can just use ‘mahf’ to load the x86 processor’s own flag results into a register and use them almost verbatim.
It’s still not worth doing, though, since I can easily reach performance targets without.
It's not shifting the goal posts, because when the cost you pay has zero measurable effect, there is literally no difference. It's like if you shaved a milligram of material from a basketball player's shoes, they'd probably be able to run and jump slightly faster, but immeasurably so to the point that people would be much more inclined to look at you like an idiot rather than go grab a razor, if you ever suggested such.
And beyond this you're also speaking of something different. You're talking about taking some output assembly and then modifying it in 'negligible' (as a percent of the whole) ways, as opposed to writing assembly oneself. For a program of minimal complexity, not only would it would require an unreasonable amount of effort, but you'd also invariably write inefficient assembly relative to a compiler. Compilers produce code that is better, faster, and cheaper.
---
Shifting outside the abstract, let's just do an example. Imagine you have a processor running at 3 billion cycles/s and you have a program that takes up to 1 million single cycle ops/s. And then some ultra clever human tunes a bit of the assembly and we get it down to 0.95m cycles per second. In reality you're probably not going to be able to tune your way to a generalizable 5% boost, but even if you do in this scenario - what have you achieved? Literally nothing. Of course this argument, taken to extremes, is why it now takes more processing power to run a text editor than it did to put a man on the Moon, but we're not talking about extremes.
Yeah, code humans can read is quickly just becoming another intermediate language for the AI to work on. We are quickly moving up another abstraction layer. I think part of the challenge for ICs is now we’re all becoming managers, which isn’t something everyone wanted.
It's a risk, not a guarantee, but there's nothing about macbooks that make them more susceptible to it than any other laptop with a li-ion battery. The batteries age. If they're in a machine that runs hot they age a bit faster (and my 2020 Intel MBP runs hot and is plugged in near 24/7), if they're charged to 100% all the time they age a bit faster (but battery management software like Apple has had for years nearly eliminates this risk factor).
There was, however, a batch of macbooks in 2019 that got recalled for a defect that increased the chance significantly, and perhaps that's what the parent poster has in mind.
- punch and kick don't seem to have differences in effect, just animation
- bosses don't have obvious gimmicks to beat them
But the main take-away for me is that this takes me back to computing in my youth, where you could dream up a project and bash it out in a few days. It wouldn't be polished, it wouldn't be perfect, but it would be yours. It would do what you wanted. Computing was ours, it didn't yet belong to big corporations controlling what we could do and how we could do it.
Projects like this give me hope that a new generation will experience that. Aiden won't ever forget this game, even if it's nothing special to you or me. Aiden won't ever forget that feeling of imagining a change, and having it happen. The price for it would've been somewhere around $300-$500, so not exactly broadly accessible - making AI efficient enough to run cheaply should be the main goal of humanity, but we're letting computing get locked up by a few rich sociopaths once again.
Related: I don't see how any kid is going to have the motivation and patience to learn how to program a game like this from scratch now when you can just conjure it up with an LLM.
Why would I sit through years of education? The number of competent programmers is going to drop significantly, but also, people are not going to learn the patience and commitment necessary to do hard things, which is part of learning to program.
I've thought a bit about this. It probably depends on whether the notion that AI can actually replace programmers is hype or fact. If it's hype, we might well see a decline in the number of competent programmers in response to a reduced market (though, IMO, the people who respond to market signals about a profession are rarely the best talents). If it's fact, we'll definitely see a decline, and that'll be appropriate.
But for whether a kid will have the motivation and patience to learn how it all works depends, as it always did, on the kid. I started out typing in BASIC programs from magazines. If I weren't who I am, that might have been the extent of it - typing programs in gets replaced with loading from diskette, but no curiosity about how they work ever kicks in. Certainly kids born just a tiny bit later than me cut their teeth on machines where you never saw source code except by choice, and still got the urge to figure out how it all works and to make it do what you wanted.
Plus, of course, I wouldn't, as a child, teenager, or young adult, have ever paid the equivalent then of $300 to have someone else write something for me. That's a rich man's trade-off. I still wouldn't today: maybe I could spare that sort of money but ingrained habits that say I can make that myself die hard.
(And maybe Aiden gets an interest in game design sparked, rather than in programming!)
I spent a long time as a younger man running general software inside ephemeral VMs. The UX was terrible, but I had no fears about browser vulnerabilities ruining my day. Ephemeral is hard, and the UX is still poor, but I did try it again a month or two back, and it's not impossible.
But now I am doing all my software development back inside ephemeral VMs, AI or otherwise - the UX there is much better, I significantly mitigate supply-chain attack risks, and agents are already constrained to a secret-less, low privilege environment, should I use them. There's a significantly higher likelihood of rogue software in third party dependency trees than there is in a small subset of programs you regularly use.
It's funny, just this morning I had Claude come to me and say "Did you delete directories X and Y?" I entered the sandbox, and sure enough, one of its subagents had deleted the directories wholesale. No idea who did it or why.
No matter; I just rebuilt the dirs from my outside copies and carried on.
You'd open your phone and nothing would work, not even the connection to the cellular network since your phone company has management components running on AWS.
You might have that problem, but us-east-1 going dark is unlikely to impact my Australian carrier enough to knock cellular service out. But granted, I might notice something is up if I tried to use my phone for much. If us-east-1 vanished at the right time of day I might notice on my phone first, sure.
> You'd open your phone and nothing would work, not even the connection to the cellular network since your phone company has management components running on AWS.
I'm pretty confident, sitting here on a different continent, that I wouldn't have that problem at all.
I think parent is trying to say that the number of services that rely themselves on AWS or some of their internal services is enormous and potentially impacts many.
That problem is as old as commercial programming; it doesn't matter that now your actors are prompt engineer and LLM, the same story can be told with manager and programmer.
Indeed. And this is also why I've never once believed the "no-code" would replace developers. And why I see a clear role for software (prompt-, context- ?) engineers at least for a while.
I've worked for CEOs and managers that would insist on ridiculous ideas. Like that time a CEO (let's call him Cedric) came in with a printed powerpoint slide that had a screenshot of the website with a "login form" drawn on top of it.
Cedric: "I need you guys to put this onto that scrunt board thing and make this before friday".
Me (tech lead at that time): "But what features would users need login for? Where or whom needs the profile data? We'd need to work this out in detail and plan it. Certainly not even this month".
Cedric: "I don't know, it's for you to figure out". and then "It can't be hard, it's just two squares one for a username one for a password" (he forgot about the submit-button, the third "square", he didn't even fathom the idea that something has to lie "behind" the "squares").
I recall this anecdote whenever I feel anxious about whether soon "stakeholders" can just chat to an AI agent and have it build features, rather than hire me to do so. Sure, a lot of them will be able to. But there's always Cedrics. Those who not only fail to communicate their ideas in a way that even an AI agent would understand, they lack any understanding of what tradeoffs of their requested features are.
The Cedric's would be happy with an AI agent that complies and starts churning away. An agent that blindly accepts any request and builds feature upon feature. Making their product worse in every sense: unusable, unmaintainable, debt-ridden, security-nightmares.
Their agent will build features that are plain illegal. Or features that users hate, or confuse them. It will oblige requests that drive users away, or changes parts that users/integrations rely on. Their AI agent will gladly add a "form" to extract all PII from their database, but on request, will remove the authorization from it. Because "you are absolutely right. If we don't link to the page from the menu, no-one can reach it".
I'm not making the last one up. Another "Cedric" alike recently hired me to look at his vibe-coded app because his go-to developer gave up and dropped the project. It had loads of such extractors, dashboards and overviews. Online. Unauthenticated. His claude, however, did add the pages to the sitemap, so a customer found their private data on google and contacted "Cedric", after which he asked me.
No, AI is getting smarter, but as long as the "Cedrics" remain as stupid as ever, I don't fear for my job.
I would agree. The AI system has destroyed junior job roles, but to understand the output from a LLM and ensure it is useful and correct, you need to be a senior/experienced developer.
AI merely makes certain folk stay at the start of the Dunning-Kruger curve for longer and longer. Having zero understanding of a system and only see the user-interface and concluding that is somehow all that is involved means people end up thinking everything is far, far simpler than it actually is.
And nothing (and I really do mean "nothing") is simple. We have layers and layers of complexity and idiocratic systems with complex interworking and are creating the opportunity to create things based merely on the appearance of the icing on the cake, or the output of a sausage machine without understanding anything about farming cows.
I am pretty sure we have always been able to add holes faster than we can find them and fill them, and that this has not changed with the advent of faster hole finding tools that are also faster hole producing tools.
SQLite has gone into a frenzy of bug fixing this past year, changing long stable processes to ease things up: opening a specific report channel just for these kinds of bugs, adding features to Fossil to help manage things on their end (and that's just the visible stuff).
And with all that, the latest release has unfortunately been the buggiest I've experienced so far.
I skipped the .0 because of a crash, and only released .1 after giving up waiting for a .2 that never came, with a patch to fix a serious performance regression.
I spent a month supposedly shipping old bugs no one had a problem with, rather than shipping new bugs that instantly crashed things or caused measurable regressions.
That's on a software with stellar testing, and a good engineering team known to favour stability over the new shiny.
Do you think AI is as good at writing bug-free code as finding bugs? If that's the case, this should be a one-time event during human coders -> AI transition. It's like catching a lot of bugs during a handover review.
What categories of bugs would you say we eliminated going from macro assemblers to compilers?
(Operating systems, by the way, are the exception to the rule for assembly: the Linux kernel today has an x86/x64 assembly source component around the same size as MSDOS 5.0: ~250kloc of it. Windows is smaller, based on the NT4 kernel leak at around 70kloc. As a percent of total they're much less, of course, but they also do much more. And have correspondingly more bugs, too.)
> What categories of bugs would you say we eliminated going from macro assemblers to compilers?
Entire classes of 'safety' bugs that just don't exist in modern compilers.
E.g.: forgetting to "POP" something you "PUSH"-ed, especially when it was a conditional allocation for a temporary.
Similarly, type errors were much more common, especially signed/unsigned, or accidentally overwriting things in scenarios that just don't occur even with ordinary C code. Function args were easy to push "correctly enough" that it "worked", but not really.
The code it writes in the first attempt is at least as buggy as a human's. So the question is more whether it is as good at spotting bugs in its own code as it is at spotting bugs in human code
I'm tempted to say "no, it isn't". But I don't have numbers to back that up
It feels like we need AI methods to write provably correct code, along with a way for AI to automatically translate existing code into corresponding provably correct code.
(And hope performance stays in the same ballpark as the old code.)
Yes. Allowing a naive agent to fix bugs can quickly become pollutive.
I suspect both old codebases and new ones that have a very intentional architecture are both dangerous to let loose.
The agent doing the fixing must have not only an incredible map of the project and how it is put together, but the ability to reach into annotated examples in the past and refer to them as it goes about a fix.
I’m seeing that frontier models will not follow intended patterns or know when to deviate if their primary charge is “fix this bug.”
It is perhaps a better idea to have agents’ primary job be “maintain this codebase” and one way that they do it is to fix bugs, and “oh by the way here is a bug.”
I don't think this is exactly true; adding holes only happens when adding features, and while LLMs can add features fast, deciding what features are actually wanted and needed is still a human factor.
So the amount of new code added is limited by processes and product management. Add to that that newly added code can get a lot more checks on it now, and new code will be more secure too.
I also don't think your main premise (adding holes faster than we can find them) holds up, but that's another matter. TL;DR I think we're in a high intensity period right now, but this time next year it'll be quiet in comparison - possibly quieter than before AI code scanners were a thing.
reply