You need to understand the system you're working on enough to make well-informed decisions about its current and future states.
In some cases you can get away with not reading the code. And maybe in the future that will be more common. But for now, I personally prefer to read (or skim) the code, and not abdicate to AI.
Informative thought process here. Pre-committing benchmarks to measure real efficiency gains might have helped, but hands-off complex rewrites are still not shovel ready.
> hands-off complex rewrites are still not shovel ready
...which is a bit disappointing, actually. I mean, if you give an AI agent the complete code for a working application (ideally including tests), it should be able to translate it into an equivalent application in another language. I can understand if it makes mistakes because of ambiguous prompts etc., but for this task you shouldn't even need a prompt, any information it might need is right there in the code?
Agreed. You would expect this to be a task that AI has a massive advantage over humans as it has both the testing suite to keep it on track and has the source implementation to reference. The classic failure case for agents is that as the task increases in complexity, it requires more steps to complete. With each step there's a chance for error. As errors accumulate, they become more likely. With verification functions, like test suites or comparison to some source, the agent is more likely to catch errors and recover.
So porting should be perfect conditions for an AI agent. It has the testing suite. It has the original implementation. Hell, it can A/B the original with its working copy and attach the original to a debugger.
So yeah I dunno. I guess despite some people's rhetoric on this site we shouldn't underestimate how difficult these tasks are "in the real world" (as opposed to like a game port which doesn't have real money on the line so far). And it is kind of a miracle these tools can even get in the ballpark and fool a lot of people.
Yes I have just started dabbling in some harness evals where the task is translating the RealWorld “mother of all demos” app, maybe one of the most translated apps of all time, and they cannot reliably 100% it
I dunno. You still have to test, but in my experience if I noticed unreliability during high load I could just tell Claude "I noticed unreliability during high load" and it would easily have set up a high load benchmark, discovered this broadcast channel issue and fixed it.
It definitely improves the results if you do think but I don't think "you still have to think" is a safe space that's going to save us from unemployment.
At work, all thinking has basically become discouraged.
If you are not using AI agents for everything, you're doing something wrong, and wasting company time. It has been emphasized that no one should be writing code by hand and if you think an AI has implemented something wrong you need solid reasoning to show why or else people just label you as some anti-AI troublemaker, who just becomes an obstacle standing in the way of things getting done.
If your human generated opinion is in any way wrong or simply not a true homerun then you get snubbed in future reviews, people stop listening to you.
> and if you think an AI has implemented something wrong you need solid reasoning to show why or else people just label you as some anti-AI troublemaker,
I'm going to read you charitably, and assume that what you really meant is "the burden of proof is entirely on you, and is set unreasonably high." Because of course, if you do think someone has done something wrong and want to say it publicly, you do need a solid reason.
Huh, I don't use AI much/or at all anywhere, apart from googling something and reading the Gemini answer before scrolling down, without facing any backlash. Though people are more likely to discuss and brainstorm their work/problems with me because of this, which I consider a positive. Maybe I've been lucky at where I work.
That is if I ignore the slop MRs with 60+ files changed that I have to painstakingly go through and then politely tell the author to fix the crater sized holes in it, while a vein in my forehead almost explodes. And some part of my sanity is lost forever.
God help me, my manager (product director) has taken this approach for product strategy docs. Everything has become very stupid and extremely shallow. It’s easier than ever to coast, but man.. that’s not really what I wanted.
Free-thinking, critical thinking, has been considered taboo, or an exclusive privilege of the elite, in most human societies since the dawn of civilization.
This post resonates a lot with me and my day-to-day efforts to keep the spinning plates that make up our systems from toppling.
Speaking of tradeoffs, I want to keep pulling the thread: is it worth reading—meaning, understanding—the code in order to prevent p95 latency from skyrocketing, preventing OOM death, and keep our apps reliable for customers?
The cost of understanding the code is ostensibly very high relative to just using a clanker (citation needed), so does paying that cost translate to value—what is it worth? Concretely, if vibe coding increases bugs and enshitification, but decreases spending without decreasing revenue (read: customers suffer, but they don't leave), do we still need to pay the cost of reading code? Is it better to invest is stickiness, lobbying, market capture?
I hope this comment isn't read as advocating for this, it's more of a thought experiment about pragmatism and trade offs. I know that I personally care a lot about understanding the code and I believe I'm paid to do exactly that (I very much enjoy understanding code so I may be biased in this). Inside of SaaS-land and outside of critical safety systems, we've seen production databases destroyed, personal data leaked, platforms unwittingly exploited, and UX bugs creep into our operating systems, and yet the companies involve keep on keeping on. Is thinking going to increase their shareholder value?
> (read: customers suffer, but they don't leave), do we still need to pay the cost of reading code? Is it better to invest in stickiness, lobbying, and market capture?
Translating this from Linkedin-speak: Is it okay to subject our users to shitty software and while we use the money saved to bribe politicians, circumvent laws and buy our competitors to kill them?
I agree. I'm using AI on a mid-complexity system (IoT devices, encryption, concurrency, etc) and the number of errors / bad decisions taken "at first" by the AI (or if I don't guide it precisely enough) is huge, and I can only imagine how feeble and unmaintainable an entire codebase done without review from a senior coder would be
I feel like the AI debate is our last best chance to agree that human values are more important and have higher long-term utility (to humans) than pure financial maximization. I think it’s very very likely that money does not capture or convert to a large subset of morally good choices we can and should make to be happy.
That's a really great point, and you can often start with documenting current behavior with tests and then carefully going through to figure out what bugs you've just enshrined in test cases…
Yeah, I think most success stories in AI seem to come from ports, or from projects where a deliberate architecture has been laid by humans who understand it, and AI is sprinkling features on top. Adding features and drivers to a Linux distro seems like one of those places where AI is uniquely well positioned to bring value, because the foundation has already been laid.
I wrote a post the other day on how agentic code still needs this kind of architectural foundation to not end up in a tangled mess. It might interest someone:
https://ljtn.github.io/epiq/blog/the-soft-fabric-of-agentic-...
anecdotally this has been a huge help for my projects. I'm seeing AI one-shot porting from one library/framework to another with very minimal handholding. It used to be that these decisions needed to be thought through a lot because they were hard to change later on
But the article showed that that the port/translation of an established app resulted in a mess anyways. Looks like even with a good foundation it's prone to fail.
“Ideal use case” such a wild take. The “10%” (assuming you mean all the issues pointed out in the article) are the things that take the most time and effort to do (or fix now), which you can’t do without understanding and fixing the “90%” of “translation”.
You simply pointed out that challenges remain in what the other poster said is otherwise the ideal use case, which was his point. What is the ideal use case in your opinion, since you disagree?
I agree with what I think you're implying, but if it needs to be started explicitly: converting a 100% handwritten, high quality repo to an different language via LLM should be trivial, because all of the hard parts have been reasoned through, and yet these conversions had mistakes, which is unimpressive. Rectifying the mistakes is non-trivial, and the LLMs did not have foresight to rectify them in advanced. (Expectant "you're right, I [sic] did completely fuck that up")
That said, I don't know if it matters at this point.... On top of Brandolini's law (mentioned elsewhere), what's more likely to happen is that developers' intellect, made available in open source, is just going to be harvested as context for different projects (I'm not taking about training data, I'm taking about devs literally cloning repos into an agent to harvest intellect).
That was the point of the article, it's not easy at all. You can't just write Ruby in Rust literally unless you want untyped bags of key value pairs and virtual functions everywhere. The languages have different fundamental semantics and there are many non trivial decisions, including and up to, total architecture change.
For example, in ruby some kind of stringly typed reflection utility might Dry out code. In Rust, that might mean writing a trait over some subset of types and a macro helper, but would require careful dosing work.
Letting the LLM decide is the approach in question and the author was pointing out how spectacularly it failed to translate a complete, human designed system.
The focus on "code" is sometimes too strong. This isn't just a code/quant issue. All of this applies too to any "answer" the LLM gives. Experts very often track their lineage - what teachers they had - because the details and slant of what they were taught guided their way of thinking and defined the "handle" they use to grab a problem. There is no "right way" to do most things - there are ways of approaching. Imagining that you are free-flowing and not in a channel is a rookie mistake! Encouraging this way of thinking is like the uptight enforcer of minor social mores: "Elbows!" no elbows on the table is how things are done and this is reified. Like you said "it takes no effort to produce and immense effort to debunk" and sometimes the stakes are high. I'm convinced that racism, for example, operates exactly like this: 0 friction go-with-the-flow insist it is natural...
My strategy is to skim the workshop to find suspicious sections, then prioritize debunking at least one part that makes the creator look bad.
Then respond with that addressed, with a firm but polite explanation that the document has some problems that need to be addressed carefully before we invest time on it.
None of this works if it’s coming from your boss, but it’s very effective at making people think twice before sending you slop.
People only do the workslop thing when they believe the benefits of showing the work outweigh the reputational risks. If they get caught every time they do it and exposed on an email chain, they start doing less.
That's very hard to do in a work environment where you have someone above you who doesn't understand or care about this. Instead of keeping things sane so they can run smoothly, you will be seen as slowing down progress.
Make it clear that workslop is produced by the human committer and not the Claude. The human has a reputation and this is hurting that reputation.
You can do this in a professional way but still get the point across that they're stealing productivity from others that have to pull up their slack.
If the commits are too big or too dense. Make them break it up, clean up the comments etc. Otherwise they are simply doing a poor job. Not Claude, them.
Corporate code is typically terrible anyway. For many years (predating LLMs) I’ve looked askance at my bank’s app with its obvious bugs, wonder how many are not visible. It was not always so (consider SABRE back in the 60s)
But it’s the fat part of the bell curve. There’s loads of even worse crap outside corporate code…and at the right end of the bell curve is deeply thought out and the result of long-term maintenance that tends towards as bulletproof as can be possible in this universe, parts of OSes, networking stacks, clocks, and the like.
It’s only because that stuff is so robust and sufficiently general that the rest of the world’s steaming pile of code works at all.
> Corporate code is typically terrible anyway. For many years (predating LLMs) I’ve looked askance at my bank’s app with its obvious bugs, wonder how many are not visible. It was not always so (consider SABRE back in the 60s)
I don't know if I've worked on your bank's app (safe bet is I haven't), but I have worked on some banks' apps and... oh boy. Let's just say that if you've seen what I've seen, "stuff it into a mattress" starts looking like a sound financial policy.
This is about computer code. Debunking is either "it runs or doesn't". Not hard.
Presentation layer code doesn't control how the machine and kernel prioritize anything; so "proof" Ruby code is doing the right thing is proving the machine does the right thing from the factory.
As for abstract theory and math, well shit since any English and any math are...mathematically possible...well shit I guess we gonna have to live in the real world and not inside a rhetorical bubble; religious or atheist philosophy... cause they are not evenly distributed frameworks as religion clearly shows; so why live by the syntax and semantics of some mathematical rando who taught a stats class years ago?
Same shit as living by religious allegory
Goodhart's Law has come for 1900s means of scientific inquiry; every technology follows an S-curve and the same for every social society. In the US we aren't all defaulting to calling ourselves British or speaking Latin.
Physics will always be there. The stupid glyphs and bird song we came up with to communicate about it isn't physics. It's just a human language system.
By default, an llm isn't going to give harsh criticisms like 'you've architectured this thing completely wrong with a poor choice of abstractions and algorithms'. As the post says, you still need to think.
Yep; tons of references to programming, Ruby, SQL, other technologies
None of which have much to do with how the hardware handles requests.
Am an EE with a background in applied physics and well aware we could jam a kernel in the BIOS/UEFI storage and generate the runtime state around it at boot from a prompt cause I am working on just that
Which is exactly where we are headed with Jev/decision models; they can generate new config to min/maxing per process resource use; look into bpf and sched_ext and meditate on their application. It should eventually jump out at you
We have known in the abstract how to handle computing efficiently on our machines since we started building transistor based machines
It doesn't require handing a bunch of meat suits verbose languages to make of mess of electrical state management
Writing code is not high tech. It's 1970s and 1980s tech. As this forum should be well aware tech evolves with the times.
The coder bros refusal to move on is them clinging to a sunk cost fallacy; but they already put time and $$ into their education in ugly languages and DSLs that merely initialize values in memory and ask the hardware to run it within some spacetime constraints
The syntactic gibberish is just a barnacle of a bygone era
Social web addicted Millennials need to grow up and move on
I’m an advocate for LLMs to code and basically use it for everything now, but just want to say you really nailed that.
It takes effort to debunk because you have to holistically consider what the problem was and actually find the better solution to prove why it’s lacking.
In other words, to debunk it, you have to do the actual work that wasn’t done the first time.
Some people may argue “so what?”
And to that I would just respond that the fast solution implies nobody probably thought about it, which is always risky and generally leads to very bad outcomes. If for no other reason than there is at least no consensus, which for long-term software evolution is deeply problematic.
This has happened many times since this trend has started, and forcing everyone to step back after a year objectively reveals the murder that has been committed that, believe it or not, is not trivially unwound.
In the wrong hands it’s a debt machine that is already killing companies from the inside.
I see increasing amounts of code merged to the codebase that is sometimes wrong, sometimes too brittle, sometimes fixes the symptom without addressing the bug. Two years ago the same code would be criticized harshly and reworked before being accepted.
Also, now people who used to manage the development but not write any code also feel their superpowers to merge LLM slop in humongous amounts. It feels like a ticking time bomb, but I am afraid of calling it out and rain on their parade of 10x productivity (or often AI psychosis). Leaving the team doesn't feel like a good decision because what I hear from many colleagues is much worse. Ah what a time to be alive...
Its the same as with luddites / textiles, people proved they were willing to accept far worse quality because "automation". People have a strange cognitive bias it seems. When they know a person has done something, the scrutinize and correct. When its a machine / automated, or the price is low enough, it gets hand-wavy.
People here often say "we can't set rules, because imagine how hard it would be to follow them at scale". That same strange cognitive bias applies here. Somehow the "push a magic button and it works" and "of course it can't do it just as well as a person every time" kind of take over.
Imagine if many tech issues like access to pornography, corporate ad tech, violent/racist material, AI slop, etc. were all just armies of people doing it (like google / X actually just had a person curate your results really fast for every search). Of course people would be outraged at the quality, but its "automated" so no one questions.
Similarly, if AI was just a giant outsourced coding firm with 10M programmers that could write you a slop app in an afternoon for $1, people would be complaining at how idiotic it is, and how inferior to regular devs. But instead, the "machine bias" takes over and people try to forgive the shortcomings.
there is something in the human psyche that badly wants to replace itself with a machine, despite it spelling our own undoing, and often resulting in worse outcomes along the way. I suppose the whole "make a tool" drive has been wildly successful overall, but this is probably the required downside to such an innate drive.
Like have you seen the 3d printed houses? They are the uggliest, shittiest houses in the world, but somehow the lure of "yes but we can build them in 24 hours" seems to somehow get people interested. If a human made one of those dung heaps they would be pillaried as a village idiot, and rightly mocked, but somehow because "machine do thing", we should get excited about excreted dung beehive houses...
I think the problem is AI meeting minutes use a template that forces a summary when it doesnt work. I found just taking the raw transcript and uploading to an LLM helps way more than using the teams summary.
Its been immensely helpful catching things I didn't understand the first time.
But you still need to pay attention in the meeting.
I'm struggling with this with an open source project I work on (that has users). I have a port that passes all the tests, but there's enough code that it's hard to review that the LLM didn't change implicit design decisions or implement things in an unmaintainble way. It not clear to me how to build confidence to switch over and implement new stuff and leave the old one behind.
I feel a bit sad DHH did the elixir one so dirty. It's the only language with the rule to follow rails to the T and of course Elixir can fly and be incredibly powerful without redis and other bullshit. It feels deliberately hamstrung. Almost maliciously because heavy hitters like Jose Valim have told him about this and he just ignores it.
All that requires _effort_. A stunt where you AI-translate a library into multiple languages is clearly not a context where you'll see that kind of effort applied.
My suspicion is DHH is intentionally creating controversy to drive interest to Omarchy
If he truly believed in the idea of never reading the code, he'd fire all his developers and have the designers do it all - create very high level feature descriptions and iterate on them. Put your money where your mouth is
I think he said the agents couldn’t make features in their existing codebases as well as in new ones, so he needed devs to still work on Basecamp. Maybe that has changed.
"Not reading the code" does not mean not knowing what the code should do, or how to probe it for correctness. Getting good outcomes from AI-generated code requires knowing exactly what to do.
I think attempting few-shot agentic ports of an app as an exercise and having the results not be perfect is really a referendum on thinking or using AI in coding in any particularly meaningful way.
"I didn't do anything. I asked two frontier agents to make the most of Elixir and this is what they came up with. Please do send a PR to speed things up! But also realize that it's not exactly extra points for Elixir if frontier agents can't find the magic "go fast" switches."
came here looking for someone to point this out. the flip from "it's more fun to be competent" to "just let the machine do it for you" has told me everything I ever need to know about DHH. The man has no principles.
"If you looked at the code, and yeah, I know, we should not be reading code anymore"
I'm pretty sure this is sarcasm, but it's also a major factor in what differentiated slop from non-slop AI work: did a developer actually take the time to review and clean up generated code. Which is, itself, an extremely time consuming process
Yes I agree thinking is still needed off course, but it has never been easier to ship 'half baked' things that don't actually matter and just works. What I mean is, if something has little proven business value, why waste time making sure it is correctly implemented? I'd rather spend time thinking about things that has actual proven business value, otherwise I'm not opposed to shipping something that I understand only 60 or 70% and save energy. ie: how it works at a high level.
If we are going to the moon, then by all means I think we should probably scrutinize every single line of code, but most business aren't going to the moon.
These articles IMO suffer from good data. It seems we could probably at this point study open source projects longitudinally and see what we learn depending on their AI policies. Are there patterns in stability? Bugginess? Performance? Readability? Etc.
LLMs produce code faster than humans are able to check it. Today's systems are able to generate thousands of lines of code per day, no human team would be able to keep up with them. The problem, in my opinion, is the way LLMs are used. An LLM reasons and makes mistakes according to the logic it was created with, but different LLMs reason and make mistakes in different ways. I'll give an example: take 2 black boxes, each one with 2 inputs and 1 output. Inside, the boxes work in a different way: with the same inputs the outputs are different. The real key is to use the method of adversarial development: this reduces to a minimum (even if it doesn't eliminate completely) the possibility of errors. So to humans the task of checking the output, and to have quality output you need to spend, and a lot, at least 2 frontier LLMs. But the question is: is quality as a goal an expense or an investment?
"Quality", as you're referring to it, is often a strict requirement expected and enforced by regulation and contracts.
In the past, I could have just easily said that there's more code out there online than I could ever hope to write. There's simply no value in gluing that code together mindlessly or even probabilistically. All the value of code is in gluing it together intentionally as an organization. The value is in knowing the precise results including all side effects.
Let's call this type of AI development what it really is. It's an attempt to jiggle the wrong key in the door. You're trying to circumvent existing standards for profit and then launder blame for it.
When you read the article you’ll see it gives numerous examples. Eg “The Rust version doesn't maintain 100% backwards compatibility, for example it drops the CSRF token so that caching is easier”
This particular quote doesn't make any sense. This is not what "backward compatibility" means. Is there a bug or does it just do thing differently so benchmark is not "fair"?
If it were me, I would start by getting a summary of what problems the existing solution solves. I would also make sure that summary had the non-functional requirement. Maybe write a test suite that opens the page and does all the stuff.
Then ask the LLM to implement in another language, with those solutions in mind, but first coming up with reasons why the target language might not be as good, and where it might have useful features that the original language didn't. Use the test suite to check if things are working.
I honestly don't think you would land far away. You would have to answer a few questions along the way, but it would mostly be plain sailing.
I would expect to be able to do this with very little human attention, whereas a language rewrite two years ago might take a whole month, not including learning the new language.
132 comments
[ 1.1 ms ] story [ 62.3 ms ] thread[0] https://xkcd.com/1053/
In some cases you can get away with not reading the code. And maybe in the future that will be more common. But for now, I personally prefer to read (or skim) the code, and not abdicate to AI.
...which is a bit disappointing, actually. I mean, if you give an AI agent the complete code for a working application (ideally including tests), it should be able to translate it into an equivalent application in another language. I can understand if it makes mistakes because of ambiguous prompts etc., but for this task you shouldn't even need a prompt, any information it might need is right there in the code?
So porting should be perfect conditions for an AI agent. It has the testing suite. It has the original implementation. Hell, it can A/B the original with its working copy and attach the original to a debugger.
So yeah I dunno. I guess despite some people's rhetoric on this site we shouldn't underestimate how difficult these tasks are "in the real world" (as opposed to like a game port which doesn't have real money on the line so far). And it is kind of a miracle these tools can even get in the ballpark and fool a lot of people.
It definitely improves the results if you do think but I don't think "you still have to think" is a safe space that's going to save us from unemployment.
If you are not using AI agents for everything, you're doing something wrong, and wasting company time. It has been emphasized that no one should be writing code by hand and if you think an AI has implemented something wrong you need solid reasoning to show why or else people just label you as some anti-AI troublemaker, who just becomes an obstacle standing in the way of things getting done.
If your human generated opinion is in any way wrong or simply not a true homerun then you get snubbed in future reviews, people stop listening to you.
I'm going to read you charitably, and assume that what you really meant is "the burden of proof is entirely on you, and is set unreasonably high." Because of course, if you do think someone has done something wrong and want to say it publicly, you do need a solid reason.
I'm curious how explicitly this is put -both in your case, and in general. Do they frame it that way, or is it more passive-aggressive?
That is if I ignore the slop MRs with 60+ files changed that I have to painstakingly go through and then politely tell the author to fix the crater sized holes in it, while a vein in my forehead almost explodes. And some part of my sanity is lost forever.
Speaking of tradeoffs, I want to keep pulling the thread: is it worth reading—meaning, understanding—the code in order to prevent p95 latency from skyrocketing, preventing OOM death, and keep our apps reliable for customers?
The cost of understanding the code is ostensibly very high relative to just using a clanker (citation needed), so does paying that cost translate to value—what is it worth? Concretely, if vibe coding increases bugs and enshitification, but decreases spending without decreasing revenue (read: customers suffer, but they don't leave), do we still need to pay the cost of reading code? Is it better to invest is stickiness, lobbying, market capture?
I hope this comment isn't read as advocating for this, it's more of a thought experiment about pragmatism and trade offs. I know that I personally care a lot about understanding the code and I believe I'm paid to do exactly that (I very much enjoy understanding code so I may be biased in this). Inside of SaaS-land and outside of critical safety systems, we've seen production databases destroyed, personal data leaked, platforms unwittingly exploited, and UX bugs creep into our operating systems, and yet the companies involve keep on keeping on. Is thinking going to increase their shareholder value?
Translating this from Linkedin-speak: Is it okay to subject our users to shitty software and while we use the money saved to bribe politicians, circumvent laws and buy our competitors to kill them?
That said, I don't know if it matters at this point.... On top of Brandolini's law (mentioned elsewhere), what's more likely to happen is that developers' intellect, made available in open source, is just going to be harvested as context for different projects (I'm not taking about training data, I'm taking about devs literally cloning repos into an agent to harvest intellect).
For example, in ruby some kind of stringly typed reflection utility might Dry out code. In Rust, that might mean writing a trait over some subset of types and a macro helper, but would require careful dosing work.
Letting the LLM decide is the approach in question and the author was pointing out how spectacularly it failed to translate a complete, human designed system.
You do still have to think, but you have to think about how to reorganize code in a way that allows AI to succeed.
This is not a great way to showcase the capabilities of this technology.
Then respond with that addressed, with a firm but polite explanation that the document has some problems that need to be addressed carefully before we invest time on it.
None of this works if it’s coming from your boss, but it’s very effective at making people think twice before sending you slop.
People only do the workslop thing when they believe the benefits of showing the work outweigh the reputational risks. If they get caught every time they do it and exposed on an email chain, they start doing less.
One of the worst things one can do is pull punches when you get "contributions" that are net-negative because they waste everyone's time.
You can do this in a professional way but still get the point across that they're stealing productivity from others that have to pull up their slack.
If the commits are too big or too dense. Make them break it up, clean up the comments etc. Otherwise they are simply doing a poor job. Not Claude, them.
But it’s the fat part of the bell curve. There’s loads of even worse crap outside corporate code…and at the right end of the bell curve is deeply thought out and the result of long-term maintenance that tends towards as bulletproof as can be possible in this universe, parts of OSes, networking stacks, clocks, and the like.
It’s only because that stuff is so robust and sufficiently general that the rest of the world’s steaming pile of code works at all.
I don't know if I've worked on your bank's app (safe bet is I haven't), but I have worked on some banks' apps and... oh boy. Let's just say that if you've seen what I've seen, "stuff it into a mattress" starts looking like a sound financial policy.
Can’t have the cake and eat it too.
If they “solve” navier stokes and mathematics, they sure as should be able figure such menial tasks out on their own, shouldn’t they?
Presentation layer code doesn't control how the machine and kernel prioritize anything; so "proof" Ruby code is doing the right thing is proving the machine does the right thing from the factory.
As for abstract theory and math, well shit since any English and any math are...mathematically possible...well shit I guess we gonna have to live in the real world and not inside a rhetorical bubble; religious or atheist philosophy... cause they are not evenly distributed frameworks as religion clearly shows; so why live by the syntax and semantics of some mathematical rando who taught a stats class years ago?
Same shit as living by religious allegory
Goodhart's Law has come for 1900s means of scientific inquiry; every technology follows an S-curve and the same for every social society. In the US we aren't all defaulting to calling ourselves British or speaking Latin.
Physics will always be there. The stupid glyphs and bird song we came up with to communicate about it isn't physics. It's just a human language system.
Performance issues in code just need an LLM now
I have to ask. Did you even skim the article you’re commenting under?
None of which have much to do with how the hardware handles requests.
Am an EE with a background in applied physics and well aware we could jam a kernel in the BIOS/UEFI storage and generate the runtime state around it at boot from a prompt cause I am working on just that
Which is exactly where we are headed with Jev/decision models; they can generate new config to min/maxing per process resource use; look into bpf and sched_ext and meditate on their application. It should eventually jump out at you
We have known in the abstract how to handle computing efficiently on our machines since we started building transistor based machines
It doesn't require handing a bunch of meat suits verbose languages to make of mess of electrical state management
Writing code is not high tech. It's 1970s and 1980s tech. As this forum should be well aware tech evolves with the times.
The coder bros refusal to move on is them clinging to a sunk cost fallacy; but they already put time and $$ into their education in ugly languages and DSLs that merely initialize values in memory and ask the hardware to run it within some spacetime constraints
The syntactic gibberish is just a barnacle of a bygone era
Social web addicted Millennials need to grow up and move on
How so?
It takes effort to debunk because you have to holistically consider what the problem was and actually find the better solution to prove why it’s lacking.
In other words, to debunk it, you have to do the actual work that wasn’t done the first time.
Some people may argue “so what?”
And to that I would just respond that the fast solution implies nobody probably thought about it, which is always risky and generally leads to very bad outcomes. If for no other reason than there is at least no consensus, which for long-term software evolution is deeply problematic.
This has happened many times since this trend has started, and forcing everyone to step back after a year objectively reveals the murder that has been committed that, believe it or not, is not trivially unwound.
In the wrong hands it’s a debt machine that is already killing companies from the inside.
Also, now people who used to manage the development but not write any code also feel their superpowers to merge LLM slop in humongous amounts. It feels like a ticking time bomb, but I am afraid of calling it out and rain on their parade of 10x productivity (or often AI psychosis). Leaving the team doesn't feel like a good decision because what I hear from many colleagues is much worse. Ah what a time to be alive...
People here often say "we can't set rules, because imagine how hard it would be to follow them at scale". That same strange cognitive bias applies here. Somehow the "push a magic button and it works" and "of course it can't do it just as well as a person every time" kind of take over.
Imagine if many tech issues like access to pornography, corporate ad tech, violent/racist material, AI slop, etc. were all just armies of people doing it (like google / X actually just had a person curate your results really fast for every search). Of course people would be outraged at the quality, but its "automated" so no one questions.
Similarly, if AI was just a giant outsourced coding firm with 10M programmers that could write you a slop app in an afternoon for $1, people would be complaining at how idiotic it is, and how inferior to regular devs. But instead, the "machine bias" takes over and people try to forgive the shortcomings.
there is something in the human psyche that badly wants to replace itself with a machine, despite it spelling our own undoing, and often resulting in worse outcomes along the way. I suppose the whole "make a tool" drive has been wildly successful overall, but this is probably the required downside to such an innate drive.
Like have you seen the 3d printed houses? They are the uggliest, shittiest houses in the world, but somehow the lure of "yes but we can build them in 24 hours" seems to somehow get people interested. If a human made one of those dung heaps they would be pillaried as a village idiot, and rightly mocked, but somehow because "machine do thing", we should get excited about excreted dung beehive houses...
Really you're just asking for manual or automated performance tests (and you might be requesting different criteria than some already provided)
I take notes, email out what is personally relevant, and put the burden on people to verify any rebuttal.
Honestly it goes far
Its been immensely helpful catching things I didn't understand the first time.
But you still need to pay attention in the meeting.
It's easy to port a codebase (at least, if you have automated tests), but once you've done that, do you
- Implement features in the old code and port again?
- Implement them in the new, unfamiliar codebase?
- Just write a Jira ticket and let the agent YOLO it?
Not a good look tbh
If he truly believed in the idea of never reading the code, he'd fire all his developers and have the designers do it all - create very high level feature descriptions and iterate on them. Put your money where your mouth is
Life, eh?
"I didn't do anything. I asked two frontier agents to make the most of Elixir and this is what they came up with. Please do send a PR to speed things up! But also realize that it's not exactly extra points for Elixir if frontier agents can't find the magic "go fast" switches."
https://x.com/dhh/status/2106864061832991134
<astronaut always has been meme>
I'm pretty sure this is sarcasm, but it's also a major factor in what differentiated slop from non-slop AI work: did a developer actually take the time to review and clean up generated code. Which is, itself, an extremely time consuming process
If we are going to the moon, then by all means I think we should probably scrutinize every single line of code, but most business aren't going to the moon.
https://arxiv.org/abs/2507.09089
In the past, I could have just easily said that there's more code out there online than I could ever hope to write. There's simply no value in gluing that code together mindlessly or even probabilistically. All the value of code is in gluing it together intentionally as an organization. The value is in knowing the precise results including all side effects.
Let's call this type of AI development what it really is. It's an attempt to jiggle the wrong key in the door. You're trying to circumvent existing standards for profit and then launder blame for it.
We got strictly better version of application for cheap. What is there even to complain about?
If it were me, I would start by getting a summary of what problems the existing solution solves. I would also make sure that summary had the non-functional requirement. Maybe write a test suite that opens the page and does all the stuff.
Then ask the LLM to implement in another language, with those solutions in mind, but first coming up with reasons why the target language might not be as good, and where it might have useful features that the original language didn't. Use the test suite to check if things are working.
I honestly don't think you would land far away. You would have to answer a few questions along the way, but it would mostly be plain sailing.
I would expect to be able to do this with very little human attention, whereas a language rewrite two years ago might take a whole month, not including learning the new language.