> I can’t help but read the logic as not being too far off from: “libfoo switched to being developed using emacs instead of vim so we can’t trust it anymore”
So let's say they up the ante and set up a cron job to rewrite the entire codebase in a new language on the first Monday of every month: from Rust to C++ to Go to Swift and back again.
For customers using the product, that's basically the same as a maintainer switching editors? Irrelevant detail?
> how many problems that you work on have many existing free solutions but you neglected to use that code and decided to spend days doing it yourself?
Only when the existing free solutions are licensed with something like GPL. Now I can just say, write me a C webserver library similar to mongoose and I get the functionality without the license burden.
You might as well have ignored or removed the GPL notice. Running it through the LLM laundering gets you a "fork" of unknown origin, questionable quality. You're still potentially open to supply chain issues but the chain is obfuscated.
And you now own full responsibility for maintenance.
I just vibe coded a socks proxy because existing ones were too thick. And let me tell you, you are absolutely right. Go libraries I’ve never heard of, new implementations that has not been tested.. I think the word for this is YOLO
People say this constantly, but it's a qualitatively different jump from all previous abstraction layers. Previously, the part of your brain you had to use, and the way you had to think, changed from old layer X to new layer Y, but they were still very similar qualitatively. A person who was good at and enjoyed layer X either naturally was good at and enjoyed layer Y, or they could achieve both of those things after a little time. But with LLMs, the jump is much more lateral.
To do the thing I hate and use an analogy: It's not like asking a furniture maker to start using power tools; it's like asking a furniture maker to start telling a robot to make the furniture, in English. Yes, the people who were already good at furniture-making will have an advantage in how to direct the robot - but the salient point is that it's a recipe for misery for many people.
Hmm. I use AI to write almost all my code, and I feel that the "part of the brain" I use is mostly the same. Pre-AI I spent a lot of time thinking about code architecture, schemas, APIs, etc. Post-AI I spend a lot of time thinking about essentially the exact same thing. Yea, there are some things that I used to think about that I don't now - the fiddly bits, like why my parentheses weren't balanced or what field I was missing that was causing a 3rd-party API to fail. But the work feels more similar than different.
Putting info into a spreadsheet is a higher level of abstraction that doesn't require thinking. There are many concrete representations like that.
LLMs don't use them much. This is a lack.
Can you point a LLM at a body of code, and tell it "give me a concise UML chart of what this does"? I'm not advocating humans writing UML, but some representation like that may be useful to AIs. Except that they don't really do graphs very well. We may need a specification language intended to be read and written by AIs, readable by humans but seldom written by them. Going directly from natural language specifications to code causes the LLM blithering problem to generate too much code.
I’m not sure you and the parent are talking about the same thing.
I think they were making a joke about us getting dumber that I am confused about the premise of.
You seem to be suggesting we are going to fill spreadsheets (which claude already does pretty well) and that spatial reasoning is an insurmountable problem instead of just something that doesn’t emerge naturally from training on text/code corpi.
The entire point of abstraction layers is that they require less thinking most of the time (and, usually as a tradeoff, more thinking a minority of the time).
I don't think I think less when writing Clojure or Rust than I would writing raw assembly code, I just broaden the scope of my projects to fill up my thinking capacity.
> ...like efficiently coding in assembly, no longer necessary in today's world.
Assembly is a stretch (albeit a few applications still need it), but otherwise that sentiment (and people who actually believe it) speaks a lot to me about what makes today's PCs slower, more latent, and less enjoyable to use than the machines of the past. Today's world sucks.
> 2. we will think of verification loop more - tasks will be chosen that have more ability to be easily verified
> 4. spec driven development will become more common
I do believe both of these, recently someone created an rar open source alternative for all its version using LLM agents because of that specs and in some sense verification/easy debug (or compile time) aspect.
On the other hand, I was making a GUI application (a rough scratchpad app) in Odin and there were so many bugs that I had to explain it and even then it was like lottery or just about unpredictable would be the better word as it would fix one thing and break another or just not fix it.
At the end of the day for GUI apps, it just doesn't have any way of testing them that greatly perhaps. There are many GUI things which I feel like LLM's are still underwhelming in, especially if you wish to create a GUI in say any niche language.
It can do that but the workflow is so bad that it might just not be worth it. i do wonder if GUI development becomes the one thing that AI can't do and their software development jobs are safe.
I was just scrolling upwork randomly and I saw tons of flutter & wordpress jobs.
I've had pretty good luck with using playwright mcp to test web front ends. I think LLMs can totally test GUIs. Either via vision and computer control or via reading the GUI node tree (e.g. DOM) used by whatever you built the GUI with.
Ha ha ha... actually in the last 20-30 years most people learnt programming in assembly no for the sake of building programs in assembly - it was tought so you can have a grasp of microprocessor architecture. Instructions, interrupts,registers and all that. It means being fully aware of your environment. Without this knowledge of our environment, not only in our jobs, but also generally in life, what are we? Not more than wild animals surviving on instincts and an occasional burst of conciousness. Well, no thanks - I don't want to be an Eloi.
Wow. That xkcd was written in 2007, and part of the dialog is "didn't that [meme] die like five years ago?" Which means All Your Base, as a meme, was already getting somewhat stale by around 2002. It's hard to believe it's been that long.
> If you're talking about your jobs, nothing is going to happen.
That reminds me of when I first moved out of California and away from the tech scene after being immersed in it for some 10-odd years. People just don't talk about their jobs! They'd much rather talk about their interests, hobbies, friends and family, ... literally anything else. Their job is just not an important part of their identity. Was quite the change in perspective and honestly and took some getting used to.
> Now, even though their parent company does some shitty practices with their other software (claude code), it's a stretch to assume this will also translate into making Bun worse: Being worried makes sense but I remain optimistic about Bun.
Anthropic acquired Bun for their own benefit, to protect and grow their investment in Claude Code. Not for the benefit the JavaScript community at large. Sounds obvious but I guess that has to be pointed out. Outcomes will follow incentives in the long run.
Bun is not a "product" at Anthropic though, it's a tool for its developers to build products. IMO as long as it remains that way, the incentives for its developers will remain fairly aligned with the incentives of people who use it outside the company.
A good example is React. Facebook's interest is that React be performant (website performance is correlated with time spent on said website), reliable (also correlated to time spent), quick to build on (features ship faster) and popular (helps new recruits hit the ground running). That's fairly well aligned with what developers outside of Facebook want too.
Sure, since Facebook's server is written in Hack it means we'll never get a truly full-stack React, and instead we'll need third parties for the back-end (Next.js, Tanstack Start, etc). But Facebook building react also means it will always be someone's job to make sure this Framework works well in codebases with millions of modules.
This is all independent of any shitty practices with their other software. And this has been for decades at this point.
> Bun is not a "product" at Anthropic though, it's a tool for its developers to build products.
Doesn't that just make it even worse? If Anthropic can't even afford to spend the engineering effort on making sure their core product functions properly, why should we assume that they'll be investing serious resource into what is essentially some upper manager's loss-leader pet project?
If Anthropic is financially hurting, why shouldn't they put Bun on the bare minimum of life support?
Because they need it to work, so that everything built on it works too.
Building developers sell you the apartment, not the elevator room, the electrical room, mechanical room, etc. They will make all sorts of controversial decisions with the apartments; odd layouts, ugly flooring, weird pricing, tacky finishes, etc. The "core product" is the money-maker, that's where the egos clash, priorities change, and where they try to charge as much as possible while they cut costs as much they can.
No one is buying the electrical room though. It just has to work. Yes, you'll make it as cheaply as possible; no flooring, no paint on the walls, no interior designer meetings to argue what's the right tone beige for the walls. But it'll do what it needs to do. It'll keep the lights on. Otherwise you can't sell any of the apartments.
Same thing with Facebook; there's active incentive to introduce all sorts of dark patterns over their app, to ignore certain bugs, to unnecessarily change things, etc. But none of those incentives are present with React. The incentive is to keep React reliable and performant, and to keep the team lean. I'm sure it's similar with Bun in Anthropic.
And to be clear, Anthropic definitely spends most of it's engineering effort making sure their core product "functions properly". This "functions properly" is just different for us as clients vs them as a corporation. There is high overlap, since they need to keep us clients happy. But a well-functioning product at a company is one that leads to money. I'm sure very capable engineers pushing the okrs they care about.
I think they're doing too much vibe coding and not enough QC... I don't think it's a matter of not having the resources so much as running while juggling multiple sets of scissors..
> Anthropic acquired Bun for their own benefit, to protect and grow their investment in Claude Code.
I’m unclear about this. What’s the business case? I use Gemini CLI a lot, which runs on Node, and I can’t see anything that would be improved by using a different JS runtime. It’s not something you notice as a user. Node is mature, stable, and perfectly fit for the purpose.
If Anthropic were public and if these decisions were comprehensible to the average investor, an acquisition like this ought to cause the stock to plummet. Luckily for the people involved, there are no constraints like that in the current market.
> But gradually I noticed that I didn’t really want a drink, I just wanted a thing. ... It could be alcohol, but I found dessert worked just as well.
Whoa! That's not healthy at all... ;)
I've found non-alcoholic beers are actually pretty tasty these days, moreso the longer its been since having a real beer. They definitely scratch the itch to "have something" while out socializing. I don't miss the alcohol at all.
I do two weeks dry a quarter (versus dry January, which became silly once I moved to a ski town). My otherwise non-existent sweet tooth revs into first gear in the second week.
reply