> I also noticed a pair of very bizarre apps, both branded with the yellow “Don’t tread on me” flag: DuressKeyboard & UnlicenseLauncher. What’s most curious is that they have been in development for quite some time, yet all the changes are done not with git but through the GitHub web file editor! Someone go find that person and teach them to use git.
My first startup job after college I was astonished to find that one of our most productive engineers was a deaf furry who used Windows Notepad as his dev environment. His code always compiled first time and was nearly always right. It really was something to behold.
Not that many years ago (maybe 2012-2014), we were taught working with R using only the base-R. Its' native script editor was a Windows Notepad or something equivalent. We used this for years.. Professors as well. For some reason we didn't know about RStudio or any other fancy IDE.
TBF using notepad + terminal is a great way to learn how a language or stack works. It's possible for pretty much everything, and once you learn how your ide (or LLM) is putting things together it makes it so much easier to fix when things go wrong
This must depend on language. I think that at least for Python, JS/TS, Go, C, Fortran there isn’t much difference in setup with notepad+terminal (or sublime+terminal for myself) relative to whatever the kids are using these days. Other than syntax highlighting and LSP, obviously, but I’m not sure those have much to do with learning how the language or stack work. Could you explain what you mean if I’m misunderstanding something?
Reminds me of a professor that displayed snippets of Haskell on MS Word in her lectures, formatted by hand. I don't blame her, this was >20 years ago, before Ctrl/Cmd + +/- became commonplace for zoom/font size.
I actually don't see any significant signs of AI use. There's Copilot listed in the contributor list, but I'm not seeing commits listed under it. Did they wipe it off Github?
Some seem to stamp Mostly AI based on weaker circumstantial like large init commits. Maybe it's just an artifact of human sloppiness.
Or maybe it was just the artifact of choosing these by last update, since vibe-coded apps genuinely do have an abnormal number of releases, and thus would be much more likely to show up.
Co-author is so strange. Like, would anyone credit an IDE or even a script generating code as co-author? Even legally, tools don't have the ontological requirement to be credited as author.
I always tell Claude to turn that off. It looks incredibly tacky. I'll leave an agents.md file in the repo if I don't care about people knowing AI helped me.
I have been working on a sub 1500 line rust init system for over a week. Hundreds of prompts. All with a local LLM running on my own GPUs because I expect to build with total sovereignty but also zero dependencies, no libc, no alloc, no std, and a test suite that proves the 20 implemented raw syscalls all use the right values by comparing against Linux kernel sources. This would be the only privileged code in my operating system so I must have absolute confidence it is perfect.
It would be too annoying for a human to ever write code to standards this high, and would have taken me months to write by hand, but with the help of AI I was able to get it done and built in a way I can easily review and reason about.
I have a memory safe baremetal tiny linux init now built to my exact requirements.
AI can help experienced engineers write better code in less time.
I don’t even disagree that “AI can help experienced engineers write better code in less time”, but “It would be too annoying for a human to ever write code to standards this high” when the standards are “zero dependencies, no libc, no alloc, no std, and [correctness]” and the project is <1500 lines of Rust implementing 20 syscalls is a little much. All software ever written before 2023 was written by humans, remember?
Of course. The humans that could have written this -eventually- certainly exist but they could not have collaborated with me to get me these results on my exact schedule in a week for the few dollars of pay I spent on electricity.
If your input is LLM-generated code, it's like taking snippets from Stack Overflow. You understand it fully and then make it yours. As long as you're hand-crafting the result, you grasp how it works.
This is an aspect of LLMs that probably shouldn't be understated.
I'm working on a validation tool with a coworker right now. We are meat-proxying it into existence, using less than two exchanges per day of his LLM validator and my LLM authoring engine (we could consolidate, but he's got some context I don't have and it would take more than zero engineering effort to ship it to me when PR messages through GitHub are a good-enough channel).
If not for the LLM, the tool wouldn't exist at all because we can't justify dedicating much of any engineering time to building it. But LLMs drive the engineering cost very close to zero, enabling the authorship of code that would never find engineering cycles otherwise.
> It would be too annoying for a human to ever write code to standards this high,
These are standards of a normal university operating systems course (assuming a university worth its salt anyway). Ridiculous to present it as some kind of feat that was "impossible" or even that rare.
Sure, a very smart and patient human could write this by hand in a long enough time horizon and unlimited budget. I should have said impossible in any realistic amount of time any responsible sponsor or employer would pay for.
is textbook definition of boilerplate. you need to be patient to cross-reference syscall tables but certainly not smart.
Again, students learning about operating systems do similar things as a normal part of their education process.
I'm not saying LLMs wouldn't help with this (in fact, this is the type of thing that becomes pretty much a no-op with them) but the notion that this is "impossible by any realistic standards" is risible, and if you have actually contributed to the kernel like you say, you should know better.
Rather than patiently referencing syscall tables by hand which is error prone and hard to review as a human, the LLM wrote tests to actually compare each of these to the kernel syscall tables to make my life a lot easier and avoid regressions or mistakes. Complex tests to write, that saves me a lot of time as a security reviewer. Can change any value and watch tests fail.
That is the point. Getting to results that satisfy security and functionality requirements in much less time.
Also, I was able to generate a bare minimal and hardened kernel config by using the LLM to write a tool to trace all kernel calls. Something that I would have normally been forced to punt on that LLMs made easy to justify.
LLMs are just as Linus Torvalds likes to say "Auto complete on steroids".
The parsing code isn't even correct, though. I'm sure it works for the current input source code, but it's a clear sign of an LLM developing by iteration, rather than actually understanding the problem and coming up with a correct solution.
How often does "this table of constants was transcribed incorrectly" even come up as a bug class? Is it worth writing a buggy C parser for a failure mode that doesn't happen? Do you expect that Linux is going to change their constant definitions out from under you?
Correct depends on what problem one is trying to solve though the parsing can certainly be cleaned up before release. It is a working WIP.
> Do you expect that Linux is going to change their constant definitions out from under you
Unlikely but I have been surprised before. Hardcoding to pretty much any modern kernel source version forever for this narrow use case is probably fine.
The goal is about helping me and a reviewer quickly form confidence none of the magic numbers are mistaken or malicious in an automated way against the source of truth.
I guess the point you're trying to make is that apps developed by LLMs don't need to be all that bad, but the problem here is that you can't know who does their due diligence with auditing their own code and who doesn't, and you can't expect potential users to do it either. Especially not when similar apps get published at increasingly faster rates.
LLMs also helps inexperienced engineers (or people who do not have any own software engineering skills themselves) to write horrible code in less time.
Of course you also can't trust everything human developers publish either, but the issue is amplified by LLMs.
Cool, but I fail to see how it is relevant in the context of the article? You clearly have the knowledge, expertise and discipline to incorporate LLM in a workflow that, taking your word for it, delivers a very good result.
That makes you a) more unique than you realize b) not all that relevant in the context of the article.
a) Because a lot of people tend to lean towards use that absolutely leads to atrophying of skills and knowledge. b) well the article does explain the criteria it used fairly well and your project would not show up there. Well, also because your project isn't an android app.
An appliance Linux distribution without dependencies is way more complex than a typical android app and there is little prior art to train on.
Android apps on the other hand, LLMs have enough training data to rapidly generate whatever you can think of with much less time required for an experienced engineer to refine it into a quality result.
I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.
It is frankly amazing we can point an LLM at a proprietary ad-ridden app and get to an ad-free open source and privacy respecting clone in a weekend now.
> I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.
Its not that hard to imagine that apps made with heavily LLM involvement suffer in quality. The article already goes into it a bit. I get the strong feeling that you are failing to approach this from anything else than your own perspective and how you use LLMs. Which, given the setup you are describing is already far from the norm.
Zooming out a bit further I think we can generally break up LLM usage in roughly two distinct ways of using LLMs. Or maybe more accurately there are two sides of a spectrum with a lot of area in between them:
1. Let LLMs do the majority of the heavy lifting and generate the output. Providing an LLM with some basic info, what you are looking for and let the LLM do most of the work for you.
2. Using LLMs as a tool external to the process where you are still doing most of the work.
The first way of using LLMs using agentic workflows, code harnesses, etc *can* produce good quality. As long as there is still a human in the mix who a) has the prerequisite knowledge to validate what the LLMs have generated b) takes their due diligence at key points in the process to actually make sure input is of high enough quality and validates the output.
You have decades of knowledge and experience you are now applying to rigidly structure how these LLMs work.
Which, yes again, I believe gives you personally pretty good results, no doubt about that. But, many people do not have that experience to begin with.
And even for those that do, using the first method comes with a risk that boils down to simple psychology, our minds are wired to take the easy approach wherever they can. Which turns the first way of using LLMS from a efficient way of using them to a lazy way of using them.
In my personal experience a lot of people who start using LLMs sort of drift to the lazy approach very easily. Because it is very convenient and easy to slowly hand over more thinking to an LLM. The latter I have seen happen all too often around me. An alarming increase of lazy non critical use of LLM tools by people who should know better. People who might have been a bit slower before but delivered excellent results now have started delivering trash. Code spanning dozens of line trying to solve something that should only take one line. Code that completely ignores and conventions or design paradigms put in place. Code that goes directly against security practices. Suddenly downgraded dependency versions (because the models training data doesn't include the latest version).
As I said, I see this as a spectrum and the more someone leans towards the first use case combined with "lazy usage" the more signs there will be in a repository that this is the case. The amount of commits, the release cadence and various other things. Which, again, the article also makes a case for and is again why your repository is irrelevant to the whole discussion. Why? Because your repository doesn't show these signs.
Fair and nuanced. Nothing I disagree with here. I think I mostly just dislike the default hate and assumptions on everyone that uses LLMs, including often me. Some of us are using these tools thoughtfully.
LLMs help experienced engineers write quality code faster and it helps amateurs write shit code faster. Problem is there are simply way more of the latter. Even so I detest engineering being judged by the tools used, instead of the work itself being judged on its own merits because there are exceptions to every rule. I would like to teach people to use these tools responsibly, instead of sending a message that use of these tools is automatically thoughtless slop.
Like, most people I know that use Vim write much higher quality code on average than the people that use VSCode as tool preferences often reflect experience, but not always! It would still be unfair to write off someone's code sight unseen because they used VSCode as there are always exceptions to the rule.
Correct. It does the bare minimum system calls to boot the system, then exec to an unprivileged service manager on a read only nosuid, nodev filesystem.
I do not personally know a single human I could have hired who could write low level nostd nolibc noalloc rust like this, and certainly not in only a week even with hundreds of messages from me giving them detailed direction. That person may exist, but a day of their time likely costs more than the GPUs I racked up in my garage to assist with this.
I know no one wants to believe an LLM plus a human could produce more secure code than an LLM or human working alone, but as engineers we should adapt to whatever gets the best results.
Also every line is manually audited by two experienced software engineers before production.
In a week for a few dollars of pay with a test suite that comprehensive and on my exact schedule to collaborate with me around the clock? I doubt it, but I would love to meet that person if I am wrong!
This is the fastest I've ever seen goalposts move. Like, this is a completely different claim from "It would be too annoying for a human to ever write code to standards this high".
If you take what I said out of context with zero charity, sure.
> and would have taken me months to write by hand
That implies humans can write it because I am a human and presumably other humans can too. I was making a statement about it not being possible to write it in any justifiable amount of resources.
My company would fail if I spent months on this, but a week to harden init is for sure worth it.
I interpreted that as you saying in a few months you could write the code but not to those standards.
If a single person can do the full job to full standards in a few months, then the whole idea of it being too annoying for a human to ever do falls apart. That's not that expensive. Your company can't spare you, sure, but most companies could handle that price.
And even with the adjustment to being something it's easy to hire someone for, that's still ballparks away from "in a week for a few dollars". Nearly every coding project is impossible for humans by that standard.
> Nearly every coding project is impossible for humans by that standard.
Exactly, which is why this small project, and the other dozen projects that need to be written to the same standards to make the final end result OS, would just simply not happen otherwise.
No small FOSS org can afford to spend person-years holding standards this high, which is why in practice most orgs just cut a ton of corners and pull in tons of dependencies no one will ever review and the attack surface that comes with them.
LLMs allow experienced engineers to get 10x as much done in the same time, and now that this is possible few will be willing to pay engineers to do it at 1x speeds again.
Just like once assemblers became normalized, few orgs would let people write all their assembly by hand anymore except for very small high performance sensitive portions.
Software engineering is not going away. It is just accelerating because we were able to move our attention up a layer again.
If you read the rest of the same line you are hung up on I literally said I could have done it in a few months, which implies I believe humans can do it, so clearly I was saying it was impossible to do in any practical amount of time or resources.
I started with a hand coded C version, then a hand coded rust version, and then an LLM refactor to remove all dependencies and add a comprehensive test suite.
Please, report me to Codeberg. It will be amusing.
I personally know a Codeberg admin that works with LLMs as a tool for things like this which are actual engineering and not vibe coding.
LLMs certainly can interpolate between information found in its training set vastly faster than humans can find similar code on GitHub and stack overflow (or in math papers). It's certainly a tool that can be used when programming.
On the other hand also calculators help solve problems people have struggled with for millennia. It also doesn't mean that the end result is better than by hand. It's actually not, and that's the reason why you cannot replace programmers, because you need them to steer the LLMs for a good outcome.
And even the answer to the question, if LLMs make us more productive as programmers long-term is not really clear
The code is not better than an imaginary human paid to work on this as long as they wanted. But said human and sponsor did not seem to exist.
If not for LLMs this type of hardening would not be possible for me to justify at a startup, and I would have had to sigh and accept the huge attack surface of systemd.
I am a security engineer and there are unlimited things to harden, so LLMs let us harden a lot more in the same very limited time.
Brute forcing faster than a human could and able to vary approaches on the fly saving humans a lot of time. Humans need only set the direction.
Lets brute force cancer. All for it.
That said, to be clear, I would never give OpenAI or Anthropic money. Their irresponsible behavior is separate from the objective capabilities of the tools, which we should seek sovereign versions of.
I'm somewhat surprised about PipePipe. I had a look on the commits of the various components and nothing looks out of place to me. Commits look rather reasonable, comments look useful and don't show obvious LLMisms.
What are the AI smells there?
It would be nice to expand a bit on the reasoning behind the verdicts.
Seems like the wrong question to ask. I've been programming my whole life but basically stopped writing code by hand in 2026. The LLM writes better code than I do, much better.
Same here. I'm still a better software architect that AI, but there is no question that my AI generated and reviewed code has fewer bugs than code I hand write. It takes some humility to acknowledge that your coding prowess is less of a useful skill than it used to be.
There's an issue where people assumed the syntactic activity of writing code was what mattered. The reality is that this was always a smaller part of the role, as opposed to thinking about observability, serviceability, and test automation. The ability to write software that is properly separated from concerns and when to enact those separations matters.
At the same time, I think we're far too far down the systems path now. We've hit a point where interviewing has become purely systems design "because the AI writes the code".
Not that I'm ever asked, but I inherently believe the act of critical thinking, communication, and expression are the key skills for those who already have the appropriate coding/engineering/cs/etc background. I now only interview for those skills - but through the lens of impossible to solve systems design conversations as opposed to problems. It tells me a lot about how people think.
So is architecting, testing, validating, and even occasionally using.
This isn't the first time I've seen this phrase recently, but I'm not sure what the thought is a cliche or what it is intended to convey (don't read my note as negative, I sincerely am unsure what connotation folks are trying to say).
The idea behind "writing is thinking" is that people often overestimate their understanding until pressed to express it in words (or code).
How many times in your career did you sit down to tackle a task thinking you knew exactly how to approach it only to realize during implementation that there were edge cases you hadn't considered, API contracts that were now broken, or that the feature was trying to solve the wrong problem.
Having to be the one at the helm during implementation made you intimately aware of not only the problem at hand, but the current state of the codebase. That's something you can't replace with automation. You can't compress all of that context into your brain in a handful of prompts with Claude.
Remember the words of your math teacher--
"Watching someone else solve the problem doesn't mean you can now solve it too."
Not sure what you mean as system design conversations because while in theory those can be good in practice the ones I have been at had been techbro wankery where the interviewer had a particular answer in mind. Like designing your own memcached clone for example is a terrible task for systems design.
What you're mentioning is 100% what's wrong with the industry. Agreed! To me a systems design conversation is a conversation - not a design goal. The idea is to determine ability and psychology:
1. When you press on someone's design respectfully, do they get defensive. Do they become argumentative.
2. When thoughtfully pointing out a concern, how does the candidate take it?
3. When you suggest a technology that makes no sense to intentionally challenge knowledge, does the candidate recognize why it makes no sense? Are they able to share what the negative of the approach is. If you indicate that you know the question is "senseless" but want their feedback, how do they communicate?
4. When you hard request a change that requires a literal rethink and rewrite do they become argumentative? Do they embrace the change?
5. When discussing testing, how do they think about it? I come down to the nitty gritty and ask about postive vs negative cases, table driven testing, what types of tests matter (for our situation) and why.
6. We discuss timeline tradeoffs, and then have the conversation about the candidate's approach given updates to see how they think.
You'll notice that I am never looking for a solution. I'm seeking communication, description, partnership while having a (relatively) thorough gasp of the subject matter.
Every single time I get a response from a candidate such as "I don't know, I'd have to learn more - or use AI to, or.. what do you think" turns out to be something I LOVE, because it creates a great fabric for the interview.
Programming languages, design languages and architecture are all inventions made to help humans write understandable source.
LLMs don’t really need to do any of that. They can store very large trees of understanding and therefore implement any application in raw binary. Why bother with abstractions at all
LLMs for sure need those things. maybe not the same abstractions as humans do but without understabdable code an LLM will just fail to accomplish the task you ask it to do.
I was thinking about that. I reckon generating massive amounts of synthetic training data for that goal should be possible - you've already got the Python, after all. It's also possible for machine code, but you'd have to target more platforms.
But ultimately, I think human readability outweighs any theoretical advantage you get from removing a step in the compilation process.
Targeting byte code or asm instead of high level would be silly for everyday tasks. You blow up the number of tokens, reduce your effective context, and there's just more places for it to make a mistake, which most likely won't be caught by the assembler (unlike compilers).
The AI machine can write better code. It can also write an interpreter which implements function calls by instantiating a new interpreter + entire standard library per function call. Or it will build a 300kloc cathedral of scaffolding and maintain that forever, never writing actual code. Or it will create a CI system that takes 2 hours to run and constantly fails, and the agent loops there all day, fixing a small bug and waiting 2 hours. (All things I’ve experienced latest frontier models do)
Agentic engineering faces all kinds of new problems that couldn’t exist before, and need experienced engineers to solve them.
With the "intelligence" of code focused and capable llm in the last six months, the main problem I'm seeing now is where some total amateur who has no previous knowledge of coding tries to one shot a project. People who have previous experience and know how to architect things (and when to stop an LLM from doing something wrong that will cause maintenance and scale and extensibility problems in the future) are doing much better building actually useful things.
This one shot thing I just don’t understand. The way I’m using it, it takes weeks of constant prompts because it never does exactly what I ask no matter how well I specify. I just don’t see how it’s possible to one shot anything unless you don’t have strong requirements on the output.
I had pretty good success with a language learning app. Initial prompt below, about an hour to get it working very close to how I imagined, then extended to Japanese, French, and audio generation.
======================================
Hi! I'd like to create an app for interactively learning Chinese using AI. My current idea is:
- The AI generates a Chinese sentence at a specified vocabulary level (e.g. HSK2)
- The user translates the sentence into English, and the AI evaluates the response. If the answer is wrong or is partially correct but could be improved, the AI offers a hint. If correct, the AI confirms and explains any particularly important vocabulary or grammar points that the sentence demonstrates.
- The user should be able to click on an individual character once to see the pinyin, and again to see its definition and any helpful techniques to remember it (radicals, similarity to other characters, visual meaning)
- The app should also be able to go the other way, giving the user an English sentence and having them translate to Chinese.
App details:
- UI is a web app
- The AI should be pluggable. We'll start with a local Ollama install running gemma4, but it should be easily possible to add support for Claude/OpenAI/Gemini or other models (may need to provide an API key).
- Not actually sure if we need a backend. It might be useful to keep track of characters or concepts that the user has difficulty with, or to keep track of what sentences the AI has previously generated so it doesn't become repetitive.
- Build everything in a Docker container (or multiple if needed with docker compose)
I can see this being a one-shot thing because the brief is pretty light; beyond broad strokes, you haven't specified much for it to actually do. Any UI that's also a webapp would satisfy this brief, but that's exactly what I mean; e.g. if you want a specific UI, there's a lot more back-and-forth that's involved. It'll one shot a UI, but it's very rarely the UI you want down to all the interactions and placement of buttons.
Yeah, that's fair. I didn't have an exact UI planned so I gave it flexibility, and it made reasonable choices that only needed a bit of tweaking to be quite usable.
For me the usefulness of a survey like this has nothing to with how effective LLMs are themselves. It's more that when someone's able to produce an app in an afternoon, and submitting the app to F-Droid becomes a checkbox, how confident can you be that they'll continue maintaining the app? Sure if it's open source you can have your own LLM maintain it, but at that point what's the value in having it on F-Droid?
"There are naïve questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question". (Carl Sagan)
Just because you don’t seem to be interested in the answer - then don’t read it? - doesn’t make the question wrong.
I just asked Astra to bring an old Windows XP game to the browser. It objdump'ed the whole thing, built a fitting Win32-like wrapper that exposes required functionality like DirectDraw, DirectSound, SEH etc., then wrote an x86-32/x87 interpreter in WASM, benchmarked how the game runs, lifted the hotspots of the executable to WASM too and now it is playable!
I mean, I'm proud of my low-level skills too but this is some Fabrice Bellard level sorcery. Very, very few humans are able to do this without AI tools.
Absolutely, the Win32-WASM layer it wrote is some of the most evil looking code I have seen in my life. But realistically, why keep it maintainable for humans if you won't find anybody that can work on it without AI anyways?
If we humans are just doing code style checks, file organizing and doc cleanups I feel we have demoted ourselves to code janitors. This is neither fun nor going to last.
Personally I've always strived for minimalism, to find the smallest, fastest, simplest solution possible so I'm pretty jaded now, too...
Code is a human formalism that is only incidentally made executable. The elegance of code represents understanding of the problem to its most minute detail. LLM code being recognizably terrible shows it still doesn't understand what it produces to the full extent, and just as with people, it will inevitably compound to it becoming unable to efficiently work on it. And if the human abdicates that responsibility too, then there is no code, only subtly broken software.
Yes you can ask the agent anything about it and interrogate it until you understand.
- is it maintainable
Yes it’s easy to ask the ai to add new features or to refactor it entirely.
- how much work is adding new features
Depends, it could just be one prompt, it’s usually many prompts. If the refactor is large it can take weeks. But before AI something g equivalent would take months.
- is it written in a way that adding new features means rewriting a lot of it
Usually no, but that depends on how well the agent is being directed and what the features are. If you come up with a feature that requires a new architecture, ai makes it doable rather than saying “would be nice but we’d also have to implement this whole new architecture and that’s a lot of work”
- is it written in a consistent style
Styles can be applied mechanically with linters and formatters, so as much as any codebase written by multiple people.
I've seen AI be wrong about things often enough to know that none of what you said is particularly true. Rather, most of it holds true most of the time. But not enough.
> Styles can be applied mechanically with linters and formatters, so as much as any codebase written by multiple people.
I'm talking more of a higher level than this - more of coding/design patterns that are common for the team.
> Rather, most of it holds true most of the time. But not enough.
I see it be wrong about things all day every day. And yet, IME it's correct enough for it to be controllable. It doesn't have to hold up all of the time, it just has to respond to corrections when they're issued in a loop so that it converges to a correct solution. And it does, despite the mistakes.
In one of my other posts in this thread I detail some of the the ways it's confounded me, but those issues have caused me to harden validation mechanisms rather than say "this thing makes mistakes so I can't use it to write software".
> I'm talking more of a higher level than this - more of coding/design patterns that are common for the team.
What people don't understand that programming is very much an art. You iteratively work on it ripping parts out, rewriting and rewriting and rewriting, while also rewriting and then rewriting every time a new feature, bug fix or scaling changes are needed.
As a bit of an observation on that specific project... By hand as a human you could spend six months of the equivalent of a full time job doing that. Even if you had extensive knowledge in all of its discrete pieces. One of the things coding focused LLM are great at is doing things that have no reasonable prospect of economic necessity to do (no for profit company is going to pay you a FTE salary for six months to do that task, because there's no possible revenue in it). But the LLM can be pointed at it and get it done in a day or two with some periodic architecture and decision making by the human, for probably under $50.
fwiw, PCGamingWiki[1] has a link to a patch[2] that someone wrote to fix the compatibility issues. If you're playing from the CD edition, you might also need SafeDiscShim.[3]
If there are very few humans that can do this is because the market for such a task is very small and thus there is little incentive to learn how to do it or produce tools that can do it.
Only people disliking AI for coding are the gatekeepers who think they are magicians and the plebs shouldn't be able to code like them, unless they become gud.
People say this every 6 months. I've stopped even paying attention to it, because (A) the code quality remains below the floor, and (B) the people saying it continue to ignore all the other issues with LLM code generation.
Up until the last couple of months, I have treated LLMs as a supercharged stackoverflow. I would ask it questions on how to do something in a general sense, and then adapt the answer to my use case.
Now, my entire programming flow does not even include an editor. The tools I use are: pi.dev to write and implement openspec specifications, herdr to manage many pi instances, and ollama to run qwen 3.8 27b on my single 7900 XTX.
Writing good specifications is the key detail here. I will often iterate on a spec for hours until I am happy with it all of the details. Once I am happy with the spec, I can be quite confident that when I tell pi to apply the spec, the changes that I want will be done, and done how I want them, when I come back to check when it reports itself as done.
The landscale is fundamentally different from what it was. Feel free to ignore it, but you can absolutely generate high quality code if you know what you're doing.
No problem. I think it's less of people withholding information to have an advantage, and more people still not having settled on a workflow they like. Herdr is the most recent addition in my workflow as of only a few days ago, but it directly solves problems I have been having (juggling tons of terminals, even with my tiling wm has been a little unwieldy). The rest I've pretty much settled into for a while now.
The other tool I wanted to throw out there is voxtype (plus wtype). I've been looking for a good, global, local dictation solution for wayland for a while now, and finally landed on this one. It's great for rambling details that pi+qwen can then convert into concrete openspec specifications.
Not sure what I can say but the LLMs simply do not write good code without tons of handholding. As a C developer most LLMed patches I have seen the last couple of months have been awful and the few good ones I know from the author themselves that they did a ton of iteration and/or manual cleanup. Maybe they are less bad at writing other languages.
At least what I have seen in Ruby and Typescript, they are excellent at doing what you asked for. But if what you asked for is stupid they will happily make it happen.
They don’t make normal mistakes like typos and they aren’t lazy so things like tests and checking error cases is usually done.
I tried a lot of tools. Claude code, deepseek with kilocode and OMP, codex... I still use claude quite a bit. But frankly, all of them produce some absolutely godawful code. Review load went way up with AI, and it's not just the volume that caused it, but also the quality. It's extremely verbose, hard to read, often repeats code instead of factoring it into reusable components. And yes, sometimes it's also buggy. Except now, you have to debug a problem that's in code you didn't write yourself, and is awful to read.
LLM is incredibly valuable for debugging complex problems, codebase exploration, and planning large changes. But the writing code part itself, I find, LLMs are just not very good at it yet.
Vaguely telling the agent what the issue is and what behavior I expect solves the issue with a fraction of the effort.
Some claim that the tech debt only keeps increasing and that the result will be unmaintainable. This is not my experience, and I don't think it is theirs either. These claims are often entirely speculative.
I, and I think most experienced developers, can recognize the type of code that incurs a maintenance cost down the line; that will make adding new code take longer. And AI writes such code "relatively" frequently. I love having the AI to write code, but I find it extremely important to review it - to make sure that it's correct, understandable, and not going to be a problem later.
I find it unnecessary for most non-critical code, such as client applications.
I doubt that any supposed future extra effort for the AI to add new code is remotely comparable to the upfront effort of you reviewing the code manually.
I know that this is the case today for native mobile apps, and I speak from hundreds of hours of experience over the last four months on such a project where I stopped reviewing the code.
We are already here today, and this balance is only going to further shift to the point where it is obvious that the hands-on approach is no longer competitive.
Everything about what you're said strikes me as sounding like "I don't bother wearing a seatbelt, because my experience is that I don't get in accidents" .. and also "I don't write automated tests, because I already hand tested my code and it works".
And neither one of those statements is very convincing to me.
And what you said strikes me as speculation not based on actual experience in using AI in this way, with a healthy dose of condescension added.
Anyway, I think we shared our viewpoints, and neither of us is going to change their mind until either my project fails spectacularly, or you change your approach in the future to use AI more autonomously.
I've had bugs the agents can't fix or figure out. Sometimes those involve third-party, proprietary, broken code (read: Windows APIs). Sometimes they just involve complex deployment situation on the client code (I work on desktop apps) where the agent can't figure out what's wrong/makes wrong assumptions/goes nowhere. Sometimes the agent is just very dumb and tunnels vision on the wrong fix.
FWIW, I've also had bugs the agent fixed that I probably never would've figured out without LLMs - LLMs are definitely useful! But I need to keep understanding how the code works so I can take over the reigns when the LLM fails.
I’ve had some luck prompting them to be concise, both in writing and in code, and with code doing an approach where they get it working, write tons of tests, and then refactor for conciseness and readability. All the tests prevent regressions doing this.
Without such prompting and a conciseness and clarity pass you get a slop grenade.
They overall work better with tests, and Rust is a great language for them. Overall they do better with lots of walls and alarms that go off if they mess up. I don’t need nearly as much of this, can mentally simulate it, which is a good “are we superintelligence yet” reality check. Still not even as good as my wet meat brain. But impressive given what was possible even two years ago!
The result is still not as clean as a good programmer but it’s better than the slop grenade you get first pass.
I spent 22 years as an engineer split between MS and Apple. SOTA LLMs can write code just as good as most human engineers. I expect to see the "LLMs are just next token predictors!" crap on Reddit... not HN.
LLMs produce pretty crappy code but they are very useful tools for protyping, code search and finding bugs. Maybe LLMs in the future will be able to write good code but they are very far from that right now.
Perhaps it would be useful if both of you could provide examples of supposedly good and bad code – the latter being the result of a genuine effort to produce good code with state of the art models. Just asserting that LLM code is good or bad ends in a yes - no - yes - no back and forth circle immediately.
I just used an LLM (along with my decades of operating system development experience) to create a macOS tool [0] that lets me see through windows, instead of having to continually command+tab between windows.
The solution required reverse engineering and internals knowledge that most human engineers don't even have.
The question is no longer "Can an LLM write code?". It can. The problem is that certain humans refuse to put in the effort required to properly utilize these tools.
LLMs have been good at knowing what's in the manual from v1.0. Super good at that. Pretty good translators. Pretty good at doing things that have been done a million times before, like your CRUD app. Super mediocre at everything else.
LLMs as things that know what's in the manual are AAA+. Extremely helpful. Very good at making a rough draft of something filled with a lot of stupid mistakes and no new abstractions. That's what your transparent window thing is. Something that you could never ship, is probably too big and doing senseless things for no intelligible reason, and definitely has bizarre bugs.
What in the world are you talking about? I was literally an senior engineer on the Windows Kernel team, the Visual Studio team, and the Xcode team at Apple.
This application, named Seymore, is being evaluated for purchase by several tech companies. (It helps having good industry contacts)
There was a ton of interesting engineering required to make this work at 60 fps+ without resorting to hacks or using private APIs. Most macOS engineers wouldn't even know where to start.
I've shipped code that is used by billions of people and all you just did was spew a bunch of bullshit. As someone who has built their own LLM from scratch, I have an extremely good idea of what they can and can't do.
If you don't know how to use these tools, you'll end up with crap. If you DO know how to use them, they are incredibly useful.
I don't agree with using your credentials to show your code quality, but I don't doubt you have better standards than most developers. That said, stop trying to change their minds. Antirez was a good at programming until he started coding using AI only. The same will be said about Carmack and Linus.
What they are saying is increasingly difficult to defend, but they will do it anyways. I see the same arguments at my job, and I just gave up arguing against
I mention my background because it is relevant context: I spent nearly 30 years building software used by billions of people. If you use Windows or macOS, you have likely used code I helped ship. I’m not going to apologize for that experience or pretend it does not inform my judgment.
Some engineering problems (such as designing a performant thread-quantum algorithm) require depth accumulated over years of working on real systems at scale. That is not elitism; it is simply how specialized expertise works. Experience is unevenly distributed, and that matters when evaluating technical claims.
When I say I trust LLM generated code, I mean that in a qualified, engineering sense. I do not treat an LLM as a slot machine: enter a prompt, paste the output, and hope. I use a deliberate workflow for decomposition, prompting, review, testing, validation, and integration. Developing that workflow took substantial time and experimentation.
The useful question is not “Can an LLM write code without oversight?” It obviously cannot, at least not reliably for nontrivial work. The question is whether an experienced engineer can build a process that makes LLM output trustworthy enough for particular classes of work. In my experience, the answer is yes. But the process, judgment, and willingness to do the work are the hard parts.
This kind of shaming is getting tired. At the end of the day, the people claiming their code quality is better without ai, while everyone else has low standards, aren’t providing any evidence of their supposed superiority.
I think the burden of proof is on the new technology. It's been almost a year since the supposed death of manual coding, depending on how you count, but I haven't seen the efficiency benefits of AI trickle down to the programs I'm an end-user of. I _have_ seen the bugs, however (rsync 3.4.3 for example.)
Depends what you mean by end-user. Power users of AI aren't using these things to build applications for users, they're using them to do all the things they couldn't do as mere mortal programmers. Like the other poster detailing how they got a game running in web assembly. That's not for end-users, and even if it was they wouldn't be able to look at that and say "Wow, this is an example of AI benefitting me as an end-user" they'd just say "Wow cool, a game".
Every codebase that is being actively worked on (closed/open source) will contain code that's AI generated. With the rising abilities of agents, expectations are sky rocketing in terms of productivity.
If you're as productive as an engineer in 2016, you're not at the level that's expected. A 7 day workflow back then should take you maybe a day or less to work on today.
I've worked with "engineers" that make one commit in 2 months and it's a spelling correction. I'm pretty sure that being 7 times faster than that is still quite slow compared to me :) I hear a lot of breathless enthusiasm, but this article is possibly the first time I'm seeing the question answered "If AI is so great, where are all the applications?"
”””
F-Droid is not hosted in just any data center where commodity hardware is managed by some unknown staff. We worked out a special arrangement so that this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access.
”””
What do you find strange about trying to protect against tampering and theft?
I find it strange how little people seem to care these days and just widely share their users and company data across clouds. Plenty of supply chain attacks to learn from.
Separate from building your own code, ,of course you may have your own standards to apply.
But for apps, well, I never had a chance to see how good or bad the code was before AI was about, so why should I care now, so long as what I paid for does what it says it does (and nothing nefarious..)
Some programmers have ethical concerns around the use of LLMs. It's like saying "my clothes still work, why should it matter if child labour made them?"
I don't know wnything of the ethics of any real meatbag developers that are working on the code or app I install on my phone either. I fail to see how, for pre-packaged code specifically, it being AI or not is a problem; ~ rather, surely all the concerns we have about AI code (hopefully properly developer reviewed.. - which I suspect is where the real problem lies) apply to developer written code also, when it comes to pre-packaged apps.
The blog post provides something akin to answer to this question:
You see, the main allure of LLMs is that they allow the developer to be more lazy. That’s kind of the whole point! You just prompt, sit back and relax. So it should not surprise you to hear that this attitude is then reflected in everything the vibe-coder touches
As I understand it, one of concerns is that with the lowered barriers there comes a flood of low quality software, vibe coded by very lazy and not very talented people.
This might be actually more of a human problem, but it's a problem nevertheless.
I had no visibility of developer attentiveness or lack thereof, not skill or code quality before AI was around, for any apps I downloaded to my phone.
I fail to see why worrying about AI code quality is any different to worrying about developer code quality when it comes to pre packaged apps.
With code I am writing, some AI generated, my work load has not really decreased, nor have I gotten lazy. My work has changed to a degree, and now involves reviewing and guiding and double checking AI code where I did not have to before, but I am certainly still working just as hard, and accomplishing more with AI's help in spite of the change in workload it brings.
delivering bad AI code because you got lazy is not the AI fault, it's the developers fault.
You can't call people lazy because they use LLMs, just like you can't call people lazy because they travel by train/plane/cars instead of their own feet.
Who/whatever does the layout and organisation of app categories is a blithering idiot and finding apps is best done with an external search as the internal one hides apps even when searched for directly by name.
And the fdroid app is relentless systems deperformance burden that often just failed, and updating manualy is simpler as a chore done after any android update.
Love a lot of the apps, and the concept of fdroid, but the fdroid UI is not good at all.
It's an emotional problem. I love writing code to solve intricate problems. But knowing that a faster, and maybe better LLM solution is just a prompt away? Somehow that takes the joy out of it. Why spend hours, when you can get an equivalent result in minutes?
I will be curious to see how I feel about AdventOfCode this year...
Virtually nobody is a professional walker or firestarter, so those are different.
And to the extent they do exist (athletes and survivalists) they might agree there is no "point" except the joy they derive from doing it themselves.
The problem is that formerly there was more alignment between the joy of solving problems with a human's mind and the business need to have problems solved.
Even before AI, I just looked at file size to determine whether an app was worth installing. There used to be tool to search the Google Play Store and sort by size. If it's a basic utility and more than a few MB, it's probably riddled with bloated libraries and ads.
What stops a bad actor from buying a bunch of these apps on fdroid adding malware to them and then having fdroid handle the distribution for you? I people did something similar with a bunch of plugins in the wordpress plugin archive.
F-droid doesn't simply distribute build apps. It requires the source to be open and will build the apps itself. This does not guarantee there will be no bad actors trying to slip in malicious code. I do believe they also do initial audits before an app is allowed in their repos. It also often takes a while for an app update to show up in F-droid, I am not sure if that is due to auditing updates or something else though.
how did critics become suddenly concerned with virtue and beauty with AI? Wouldn't it be better to judge these apps on their utility?
The authors are sharing their creativity, and spending time & money to publish apps with a free license.
I have disdain for how entitled open source consumers are. Before AI, demanding free accounts, support , resources, traffic, cpu -- after AI demanding bespoke hand-written code be given out for free.
> Text just doesn’t carry enough meta information for any kind of assessments to be even close to accurate.
Well, that is true, but I have seen how one japanese developer, who has
had low english language skills, suddenly writes epic text. So it is clear
that he is using AI when interacting with other people. This is a problem
because a lot of it is just AI slop fake interacting. I don't want to
interact through any AI filter; it means the other human being is not
interested in communicating with me, so why would I want to communicate
with an AI slop controlled human? It makes no sense.
As for software: IMO documentation is very important. Many projects lack
good documentation. This is valid for both AI slop created projects and
real humans created projects. There are too many software developers who
hate writing documentation. I don't want to use such software anymore.
Unfortunately AI slop documentation often sucks too. They just spam you down
with words that mean nothing. And are very verbose. This is also totally
useless.
It seems as if software designers indeed fail hard in the last years. Quality
standards used to be higher in, say, 2005 to 2010, compared to now and the last five years.
> Their mere existence makes educating yourself and going on fun side projects much less rewarding.
It's not just AI though. Look at Google search. Use it. It is totally useless now. Google crippled it deliberately some years ago. Now you'd think alternatives are better, but they also suck. DuckDuckGo? Qwant? They, oddly enough, manage to be even worse crap than Google search, which is amazing. Crapification has become the default now.
This reminds me of another time... Let's travel back to 1980 and interview a local grey beard:
Everything these days is shell scripts! They are even selling them like they have the same value as a C program! csh will never be real C. The kids have no idea what a stack is or how to optimize system calls. The performance is awful and they barely work! The way scripts spawn processes can bring a multi-user terminal system to its knees!
I mean, sure, I write some scripts now and then, but the real logic always goes in C. And just the other day my boss gave me a shell script he coded over the weekend and said putting it in production should be easy!
Over the weekend I was checking out BSD and I couldn't believe the number of scripts I found. I fear for the future of my career and computer science in general. Our field might die out before it can even get off the ground.
Please stop labelling a project as slop just because it has been developed using AI. Coding agent are now replacing the IDE and code is now mostly written by the agents.
Please stop telling people what to do. Also, the discussion of the merits of LLM code writing is far from over. Author of TFA actually provided an interesting data point, you are just rehashing an often heard opinion.
Why are you so aggressive? I am not rehashing opinions, I'm writing my opinion. Also, I'm not even saying that the author did a bad article. So your comment is a bit out of line.
So we are calling the developers as sloppy now just because they use AI? It is entirely possible to use AI and still produce good code - the effort required changes, but so long as it is done by a diligent developer capable of asessing and correcting AI code, it should be fine.
I did not say I don't read any produced code; I said I don't write it manually. What I wanted to demystify is that you can generate everything with AI and still put a lot of work into design choices, good code structure, and so on, without producing any slop.
> I also noticed a pair of very bizarre apps, both branded with the yellow “Don’t tread on me” flag: DuressKeyboard & UnlicenseLauncher. What’s most curious is that they have been in development for quite some time, yet all the changes are done not with git but through the GitHub web file editor! Someone go find that person and teach them to use git.
My first startup job after college I was astonished to find that one of our most productive engineers was a deaf furry who used Windows Notepad as his dev environment. His code always compiled first time and was nearly always right. It really was something to behold.
"The way that works for you is the right way."
Not that many years ago (maybe 2012-2014), we were taught working with R using only the base-R. Its' native script editor was a Windows Notepad or something equivalent. We used this for years.. Professors as well. For some reason we didn't know about RStudio or any other fancy IDE.
And this is why I hate reading other peoples R scripts.
15 packages loaded but only 3 used, `rm(list = ls())` at the top of every script, hard coded paths or worse using the `here` package.
I think I read somewhere that Ken Thompson still uses ed. I can't find a mention of it though
TBF using notepad + terminal is a great way to learn how a language or stack works. It's possible for pretty much everything, and once you learn how your ide (or LLM) is putting things together it makes it so much easier to fix when things go wrong
This must depend on language. I think that at least for Python, JS/TS, Go, C, Fortran there isn’t much difference in setup with notepad+terminal (or sublime+terminal for myself) relative to whatever the kids are using these days. Other than syntax highlighting and LSP, obviously, but I’m not sure those have much to do with learning how the language or stack work. Could you explain what you mean if I’m misunderstanding something?
Reminds me of a professor that displayed snippets of Haskell on MS Word in her lectures, formatted by hand. I don't blame her, this was >20 years ago, before Ctrl/Cmd + +/- became commonplace for zoom/font size.
70% seems unexpectedly high... Was there maybe some overcounting?
Yubico Authenticator https://github.com/Yubico/yubioath-flutter
I actually don't see any significant signs of AI use. There's Copilot listed in the contributor list, but I'm not seeing commits listed under it. Did they wipe it off Github?
Some seem to stamp Mostly AI based on weaker circumstantial like large init commits. Maybe it's just an artifact of human sloppiness.
Or maybe it was just the artifact of choosing these by last update, since vibe-coded apps genuinely do have an abnormal number of releases, and thus would be much more likely to show up.
Usually AI is marked as co-author, so you can't find it in the commit list.
I use the contributor graph to find where the AI made the commits [1] and then I search using the date [2], I found 3 commits relative to a11y stuff.
[1] https://github.com/Yubico/yubioath-flutter/graphs/contributo...
[2] https://github.com/Yubico/yubioath-flutter/commits/main/?sin...
Co-author is so strange. Like, would anyone credit an IDE or even a script generating code as co-author? Even legally, tools don't have the ontological requirement to be credited as author.
Pretty sure it's just because if the tool generates the commit, it auto-adds itself as co-author. Like the iPhone emails that say "sent from iPhone"
I always tell Claude to turn that off. It looks incredibly tacky. I'll leave an agents.md file in the repo if I don't care about people knowing AI helped me.
Waiting for the day I get an email from someone that says "co-authored by my iphone"
Yes, but the equivalent of "sent from Invasive·marketing·of·some·MUA™" would be "generated with Ludicrious·Laughable·Mockery™".
That is, the MUAs don’t add "co-authored by myMUA".
"Sent from my iPhone"
There are many reasons: https://news.ycombinator.com/item?id=47164481
Perhaps cause OP used "recently updated" apps? Vibecoded apps tend to have a higher update speed, thus skewing those results?
This is about apps on F-Droid, not F-Droid itself.
Yeah maybe title should be "How much on F-Droid is LLM generated?"
I have been working on a sub 1500 line rust init system for over a week. Hundreds of prompts. All with a local LLM running on my own GPUs because I expect to build with total sovereignty but also zero dependencies, no libc, no alloc, no std, and a test suite that proves the 20 implemented raw syscalls all use the right values by comparing against Linux kernel sources. This would be the only privileged code in my operating system so I must have absolute confidence it is perfect.
It would be too annoying for a human to ever write code to standards this high, and would have taken me months to write by hand, but with the help of AI I was able to get it done and built in a way I can easily review and reason about.
I have a memory safe baremetal tiny linux init now built to my exact requirements.
AI can help experienced engineers write better code in less time.
I don’t even disagree that “AI can help experienced engineers write better code in less time”, but “It would be too annoying for a human to ever write code to standards this high” when the standards are “zero dependencies, no libc, no alloc, no std, and [correctness]” and the project is <1500 lines of Rust implementing 20 syscalls is a little much. All software ever written before 2023 was written by humans, remember?
Of course. The humans that could have written this -eventually- certainly exist but they could not have collaborated with me to get me these results on my exact schedule in a week for the few dollars of pay I spent on electricity.
That is the real difference.
And they never will, with that attitude.
It would be an irresponsible waste of limited time and budget for a human to write this which is probably why it did not exist before.
I wrote the first version by hand in C, and then rust.
The LLM was able to rewrite it with no dependencies implementing the low level system calls and test suites that would be a nightmare to do by hand.
The best use of human time for something like this is code review.
If your input is LLM-generated code, it's like taking snippets from Stack Overflow. You understand it fully and then make it yours. As long as you're hand-crafting the result, you grasp how it works.
This is an aspect of LLMs that probably shouldn't be understated.
I'm working on a validation tool with a coworker right now. We are meat-proxying it into existence, using less than two exchanges per day of his LLM validator and my LLM authoring engine (we could consolidate, but he's got some context I don't have and it would take more than zero engineering effort to ship it to me when PR messages through GitHub are a good-enough channel).
If not for the LLM, the tool wouldn't exist at all because we can't justify dedicating much of any engineering time to building it. But LLMs drive the engineering cost very close to zero, enabling the authorship of code that would never find engineering cycles otherwise.
> It would be too annoying for a human to ever write code to standards this high,
These are standards of a normal university operating systems course (assuming a university worth its salt anyway). Ridiculous to present it as some kind of feat that was "impossible" or even that rare.
Sure, a very smart and patient human could write this by hand in a long enough time horizon and unlimited budget. I should have said impossible in any realistic amount of time any responsible sponsor or employer would pay for.
I'm sorry, this is simply not true.
this https://codeberg.org/lrvick/nit/src/branch/main/src/system/r...
is textbook definition of boilerplate. you need to be patient to cross-reference syscall tables but certainly not smart.
Again, students learning about operating systems do similar things as a normal part of their education process.
I'm not saying LLMs wouldn't help with this (in fact, this is the type of thing that becomes pretty much a no-op with them) but the notion that this is "impossible by any realistic standards" is risible, and if you have actually contributed to the kernel like you say, you should know better.
Rather than patiently referencing syscall tables by hand which is error prone and hard to review as a human, the LLM wrote tests to actually compare each of these to the kernel syscall tables to make my life a lot easier and avoid regressions or mistakes. Complex tests to write, that saves me a lot of time as a security reviewer. Can change any value and watch tests fail.
https://codeberg.org/lrvick/nit/src/branch/main/tests/kernel...
That is the point. Getting to results that satisfy security and functionality requirements in much less time.
Also, I was able to generate a bare minimal and hardened kernel config by using the LLM to write a tool to trace all kernel calls. Something that I would have normally been forced to punt on that LLMs made easy to justify.
LLMs are just as Linus Torvalds likes to say "Auto complete on steroids".
The parsing code isn't even correct, though. I'm sure it works for the current input source code, but it's a clear sign of an LLM developing by iteration, rather than actually understanding the problem and coming up with a correct solution.
How often does "this table of constants was transcribed incorrectly" even come up as a bug class? Is it worth writing a buggy C parser for a failure mode that doesn't happen? Do you expect that Linux is going to change their constant definitions out from under you?
Correct depends on what problem one is trying to solve though the parsing can certainly be cleaned up before release. It is a working WIP.
> Do you expect that Linux is going to change their constant definitions out from under you
Unlikely but I have been surprised before. Hardcoding to pretty much any modern kernel source version forever for this narrow use case is probably fine.
The goal is about helping me and a reviewer quickly form confidence none of the magic numbers are mistaken or malicious in an automated way against the source of truth.
I guess the point you're trying to make is that apps developed by LLMs don't need to be all that bad, but the problem here is that you can't know who does their due diligence with auditing their own code and who doesn't, and you can't expect potential users to do it either. Especially not when similar apps get published at increasingly faster rates.
LLMs also helps inexperienced engineers (or people who do not have any own software engineering skills themselves) to write horrible code in less time.
Of course you also can't trust everything human developers publish either, but the issue is amplified by LLMs.
Cool, but I fail to see how it is relevant in the context of the article? You clearly have the knowledge, expertise and discipline to incorporate LLM in a workflow that, taking your word for it, delivers a very good result.
That makes you a) more unique than you realize b) not all that relevant in the context of the article.
a) Because a lot of people tend to lean towards use that absolutely leads to atrophying of skills and knowledge. b) well the article does explain the criteria it used fairly well and your project would not show up there. Well, also because your project isn't an android app.
An appliance Linux distribution without dependencies is way more complex than a typical android app and there is little prior art to train on.
Android apps on the other hand, LLMs have enough training data to rapidly generate whatever you can think of with much less time required for an experienced engineer to refine it into a quality result.
I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.
It is frankly amazing we can point an LLM at a proprietary ad-ridden app and get to an ad-free open source and privacy respecting clone in a weekend now.
> I am mostly pushing back on the notion of dismissing software as low quality just because the author used LLMs.
Its not that hard to imagine that apps made with heavily LLM involvement suffer in quality. The article already goes into it a bit. I get the strong feeling that you are failing to approach this from anything else than your own perspective and how you use LLMs. Which, given the setup you are describing is already far from the norm.
Zooming out a bit further I think we can generally break up LLM usage in roughly two distinct ways of using LLMs. Or maybe more accurately there are two sides of a spectrum with a lot of area in between them:
1. Let LLMs do the majority of the heavy lifting and generate the output. Providing an LLM with some basic info, what you are looking for and let the LLM do most of the work for you. 2. Using LLMs as a tool external to the process where you are still doing most of the work.
The first way of using LLMs using agentic workflows, code harnesses, etc *can* produce good quality. As long as there is still a human in the mix who a) has the prerequisite knowledge to validate what the LLMs have generated b) takes their due diligence at key points in the process to actually make sure input is of high enough quality and validates the output.
You have decades of knowledge and experience you are now applying to rigidly structure how these LLMs work. Which, yes again, I believe gives you personally pretty good results, no doubt about that. But, many people do not have that experience to begin with. And even for those that do, using the first method comes with a risk that boils down to simple psychology, our minds are wired to take the easy approach wherever they can. Which turns the first way of using LLMS from a efficient way of using them to a lazy way of using them.
In my personal experience a lot of people who start using LLMs sort of drift to the lazy approach very easily. Because it is very convenient and easy to slowly hand over more thinking to an LLM. The latter I have seen happen all too often around me. An alarming increase of lazy non critical use of LLM tools by people who should know better. People who might have been a bit slower before but delivered excellent results now have started delivering trash. Code spanning dozens of line trying to solve something that should only take one line. Code that completely ignores and conventions or design paradigms put in place. Code that goes directly against security practices. Suddenly downgraded dependency versions (because the models training data doesn't include the latest version).
As I said, I see this as a spectrum and the more someone leans towards the first use case combined with "lazy usage" the more signs there will be in a repository that this is the case. The amount of commits, the release cadence and various other things. Which, again, the article also makes a case for and is again why your repository is irrelevant to the whole discussion. Why? Because your repository doesn't show these signs.
Fair and nuanced. Nothing I disagree with here. I think I mostly just dislike the default hate and assumptions on everyone that uses LLMs, including often me. Some of us are using these tools thoughtfully.
LLMs help experienced engineers write quality code faster and it helps amateurs write shit code faster. Problem is there are simply way more of the latter. Even so I detest engineering being judged by the tools used, instead of the work itself being judged on its own merits because there are exceptions to every rule. I would like to teach people to use these tools responsibly, instead of sending a message that use of these tools is automatically thoughtless slop.
Like, most people I know that use Vim write much higher quality code on average than the people that use VSCode as tool preferences often reflect experience, but not always! It would still be unfair to write off someone's code sight unseen because they used VSCode as there are always exceptions to the rule.
[flagged]
> This would be the only privileged code in my operating system
What does that mean? Are you building a system without a root user or something?
Correct. It does the bare minimum system calls to boot the system, then exec to an unprivileged service manager on a read only nosuid, nodev filesystem.
I design confidential compute systems.
[flagged]
https://codeberg.org/lrvick/nit
Still WIP but working.
I do not personally know a single human I could have hired who could write low level nostd nolibc noalloc rust like this, and certainly not in only a week even with hundreds of messages from me giving them detailed direction. That person may exist, but a day of their time likely costs more than the GPUs I racked up in my garage to assist with this.
I know no one wants to believe an LLM plus a human could produce more secure code than an LLM or human working alone, but as engineers we should adapt to whatever gets the best results.
Also every line is manually audited by two experienced software engineers before production.
Nearly any C programmer could write this.
In a week for a few dollars of pay with a test suite that comprehensive and on my exact schedule to collaborate with me around the clock? I doubt it, but I would love to meet that person if I am wrong!
This is the fastest I've ever seen goalposts move. Like, this is a completely different claim from "It would be too annoying for a human to ever write code to standards this high".
If you take what I said out of context with zero charity, sure.
> and would have taken me months to write by hand
That implies humans can write it because I am a human and presumably other humans can too. I was making a statement about it not being possible to write it in any justifiable amount of resources.
My company would fail if I spent months on this, but a week to harden init is for sure worth it.
I interpreted that as you saying in a few months you could write the code but not to those standards.
If a single person can do the full job to full standards in a few months, then the whole idea of it being too annoying for a human to ever do falls apart. That's not that expensive. Your company can't spare you, sure, but most companies could handle that price.
And even with the adjustment to being something it's easy to hire someone for, that's still ballparks away from "in a week for a few dollars". Nearly every coding project is impossible for humans by that standard.
> Nearly every coding project is impossible for humans by that standard.
Exactly, which is why this small project, and the other dozen projects that need to be written to the same standards to make the final end result OS, would just simply not happen otherwise.
No small FOSS org can afford to spend person-years holding standards this high, which is why in practice most orgs just cut a ton of corners and pull in tons of dependencies no one will ever review and the attack surface that comes with them.
LLMs allow experienced engineers to get 10x as much done in the same time, and now that this is possible few will be willing to pay engineers to do it at 1x speeds again.
Just like once assemblers became normalized, few orgs would let people write all their assembly by hand anymore except for very small high performance sensitive portions.
Software engineering is not going away. It is just accelerating because we were able to move our attention up a layer again.
> Exactly
Please use very different wording from "impossible" or "can't be done" then. It not being price-competitive is a far weaker claim.
If you read the rest of the same line you are hung up on I literally said I could have done it in a few months, which implies I believe humans can do it, so clearly I was saying it was impossible to do in any practical amount of time or resources.
I already addressed that https://news.ycombinator.com/item?id=49718446
My request for better wording stands. The context was not enough to make things clear.
So it violates codeberg's policy.
I started with a hand coded C version, then a hand coded rust version, and then an LLM refactor to remove all dependencies and add a comprehensive test suite.
Please, report me to Codeberg. It will be amusing.
I personally know a Codeberg admin that works with LLMs as a tool for things like this which are actual engineering and not vibe coding.
You should move it yourself out of respect for the community.
No.
I actually read the terms and my community and I comply with them.
If you think I do not, you are free to report me.
> If your work fits into these cases, it is unlikely that you are affected at all:
> Projects who have an active community that cares about and maintains the software
> Projects with a significant pre-LLM history
Maybe it is tolerated.
[flagged]
The fact this got flagged says all you need to know about the current dev ecosystem.
It got flagged because it is wildly wrong.
LLMs are literally solving math problems humans have struggled with for decades.
It took me a while to get through the cognitive dissonance too, but we are all going to have to do it.
LLMs certainly can interpolate between information found in its training set vastly faster than humans can find similar code on GitHub and stack overflow (or in math papers). It's certainly a tool that can be used when programming.
On the other hand also calculators help solve problems people have struggled with for millennia. It also doesn't mean that the end result is better than by hand. It's actually not, and that's the reason why you cannot replace programmers, because you need them to steer the LLMs for a good outcome.
And even the answer to the question, if LLMs make us more productive as programmers long-term is not really clear
The code is not better than an imaginary human paid to work on this as long as they wanted. But said human and sponsor did not seem to exist.
If not for LLMs this type of hardening would not be possible for me to justify at a startup, and I would have had to sigh and accept the huge attack surface of systemd.
I am a security engineer and there are unlimited things to harden, so LLMs let us harden a lot more in the same very limited time.
You mean plagiarizing math problems humans have tackled for decades?
And brute forcing solutions within well-understood constraints.
Brute forcing faster than a human could and able to vary approaches on the fly saving humans a lot of time. Humans need only set the direction.
Lets brute force cancer. All for it.
That said, to be clear, I would never give OpenAI or Anthropic money. Their irresponsible behavior is separate from the objective capabilities of the tools, which we should seek sovereign versions of.
But they have absolute confidence! They're absolutely right
I can have confidence because I specced the test suite to prove the rust assembly calls matches up with the tables in the linux source code.
If any of that is wrong, then the Linux kernel is wrong the same way.
I am not even close to vibe coding. This is built to my exact spec because I actually understand this area pretty well.
I constructed a Linux distribution on my own before AI and contributed to the kernel by hand going back 20 years ago now.
humans are overly confident too when they are mostly wrong
I'm somewhat surprised about PipePipe. I had a look on the commits of the various components and nothing looks out of place to me. Commits look rather reasonable, comments look useful and don't show obvious LLMisms.
What are the AI smells there?
It would be nice to expand a bit on the reasoning behind the verdicts.
Many of the projects here predate 2022, so they wouldn't be "ai-generated" in that sense.
Seems like the wrong question to ask. I've been programming my whole life but basically stopped writing code by hand in 2026. The LLM writes better code than I do, much better.
Same here. I'm still a better software architect that AI, but there is no question that my AI generated and reviewed code has fewer bugs than code I hand write. It takes some humility to acknowledge that your coding prowess is less of a useful skill than it used to be.
There's an issue where people assumed the syntactic activity of writing code was what mattered. The reality is that this was always a smaller part of the role, as opposed to thinking about observability, serviceability, and test automation. The ability to write software that is properly separated from concerns and when to enact those separations matters.
At the same time, I think we're far too far down the systems path now. We've hit a point where interviewing has become purely systems design "because the AI writes the code".
Not that I'm ever asked, but I inherently believe the act of critical thinking, communication, and expression are the key skills for those who already have the appropriate coding/engineering/cs/etc background. I now only interview for those skills - but through the lens of impossible to solve systems design conversations as opposed to problems. It tells me a lot about how people think.
Writing is thinking
So is architecting, testing, validating, and even occasionally using.
This isn't the first time I've seen this phrase recently, but I'm not sure what the thought is a cliche or what it is intended to convey (don't read my note as negative, I sincerely am unsure what connotation folks are trying to say).
The idea behind "writing is thinking" is that people often overestimate their understanding until pressed to express it in words (or code).
How many times in your career did you sit down to tackle a task thinking you knew exactly how to approach it only to realize during implementation that there were edge cases you hadn't considered, API contracts that were now broken, or that the feature was trying to solve the wrong problem.
Having to be the one at the helm during implementation made you intimately aware of not only the problem at hand, but the current state of the codebase. That's something you can't replace with automation. You can't compress all of that context into your brain in a handful of prompts with Claude.
Remember the words of your math teacher--
"Watching someone else solve the problem doesn't mean you can now solve it too."
Not sure what you mean as system design conversations because while in theory those can be good in practice the ones I have been at had been techbro wankery where the interviewer had a particular answer in mind. Like designing your own memcached clone for example is a terrible task for systems design.
What you're mentioning is 100% what's wrong with the industry. Agreed! To me a systems design conversation is a conversation - not a design goal. The idea is to determine ability and psychology:
1. When you press on someone's design respectfully, do they get defensive. Do they become argumentative.
2. When thoughtfully pointing out a concern, how does the candidate take it?
3. When you suggest a technology that makes no sense to intentionally challenge knowledge, does the candidate recognize why it makes no sense? Are they able to share what the negative of the approach is. If you indicate that you know the question is "senseless" but want their feedback, how do they communicate?
4. When you hard request a change that requires a literal rethink and rewrite do they become argumentative? Do they embrace the change?
5. When discussing testing, how do they think about it? I come down to the nitty gritty and ask about postive vs negative cases, table driven testing, what types of tests matter (for our situation) and why.
6. We discuss timeline tradeoffs, and then have the conversation about the candidate's approach given updates to see how they think.
You'll notice that I am never looking for a solution. I'm seeking communication, description, partnership while having a (relatively) thorough gasp of the subject matter.
Every single time I get a response from a candidate such as "I don't know, I'd have to learn more - or use AI to, or.. what do you think" turns out to be something I LOVE, because it creates a great fabric for the interview.
Programming languages, design languages and architecture are all inventions made to help humans write understandable source. LLMs don’t really need to do any of that. They can store very large trees of understanding and therefore implement any application in raw binary. Why bother with abstractions at all
LLMs for sure need those things. maybe not the same abstractions as humans do but without understabdable code an LLM will just fail to accomplish the task you ask it to do.
It might be less ambitious and more practical to target bytecode.
But you effectively lose the human review component.
There's more python and typescript in the training data than bytecode.
I was thinking about that. I reckon generating massive amounts of synthetic training data for that goal should be possible - you've already got the Python, after all. It's also possible for machine code, but you'd have to target more platforms.
But ultimately, I think human readability outweighs any theoretical advantage you get from removing a step in the compilation process.
Targeting byte code or asm instead of high level would be silly for everyday tasks. You blow up the number of tokens, reduce your effective context, and there's just more places for it to make a mistake, which most likely won't be caught by the assembler (unlike compilers).
The AI machine can write better code. It can also write an interpreter which implements function calls by instantiating a new interpreter + entire standard library per function call. Or it will build a 300kloc cathedral of scaffolding and maintain that forever, never writing actual code. Or it will create a CI system that takes 2 hours to run and constantly fails, and the agent loops there all day, fixing a small bug and waiting 2 hours. (All things I’ve experienced latest frontier models do)
Agentic engineering faces all kinds of new problems that couldn’t exist before, and need experienced engineers to solve them.
With the "intelligence" of code focused and capable llm in the last six months, the main problem I'm seeing now is where some total amateur who has no previous knowledge of coding tries to one shot a project. People who have previous experience and know how to architect things (and when to stop an LLM from doing something wrong that will cause maintenance and scale and extensibility problems in the future) are doing much better building actually useful things.
This one shot thing I just don’t understand. The way I’m using it, it takes weeks of constant prompts because it never does exactly what I ask no matter how well I specify. I just don’t see how it’s possible to one shot anything unless you don’t have strong requirements on the output.
I had pretty good success with a language learning app. Initial prompt below, about an hour to get it working very close to how I imagined, then extended to Japanese, French, and audio generation.
======================================
Hi! I'd like to create an app for interactively learning Chinese using AI. My current idea is:
- The AI generates a Chinese sentence at a specified vocabulary level (e.g. HSK2)
- The user translates the sentence into English, and the AI evaluates the response. If the answer is wrong or is partially correct but could be improved, the AI offers a hint. If correct, the AI confirms and explains any particularly important vocabulary or grammar points that the sentence demonstrates.
- The user should be able to click on an individual character once to see the pinyin, and again to see its definition and any helpful techniques to remember it (radicals, similarity to other characters, visual meaning)
- The app should also be able to go the other way, giving the user an English sentence and having them translate to Chinese.
App details:
- UI is a web app
- The AI should be pluggable. We'll start with a local Ollama install running gemma4, but it should be easily possible to add support for Claude/OpenAI/Gemini or other models (may need to provide an API key).
- Not actually sure if we need a backend. It might be useful to keep track of characters or concepts that the user has difficulty with, or to keep track of what sentences the AI has previously generated so it doesn't become repetitive.
- Build everything in a Docker container (or multiple if needed with docker compose)
I can see this being a one-shot thing because the brief is pretty light; beyond broad strokes, you haven't specified much for it to actually do. Any UI that's also a webapp would satisfy this brief, but that's exactly what I mean; e.g. if you want a specific UI, there's a lot more back-and-forth that's involved. It'll one shot a UI, but it's very rarely the UI you want down to all the interactions and placement of buttons.
Yeah, that's fair. I didn't have an exact UI planned so I gave it flexibility, and it made reasonable choices that only needed a bit of tweaking to be quite usable.
For me the usefulness of a survey like this has nothing to with how effective LLMs are themselves. It's more that when someone's able to produce an app in an afternoon, and submitting the app to F-Droid becomes a checkbox, how confident can you be that they'll continue maintaining the app? Sure if it's open source you can have your own LLM maintain it, but at that point what's the value in having it on F-Droid?
"There are naïve questions, tedious questions, ill-phrased questions, questions put after inadequate self-criticism. But every question is a cry to understand the world. There is no such thing as a dumb question". (Carl Sagan)
Just because you don’t seem to be interested in the answer - then don’t read it? - doesn’t make the question wrong.
Skill issue then
I just asked Astra to bring an old Windows XP game to the browser. It objdump'ed the whole thing, built a fitting Win32-like wrapper that exposes required functionality like DirectDraw, DirectSound, SEH etc., then wrote an x86-32/x87 interpreter in WASM, benchmarked how the game runs, lifted the hotspots of the executable to WASM too and now it is playable!
I mean, I'm proud of my low-level skills too but this is some Fabrice Bellard level sorcery. Very, very few humans are able to do this without AI tools.
But good code isn't just "does it work", it's also
- is it understandable
- is it maintainable
- how much work is adding new features
- is it written in a way that adding new features means rewriting a lot of it
- is it written in a consistent style
- and lots of other things
I use AI to write a lot of my code, but the only time it's clearly "better" than a competent human is for one-off things.
That being said - AI + human is, without any doubt in my mind, better than either one alone.
Absolutely, the Win32-WASM layer it wrote is some of the most evil looking code I have seen in my life. But realistically, why keep it maintainable for humans if you won't find anybody that can work on it without AI anyways?
If we humans are just doing code style checks, file organizing and doc cleanups I feel we have demoted ourselves to code janitors. This is neither fun nor going to last.
Personally I've always strived for minimalism, to find the smallest, fastest, simplest solution possible so I'm pretty jaded now, too...
Code is a human formalism that is only incidentally made executable. The elegance of code represents understanding of the problem to its most minute detail. LLM code being recognizably terrible shows it still doesn't understand what it produces to the full extent, and just as with people, it will inevitably compound to it becoming unable to efficiently work on it. And if the human abdicates that responsibility too, then there is no code, only subtly broken software.
Aye. Some of these targets are far away, others perhaps closer.
Human+AI systems is a good match. Like Human+docs or Human+encyclopedia.
- is it understandable
Yes you can ask the agent anything about it and interrogate it until you understand.
- is it maintainable
Yes it’s easy to ask the ai to add new features or to refactor it entirely.
- how much work is adding new features
Depends, it could just be one prompt, it’s usually many prompts. If the refactor is large it can take weeks. But before AI something g equivalent would take months.
- is it written in a way that adding new features means rewriting a lot of it
Usually no, but that depends on how well the agent is being directed and what the features are. If you come up with a feature that requires a new architecture, ai makes it doable rather than saying “would be nice but we’d also have to implement this whole new architecture and that’s a lot of work”
- is it written in a consistent style
Styles can be applied mechanically with linters and formatters, so as much as any codebase written by multiple people.
I've seen AI be wrong about things often enough to know that none of what you said is particularly true. Rather, most of it holds true most of the time. But not enough.
> Styles can be applied mechanically with linters and formatters, so as much as any codebase written by multiple people.
I'm talking more of a higher level than this - more of coding/design patterns that are common for the team.
> Rather, most of it holds true most of the time. But not enough.
I see it be wrong about things all day every day. And yet, IME it's correct enough for it to be controllable. It doesn't have to hold up all of the time, it just has to respond to corrections when they're issued in a loop so that it converges to a correct solution. And it does, despite the mistakes.
In one of my other posts in this thread I detail some of the the ways it's confounded me, but those issues have caused me to harden validation mechanisms rather than say "this thing makes mistakes so I can't use it to write software".
> I'm talking more of a higher level than this - more of coding/design patterns that are common for the team.
Do you have a concrete example?
What people don't understand that programming is very much an art. You iteratively work on it ripping parts out, rewriting and rewriting and rewriting, while also rewriting and then rewriting every time a new feature, bug fix or scaling changes are needed.
As a bit of an observation on that specific project... By hand as a human you could spend six months of the equivalent of a full time job doing that. Even if you had extensive knowledge in all of its discrete pieces. One of the things coding focused LLM are great at is doing things that have no reasonable prospect of economic necessity to do (no for profit company is going to pay you a FTE salary for six months to do that task, because there's no possible revenue in it). But the LLM can be pointed at it and get it done in a day or two with some periodic architecture and decision making by the human, for probably under $50.
It took two days and 50% of my Codex Plus week limit, so around 3$. Finally I can play the game on multiplayer again next evening!
What is the game?
https://www.gog.com/en/game/the_settlers_4_gold_edition
It did not work properly on Wine nor Windows 10, that was the entire reason for trying it out.
fwiw, PCGamingWiki[1] has a link to a patch[2] that someone wrote to fix the compatibility issues. If you're playing from the CD edition, you might also need SafeDiscShim.[3]
[1]: https://www.pcgamingwiki.com/wiki/The_Settlers_IV
[2]: https://github.com/elishacloud/dxwrapper/wiki/The-Settlers-I...
[3]: https://github.com/RibShark/SafeDiscShim
If there are very few humans that can do this is because the market for such a task is very small and thus there is little incentive to learn how to do it or produce tools that can do it.
Only people disliking AI for coding are the gatekeepers who think they are magicians and the plebs shouldn't be able to code like them, unless they become gud.
This is a false generalization. Lots of AI dislikers do so for a wide variety of reasons. I dislike it and don't care how other people use it.
[dead]
[flagged]
If you truly think LLM are not useful tools for programming, you haven't tried the right tools.
That is not the same topic. LLMs are useful tools, and that is despite them producing fucking awful code.
I would have agreed with you 6 months ago but things have changed rapidly.
People say this every 6 months. I've stopped even paying attention to it, because (A) the code quality remains below the floor, and (B) the people saying it continue to ignore all the other issues with LLM code generation.
Up until the last couple of months, I have treated LLMs as a supercharged stackoverflow. I would ask it questions on how to do something in a general sense, and then adapt the answer to my use case.
Now, my entire programming flow does not even include an editor. The tools I use are: pi.dev to write and implement openspec specifications, herdr to manage many pi instances, and ollama to run qwen 3.8 27b on my single 7900 XTX.
Writing good specifications is the key detail here. I will often iterate on a spec for hours until I am happy with it all of the details. Once I am happy with the spec, I can be quite confident that when I tell pi to apply the spec, the changes that I want will be done, and done how I want them, when I come back to check when it reports itself as done.
The landscale is fundamentally different from what it was. Feel free to ignore it, but you can absolutely generate high quality code if you know what you're doing.
>ollama to run qwen 3.8 27b
Installed this recently to try it out.
>pi.dev to write and implement openspec specifications, herdr to manage many pi instances
Thanks for mentioning the tools you're using successfully. It seems like most people using LLMs are keen to keep their cards close to their chest.
No problem. I think it's less of people withholding information to have an advantage, and more people still not having settled on a workflow they like. Herdr is the most recent addition in my workflow as of only a few days ago, but it directly solves problems I have been having (juggling tons of terminals, even with my tiling wm has been a little unwieldy). The rest I've pretty much settled into for a while now.
The other tool I wanted to throw out there is voxtype (plus wtype). I've been looking for a good, global, local dictation solution for wayland for a while now, and finally landed on this one. It's great for rambling details that pi+qwen can then convert into concrete openspec specifications.
N=1 and might be a raw skill issue on my end.
But I all but stopped writing code 13 months ago. At the beginning the code was often bad.
In the last 6 months alone I had received more praise from my customers for excellent work than ever before.
Not sure what I can say but the LLMs simply do not write good code without tons of handholding. As a C developer most LLMed patches I have seen the last couple of months have been awful and the few good ones I know from the author themselves that they did a ton of iteration and/or manual cleanup. Maybe they are less bad at writing other languages.
At least what I have seen in Ruby and Typescript, they are excellent at doing what you asked for. But if what you asked for is stupid they will happily make it happen.
They don’t make normal mistakes like typos and they aren’t lazy so things like tests and checking error cases is usually done.
I tried a lot of tools. Claude code, deepseek with kilocode and OMP, codex... I still use claude quite a bit. But frankly, all of them produce some absolutely godawful code. Review load went way up with AI, and it's not just the volume that caused it, but also the quality. It's extremely verbose, hard to read, often repeats code instead of factoring it into reusable components. And yes, sometimes it's also buggy. Except now, you have to debug a problem that's in code you didn't write yourself, and is awful to read.
LLM is incredibly valuable for debugging complex problems, codebase exploration, and planning large changes. But the writing code part itself, I find, LLMs are just not very good at it yet.
I don't have to debug anything.
Vaguely telling the agent what the issue is and what behavior I expect solves the issue with a fraction of the effort.
Some claim that the tech debt only keeps increasing and that the result will be unmaintainable. This is not my experience, and I don't think it is theirs either. These claims are often entirely speculative.
I, and I think most experienced developers, can recognize the type of code that incurs a maintenance cost down the line; that will make adding new code take longer. And AI writes such code "relatively" frequently. I love having the AI to write code, but I find it extremely important to review it - to make sure that it's correct, understandable, and not going to be a problem later.
I find it unnecessary for most non-critical code, such as client applications.
I doubt that any supposed future extra effort for the AI to add new code is remotely comparable to the upfront effort of you reviewing the code manually.
I know that this is the case today for native mobile apps, and I speak from hundreds of hours of experience over the last four months on such a project where I stopped reviewing the code.
We are already here today, and this balance is only going to further shift to the point where it is obvious that the hands-on approach is no longer competitive.
Everything about what you're said strikes me as sounding like "I don't bother wearing a seatbelt, because my experience is that I don't get in accidents" .. and also "I don't write automated tests, because I already hand tested my code and it works".
And neither one of those statements is very convincing to me.
And what you said strikes me as speculation not based on actual experience in using AI in this way, with a healthy dose of condescension added.
Anyway, I think we shared our viewpoints, and neither of us is going to change their mind until either my project fails spectacularly, or you change your approach in the future to use AI more autonomously.
I've had bugs the agents can't fix or figure out. Sometimes those involve third-party, proprietary, broken code (read: Windows APIs). Sometimes they just involve complex deployment situation on the client code (I work on desktop apps) where the agent can't figure out what's wrong/makes wrong assumptions/goes nowhere. Sometimes the agent is just very dumb and tunnels vision on the wrong fix.
FWIW, I've also had bugs the agent fixed that I probably never would've figured out without LLMs - LLMs are definitely useful! But I need to keep understanding how the code works so I can take over the reigns when the LLM fails.
I’ve had some luck prompting them to be concise, both in writing and in code, and with code doing an approach where they get it working, write tons of tests, and then refactor for conciseness and readability. All the tests prevent regressions doing this.
Without such prompting and a conciseness and clarity pass you get a slop grenade.
They overall work better with tests, and Rust is a great language for them. Overall they do better with lots of walls and alarms that go off if they mess up. I don’t need nearly as much of this, can mentally simulate it, which is a good “are we superintelligence yet” reality check. Still not even as good as my wet meat brain. But impressive given what was possible even two years ago!
The result is still not as clean as a good programmer but it’s better than the slop grenade you get first pass.
I'm pretty sure you used chat gpt when it came out and literally stopped looking then.
GPT 5.6 sol and Astra can now one shot incredible stuff.
I spent 22 years as an engineer split between MS and Apple. SOTA LLMs can write code just as good as most human engineers. I expect to see the "LLMs are just next token predictors!" crap on Reddit... not HN.
LLMs produce pretty crappy code but they are very useful tools for protyping, code search and finding bugs. Maybe LLMs in the future will be able to write good code but they are very far from that right now.
Perhaps it would be useful if both of you could provide examples of supposedly good and bad code – the latter being the result of a genuine effort to produce good code with state of the art models. Just asserting that LLM code is good or bad ends in a yes - no - yes - no back and forth circle immediately.
I just used an LLM (along with my decades of operating system development experience) to create a macOS tool [0] that lets me see through windows, instead of having to continually command+tab between windows.
The solution required reverse engineering and internals knowledge that most human engineers don't even have.
The question is no longer "Can an LLM write code?". It can. The problem is that certain humans refuse to put in the effort required to properly utilize these tools.
[0] https://imgur.com/a/2CUEjmA
LLMs have been good at knowing what's in the manual from v1.0. Super good at that. Pretty good translators. Pretty good at doing things that have been done a million times before, like your CRUD app. Super mediocre at everything else.
LLMs as things that know what's in the manual are AAA+. Extremely helpful. Very good at making a rough draft of something filled with a lot of stupid mistakes and no new abstractions. That's what your transparent window thing is. Something that you could never ship, is probably too big and doing senseless things for no intelligible reason, and definitely has bizarre bugs.
What in the world are you talking about? I was literally an senior engineer on the Windows Kernel team, the Visual Studio team, and the Xcode team at Apple.
This application, named Seymore, is being evaluated for purchase by several tech companies. (It helps having good industry contacts)
There was a ton of interesting engineering required to make this work at 60 fps+ without resorting to hacks or using private APIs. Most macOS engineers wouldn't even know where to start.
I've shipped code that is used by billions of people and all you just did was spew a bunch of bullshit. As someone who has built their own LLM from scratch, I have an extremely good idea of what they can and can't do.
If you don't know how to use these tools, you'll end up with crap. If you DO know how to use them, they are incredibly useful.
I don't agree with using your credentials to show your code quality, but I don't doubt you have better standards than most developers. That said, stop trying to change their minds. Antirez was a good at programming until he started coding using AI only. The same will be said about Carmack and Linus.
What they are saying is increasingly difficult to defend, but they will do it anyways. I see the same arguments at my job, and I just gave up arguing against
I mention my background because it is relevant context: I spent nearly 30 years building software used by billions of people. If you use Windows or macOS, you have likely used code I helped ship. I’m not going to apologize for that experience or pretend it does not inform my judgment.
Some engineering problems (such as designing a performant thread-quantum algorithm) require depth accumulated over years of working on real systems at scale. That is not elitism; it is simply how specialized expertise works. Experience is unevenly distributed, and that matters when evaluating technical claims.
When I say I trust LLM generated code, I mean that in a qualified, engineering sense. I do not treat an LLM as a slot machine: enter a prompt, paste the output, and hope. I use a deliberate workflow for decomposition, prompting, review, testing, validation, and integration. Developing that workflow took substantial time and experimentation.
The useful question is not “Can an LLM write code without oversight?” It obviously cannot, at least not reliably for nontrivial work. The question is whether an experienced engineer can build a process that makes LLM output trustworthy enough for particular classes of work. In my experience, the answer is yes. But the process, judgment, and willingness to do the work are the hard parts.
We can't judge code quality without having the code.
This kind of shaming is getting tired. At the end of the day, the people claiming their code quality is better without ai, while everyone else has low standards, aren’t providing any evidence of their supposed superiority.
I think the burden of proof is on the new technology. It's been almost a year since the supposed death of manual coding, depending on how you count, but I haven't seen the efficiency benefits of AI trickle down to the programs I'm an end-user of. I _have_ seen the bugs, however (rsync 3.4.3 for example.)
Depends what you mean by end-user. Power users of AI aren't using these things to build applications for users, they're using them to do all the things they couldn't do as mere mortal programmers. Like the other poster detailing how they got a game running in web assembly. That's not for end-users, and even if it was they wouldn't be able to look at that and say "Wow, this is an example of AI benefitting me as an end-user" they'd just say "Wow cool, a game".
What is fkn?
It's short for "fucking".
That’s fn lazy.
TIL what `fn()` actually means.
Every codebase that is being actively worked on (closed/open source) will contain code that's AI generated. With the rising abilities of agents, expectations are sky rocketing in terms of productivity.
If you're as productive as an engineer in 2016, you're not at the level that's expected. A 7 day workflow back then should take you maybe a day or less to work on today.
I've worked with "engineers" that make one commit in 2 months and it's a spelling correction. I'm pretty sure that being 7 times faster than that is still quite slow compared to me :) I hear a lot of breathless enthusiasm, but this article is possibly the first time I'm seeing the question answered "If AI is so great, where are all the applications?"
FDroid can be very strange…
””” F-Droid is not hosted in just any data center where commodity hardware is managed by some unknown staff. We worked out a special arrangement so that this server is physically held by a long time contributor with a proven track record of securely hosting services. We can control it remotely, we know exactly where it is, and we know who has access. ”””
What do you find strange about trying to protect against tampering and theft?
I find it strange how little people seem to care these days and just widely share their users and company data across clouds. Plenty of supply chain attacks to learn from.
If they work, does it matter?
Separate from building your own code, ,of course you may have your own standards to apply.
But for apps, well, I never had a chance to see how good or bad the code was before AI was about, so why should I care now, so long as what I paid for does what it says it does (and nothing nefarious..)
Some programmers have ethical concerns around the use of LLMs. It's like saying "my clothes still work, why should it matter if child labour made them?"
I don't know wnything of the ethics of any real meatbag developers that are working on the code or app I install on my phone either. I fail to see how, for pre-packaged code specifically, it being AI or not is a problem; ~ rather, surely all the concerns we have about AI code (hopefully properly developer reviewed.. - which I suspect is where the real problem lies) apply to developer written code also, when it comes to pre-packaged apps.
This seems tenuous. The LLM is not being exploited.
> If they work, does it matter?
The blog post provides something akin to answer to this question:
You see, the main allure of LLMs is that they allow the developer to be more lazy. That’s kind of the whole point! You just prompt, sit back and relax. So it should not surprise you to hear that this attitude is then reflected in everything the vibe-coder touches
As I understand it, one of concerns is that with the lowered barriers there comes a flood of low quality software, vibe coded by very lazy and not very talented people.
This might be actually more of a human problem, but it's a problem nevertheless.
I had no visibility of developer attentiveness or lack thereof, not skill or code quality before AI was around, for any apps I downloaded to my phone.
I fail to see why worrying about AI code quality is any different to worrying about developer code quality when it comes to pre packaged apps.
With code I am writing, some AI generated, my work load has not really decreased, nor have I gotten lazy. My work has changed to a degree, and now involves reviewing and guiding and double checking AI code where I did not have to before, but I am certainly still working just as hard, and accomplishing more with AI's help in spite of the change in workload it brings.
delivering bad AI code because you got lazy is not the AI fault, it's the developers fault.
You can't call people lazy because they use LLMs, just like you can't call people lazy because they travel by train/plane/cars instead of their own feet.
> You can't call people lazy because they use LLMs
I haven't done that at all.
> If they work, does it matter?
If you're using an LLM to write your code, odds are very high it does not work.
Who/whatever does the layout and organisation of app categories is a blithering idiot and finding apps is best done with an external search as the internal one hides apps even when searched for directly by name. And the fdroid app is relentless systems deperformance burden that often just failed, and updating manualy is simpler as a chore done after any android update. Love a lot of the apps, and the concept of fdroid, but the fdroid UI is not good at all.
It's an emotional problem. I love writing code to solve intricate problems. But knowing that a faster, and maybe better LLM solution is just a prompt away? Somehow that takes the joy out of it. Why spend hours, when you can get an equivalent result in minutes?
I will be curious to see how I feel about AdventOfCode this year...
Is the goal solving a problem or spending time over it?
Because then why do you ride a vehicle when you could walk?
Why do you use fire when a well-positioned mirror with sun could do?
Why a piezo ignition or lighter when a stick and lots of friction would do as well?
Virtually nobody is a professional walker or firestarter, so those are different.
And to the extent they do exist (athletes and survivalists) they might agree there is no "point" except the joy they derive from doing it themselves.
The problem is that formerly there was more alignment between the joy of solving problems with a human's mind and the business need to have problems solved.
Think of that the next time you take the train.
Even before AI, I just looked at file size to determine whether an app was worth installing. There used to be tool to search the Google Play Store and sort by size. If it's a basic utility and more than a few MB, it's probably riddled with bloated libraries and ads.
What stops a bad actor from buying a bunch of these apps on fdroid adding malware to them and then having fdroid handle the distribution for you? I people did something similar with a bunch of plugins in the wordpress plugin archive.
F-droid doesn't simply distribute build apps. It requires the source to be open and will build the apps itself. This does not guarantee there will be no bad actors trying to slip in malicious code. I do believe they also do initial audits before an app is allowed in their repos. It also often takes a while for an app update to show up in F-droid, I am not sure if that is due to auditing updates or something else though.
More here:
- https://f-droid.org/en/docs/Inclusion_Policy/
- https://f-droid.org/en/docs/Security_Model/
how did critics become suddenly concerned with virtue and beauty with AI? Wouldn't it be better to judge these apps on their utility?
The authors are sharing their creativity, and spending time & money to publish apps with a free license.
I have disdain for how entitled open source consumers are. Before AI, demanding free accounts, support , resources, traffic, cpu -- after AI demanding bespoke hand-written code be given out for free.
> The authors are sharing their creativity, and spending time
Well no, they are exactly not doing that but pretending that they are.
It takes time, money , a creative idea, development time, testing time. Don’t be a snob.
The don’t tread on me person is fascinating. I wonder if they wrote the software from their phone using github codespaces in browser?
> Text just doesn’t carry enough meta information for any kind of assessments to be even close to accurate.
Well, that is true, but I have seen how one japanese developer, who has had low english language skills, suddenly writes epic text. So it is clear that he is using AI when interacting with other people. This is a problem because a lot of it is just AI slop fake interacting. I don't want to interact through any AI filter; it means the other human being is not interested in communicating with me, so why would I want to communicate with an AI slop controlled human? It makes no sense.
As for software: IMO documentation is very important. Many projects lack good documentation. This is valid for both AI slop created projects and real humans created projects. There are too many software developers who hate writing documentation. I don't want to use such software anymore.
Unfortunately AI slop documentation often sucks too. They just spam you down with words that mean nothing. And are very verbose. This is also totally useless.
It seems as if software designers indeed fail hard in the last years. Quality standards used to be higher in, say, 2005 to 2010, compared to now and the last five years.
> Their mere existence makes educating yourself and going on fun side projects much less rewarding.
It's not just AI though. Look at Google search. Use it. It is totally useless now. Google crippled it deliberately some years ago. Now you'd think alternatives are better, but they also suck. DuckDuckGo? Qwant? They, oddly enough, manage to be even worse crap than Google search, which is amazing. Crapification has become the default now.
When your "app store" is just a chatbot role-playing being an app store.
This reminds me of another time... Let's travel back to 1980 and interview a local grey beard:
Everything these days is shell scripts! They are even selling them like they have the same value as a C program! csh will never be real C. The kids have no idea what a stack is or how to optimize system calls. The performance is awful and they barely work! The way scripts spawn processes can bring a multi-user terminal system to its knees!
I mean, sure, I write some scripts now and then, but the real logic always goes in C. And just the other day my boss gave me a shell script he coded over the weekend and said putting it in production should be easy!
Over the weekend I was checking out BSD and I couldn't believe the number of scripts I found. I fear for the future of my career and computer science in general. Our field might die out before it can even get off the ground.
[flagged]
[flagged]
[dead]
[dead]
[flagged]
Please stop labelling a project as slop just because it has been developed using AI. Coding agent are now replacing the IDE and code is now mostly written by the agents.
Please stop telling people what to do. Also, the discussion of the merits of LLM code writing is far from over. Author of TFA actually provided an interesting data point, you are just rehashing an often heard opinion.
Why are you so aggressive? I am not rehashing opinions, I'm writing my opinion. Also, I'm not even saying that the author did a bad article. So your comment is a bit out of line.
It's not about who wrote the code, rather who made decisions.
So we are calling the developers as sloppy now just because they use AI? It is entirely possible to use AI and still produce good code - the effort required changes, but so long as it is done by a diligent developer capable of asessing and correcting AI code, it should be fine.
That's my point, diligent use of AI is indistinguishable. And because of bad rep we will see any bad code called out "AI slop".
> Coding agent are now replacing the IDE and code is now mostly written by the agents.
If you're doing that, you are producing slop. So it should be called out as slop.
I did not say I don't read any produced code; I said I don't write it manually. What I wanted to demystify is that you can generate everything with AI and still put a lot of work into design choices, good code structure, and so on, without producing any slop.
How much of iOS is vibe coded?
Fitbook and Flexify I hand slopped until recently. Not my fault vibes win so hard maybe cry about it.