I find Dan Luu's blog extremely good to read on mobile, with great typography. The website also works with Firefox Reader mode and loads pretty quickly due to using the system's font.
It used to be that people set the width of their browser window to the text page width they’re comfortable with, and configured a different font if they didn’t like the default one on their browser.
We should be more ambitious in letting the browser software control the presentation according to the user’s preferences. This is not facetious. We should use the increased ease of building software to create software that is flexible, empowers the user, and accommodates different user preferences.
Please don't complain about tangential annoyances—e.g. article or website formats, name collisions, or back-button breakage. They're too common to be interesting.
No. Line length and text wrapping restrictions are the devil. If you want smaller width text, resize your browser window rather than making a site that sucks for us who don't want smaller text width.
I've been seeing too much "I've been coding for decades and what I've always done has be reduced to telling AI to do it for me."
and not nearly enough "I've been coding for decades and recently worked hard for months with AI's help to make something I would have never considered possible before."
Much easier to complain that you are bored than to step back up to high-effort with your new fancy tools.
I am mostly in agreement. And I suspect there are many folks that’re trying to ship something AI-assisted that’s sufficient to get to income security first, and who would use success there as a stepping stone to greater things.
A UBI will never work, the Soviets tried effectively that and it fails miserably.
You end up with the government deciding how much bread each person needs, how much the bread will cost, how much to pay a person so they can pay the defined price for the allocated amount of bread, etc.
Either utopian claims of an AI and robot-powered future are right and we don't need money because you can just have what you want, or money and resources will still be scarce and we will continue to compete amongst ourselves for resources.
I think something like "negative income tax", or basically a UBI plus a higher income tax, could work, only it would be very expensive, probably make many other things more expensive as well, and there might be better ways to implement a welfare state.
2) America in 2026 is not the USSR in the 20th century, so even if they did, our circumstances are very different from theirs.
3) UBI was only the first suggestion; you completely failed to address the other and then jumped to a black-and-white conclusion.
The general thrust of my proposition was that people shouldn't have to submit to an artificial system of manufactured competition and unnecessary "productivity" in order to access goods that are objectively abundant. When people realize that and make the necessary compromises, they won't have to worry about shipping useless AI-assisted slop for "income security" and can focus on using AI to build consequential and useful software.
Please do not get bogged down in whatever kneejerk anti-UBI thought-loop your misaligned amygdala is screaming at you.
1) you'd have to expand on your refutation here. The soviets absolutely did decide top down how much bread each person deserved and how much it cost. They used that type of data to help decide how much grain to have farmers grow, where and when to ship it for bread production, and in part how much to pay people so they could buy their allocation of bread. Not directly a UBI, but functionally very similar with the caveat being they forced people to work in predefined jobs for a set pay rate.
2) I didn't say the US is the USSR. I pointed to a clear example where a UBI-like structure was tried and failed. Feel free to call out specific differences that may help it work better today in the US, I'm genuinely curious despite my skeptism.
3) I can respond to the others as well, but that isn't necessary to have an interesting debate or discussion on any one topic. If one was required to respond to all raised ideas they could try to shut down all conversation by threading together a long list of hard to discuss topics, avoiding responses to any one topic.
I do agree people can avoid having to submit to AI or ML systems though. We ultimately all make our decisions, some more impactful than others, and if we end up in a dystopian future with no jobs and AIs/robots in charge of the world we made that bed for ourselves.
I'm not bogged down in any kneejerk reactions and I'm not parroting what I've heard air bags saying elsewhere. I've read up on the topic, the history of the USSR, and read Marx writings (well the translations, I speak some Dutch but no German). We may disagree, but my views aren't uneducated reactions.
1) You are describing something that is not UBI, and calling it UBI anyway. A rationing system that is not fungible and that varies allocation is not universal, and not income as capitalism knows it. The Soviet planned economy was categorically not UBI. Full stop.
2) >I pointed to a clear example where a UBI-like structure was tried and failed.
You did not.
3) That's not applicable here. Why did you respond to the UBI issue only?
>I do agree people can avoid having to submit to AI or ML systems though.
I didn't speak to this at all. The "artificial system of manufactured competition and unnecessary 'productivity'" is independent of AI and ML and has existed for several decades.
>my views aren't uneducated reactions.
See 1.
My conclusion is that you actually aren't interested in a conversation. You haven't responded earnestly or considerately to anything in my initial post except the portion suggesting UBI, which you dismissed with a faulty presence.
Here is my suggestion: talk about something else from that post. Anything else. Do not revisit the UBI topic.
The only reason the Soviets didn't have a true UBI is because they realised they still needed people to work and they wouldn't if you gave them what they needed for free. That's why I said they had what was effectively a UBI, they decided what people needed or were entitled to and created a system that would give them only that. The fact that they forced people to work is an implementation detail that we'd likely run into in the US today as well, we couldn't afford for the government to cut checks and no one work.
I did respond earnestly, whether you accept it or if I'm explaining myself poorly. You have yet to propose how a UBI would actually work, or pointed to an example of it ever having worked in the past. Socialism and Marxism have been tried, the don't work. And yes, UBI is an idea that goes back to Marx's writings.
You asked me to respond to more than just the UBI concept raised.
I 100% agree people need a culture of looking out for each other. I'd argue that has only successfully happened sustainably in smaller communities, and from the bottom up rather than the top down.
Take care of your neighbors, and ask them for help when you need it. You aren't proposing this here so I'm not arguing with you, but it never works for long when the "help" comes from the top down. For a short period we may actually see the government take resources from some to help others, but eventually that is corrupted and they stop at the point of taking resources and power.
The problem is now the AI can do for $100 what took you 3 months full time.
Employers previously hired you because cheaper alternatives such as offshoring were impractical…
Now the AI is cheaper, faster, and better than domestic labor and offshoring while still hosted domestically…
Some will feel one doesn’t need an experienced rockstar to babysit an AI…
In about an hour I just solved about 80hrs worth of personal coding/debugging with a portion of a $20/month Claude subscription… Frankly it makes all my knowledge and experience feel kinda worthless… I only gave it a few sentences…
My POV is that indicates you need to up your expectations for yourself. You apparently have the knowledge and experience to cause 80 hours worth of work to be completed in a few sentences given today’s tools.
So then, given your knowledge and experience, what challenge would require 80 hours of real, focused work out of you using today’s tools?
It makes me feel actually sick that so many people can't separate their positive feelings about AI from people's misery (it must simply be "complaining"), and vice versa. As if both things can't exist, for some reason. It's a common tribalism problem, but it's been kicked up a hundredfold by AI.
The distinction you're making between "people's misery" and "complaining" is just emotive pandering. You're complaining that people aren't understanding the depths of your misery. That certainly annoys me; everybody has problems.
The amount of sympathy programmers are expecting others to feel about their problems has been kicked up a hundredfold now that its their jobs that have been threatened by AI. Their tribe feels pain more deeply than others, I guess.
My positive feelings about AI are marginal; my feelings about its performance and the power of the people who scheme to control it are very mixed. My negative feelings about the whining of the most coddled profession on the planet outside of finance are intense.
The problem is that making CRUD apps is not creative, and even if AI plateaus at mediocre, it will still replace a Rails monkey. If you are creative, AI has opened up a world of possibility and productivity, and you painfully feel the limitations and the stupidity of the current level of LLMS; but if you're a mechanic, it's over - I'm pretty sure that was the keynote at the last Rails con. Sorry. Hope you didn't spend all of your massive incomes on toys and rent.
> The amount of sympathy programmers are expecting others to feel about their problems has been kicked up a hundredfold now that its their jobs that have been threatened by AI. Their tribe feels pain more deeply than others, I guess.
Well, just wait then, lots of other professions will soon get to realize the same sort of pain, so you'll be able to be similarly dismissive and condescending to them, too.
A lot of people don't realize that the frontier AI companies are so focused on automating software development first because they are all racing to be the first to get to RSI. I don't know if RSI will actually happen, but many, many other professions will soon be in the same boat. Mathematicians have already felt the pain, and those mathematicians who aren't the few who have tenured professorships are certainly not (generally) some of the most coddled professionals.
But lots of folks low on the salary totem pole (copywriters, paralegals, etc.) are already being hit hard by AI and that blast radius will continue to grow.
> you'll be able to be similarly dismissive and condescending to them, too
And? Who are these people that need all this sympathy from internet strangers? Grow the fuck up and go solve your own damn problems. I can’t stand these “I need internet strangers to tell me that my life is, in fact, hard” people.
Plenty of other professions were hit by computing. Part of why programmers are so emotive about this concept (other than the fact that emoting online loudly seems to be much more accepted in software than other professions) is that programming has never been threatened in the same way as other professions have been until now.
My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career; free flow of information over the internet and commodification of spreadsheets changed all of it. From my parents' generation, I know practical effects folks who became unemployable once movies went to digital effects; engineers who found their draftsmanship skills obsolete. Folks with near-photographic memories whose entire superpower was destroyed by computing. I personally grew up in a blue collar community that was income depressed because its labor became commodified, though that was due to mechanization.
FWIW, I agree with pretty much everything you've said. But I don't think it's unique to any profession or individual that they tend to care the most deeply when it hits them directly.
The only thing I don't really agree with is where you say "My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career." I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs (for MBA types anyway) there is, so I just don't know what you're talking about with this one.
> But I don't think it's unique to any profession or individual that they tend to care the most deeply when it hits them directly.
Sorry, I didn't mean to imply that. I just meant that part of the unique feelings in the air for software engineers is that this is the first time we're facing this.
> I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs
There's plenty of other jobs the MBA type could get into these days which are also high prestige and there are now many more tiers of management consultants. The elite folks at McKinsey are still high prestige with high salaries, but your average Accenture or Deloitte consultant is both pay and prestige wise about the same as an average knowledge worker. Plenty of VCs, fund managers, and investors are MBA-types. The explosion of private capital means there's a lot of opportunity to manage private capital; private capital markets were just much shallower 50 years ago.
if the complaints can be properly pointed at the actual problem - the corporate culture the complainers are actively upholding or the capitalist system at large, id be much more sympathetic
its a tribalism problem, but one of trying to uphold the current tribe system while theres a pretty obvious new tribe system replacing it
Precisely. I have both feelings simulataneously. I am impressed by what it can do and horrified because I realize what it will do to the job market and society in general. Meanwhile everybody seems to believe that AI will cure cancer and therefore we should let it do all the damage it will do without realizing that people will die because of AI as well (in fact have already died because of AI).
I don't think that's true, Gaza residents die at much higher rates. Give it another 30 years for all the truth to come out and we'll probably learn that 98% of them were already dead as of the time of this comment.
Yes, what is happening in Gaza is disgusting, but the context was people dying on account of AI and this was the most concrete example that came to mind.
If anything, AI could have prevented this strike by invalidating stale targeting data. The school building had originally been part of an IRGC military installation, then was physically separated about ten years ago. Satellite data would have made it abundantly clear that it was functioning as a school. A human in the loop could have prevented this tragedy by looking at the satellite data, but so could an AI system.
In every war, countless innocent people die due to mis-targeting or other failure modes. At times the casualty count there exceeds military deaths. It is so common that we have a term for it: collateral damage.
So the question is: does AI lower such damage?
If AI had not been used in the attack on Iran, history indicates the death tolls in this regard would likely been much higher.
Not making a political statement or implying support for the war. Just making a point that these comparisons are more complicated that your example.
> If anything, it should make me more optimistic, not less. If you have an idea, you can turn it into product within 30 minutes, no matter how complicated it is.
There is no product in that anymore because someone else could copy your product in the same time.
Right? If it's so easy and cheap where is the value? There is no value.
This fallacy is second to only every SME believing their jobs are going to be the jobs AI can't replace.
You have QA engineers chiming in about how "QA" isn't going anywhere.. On threads talking about code, tests, and PR reviews being completely automated.. PR reviews being a quality assurance activity..
AI cannot possibly do meaningful bio science because it cannot run experiments on its own. It's limited by the crap science papers others have written, often with "third party" funding, i.e. in direct or indirect dependency from pharma.
AI has essentially stolen my career from me. I _liked_ having to solve complicated problems with software, I enjoyed having to get into the nitty gritty to get things done. I never really cared that much about the actual business problems I was solving, so moving up a layer of abstraction to be some sort of bastardized product manager/architect does not scratch the same itch.
OTOH, for solving problems I care about, AI has been a god send. I can achieve things that I would have never had the time for.
Ooph, this quote sounds so much worse taken out of context.
My understanding from reading the lwn article is Linus's implication is more specifically about filtering out people that cannot write code without LLMs or the willingness to spend the money on the tokens required to uphold the quality of the kernel. He does not want to push out developers that do not use LLMs.
Linus Torvalds has never cared all that much about the freedom aspect. Why not make the kernel GPLv3 or sue some companies violating even the GPLv2, for example?
I agree.. partly, and my problem is with enjoyment. I did some hand coding today and immediately got in the zone, something I'm still not able to do with LLMs. It most definitely took me probably ~2x longer than it would with an LLM, but it was much more enjoyable owning every decision behind the process, and having a full view of how the system worked.
I think this could be achievable with LLMs if they had a much higher token rate. That way you'd have less downtime and could work on the problem more aggressively. How it's designed to work now, offloading cognitively, doesn't feel very good, even when you 'ship' more.
Yeah, I can never get in the zone with LLMs either. It’s like operating in constant interruption mode. And I always thought I was good at multitasking (even though I know formally it’s an illusion)
I get it, I've gotten a lot of joy over the decades from the specific act of programming. But I also get a lot of joy from making something. I'm old enough now that I don't have a lot of my time left to "hand stitch an amazing tapestry". But with AI tooling, I do have time to try out a bunch of ideas and see how they work, scratch little itches and also just run a mad scientist library of experiments, without each experiment taking tens or hundreds of hours of coding to see how that experiment pans out.
> I'm old enough now that I don't have a lot of my time left to "hand stitch an amazing tapestry".
Why not? What is the goal of "having an amazing tapestry"? Do you need to do increasing more things in the limited time you have left and making a tapestry isn't one of those things? What will you have once you've "finished" an amazing tapestry, just something to hang on the wall and look at? How does one "use" a tapestry after it's "finished" such that the act of finishing it is the most important thing? If you've finished it, will you get more enjoyment from looking at it for longer because it was finished sooner and thus the length of time you can look at it before you die is maximized? Exactly what you are optimizing for here?
I've done hard things. Many of them have a significant amount of time that is a slog. A tapestry is going to have a lot of days of just slog work. And that's fine. Doing hard things can be very rewarding. I've reupholstered a couch by taking it down to the sticks, repairing and reinforcing the frame ("hey kids, the couch isn't designed for walking and jumping on"), enhancing the design, re-springing it, redesigning the cushions so that they didn't need readjusting every time you sat down, making new foam cushions, and then sewing a upholstery. Took 3-4 months.
But, I'm in the last half of my 50s. The project you're commenting on, apt-cacher-ultra, probably would have taken 2 full time developer years to get to where it is now, and I'm doing some pretty big changes for the next version. I literally probably have a handful of that sort of project I can do left in my life, assuming I quit my job now and work full time on it.
Let me tell you, it's pretty sobering to be faced with: "I may only be doing this once, maybe twice more in my career."
So yes, building experiments where I get to try out my ideas without 2 developer-years of coding required is going to give me an opportunity for a lot of creation that I otherwise wouldn't have had. I've spent decades hand-crafting code, I fully understand the joy of doing so.
To be clear, I've made large software and game projects over the years, but no way I'd have found the time to do a remake/enhancement of a game I loved as a kid from 1995 that has zero business case. Not without AI.
It is a robust, reliable cache of apt packages, with the additional goal of still being able to serve packages from the cache even when the upstream is down. This was started shortly after that DDoS of Canonical this past year. We've run apt-cacher-ng and apt-cacher over the last dozen years, but (a) it requires hand-holding about once a month and (b) it did absolutely nothing for us when Canonical was under DDoS.
I've put well over 100 hours of my time into it. Still running into a lot of people knee-jerk calling it "slop", but I've had 200-ish machines pulling from it for 6 months and it has worked way better than apt-cacher-ng.
I'm not really sure what to do with people who dismiss AI-assisted projects, while dehumanizing the 100 hours of my time I've put into it. I fear we're running the very real risk of both sides losing: the people trying to thoughtfully create with AI losing because of the AI, and the people avoiding AI losing because they can't keep pace.
To play devil's advocate, that sounds like the sort of uncomplicated thing that you could've manually vibecoded in 2020 without an LLM. What changed is that the LLM doesn't let you get analysis paralysis.
> you can use a language more towards the YOLO end of the spectrum - more Go or Python or JavaScript than assembly or Rust
You might want to change the way you phrase this idea. I think you meant that Go/Python/JS are more "YOLO-friendly languages" (you'll get into far less trouble if you write slop). My initial reading was the opposite. It sounded like you're saying the languages themselves are slapped together garbage.
Assembly is most certainly not "YOLO-friendly", but is more YOLO.
>You only have to implement the very small set of requests that an apt client can make
Why even write one of those? Just set up an nginx proxy cache and call it done.
But that doesn't even scratch the surface of what this project does. We already have a few simple approaches to this problem: apt-cacher and apt-cacher-ng. Neither of which were any help when Canonical was under DDoS. Both of which have proven unreliable.
As I said elsewhere, apt-cacher-ultra is a pretty subtle piece of software, it doesn't just do a naive cache, it fully understands the apt repo structure, validates the repo, and snapshots it, understands what packages your clients frequently request and preemptively downloads updates to them as part of the snapshot promotion, etc. A DDoS of the package sources, even in the middle of an upstream releasing updates, is something a-c-u will handle no problem. I've simulated this by firewall rules blocking upstream traffic. It's also proven much more reliable than apt-cacher-ng.
I've been in the software game ~40 years, I've seen it time and time again: "How hard could it be" and then when you get into it you realize there are a lot of devils in the details.
This isn't just a simple http proxy and checking if the requested URL exists on disc. It's a pretty subtle snapshotting system that fully understands and vets apt repos, detecting when the repo changes, proactively downloading "interesting" packages that have updated, verifying and validating all packages, and then promoting the repo to active when it is healthy. Plus a web-based admin interface.
The core of it is around 20K LOC, with another 40K in tests. The COCOMO model gives that an estimate of around 2 developer years of effort assuming full time work.
apt-cacher-ng, the hand-written C++ version, is 16K LOC for the core. apt-cacher-ultra does a lot more. Seems like a pretty reasonable LOC count to me.
> I've put well over 100 hours of my time into it. Still running into a lot of people knee-jerk calling it "slop"
Indeed. The number of hours is my goto defence too. So far I've put in maybe 200 hours of time into design, iteration, playtesting, QA, and balance of my game. Sure - almost zero has gone directly into writing code but this is still a major project.
People who one shot a crappy game have no idea how much work it still takes to get something really good over the finish line.
>I'm not really sure what to do with people who dismiss AI-assisted projects
Mostly I've stopped worrying or trying to convince the haters. I'm having a blast and building great things (lots more than just Asteria).
I think we'll see a lot less people willing to share if the end result is just to feed the machine no matter how they arrived at it.
I don't see why I should care about this any more than I cared about "somebody I don't like could read my code and learn from it" in the past. The frontier labs can generate or buy all the training data they need; not releasing your app isn't going to hurt them in the slightest.
I get not wanting to contribute to closed, commercial models. We need to hurry up and get Folding-at-Home style distributed community model training going. At that point, I’d be pretty happy if my projects contributed to improving community models. Even if commercial models benefited too.
Those were exactly my thoughts before creating boomkat[1], a JS engine written from scratch.
Having been a UX-focused dev for my entire career, I knew only the basics about parsers and compilers, but have enough experience to grasp what each piece should be doing. At the beginning it was just a fun test, but it got progressively more serious; it now implements 100% of the latest spec, beats QuickJS in performance, and surpasses V8/JSC in test262.
It took me four months, and I imagine it would take me a single month now that I’ve learned a lot. Someone who already knew what they were doing, and with the right orchestration could achieve this in weeks at minimal cost. I really think we are in for a cambrian explosion of software, enabling things that were just always a little out of reach before (like why can’t most of your devices really talk to each other, in 2026).
I understand the feeling, but would you not have read other engine’s code to understand the problem space and existing solutions too?
The architecture is different, the language is different, implementation choices are all mine. I don’t think you’ll find any code that is a duplicate of other engines - happy to be proven wrong here.
Exactly. A common LLM criticism is that they "steal copyrighted code" (or other IP), but then often the same people say that code or music should not be patentable because it's all the same basic patterns just combined in different ways, so nobody should have a monopoly on that.
Count me in the second camp. I've been writing software for 20+ years, and I recently built a low-cost Google Voice alternative because every business VoIP option I looked at was either overpriced or missing something I wanted. Without AI, that's a project I'd never have started. With AI, I built it in under a month, and it has a few features Google Voice lacks. I even have some paying customers now, though that wasn't part of the original plan.
It would be nice if we could get a Show HN category specifically for this. I feel like often times when people share projects (whether on HN or otherwise) they're immediately downvoted and cast aside as "AI".
Can we get a forum for sharing project that were _proudly_ built with AI due how ambitious they are?
Building a procedural open world at the scale of a flight sim in UE5, in a month wrote 5k prompts, spent 40B tokens and will likely take at least a trillion more over the next year of full time dev work.
Big solo projects exist, they're just not coming out as frequently because of, uh, how time works
If you got into software because there was something you wanted to make with it, now is the best time to be doing it. I can't stop building and might need the max plans.
Yeah, I think people are not sufficiently appreciating the value of knowing what to tell the AI to do, and how to tell it. (Or the value of having the AI help you figure that out.) In previous decades, we had to know this stuff, it just usually stayed inside our own brains. Perhaps the incentive to type[1] it out is also helpful.
[1] Yes, lots of people use dictation instead. I feel like speech-to-text loses you the benefits that speaking has over writing in terms of communication power, plus it's inefficient. I'd rather harness the benefits that writing (really, editing) has.
> I have a similar thought about "there's no reason for software to be slow" BTW; in many cases, if you use AI to speed up some flow, you will add a bunch of messy code that will be overfit for the use case you tested on and will neither generalize, perf-wise, for all the use cases you should care about, nor will be maintainable upon future changes.
LLMs have hardened hundreds of apps where I work.
Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so.
Ofc, if you have:
- Functional tests - you'll be able to see it in the execution times of specific APIs
- Stress testing - performance profiling is the most important output artifact
> Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so.
Claude in its current Opus 5.5 form has made some wild reaches in response to reasonable-seeming prompts. For instance: "this error is getting swallowed, make sure the real termination message exposes the root cause" -> discovering that the issue is actually in a third party library that isn't exposing the original error except so through logs, so doing some hackery to inject a log-capturer that gets the stdout, buffers it, and looks for the message in order to re-throw based on that...
And it can demonstrate that working, but it's added some fragile and/or unintended consequences like (a) string matching on a particular WARN log message of a particular version of the lib, and (b) buffering those logs such that there were now cases where they would never make it to the actual output stream before the program terminating.
It's certainly capable of being used smarter than that, but it's also really easy to end up with messy fragile stuff if you get lazy about reviewing the output.
> "this error is getting swallowed, make sure the real termination message exposes the root cause"
I think this illustrates a fundamental objection the anti-AI crowd raises.
The prompt requires no understanding of what's happening, before suggesting action. It's required that a PR review that has a solution, has to have a corresponding explanation or it's marked needs work
I think there's some nuance here though between "fully anti-AI" and "be careful with that power saw."
That example I mentioned didn't make it to production. It got noticed and fixed more properly by the person who submitted the first prompt before it even went to PR.
But a lot of times things in that same vein can be solved sufficiently with a "dumb" prompt like that, so a one-line prompt to get a PR drafted in the background for the dumb stuff can be a pretty good time saver.
The art is not skimping on your attention to the bigger or more important stuff so much that all the time you save on first getting code written is lost by cleaning up stuff like that...
As a very amateur woodworker in addition to my day job, I have always thought the power tool analogy is a good one for LLMs. The tools don’t remove the need for skill and being very very careful with how you use them. You can work faster but do a lot more damage also.
I used Opus 5.5 to figure out that a language model we were serving at work for internal use (we don't really serve models, we only use this internally because it processes sensitive data that we can't send to external endpoints) was being bottlenecked by CPU contention on tokenization, by having Opus run in an autoresearch style loop.
Opus's first proposal for a fix was to spawn multiple Python processes and build a load balancer between them in Python. At first I asked it why it wasn't using haproxy and it said that haproxy would be an added dependency and that the overhead for this kind of thing in Python would be negligible. I knew this was idiotic but wanted to test this out, so had Opus run two experiments in parallel. Sure enough an haproxy load balancer was much, much better on HTTP load balancing than Python code was.
This is the kind of thing that if you're unfamiliar with how networking code works, the models can autopilot into bad decisions that are verifiably correct (higher throughput than the original CPU-bottlenecked implementation) but much short of best practice.
Are you doing CPU inferencing? For small models you could check qxotic.ai which is a whole inferencing stack for many popular open models in Java, which can beat llama.cpp in speed in some cases. Its tokenizer toknroll is faster than tiktoken, which is what made me think of it for your use case.
The advantage is that you don't have issues like the GIL or whatever, so there's no need for all the complexity of load balancing between multiple pythons.
Thanks for the pointers, I'm gonna look into them.
I'm not doing CPU inferencing but I'm doing some tokenization in Python which is CPU-bound. In all honesty I started on this project to scale the model and did not build it myself so have been trying to read code and walk back the approach. I've been thinking about rewriting the Python glue in Go to avoid issues with the GIL.
> but it's added some fragile and/or unintended consequences
In python, in a co-worker's code, it seems to significantly prefer "some_dict.get('key')" over "some_dict['key']". For the non-python-users, the first one will return None (equivalent to null) when the key is missing, while the second raises a KeyError. It was being used in a whole bunch of places that would cause problems (bad data instead of errors) if it did receive None. Some of these keys were actually optional and it does makes sense for those, but it looks like whichever model he was using just repeated the pattern everywhere instead of just where it was appropriate.
I don't get it... What's the problem? I too prefer getting None as opposed to a key Error which would prolly necessitate a try..catch as opposed just checking for None. I'm having trouble reasoning up a situation where raising a keyError would make any sense over a None for data structures like dicts that could return a value or no value! Help?
Or you know, test if the key exists before using it. The key could exist and be None, representing a legitimate None at that key. Or the key might not exist and asking for it is a bug.
Use a defaultdict if you must have all keys optional. Using get() everywhere is buggy because it masks illegal key use.
There are times where you want to check for existence before fetching a key-value pair, and there are times where you want to automatically throw an error if the value doesn't exist.
Both have valid use cases. It's weird to be sarcastic about it.
Oh man, you're giving me flashbacks to a vibe coded utter mess. Gets were a big offender. It seemed to have no discipline to commit to a data format, added all kinds of optional parameters everywhere, was also doing truly insane things like having contingency fallbacks in case some library it wanted to import wasn't where it expected, sometimes even importing things in the middle of a function.
This to me feels more like a developer skills issue than a problem with the LLM. At my day job, we banned using untyped data structures like this entirely well before LLMs because no one could read code that passed them around.
You could use a data structure that better articulates an optional field, like a dataclass with type hints or a pydantic model. Then you, your coworker, and the agent alike, aren’t guessing at whether the key’s value is optional.
Another example in this vein is having many optional parameters on a function or api route, that drive behavior deeply nested in the application logic. Or maybe they were there for testing and never deleted. No one comes across this code next and understands it easily. How could you expect a LLM to understand it, either?
I find it funny when people blame the LLM for dog shit code, but at the same time have a pollock painting of code they load into its context, and are like “put a person in the horse and carriage!” And the LLM is like “bro I just see dots and squiggles but you asked so boom!”
The square bracket version tells the reader it's required, the .get version tells the reader it's optional. Kind of the reason both exist in the language (the .get version has an optional second argument to return instead of None when the key is missing).
> BTW; in many cases, if you use AI to speed up some flow, you will add a bunch of messy code that will be overfit for the use case you tested on and will neither generalize
Be careful to not frame this as a feature of AI and not a feature of the approach people have taken that you have observed, it doesnt have to be this way.
Also, nothing a good engineer cannot fix. Instead of just prompting an LLM with something lazy like "eee make it fast", you can tell it to run perf trace, analyze the output, give you a rundown, propose ideas, and then you can go back and forth with an LLM until you arrive at a theoretical solution that sounds good before executing.
I think if you do iterate on cycles of development and hardening maybe this can be done, but LLM code, specially by Claude, has been too verbose for me.
Other models are less
I suspect it's far more about workflow and developer attitude. Messy code stays because you don't object to it staying; overfitting happens in code because it happens in prompts.
For me the most recent Claude models are consistently delivering complex PRs that only receive minor and nit level feedback from multiple automated AI reviewers. I rarely plan anymore, but still submit fairly long dictated prompts. It took me a couple of weeks to realize this was the case, and I haven't done any analysis on pre-5.5 PRs, but it definitely feels like they quietly crossed some kind of new threshold of quality and accuracy in coding.
"[..] the last time I taked to him about pgrust verification, he mentioned using Kani to verify some parts of the code. He's since switched to Lean and has been using Lean to verify things that are too complex to do in Kani. This would be another topic for another post,"
I'd love to read that post!
I understand how to use Kani. I suppose Rust with Lean involves Aeneas, but this is over my head. I'd love someone to write this up, not only the mechanics but also exploring the current practical limits of it.
Happy to chat about it. I looked at Aeneas, but as described, it only supports safe Rust. I also need C support so I can prove both the C and Rust code
Right now, I wrote a compiler that takes C and Rust code and compiles it to Lean. Then I have an LLM write a proof that the C and Rust code behave identically. I've been able to prove equivalent behavior for about ~70k lines of C code with pgrust.
The issue I've started to encounter is that the context needed for each incremental proof has kept growing, and things have slowed down dramatically. My hunch is that the speed is the time it takes to prove a line of code is on the order of O(n^2) of how much you've proved so far
I'm looking to see if there are ways to shard things so the required context scales better. Today I was going through the formal verification work Anthropic and Theorem published a few days ago, and it looks like they used some sort of orchestrator to manage all their proofs and ensure good clustering of similar code. I'm seeing if I can get an approach like that to work
It's just difficult enough that I think it's doable if done right. Half of me is debating if I should wait until the next model release because any improvement in model performance will help a ton
> I wrote a compiler that takes C and Rust code and compiles it to Lean
What if there are bugs in this C,Rust->Lean compiler? Anthropic are able to sidestep this by reasoning at the RISC V level for which its easier to develop a correct semantics.
> I find it understandable that, every time I see pgrust discussed on a news aggregator, most people dismiss it as vibeslop garbage because almost all of these rewrite projects are slop. If I didn't know Malis, I would make the same assumption, because who has the time to look into all of these projects? Because I know Malis, I didn't bother to look at it; I just trusted him
Perhaps a poor choice, given just yesterday pgrust was removed from ClickBench for cheating the benchmark in three different ways (hand-rolled code specifically targeting each of the benchmark queries, caching, and being unable to execute queries outside of the ones tested by the benchmark).
> Cheaters denying they cheat is a matter of course.
What happens in an environment of cheaters is that cheating becomes so commonplace, the competition becomes one that assumes cheats are enabled, and then everyone involved either denies cheating or is silent about it because IYKYK and if you DK, you don't need to K. Look at bodybuilding, which is full of men (and women!) absolutely juiced to the gills getting on Instagram and assuring everyone that their physique is totally natty, bro, just hard work and proper nutrition.
Programming is headed in that direction. LLM use, even to the point of "vibeslop", is the new default, and while LLMs do overindex on benchmarks, our benchmarks are going to end up overindexing on validating whatever public opinion thinks is "great" at the time, irrespective of whether it actually is, so "cheating" as we know it will go undetected, and certainly unpunished if it is detected. I don't know what the equivalent of falsely claiming you're natty is. Maybe saying "I wrote this" when you wrote it about as much as the Pope painted the Sistine Chapel fresco?
Right, exactly. Its like 'look I know a lot of people have ai psychosis and are vibeslopping things left and right but my friend is _actually smart_ unlike all those people who are totally not actually smart'
You can run the binary with PGRUST_GRAVITY_REPORT=1 which logs the code path hit for every query. You'll see that all the code goes through the general query path. We did have hand-rolled code in the binary, but we used it for testing. The code is not used when running the benchmark. We also did not use a results cache. Warm runs still scan all the data. You can verify all of this
You are right, though, that it did support a narrow set of SQL. It supported scans, group bys, sorts, and filters. That's enough to run all the queries on ClickBench, but failed on functionality not tested by the benchmark like subqueries
You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?
The more you make excuses, the more we get suspicious
(copied and pasted from another place you gave this unsatisfactory answer)
I read it as that Dan Luu and Michael Malis are friends, or at least fellow insiders who believe good things about each other and wouldn't think about hurting each other's careers or reputations. Especially over inconvenient truths.
> For real judgements on database products, I'd look to https://jepsen.io/. That author tends to be refreshingly straightforward in a field where many vendors love to cheat by different names
As far as I'm aware, Jepsen solely focuses on correctness (which is more than enough for someone to do!), not performance.
Update: ClickHouse finished the preliminary benchmarks for 0.4-beta[0], the version we've open-sourced. If you compute the geomean across all queries and instance sizes, it comes out as 7% faster than the 0.4-preview entry[1] that was accused of cheating.
To give you a sense of how fast it is, pgrust on a c6a.2xl is faster than ClickHouse running on a c6a.metal, a machine with 24x as many cores and costs 24x as much.
It’s sad the amount of times I’ve heard super talented programmers say “ofcourse we’re not gonna build another X” then proceed writing a wrapper around X and pretend that’s a product.
>every time I see pgrust discussed on a news aggregator, most people dismiss it as vibeslop garbage because almost all of these rewrite projects are slop.
I understand being predisposed to expect a poor quality half arsed effort for projects like this. I don't really have a problem with that. There is a lot of crap out there.
What I find rather offensive is when people declare something to be poor quality and half arsed before they have taken a good look at it.
It's one thing to think something is probably crap so I'm not going to bother even looking. It is something completely different when you think something is probably crap so you tell people that it is crap without checking.
Because it's hard to trust something. After all that's why you trust a brand more than others without trying all the products every single time. You can thank all the AI slop and kool aid promotion for the lack of confidence.
this feels reasonable. for communities like r/selfhosted there has been an influx of new projects, many of which initially get dismissed. this more generous attitude can likely go a long way.
I'm building an open-source Shopify for every vertical and built a software factory to do it. I envisioned this before LLMs, but LLMs are finally making it possible!
I think we should focus on writing the existing software better before being more ambitious. The absolute wave of "ai slop" is from people who are "more ambitious" now. Why do we want more of that?
I'm being more ambitious in that I'm working on projects that I had sidelined for literal decades because I didn't have time for them. But I'm writing the same things, just faster. And probably better, rather than just what I'd have done before.
And I'm being slightly more ambitious in that I'm using languages I haven't used before, like Rust.
But when I hear that a non-programmer wrote a new ai-assisted (vibe or not) thing, I walk away and wait for the it to mature, be surpassed, or find out it's an absolute shitshow. An unsurprising number of them were shitshows and it came out fairly quickly after I decided to wait and see.
Do we particularly like the existing software though? So much of it is just about making money, because until recently custom software cost too much money to make without investors, and what do investors want? returns.
Now that custom software is cheap (if you can tolerate a bit of slop here and there), it seems like there's an opportunity to do some important things that weren't being done before because they're not profitable--and you can't get at those things by incrementally improving the old stuff.
LLMs are great for being nerdsniped. I started work on walshadow (reading pg wal into clickhouse) to demonstrate the project's infeasibility, but pieces started coming together into something reasonable & order of magnitude faster
The project would've been impossible for me without LLMs. & even with them there's an argument that this project is pushing complexity limits too far. But at least with ETL there's a clear feedback loop to build on
Thank you for introducing me to the word "nerd-sniping"[1].
This is, as you say, exactly the paradox of having ourselves assisted by LLMs. We are no different from our cats. Except imagine the cats start making the laser lights for themselves.
LLMs have introduced me to things like photodiodes and specific economists I would likely not have found on my own
I do however wonder about specific research priority/project from labs' solving their own problems leaking into my chats. I noticed one month that Claude really started harping on about "legibility" and suggesting Seeing Like A State to me, and saw it like any other interesting suggestion/insight.
Now I see a lot of people mentioning "legibility" and think that was just some weird attractor state or useful vocabulary term for being an LLM (that literally can't see certain things or be observed easily!). It's a weird feeling, because nobody tried to trick me and in fact it objectively helped me to acquire useful information. I just have to wonder if other people are having the same conversation and there's really nothing special about it - maybe Anthropic just really liked that book right around when they were doing a lot of RL
Not only that, was the intent just to give Claude the vocabulary to be an LLM in a company that wants it to be legible, and apply that book to managing it, and we're either intentionally or unintentionally memetically downstream of that? Or was it just extra likely to be mentioned because it's a genuinely helpful book - either because the AI learned over time that it was (very good!), someone just wanted to recommend it to more people to help them (~good). I worry that the "intelligent conversation" or "wow look at the agent go" can give us very poor epistemics
We should be more ambitious, but we need to learn how we can be ambitious with AI, and what value we can create.
AI can take us from 0 to MVP in a prompt. It can fill in gaps of knowledge and allows someone who knows half of the stack to build the whole thing nearly seamlessly. These are superpowers but don't by themselves lead to new products.
What AI cannot do is remove the world of complications that happen after the MVP - product feature tradeoffs and choices, how to handle integrations and customizations, how to serve multiple types of users, how to communicate and market the app, how to handle security and data storage, how to deal with customers and bugs, etc. All of these need to be considered and acted on by a human in some fashion. AI can help with each concern but can't solve them without understanding the concern and determining how to frame it in a prompt.
This is why we have a glut of amazing demos that go nowhere while we figure out how to build software differently. This will take some time and I imagine the result will be software heavily-structured with a bit of AI reasoning woven throughout, not an army of agents and sub-agents burning infinite tokens.
Agreed. Been experiencing this firsthand with an app I've been building myself. Vibecoded a working prototype ridiculously fast but then came the optimization issues. Since mine is very hardware dependent every different brand, oem stack, processor, video card, and every little thing changes how my app functions and a lot of it isnt even documented properly. Now AI is still very useful here, but you actually need to know what even to ask and fix in the first place
If you're being ambitious enough, you shouldn't be able to there in one prompt. Ambitious work with AI is done 24/7 for months and guiding it continuously, because it's not good enough to work autonomously for that long without going off the rails.
I haven't yet seen any significant products made with AI that are at least used long-term. All these browser demos, from the Adobe killers to Star Citizen, are just bells and whistles that I close after 30 seconds of use.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
And I feel that sums up my feelings on AI this and that. Just as the wood and clay contain the sculpture within and it's the artist's duty and privilege to reveal that. So, is elegant software exposed from the conceptual mass, rather than built up.
The AI zeitgeist currently is 'how many features can I add' because we've tied self worth to work output instead of some other more personal or human rubric. AI will happily pile more and more and more code on your plate because it's a buffet. It's gone through reinforcement cycles guiding it to add whatever feature you ask. There is no training for elegance or careful considered design. Nobody is teaching this generation of LLM restraint.
The safest code is that which never runs. The most elegant feature is that which is not necessary.
"The safest code is that which never runs. The most elegant feature is that which is not necessary."
I assume you run GNU Hurd as your OS? ...
In general I very much agree to the quote of the Little Prince's creator, but I am not sure if we mean the same by it, because you seem to value code elegance more than adding useful features?
Now "useful" does the heavy lifting here, but my point is a useful feature is useful, even if it is achieved by the most ugly unmaintainable code. And what counts as a useful feature will depend on who you ask, but in general you should ask some users. (They don't care how the code looks)
And sure, they do not enjoy a pile of garbage of new features that only work sometimes, but managed to destroy their existing flow. But "Nobody is teaching this generation of LLM restraint" this is hyperbole and up to each developer. There is no need to let the AI run on auto for hours, this is only one way how to use that tool. The other way is, you make the design yourself - and let the AI implement it.
My interpretation of "be more ambitious" is not only give it harder problems, but be more creative about what you ask. The problem is that most of the MVPs that people ask for a boring and lame. AI can help us make things that blow your mind, things that we would never build because they don't make sense, but the cost models for code generation have changed.
I don’t. I think we’ll zoom right past that benchmark. In a couple years your grandma will be able to build real, ambitious software with AI better than you can today. Shortly after that AI won’t even need Grandma.
Speaking only for myself, I have found that using an LLM has allowed me to add significant utility to the apps that I ship.
I am not thrilled with all the coding decisions that it makes. I would definitely do stuff differently, but I have learned not to pop the hood and mess with the engine, myself. If I really don't like something, I ask the LLM to change it.
It's worked for me, but YMMV. I'm just one guy, shipping relatively small apps.
> Do you still feel responsible for what you ship?
Absolutely. If it has my chop, it's my ass on the line; no one else's. It's the way I was trained, and it's the way I worked; my entire career.
It doesn't matter how the stuff I ship gets there. It may be my own code, it may be a contracted pro, it may be an unpaid intern, it may be an LLM, it may be a howler monkey, banging on a typewriter.
If I sign off on it, and ship it, it's mine.
But that kind of attitude is considered "quaint," these days, and that's from long before LLMs were a broken rubber on the drug store shelf.
> Would you be ok with someone reverse engineering what you ship and then releasing their own version of the app?
Absolutely no problem. If they can do better, then more power to them, and I'll step out of the way. Might want to take a gander at the kind of stuff I write, and who I write it for. It's no secret.
You're obviously wrong, and people will be around shortly to tell you how you're actively delusional and not doing what you observe yourself to be doing. Stochastic parrots, I think they call themselves.
I’ve been coming around to the same conclusion. We are really just scratching the surface of what we can do with these new tool1. The windmill I have been tilting at is creating a c++ compiler[1] and the most recent version is able to compile about 7x faster than gcc[2]. I don’t know that this is super-useful because people aren’t writing much in c++ these days, but as the article mentions, faster rust compilation would accelerate agentic coding considerably. I’ve just started tackling rust and I don’t have a confirmed result yet but early testing makes me think I can find a 4x+ speed up here.
For reference I blogged about the previous version here which was ahead of gcc in compile time and produced 50% slower compiled code here: https://medium.com/@vishvananda/agentic-c-compiler-redux-5d1...
I haven’t updated with the most recent results but the current v5 reference has the perf stated above
I think the CSS they use (which isn't much) is good enough (and "img{max-width:100%}" really ought to be the default setting even if the user disables CSS).
Software is already too ambitious. It's beyond our ability to write correctly, reason about or manage securely. When we can get to a point where we don't have a level 10 CVE every other week, maybe we can talk about getting more ambitious.
Who is “we” here? Every company and individual out there? Do you anticipate a solution to these issues you mentioned that would work to solve all the world’s problems?
I'm not too familiar with synths, but aren't they good yet?
In the guitar world, you can get really good (for most people) modelers that emulate a good amp sound for like 100 bucks, and for 10 times that you can get _excellent_ sound.
My expectation would be that for similar prices you could get really good synths as well by now.
Synths that replicate real instruments are almost always sampled, which means they're just fancy recordings of real instruments. The problem with a recording is you are limited in how much you can adjust it; you cannot customize it as much as you can with algorithmically generated sounds.
I think this is simply because nobody knows an algorithm to create realistic piano sounds, etc. There are some good attempts, but they are paid and expensive. Hence my suggestion here.
Behind the link "slow software that the creator is claiming is fast" is the following text:
"funnily enough, I have some faith in some of the projects that people are the most skeptical of, e.g., every time I see pgrust somewhere, there are a lot of skeptical comments. But, without having looked into the details of what he's optimizing, I would trust that they're not doing something shady with their benchmarks because Michael Malis started the project (and is still involved)"
This aged like milk. pgrust was caught cheating on all benchmarks this week.
The author claimed that it was an honest mistake, but looking closer at the original PR removing it, his explanation doesn't make sense.
Maybe what's happened is that their bots reward hacked their way into special-casing the benchmarks without a proper audit from the humans involved, and now they're doing vibed damage control....
This comes up a lot in People Management. An engineer cheats or does something that qualifies as cheating in any reasonable person's eyes. Their manager benefits from that shortcut, pretends not to see it, and if it comes up, takes the coder's technical excuses and shops it around.
No one "lies" per se, the guilty parties are merely engaging in a beneficial deception turned a cover-up.
Where's the source code for the version that was already caught cheating? Prompting Claude to remove the evidence of cheating and then publishing that doesn't undo the cheating.
If you run it with PGRUST_GRAVITY_REPORT=1 it will report the code path hit for each query. You can see that all the queries go through the general query engine.
The binary does contain hand-written kernels in the irprobe files. These were used for testing. You can validate that when running the benchmark, those files are dead code.
The engine supports a narrow subset of SQL: scans, group-bys, filters, and sorting. That's enough to run ClickBench. It doesn't support e.g. subqueries which is why some of the follow up queries failed
You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?
The more you make excuses, the more we get suspicious
(copied and pasted from another place you gave this unsatisfactory answer)
the first commit has 400k files, the other two more than 1000 each, if you are going to ask others to audit this scale of ai generated code, can you tell us what you have done to audit it?
What I have seen is your Ai adding a lint test to make sure it doesn't cheat again. Are you personally aware of this file? How can you ensure it doesn't alter it and reinject the hand rolled benchmark queries? Will you be reviewing changes more thoroughly going forward?
You can run it with PGRUST_GRAVITY_REPORT=1 and it will log the codepath that was hit for every query
On the lint, yes, I'm aware. It's one layer of defense. When we were prepping for the 0.4-beta release, we generated a large number of fresh queries and made sure the engine runs them and performs well across all of them
You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?
The more you make excuses, the more we get suspicious
> It's one layer of defense.
Needing to put in tests to make sure the Ai doesn't cheat is an interesting development in software development. I personally see it as a big red flag and evidence the machines are not going to replace human developers. It's categorically slop or the opposite of quality and care in development.
How is anyone supposed to audit that? I doubt you’ve looked at even a small fraction of the code, if any. Especially since this commit is two days after the second. Pure vibes.
Madness. Makes me think back to a coding horror article from 2006 (I think) where it was accepted that even 500k loc codebases were generally incomprehensible by a single engineer. Now we’re at the stage of almost 500k FILES changing on a single commit…
And people still seem to believe they know what’s going on…
HN is waiting for the release of the source code of the 0.4 preview build that allegedly cheated the benchmark. So far, the people (person?) behind pgrust hasn’t committed to releasing it.
Even he’s not ambitious enough. Set the boundaries according to the hardware – billions of ops a second . Your rewrite should run at least 1000x faster than the handwritten version , with 1/10 resources.
I noticed my cloud images had 150mb ram wasted by vendor slop. AI rewrote the functionality into a few mb .
We’ve had slop long before AI . What you produce now is up to you
I’ve been using the latest agentic frameworks and have come to realize that the discourse around vibe coding and slop really needs more nuance.
There is a gulf of difference between someone who doesn’t understand how to program “vibe coding” software and an experienced software developer using ai to write code with heavy direction, review, and best practices.
Today both would be said to be “vibe coded” but we really need to differentiate them. Also, if everything I’m hearing from people is true, it sounds like most corporate code is now completely ai written in the latter way I described. It’s interesting we don’t hear commercial software being called slop yet. Maybe it’s coming.
In any case, ai is far more capable than I realized. Not sure what to make of it.
637 comments
[ 0.21 ms ] story [ 128 ms ] threadOr even just a nicer font, maybe?
We should be more ambitious in letting the browser software control the presentation according to the user’s preferences. This is not facetious. We should use the increased ease of building software to create software that is flexible, empowers the user, and accommodates different user preferences.
https://news.ycombinator.com/newsguidelines.html
By the way, I'm still waiting for Meta and Google do something about Instagram and Chrome so that my CPU usage doesn't go to the roof.
I've been seeing too much "I've been coding for decades and what I've always done has be reduced to telling AI to do it for me."
and not nearly enough "I've been coding for decades and recently worked hard for months with AI's help to make something I would have never considered possible before."
Much easier to complain that you are bored than to step back up to high-effort with your new fancy tools.
You end up with the government deciding how much bread each person needs, how much the bread will cost, how much to pay a person so they can pay the defined price for the allocated amount of bread, etc.
Either utopian claims of an AI and robot-powered future are right and we don't need money because you can just have what you want, or money and resources will still be scarce and we will continue to compete amongst ourselves for resources.
2) America in 2026 is not the USSR in the 20th century, so even if they did, our circumstances are very different from theirs.
3) UBI was only the first suggestion; you completely failed to address the other and then jumped to a black-and-white conclusion.
The general thrust of my proposition was that people shouldn't have to submit to an artificial system of manufactured competition and unnecessary "productivity" in order to access goods that are objectively abundant. When people realize that and make the necessary compromises, they won't have to worry about shipping useless AI-assisted slop for "income security" and can focus on using AI to build consequential and useful software.
Please do not get bogged down in whatever kneejerk anti-UBI thought-loop your misaligned amygdala is screaming at you.
2) I didn't say the US is the USSR. I pointed to a clear example where a UBI-like structure was tried and failed. Feel free to call out specific differences that may help it work better today in the US, I'm genuinely curious despite my skeptism.
3) I can respond to the others as well, but that isn't necessary to have an interesting debate or discussion on any one topic. If one was required to respond to all raised ideas they could try to shut down all conversation by threading together a long list of hard to discuss topics, avoiding responses to any one topic.
I do agree people can avoid having to submit to AI or ML systems though. We ultimately all make our decisions, some more impactful than others, and if we end up in a dystopian future with no jobs and AIs/robots in charge of the world we made that bed for ourselves.
I'm not bogged down in any kneejerk reactions and I'm not parroting what I've heard air bags saying elsewhere. I've read up on the topic, the history of the USSR, and read Marx writings (well the translations, I speak some Dutch but no German). We may disagree, but my views aren't uneducated reactions.
2) >I pointed to a clear example where a UBI-like structure was tried and failed.
You did not.
3) That's not applicable here. Why did you respond to the UBI issue only?
>I do agree people can avoid having to submit to AI or ML systems though.
I didn't speak to this at all. The "artificial system of manufactured competition and unnecessary 'productivity'" is independent of AI and ML and has existed for several decades.
>my views aren't uneducated reactions.
See 1.
My conclusion is that you actually aren't interested in a conversation. You haven't responded earnestly or considerately to anything in my initial post except the portion suggesting UBI, which you dismissed with a faulty presence.
Here is my suggestion: talk about something else from that post. Anything else. Do not revisit the UBI topic.
I did respond earnestly, whether you accept it or if I'm explaining myself poorly. You have yet to propose how a UBI would actually work, or pointed to an example of it ever having worked in the past. Socialism and Marxism have been tried, the don't work. And yes, UBI is an idea that goes back to Marx's writings.
I 100% agree people need a culture of looking out for each other. I'd argue that has only successfully happened sustainably in smaller communities, and from the bottom up rather than the top down.
Take care of your neighbors, and ask them for help when you need it. You aren't proposing this here so I'm not arguing with you, but it never works for long when the "help" comes from the top down. For a short period we may actually see the government take resources from some to help others, but eventually that is corrupted and they stop at the point of taking resources and power.
I was a fantastic IC and built really amazing software. I'm an even better AI-empowered engineer.
The old era is dead. The new one is exciting.
Employers previously hired you because cheaper alternatives such as offshoring were impractical…
Now the AI is cheaper, faster, and better than domestic labor and offshoring while still hosted domestically…
Some will feel one doesn’t need an experienced rockstar to babysit an AI…
In about an hour I just solved about 80hrs worth of personal coding/debugging with a portion of a $20/month Claude subscription… Frankly it makes all my knowledge and experience feel kinda worthless… I only gave it a few sentences…
So then, given your knowledge and experience, what challenge would require 80 hours of real, focused work out of you using today’s tools?
The amount of sympathy programmers are expecting others to feel about their problems has been kicked up a hundredfold now that its their jobs that have been threatened by AI. Their tribe feels pain more deeply than others, I guess.
My positive feelings about AI are marginal; my feelings about its performance and the power of the people who scheme to control it are very mixed. My negative feelings about the whining of the most coddled profession on the planet outside of finance are intense.
The problem is that making CRUD apps is not creative, and even if AI plateaus at mediocre, it will still replace a Rails monkey. If you are creative, AI has opened up a world of possibility and productivity, and you painfully feel the limitations and the stupidity of the current level of LLMS; but if you're a mechanic, it's over - I'm pretty sure that was the keynote at the last Rails con. Sorry. Hope you didn't spend all of your massive incomes on toys and rent.
Well, just wait then, lots of other professions will soon get to realize the same sort of pain, so you'll be able to be similarly dismissive and condescending to them, too.
A lot of people don't realize that the frontier AI companies are so focused on automating software development first because they are all racing to be the first to get to RSI. I don't know if RSI will actually happen, but many, many other professions will soon be in the same boat. Mathematicians have already felt the pain, and those mathematicians who aren't the few who have tenured professorships are certainly not (generally) some of the most coddled professionals.
But lots of folks low on the salary totem pole (copywriters, paralegals, etc.) are already being hit hard by AI and that blast radius will continue to grow.
And? Who are these people that need all this sympathy from internet strangers? Grow the fuck up and go solve your own damn problems. I can’t stand these “I need internet strangers to tell me that my life is, in fact, hard” people.
My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career; free flow of information over the internet and commodification of spreadsheets changed all of it. From my parents' generation, I know practical effects folks who became unemployable once movies went to digital effects; engineers who found their draftsmanship skills obsolete. Folks with near-photographic memories whose entire superpower was destroyed by computing. I personally grew up in a blue collar community that was income depressed because its labor became commodified, though that was due to mechanization.
The only thing I don't really agree with is where you say "My parents-in-law started their careers as management consultants. The job in their time was much higher prestige and much higher value than it was when I started my career." I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs (for MBA types anyway) there is, so I just don't know what you're talking about with this one.
Sorry, I didn't mean to imply that. I just meant that part of the unique feelings in the air for software engineers is that this is the first time we're facing this.
> I still think of management consultants as some of the highest paid careers around, and getting a partnership track job at one of the Big 3 is one of the most desirable jobs
There's plenty of other jobs the MBA type could get into these days which are also high prestige and there are now many more tiers of management consultants. The elite folks at McKinsey are still high prestige with high salaries, but your average Accenture or Deloitte consultant is both pay and prestige wise about the same as an average knowledge worker. Plenty of VCs, fund managers, and investors are MBA-types. The explosion of private capital means there's a lot of opportunity to manage private capital; private capital markets were just much shallower 50 years ago.
its a tribalism problem, but one of trying to uphold the current tribe system while theres a pretty obvious new tribe system replacing it
Give it some time and you'll be adding to that list.
In every war, countless innocent people die due to mis-targeting or other failure modes. At times the casualty count there exceeds military deaths. It is so common that we have a term for it: collateral damage.
So the question is: does AI lower such damage?
If AI had not been used in the attack on Iran, history indicates the death tolls in this regard would likely been much higher.
Not making a political statement or implying support for the war. Just making a point that these comparisons are more complicated that your example.
> If anything, it should make me more optimistic, not less. If you have an idea, you can turn it into product within 30 minutes, no matter how complicated it is.
There is no product in that anymore because someone else could copy your product in the same time.
This fallacy is second to only every SME believing their jobs are going to be the jobs AI can't replace.
You have QA engineers chiming in about how "QA" isn't going anywhere.. On threads talking about code, tests, and PR reviews being completely automated.. PR reviews being a quality assurance activity..
Cancer deaths are going to sky rocket before this is all over.
https://globalmecho.com/lights-out-lab/
AI has essentially stolen my career from me. I _liked_ having to solve complicated problems with software, I enjoyed having to get into the nitty gritty to get things done. I never really cared that much about the actual business problems I was solving, so moving up a layer of abstraction to be some sort of bastardized product manager/architect does not scratch the same itch.
OTOH, for solving problems I care about, AI has been a god send. I can achieve things that I would have never had the time for.
Now I must pay for codex/claude, and that money goes to billionaires psychopaths. So that sucks as you can imagine
My understanding from reading the lwn article is Linus's implication is more specifically about filtering out people that cannot write code without LLMs or the willingness to spend the money on the tokens required to uphold the quality of the kernel. He does not want to push out developers that do not use LLMs.
I think this could be achievable with LLMs if they had a much higher token rate. That way you'd have less downtime and could work on the problem more aggressively. How it's designed to work now, offloading cognitively, doesn't feel very good, even when you 'ship' more.
I get it, I've gotten a lot of joy over the decades from the specific act of programming. But I also get a lot of joy from making something. I'm old enough now that I don't have a lot of my time left to "hand stitch an amazing tapestry". But with AI tooling, I do have time to try out a bunch of ideas and see how they work, scratch little itches and also just run a mad scientist library of experiments, without each experiment taking tens or hundreds of hours of coding to see how that experiment pans out.
Why not? What is the goal of "having an amazing tapestry"? Do you need to do increasing more things in the limited time you have left and making a tapestry isn't one of those things? What will you have once you've "finished" an amazing tapestry, just something to hang on the wall and look at? How does one "use" a tapestry after it's "finished" such that the act of finishing it is the most important thing? If you've finished it, will you get more enjoyment from looking at it for longer because it was finished sooner and thus the length of time you can look at it before you die is maximized? Exactly what you are optimizing for here?
Let's call it "Joy".
I've done hard things. Many of them have a significant amount of time that is a slog. A tapestry is going to have a lot of days of just slog work. And that's fine. Doing hard things can be very rewarding. I've reupholstered a couch by taking it down to the sticks, repairing and reinforcing the frame ("hey kids, the couch isn't designed for walking and jumping on"), enhancing the design, re-springing it, redesigning the cushions so that they didn't need readjusting every time you sat down, making new foam cushions, and then sewing a upholstery. Took 3-4 months.
But, I'm in the last half of my 50s. The project you're commenting on, apt-cacher-ultra, probably would have taken 2 full time developer years to get to where it is now, and I'm doing some pretty big changes for the next version. I literally probably have a handful of that sort of project I can do left in my life, assuming I quit my job now and work full time on it.
Let me tell you, it's pretty sobering to be faced with: "I may only be doing this once, maybe twice more in my career."
So yes, building experiments where I get to try out my ideas without 2 developer-years of coding required is going to give me an opportunity for a lot of creation that I otherwise wouldn't have had. I've spent decades hand-crafting code, I fully understand the joy of doing so.
https://blog.stuartspence.ca/introducing-asteria.html
https://store.steampowered.com/app/5482440/Asteria_4X/?beta=...
To be clear, I've made large software and game projects over the years, but no way I'd have found the time to do a remake/enhancement of a game I loved as a kid from 1995 that has zero business case. Not without AI.
To pile on, here's mine: https://github.com/linsomniac/apt-cacher-ultra
It is a robust, reliable cache of apt packages, with the additional goal of still being able to serve packages from the cache even when the upstream is down. This was started shortly after that DDoS of Canonical this past year. We've run apt-cacher-ng and apt-cacher over the last dozen years, but (a) it requires hand-holding about once a month and (b) it did absolutely nothing for us when Canonical was under DDoS.
I've put well over 100 hours of my time into it. Still running into a lot of people knee-jerk calling it "slop", but I've had 200-ish machines pulling from it for 6 months and it has worked way better than apt-cacher-ng.
I'm not really sure what to do with people who dismiss AI-assisted projects, while dehumanizing the 100 hours of my time I've put into it. I fear we're running the very real risk of both sides losing: the people trying to thoughtfully create with AI losing because of the AI, and the people avoiding AI losing because they can't keep pace.
What the fuck does this even mean?
You might want to change the way you phrase this idea. I think you meant that Go/Python/JS are more "YOLO-friendly languages" (you'll get into far less trouble if you write slop). My initial reading was the opposite. It sounded like you're saying the languages themselves are slapped together garbage.
Assembly is most certainly not "YOLO-friendly", but is more YOLO.
Why even write one of those? Just set up an nginx proxy cache and call it done.
But that doesn't even scratch the surface of what this project does. We already have a few simple approaches to this problem: apt-cacher and apt-cacher-ng. Neither of which were any help when Canonical was under DDoS. Both of which have proven unreliable.
As I said elsewhere, apt-cacher-ultra is a pretty subtle piece of software, it doesn't just do a naive cache, it fully understands the apt repo structure, validates the repo, and snapshots it, understands what packages your clients frequently request and preemptively downloads updates to them as part of the snapshot promotion, etc. A DDoS of the package sources, even in the middle of an upstream releasing updates, is something a-c-u will handle no problem. I've simulated this by firewall rules blocking upstream traffic. It's also proven much more reliable than apt-cacher-ng.
I've been in the software game ~40 years, I've seen it time and time again: "How hard could it be" and then when you get into it you realize there are a lot of devils in the details.
That's pretty naive.
This isn't just a simple http proxy and checking if the requested URL exists on disc. It's a pretty subtle snapshotting system that fully understands and vets apt repos, detecting when the repo changes, proactively downloading "interesting" packages that have updated, verifying and validating all packages, and then promoting the repo to active when it is healthy. Plus a web-based admin interface.
The core of it is around 20K LOC, with another 40K in tests. The COCOMO model gives that an estimate of around 2 developer years of effort assuming full time work.
apt-cacher-ng, the hand-written C++ version, is 16K LOC for the core. apt-cacher-ultra does a lot more. Seems like a pretty reasonable LOC count to me.
What are you basing your assertion above on?
Indeed. The number of hours is my goto defence too. So far I've put in maybe 200 hours of time into design, iteration, playtesting, QA, and balance of my game. Sure - almost zero has gone directly into writing code but this is still a major project.
People who one shot a crappy game have no idea how much work it still takes to get something really good over the finish line.
>I'm not really sure what to do with people who dismiss AI-assisted projects
Mostly I've stopped worrying or trying to convince the haters. I'm having a blast and building great things (lots more than just Asteria).
Good luck with your apt project!
I think we'll see a lot less people willing to share if the end result is just to feed the machine no matter how they arrived at it.
I don't see why I should care about this any more than I cared about "somebody I don't like could read my code and learn from it" in the past. The frontier labs can generate or buy all the training data they need; not releasing your app isn't going to hurt them in the slightest.
Having been a UX-focused dev for my entire career, I knew only the basics about parsers and compilers, but have enough experience to grasp what each piece should be doing. At the beginning it was just a fun test, but it got progressively more serious; it now implements 100% of the latest spec, beats QuickJS in performance, and surpasses V8/JSC in test262.
It took me four months, and I imagine it would take me a single month now that I’ve learned a lot. Someone who already knew what they were doing, and with the right orchestration could achieve this in weeks at minimal cost. I really think we are in for a cambrian explosion of software, enabling things that were just always a little out of reach before (like why can’t most of your devices really talk to each other, in 2026).
[1] https://github.com/ricardobeat/boomkat
Beg to differ.
The architecture is different, the language is different, implementation choices are all mine. I don’t think you’ll find any code that is a duplicate of other engines - happy to be proven wrong here.
Which talk of his gave this impression?
Don't we see this already a lot? I feel like people constantly say this exact same words.
Can we get a forum for sharing project that were _proudly_ built with AI due how ambitious they are?
Big solo projects exist, they're just not coming out as frequently because of, uh, how time works
[1] Yes, lots of people use dictation instead. I feel like speech-to-text loses you the benefits that speaking has over writing in terms of communication power, plus it's inefficient. I'd rather harness the benefits that writing (really, editing) has.
> I have a similar thought about "there's no reason for software to be slow" BTW; in many cases, if you use AI to speed up some flow, you will add a bunch of messy code that will be overfit for the use case you tested on and will neither generalize, perf-wise, for all the use cases you should care about, nor will be maintainable upon future changes.
LLMs have hardened hundreds of apps where I work.
Maybe it's a language-specific thing. Most of the time, in Java, LLMs take into consideration tradeoffs (especially if they are part of the initial prompt) and actively explains them. It generally won't make messy workarounds, without a lot of extra prompting forcing it to do so.
Ofc, if you have:
- Functional tests - you'll be able to see it in the execution times of specific APIs
- Stress testing - performance profiling is the most important output artifact
Claude in its current Opus 5.5 form has made some wild reaches in response to reasonable-seeming prompts. For instance: "this error is getting swallowed, make sure the real termination message exposes the root cause" -> discovering that the issue is actually in a third party library that isn't exposing the original error except so through logs, so doing some hackery to inject a log-capturer that gets the stdout, buffers it, and looks for the message in order to re-throw based on that...
And it can demonstrate that working, but it's added some fragile and/or unintended consequences like (a) string matching on a particular WARN log message of a particular version of the lib, and (b) buffering those logs such that there were now cases where they would never make it to the actual output stream before the program terminating.
It's certainly capable of being used smarter than that, but it's also really easy to end up with messy fragile stuff if you get lazy about reviewing the output.
I think this illustrates a fundamental objection the anti-AI crowd raises.
The prompt requires no understanding of what's happening, before suggesting action. It's required that a PR review that has a solution, has to have a corresponding explanation or it's marked needs work
I think there's some nuance here though between "fully anti-AI" and "be careful with that power saw."
That example I mentioned didn't make it to production. It got noticed and fixed more properly by the person who submitted the first prompt before it even went to PR.
But a lot of times things in that same vein can be solved sufficiently with a "dumb" prompt like that, so a one-line prompt to get a PR drafted in the background for the dumb stuff can be a pretty good time saver.
The art is not skimping on your attention to the bigger or more important stuff so much that all the time you save on first getting code written is lost by cleaning up stuff like that...
Opus's first proposal for a fix was to spawn multiple Python processes and build a load balancer between them in Python. At first I asked it why it wasn't using haproxy and it said that haproxy would be an added dependency and that the overhead for this kind of thing in Python would be negligible. I knew this was idiotic but wanted to test this out, so had Opus run two experiments in parallel. Sure enough an haproxy load balancer was much, much better on HTTP load balancing than Python code was.
This is the kind of thing that if you're unfamiliar with how networking code works, the models can autopilot into bad decisions that are verifiably correct (higher throughput than the original CPU-bottlenecked implementation) but much short of best practice.
The advantage is that you don't have issues like the GIL or whatever, so there's no need for all the complexity of load balancing between multiple pythons.
I'm not doing CPU inferencing but I'm doing some tokenization in Python which is CPU-bound. In all honesty I started on this project to scale the model and did not build it myself so have been trying to read code and walk back the approach. I've been thinking about rewriting the Python glue in Go to avoid issues with the GIL.
In python, in a co-worker's code, it seems to significantly prefer "some_dict.get('key')" over "some_dict['key']". For the non-python-users, the first one will return None (equivalent to null) when the key is missing, while the second raises a KeyError. It was being used in a whole bunch of places that would cause problems (bad data instead of errors) if it did receive None. Some of these keys were actually optional and it does makes sense for those, but it looks like whichever model he was using just repeated the pattern everywhere instead of just where it was appropriate.
Use a defaultdict if you must have all keys optional. Using get() everywhere is buggy because it masks illegal key use.
Double lookup.
Cheaper than get() masking bugs in your code or dict generation.
But yes let's prematurely optimise for speed in a slow-by-default language by writing bug prone non-idiomatic code. OK.
Both have valid use cases. It's weird to be sarcastic about it.
You have two choices:
1) Code that dies once loudly and then you fix it.
2) Code that silently corrupts your data forever until you notice.
Generally I prefer the former.
You could use a data structure that better articulates an optional field, like a dataclass with type hints or a pydantic model. Then you, your coworker, and the agent alike, aren’t guessing at whether the key’s value is optional.
Another example in this vein is having many optional parameters on a function or api route, that drive behavior deeply nested in the application logic. Or maybe they were there for testing and never deleted. No one comes across this code next and understands it easily. How could you expect a LLM to understand it, either?
I find it funny when people blame the LLM for dog shit code, but at the same time have a pollock painting of code they load into its context, and are like “put a person in the horse and carriage!” And the LLM is like “bro I just see dots and squiggles but you asked so boom!”
Be careful to not frame this as a feature of AI and not a feature of the approach people have taken that you have observed, it doesnt have to be this way.
I suspect it's far more about workflow and developer attitude. Messy code stays because you don't object to it staying; overfitting happens in code because it happens in prompts.
https://taktile.com/blog/property-based-testing-claude
I'd love to read that post!
I understand how to use Kani. I suppose Rust with Lean involves Aeneas, but this is over my head. I'd love someone to write this up, not only the mechanics but also exploring the current practical limits of it.
Right now, I wrote a compiler that takes C and Rust code and compiles it to Lean. Then I have an LLM write a proof that the C and Rust code behave identically. I've been able to prove equivalent behavior for about ~70k lines of C code with pgrust.
The issue I've started to encounter is that the context needed for each incremental proof has kept growing, and things have slowed down dramatically. My hunch is that the speed is the time it takes to prove a line of code is on the order of O(n^2) of how much you've proved so far
I'm looking to see if there are ways to shard things so the required context scales better. Today I was going through the formal verification work Anthropic and Theorem published a few days ago, and it looks like they used some sort of orchestrator to manage all their proofs and ensure good clustering of similar code. I'm seeing if I can get an approach like that to work
It's just difficult enough that I think it's doable if done right. Half of me is debating if I should wait until the next model release because any improvement in model performance will help a ton
What if there are bugs in this C,Rust->Lean compiler? Anthropic are able to sidestep this by reasoning at the RISC V level for which its easier to develop a correct semantics.
Perhaps a poor choice, given just yesterday pgrust was removed from ClickBench for cheating the benchmark in three different ways (hand-rolled code specifically targeting each of the benchmark queries, caching, and being unable to execute queries outside of the ones tested by the benchmark).
What happens in an environment of cheaters is that cheating becomes so commonplace, the competition becomes one that assumes cheats are enabled, and then everyone involved either denies cheating or is silent about it because IYKYK and if you DK, you don't need to K. Look at bodybuilding, which is full of men (and women!) absolutely juiced to the gills getting on Instagram and assuring everyone that their physique is totally natty, bro, just hard work and proper nutrition.
Programming is headed in that direction. LLM use, even to the point of "vibeslop", is the new default, and while LLMs do overindex on benchmarks, our benchmarks are going to end up overindexing on validating whatever public opinion thinks is "great" at the time, irrespective of whether it actually is, so "cheating" as we know it will go undetected, and certainly unpunished if it is detected. I don't know what the equivalent of falsely claiming you're natty is. Maybe saying "I wrote this" when you wrote it about as much as the Pope painted the Sistine Chapel fresco?
You don't have to take my word for it. If you want you can inspect the binary yourself: https://pgrust.com/downloads/archive/2026-09-clickbench-snap...
You can run the binary with PGRUST_GRAVITY_REPORT=1 which logs the code path hit for every query. You'll see that all the code goes through the general query path. We did have hand-rolled code in the binary, but we used it for testing. The code is not used when running the benchmark. We also did not use a results cache. Warm runs still scan all the data. You can verify all of this
You are right, though, that it did support a narrow set of SQL. It supported scans, group bys, sorts, and filters. That's enough to run all the queries on ClickBench, but failed on functionality not tested by the benchmark like subqueries
You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?
The more you make excuses, the more we get suspicious
(copied and pasted from another place you gave this unsatisfactory answer)
It instruments the files that were called out in the PR, then runs ClickBench. You can run it and see that the code in those files doesn't run.
If you can find anything suspicious in the binary, let me know, and I'm happy to dig in
As far as I'm aware, Jepsen solely focuses on correctness (which is more than enough for someone to do!), not performance.
To give you a sense of how fast it is, pgrust on a c6a.2xl is faster than ClickHouse running on a c6a.metal, a machine with 24x as many cores and costs 24x as much.
[0] https://github.com/ClickHouse/ClickBench/commit/56535d29e825...
[1] https://github.com/ClickHouse/ClickBench/commit/89cc76e1e4e2...
I understand being predisposed to expect a poor quality half arsed effort for projects like this. I don't really have a problem with that. There is a lot of crap out there.
What I find rather offensive is when people declare something to be poor quality and half arsed before they have taken a good look at it.
It's one thing to think something is probably crap so I'm not going to bother even looking. It is something completely different when you think something is probably crap so you tell people that it is crap without checking.
unfortunately though pgrust appears to be at best misleading, at worst vibeslop: https://github.com/ClickHouse/ClickBench/pull/2165 hacknews thread isn’t much prettier either https://news.ycombinator.com/item?id=50205816
I'm being more ambitious in that I'm working on projects that I had sidelined for literal decades because I didn't have time for them. But I'm writing the same things, just faster. And probably better, rather than just what I'd have done before.
And I'm being slightly more ambitious in that I'm using languages I haven't used before, like Rust.
But when I hear that a non-programmer wrote a new ai-assisted (vibe or not) thing, I walk away and wait for the it to mature, be surpassed, or find out it's an absolute shitshow. An unsurprising number of them were shitshows and it came out fairly quickly after I decided to wait and see.
Now that custom software is cheap (if you can tolerate a bit of slop here and there), it seems like there's an opportunity to do some important things that weren't being done before because they're not profitable--and you can't get at those things by incrementally improving the old stuff.
AI could help making life a lot better in all these cases.
But yes, we should also aim higher in general.
The project would've been impossible for me without LLMs. & even with them there's an argument that this project is pushing complexity limits too far. But at least with ETL there's a clear feedback loop to build on
This is, as you say, exactly the paradox of having ourselves assisted by LLMs. We are no different from our cats. Except imagine the cats start making the laser lights for themselves.
[1] https://xkcd.com/356/
I do however wonder about specific research priority/project from labs' solving their own problems leaking into my chats. I noticed one month that Claude really started harping on about "legibility" and suggesting Seeing Like A State to me, and saw it like any other interesting suggestion/insight.
Now I see a lot of people mentioning "legibility" and think that was just some weird attractor state or useful vocabulary term for being an LLM (that literally can't see certain things or be observed easily!). It's a weird feeling, because nobody tried to trick me and in fact it objectively helped me to acquire useful information. I just have to wonder if other people are having the same conversation and there's really nothing special about it - maybe Anthropic just really liked that book right around when they were doing a lot of RL
Not only that, was the intent just to give Claude the vocabulary to be an LLM in a company that wants it to be legible, and apply that book to managing it, and we're either intentionally or unintentionally memetically downstream of that? Or was it just extra likely to be mentioned because it's a genuinely helpful book - either because the AI learned over time that it was (very good!), someone just wanted to recommend it to more people to help them (~good). I worry that the "intelligent conversation" or "wow look at the agent go" can give us very poor epistemics
AI can take us from 0 to MVP in a prompt. It can fill in gaps of knowledge and allows someone who knows half of the stack to build the whole thing nearly seamlessly. These are superpowers but don't by themselves lead to new products.
What AI cannot do is remove the world of complications that happen after the MVP - product feature tradeoffs and choices, how to handle integrations and customizations, how to serve multiple types of users, how to communicate and market the app, how to handle security and data storage, how to deal with customers and bugs, etc. All of these need to be considered and acted on by a human in some fashion. AI can help with each concern but can't solve them without understanding the concern and determining how to frame it in a prompt.
This is why we have a glut of amazing demos that go nowhere while we figure out how to build software differently. This will take some time and I imagine the result will be software heavily-structured with a bit of AI reasoning woven throughout, not an army of agents and sub-agents burning infinite tokens.
If you're being ambitious enough, you shouldn't be able to there in one prompt. Ambitious work with AI is done 24/7 for months and guiding it continuously, because it's not good enough to work autonomously for that long without going off the rails.
"Perfection is achieved, not when there is nothing more to add, but when there is nothing left to take away."
And I feel that sums up my feelings on AI this and that. Just as the wood and clay contain the sculpture within and it's the artist's duty and privilege to reveal that. So, is elegant software exposed from the conceptual mass, rather than built up.
The AI zeitgeist currently is 'how many features can I add' because we've tied self worth to work output instead of some other more personal or human rubric. AI will happily pile more and more and more code on your plate because it's a buffet. It's gone through reinforcement cycles guiding it to add whatever feature you ask. There is no training for elegance or careful considered design. Nobody is teaching this generation of LLM restraint.
The safest code is that which never runs. The most elegant feature is that which is not necessary.
Yes, but the most useless software is that which doesn't exist.
At some point, you actually do have to write some code and add some features, or else the most satisfied client is the one who hired your competitor.
They are not. Quote: "The safest code is that which never runs. The most elegant feature is that which is not necessary."
> you're bringing it back to capital.
I am not. I'm talking about satisfying customer requirements, not about capital.
I think you've replied to the wrong comment. Either that, or your reading comprehension needs some work.
I assume you run GNU Hurd as your OS? ...
In general I very much agree to the quote of the Little Prince's creator, but I am not sure if we mean the same by it, because you seem to value code elegance more than adding useful features?
Now "useful" does the heavy lifting here, but my point is a useful feature is useful, even if it is achieved by the most ugly unmaintainable code. And what counts as a useful feature will depend on who you ask, but in general you should ask some users. (They don't care how the code looks)
And sure, they do not enjoy a pile of garbage of new features that only work sometimes, but managed to destroy their existing flow. But "Nobody is teaching this generation of LLM restraint" this is hyperbole and up to each developer. There is no need to let the AI run on auto for hours, this is only one way how to use that tool. The other way is, you make the design yourself - and let the AI implement it.
But long term AI will allow us to unbundle and implement only the features we need.
All I need to know is it's the most widely used piece of software in my stack, by far.
I am not thrilled with all the coding decisions that it makes. I would definitely do stuff differently, but I have learned not to pop the hood and mess with the engine, myself. If I really don't like something, I ask the LLM to change it.
It's worked for me, but YMMV. I'm just one guy, shipping relatively small apps.
Do you still feel responsible for what you ship?
What about the copyright on your code?
Would you be ok with someone reverse engineering what you ship and then releasing their own version of the app?
Absolutely. If it has my chop, it's my ass on the line; no one else's. It's the way I was trained, and it's the way I worked; my entire career.
It doesn't matter how the stuff I ship gets there. It may be my own code, it may be a contracted pro, it may be an unpaid intern, it may be an LLM, it may be a howler monkey, banging on a typewriter.
If I sign off on it, and ship it, it's mine.
But that kind of attitude is considered "quaint," these days, and that's from long before LLMs were a broken rubber on the drug store shelf.
> Would you be ok with someone reverse engineering what you ship and then releasing their own version of the app?
Absolutely no problem. If they can do better, then more power to them, and I'll step out of the way. Might want to take a gander at the kind of stuff I write, and who I write it for. It's no secret.
I read every line and make sure it does exactly what I want it to do unless it is external plumbing, then I don't care.
/s
And if you don't get it: https://news.ycombinator.com/item?id=37090205
[1]: https://github.com/vishvananda/cppgm-extended
[2]: caveats here include only c++11, only x86, and potential for bugs, but 7x is pretty darn significant even with caveats
Make a reliable and robust geometry kernel. People will pay thousands--or maybe millions for it.
In the guitar world, you can get really good (for most people) modelers that emulate a good amp sound for like 100 bucks, and for 10 times that you can get _excellent_ sound.
My expectation would be that for similar prices you could get really good synths as well by now.
I think this is simply because nobody knows an algorithm to create realistic piano sounds, etc. There are some good attempts, but they are paid and expensive. Hence my suggestion here.
Already made the geometry kernel. So far, nobody has offered me even like 20 dollars to license it yet, nevermind millions of dollars.
"funnily enough, I have some faith in some of the projects that people are the most skeptical of, e.g., every time I see pgrust somewhere, there are a lot of skeptical comments. But, without having looked into the details of what he's optimizing, I would trust that they're not doing something shady with their benchmarks because Michael Malis started the project (and is still involved)"
This aged like milk. pgrust was caught cheating on all benchmarks this week.
Maybe what's happened is that their bots reward hacked their way into special-casing the benchmarks without a proper audit from the humans involved, and now they're doing vibed damage control....
The project has tell tale signs of eyes free coding and ralph-like loops.
No one "lies" per se, the guilty parties are merely engaging in a beneficial deception turned a cover-up.
Can you back this up? Our code is open source here[0]. You're free to audit it and benchmark it as much as you want
[0] https://github.com/malisper/pgrust
If you run it with PGRUST_GRAVITY_REPORT=1 it will report the code path hit for each query. You can see that all the queries go through the general query engine.
The binary does contain hand-written kernels in the irprobe files. These were used for testing. You can validate that when running the benchmark, those files are dead code.
The engine supports a narrow subset of SQL: scans, group-bys, filters, and sorting. That's enough to run ClickBench. It doesn't support e.g. subqueries which is why some of the follow up queries failed
You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?
The more you make excuses, the more we get suspicious
(copied and pasted from another place you gave this unsatisfactory answer)
the first commit has 400k files, the other two more than 1000 each, if you are going to ask others to audit this scale of ai generated code, can you tell us what you have done to audit it?
What I have seen is your Ai adding a lint test to make sure it doesn't cheat again. Are you personally aware of this file? How can you ensure it doesn't alter it and reinject the hand rolled benchmark queries? Will you be reviewing changes more thoroughly going forward?
https://github.com/malisper/pgrust/blob/38634b408dea373f3944...
transparency is the way to end the controversy, which appears to be sharing the full commit history based on HN responses
You can run it with PGRUST_GRAVITY_REPORT=1 and it will log the codepath that was hit for every query
On the lint, yes, I'm aware. It's one layer of defense. When we were prepping for the 0.4-beta release, we generated a large number of fresh queries and made sure the engine runs them and performs well across all of them
You keep giving this same answer to no one's satisfaction. Saying go check the binary is worse than saying go audit 400k+ files. How do we know the Ai has not cheated in the code path logging? How do you know that it has not?
The more you make excuses, the more we get suspicious
> It's one layer of defense.
Needing to put in tests to make sure the Ai doesn't cheat is an interesting development in software development. I personally see it as a big red flag and evidence the machines are not going to replace human developers. It's categorically slop or the opposite of quality and care in development.
> 413,963 files changed
> +2,908,538
> -3,423,007
How is anyone supposed to audit that? I doubt you’ve looked at even a small fraction of the code, if any. Especially since this commit is two days after the second. Pure vibes.
And people still seem to believe they know what’s going on…
HN is waiting for the release of the source code of the 0.4 preview build that allegedly cheated the benchmark. So far, the people (person?) behind pgrust hasn’t committed to releasing it.
I noticed my cloud images had 150mb ram wasted by vendor slop. AI rewrote the functionality into a few mb .
We’ve had slop long before AI . What you produce now is up to you
There is a gulf of difference between someone who doesn’t understand how to program “vibe coding” software and an experienced software developer using ai to write code with heavy direction, review, and best practices.
Today both would be said to be “vibe coded” but we really need to differentiate them. Also, if everything I’m hearing from people is true, it sounds like most corporate code is now completely ai written in the latter way I described. It’s interesting we don’t hear commercial software being called slop yet. Maybe it’s coming.
In any case, ai is far more capable than I realized. Not sure what to make of it.