I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow.
Forgetting all the predictions about singularity etc, at the very least AI as it is now, is going to make it very hard to justify hiring a SWE for 200k. I will say, at the very top for a software heavy company like Google or Anthropic, they will still hire excellent engineers to create new software that AI is not very good at.
But for companies where software is simply a cost center. Like Walmart, or Target, companies that were already outsourcing software development, or using cheap H1bs, now they have the alternative of AI which is much better than even hiring an average software engineer for 200k. This is a sea change in the job market, it’s going to have a pretty big effect as it is right now. US has around 1.6 Million software developers, this number is going to get cut drastically, the very top, say an L6 quality in FAANG will be fine, the average in a no name Bank, or the guy building the website for McDonalds is out, he needs to learn something else or he’ll end up without a job soon.
I would not have predicted this a year ago, now it seems clear that this will happen. Just shows how much of a sea change we have witnessed just like that.
"In economics, the Jevons paradox is said to occur when technological improvements that increase the efficiency of a resource's use lead to a rise, rather than a fall, in total consumption of that resource. Greater efficiency reduces the amount of the resource needed per application, lowering its effective cost; if demand is sufficiently price elastic, this induces demand, frequently resulting in a net increase of total resource consumption."
https://en.wikipedia.org/wiki/Jevons_paradox
the elastic demand will be consumed by ai
jevon's paradox just says people will consume more software as software gets cheaper, which is likely true, not that there will be more high paid jobs for programmers.
as programmers are not the resource, the program is the resource, programmers were the means of production of said resource.
stated differently: in a world where you dont need programmers to make programs, there is infinity of programs, and no jobs for programmers.
You are assuming an infinite productivity boost, i.e. that no programmers at all are needed to make programs.
A more realistic scenario is that programmers are still needed in the foreseeable future (for some definition a what a programmer is, even if it's "understands software enough to be able to write good prompts and judge the results"). So the question is how the productivity boost compares to the increase in the amount of software being made.
Yes ai + programmer are the resource.
Ai won't work on it's own until we get agi.
yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
experiencing the gpt3->4o->sonnet4->opus4.6->fable trajectory I am fairly confident what we call programmer today will not exist, in the same time regular people will finally be able to tell computers what to do and this will unlock the next stage of complexity in manufacturing/material science/medicine and so on.
of course I am likely wrong, people say: its never as good or as bad as you think.
> gpt3->4o->sonnet4->opus4.6->fable
While there are a lot of resources being poured into improving and integrating tooling and use cases and increasing model sizes, the leap between the models you notes are not as much as you think it is. It's the same tech that's scalable to a certain limit of diminishing return. It's a recurrent pattern in technology.
> yes, I assume we will have the 'replicator' from Star Trek, and programs will just appear as you want them.
Yes, perhaps one day. Probably no other "job" as they are today will have the same shape and form. Cancer will be cured and fission will be solved. We may even crack teleporting. Let's hope these all happen and the outcome is not detrimental the livelihood of humans.
> It's the same tech that's scalable to a certain limit of diminishing return.
of course, my point was that gpt3->4o was smaller jump than opus 4.6->fable
Ha. You'll be surprised when you find out how much new problems were created in the code base precisely because the author's (not sure if it's still the right word here, they barely involved) lack of knowledge of Rust.
And no, since they don't know they don't know about it, there are no signs of fixes around these real issues. They had posted something about the unsafe usage, but lol most of the UBs are casually swept away (not even treated as unsoundness), if you actually look at the code and the summary.
As opposed to the known problems caused by using Zig?
Measurably yes. They claim that 128 problems from the zig version was fixed, so I grepped for two known categories of UBs and unsoundness unique to unsafe Rust and found 237.
So there were 128 known problems fixed and you've found 237 potential bugs that were greppable. And you think that's a regression?
Can't assume good faith in you at this point but I'll explain it.
- They've written two articles, one by claude doing the migration another by the human behind it, neither acknowledge these problems. Nor does the incorrect SAFETY comments in code.
- I only spent ten minutes and found two code patterns that are wrong with little exceptions. Also randomly checked a few samples and there was no exception. This basically means that failure patterns not explicitly picked and disallowed will repeat themselves over and over. Try imagine the more subtle ones hiding in this huge codebase.
- Trivial to find != Trivial to fix. 107 of the problems (one of the categories) are borrow issue and requires large refactoring (rearrange and rethink whole modules of code) to be removed completely.
So yes, huge regression by my standards. And I'm not questioning Rust the language. I'm questioning Claude, Jarred the person, their dev & marketing practice and the Bun project.
Btw these categories are separate from the (still unfixed) category of problems I mentioned 54 days ago in the comments before.
Our standards are different. I don't see any of that as a regression. You're pointing out potential problems that can be resolved, and specifically can be resolved because rust makes those problems grep'able.
From my perspective.
1. 128 known bugs were fixed.
2. 237 potential bugs were made grep'able.
That is a massive win to me.
> made grep'able
That's not the correct understanding. These are specifically the ones that were not bugs in Zig. They are forbidden in Rust because of reference invariants that don't even exist in Zig, so correct code are made incorrect during the port. That's what I meant by new problems were created and unique to unsafe Rust in my previous comments, if that wasn't clear enough.
Again I'm not sure if you are intentionally ignoring the context. Please clarify that.
It is highly debatable if a 200k cost engineer that is suitable for the job wouldn’t bring in more value.
Also it is debatable they got any value at all from this. Anyone who wrote unsafe rust and also wrote zig would know that unsafe rust is much much more unsafe in comparison
It's only 4% unsafe and most of it is single-line pointers that came from C++
> At the time of writing, about 4% of Bun's Rust code sits inside an unsafe block (~13,000 unsafe keywords across ~27,000 lines / ~780,000 lines), and 78% of those blocks are a single line — a pointer that came from C++, or one call into a C library.
I don't know much about Rust but I imagine this is safer than 100% 'unsafe' code in Zig or C++.
That’s a lot of unsafe. I worked in a project with 50k lines of rust. 9 lines were unsafe. Turned out one of those was a hairy bug. Now it’s 8 lines.
4% of 100k is 4k. 4k lines of unsafe rust is more likely to be unmanageable compared to 4k lines of zig or c dependency on a 100k line rust codebase.
Not sure if they have 100k or a million lines of code
I'm honestly surprised, almost disappointed, that Claude couldn't reduce this 4% to way less.
It is possible because they hired the original author of Bun to do this.
It won't be possible to HIRE anyone doing this job confidently, they won't even know if they f*ked up.
I am not too worried anyway, one person with no context, with or without AI, can't do this job. Just like with all the AIs you have, giving you 10 millions, you still can't build a AAA game, it is that simple.
I'm not so pessimistic. There is an infinite amount of work that could be done. No one would have entertained the idea of rewriting a project in Rust before this. It hasn't replaced anyone's actual job and they still had to hire a high paid employee to pull it off.
I suspect rather than hire less people we will just produce more code changes.
But do the markets care about a Postgres in Rust? Probably not, or at least not right away. It is a long way towards commercial success.
> I suspect rather than hire less people we will just produce more code changes.
Why? Towards what end? Code changes are output, not outcome. It also needs to be connected to someone willing to pay you hard cash. That is the hard part, a race to the bottom, and the reason I also believe there will be downwards pressure on salaries and even employment.
> No one would have entertained the idea of rewriting a project in Rust before this.
I largely agree with your comment, but is this sentence typo'd or something? "Rewrite it in Rust" happens so often that it's become a meme (and that was so before the rise of agentic coding).
Maybe you meant to say that nobody would have entertained the idea of rewriting this project in Rust?
It's funny, I see the opposite and I would only trust a senior engineer with conducting such a wide-reaching change. I would be more likely to hire a senior engineer who might now be able to effect such change.
Exactly. AI opens up a massive development frontier of projects that were simply impossible before. It does differentiate though. In the old world most "software engineering" work had nothing to do with software engineering so being highly skilled, educated, and experienced in software engineering made very little difference in compensation, position, promotion, etc. "software engineer" isn't a real thing anyway. coding is a secretarial job. you have to move beyond the mindset that coding is doing something useful. it's not. it is a means to an end and now better means exist. if you want to be an engineer you have to think in terms of systems engineering and building systems that deliver defined externally testable capabilities. in a few more years the idea of reading and writing source code will seem as absurd as reading and writing asm seems today.
Not only that. I think most of us, including the author wouldn't have thought this was actually feasible.
Not only is the time and dollar spent lower than a lot of people expected. We could now foresee a lot of these human interaction, mistakes, time and cost could be further reduced by a factor of 2, 5 or even 10+ in the not far future.
Also worth taking into account what is stated in the blog post is also acting as PR piece for Claude and LLM in general.
Getting tired of these comments trying to hype AI. All of us use AI, and if we don't, we have a reason. Chill.
This project is very well suited for AI. It's not clear to me if AI is nearly as good or cheap when building things that are new, where it doesn't have an existing target to match and doesn't have an existing test suite to bounce off of and has the benefit of being lead by an actual human with a very intimate understanding of the codebase.
Ehh, I think this take needs a grain of salt.
There's a few significant facts here:
- They had an existing functional Zig implementation
- They had an existing test suite for the Zip implementation
- They had a separate JavaScript compliance test suite with ~ 1 million tests
- The person overseeing the rewrite was responsible for a huge portion of the existing codebase and was very familiar with the existing architecture and problems
I don't think that middle management at most companies is going to be starting from that same point when it comes to building or updating something. Generally, I don't think there are many projects out there that have such robust existing tests and specifications.
In this case, the engineering behind the tests and specifications need to also be considered part of the process, since without those you wouldn't be able to build a control loop in the same way.
Also I'm pretty sure Walmart directly hires software engineers and doesn't just outsource everything - https://careers.walmart.com/us/en/results?searchQuery=softwa...
[dead]
Every single SaaS app will be completely rewritten in the next couple years. Fair warning. If you aren't on that train you won't have a job.
You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
and btw, if it can write code, it can write tests and test suite
Ai has come a long way, 2 years ago, this task would be impossible ! 1 year ago, it would hit a dead-end in the first hours of the execution
This blog post is nothing short of an amazing and fascinating tale, yet in some aspect very very scary ...
> You are missing the big picture here The AI literally was able to do a year's work of a top notch developer team in just 11 days (mainly because of a lot of human intervention, otherwise it would have been faster) Why do you think its cant or wont be able to replace the lead developer and/or designer's 11 day job !
It would help if you actually engaged at all with any of the points they just made. They were good points!
I am also very curious what the actual cost of this is, esp. if you are not an Anthropic employee and have to pay the API cost.
I think this problem is especially perfect for an LLM though. Its effectively translating with a great test harness.
As for your other arguments, I’m not certain we won’t just Jevon's Paradox into more work.
Nah. You got it wrong. Don’t think too much of yourself, pal
> They could have hired me for 200k and I could not do this in a year. I do not have the context, and I do not know Zig or Rust, perhaps I could pick it up in a month, but I would be extremely slow.
All that really proves is that you’d be an astoundingly poor choice to hire. If you’re spending $200k on someone that doesn’t know at least two out of three (context, Rust, or Zig), you’re just burning money.
That’s not to say that experienced engineers familiar with the stack would or wouldn’t be able to do it in a year, but they’d certainly have a better shot at it.
It’s also not that this project sprung into thin air from a quick prompt and LLM magic… it was driven by a dedicated, highly talented, subject matter expert with extensive SWE background and extensive support from the leading experts in the world. You’ll continue to need someone to steer the ship, even in the Wal-Marts and Targets. An LLM is only ever as good as the input it’s given.
> I think the important thing is this is much cheaper than hiring a software engineering team. They could have hired me for 200k and I could not do this in a year.
Sure, if you're wasting money in silicon valley. They could have hired in Europe and got three people for $300k, which is only double what they spent.
I think the time is the really significant factor, not the money. I bet if they had the option of paying $300k to have it done by humans rather than AI, but magically in a week instead of a year, they would have gone for that instead. $300k is nothing to Anthropic.
If you already employed the engineers the extra cost would have been $0.
https://en.wikipedia.org/wiki/Opportunity_cost
Opportunity cost is not a real cost. No money leaves your bank account. It is a decision making tool, and treating it as an actual financial cost is a misuse of the idea.
It’s literally the price of lost opportunities. It’s not understood to be a financial cost. It’s exactly what it says on the tin. Lost opportunities may not be a financial cost, but they’re certainly a cost.
Opportunity cost isn't just a real cost. It's THE real cost.