Either they're using GenAI or the entire team collectively lost their minds and started getting a huge number of colossally bad ideas about fundamental primitives of Windows that hadn't changed for decades. Backwards compatibility used to be the major concern and now it feels like they didn't even know what would break ahead of time. If that doesn't feel like GenAI then I don't know what does
Believe it or not, I find it more plausible that the entire team collectively lost their minds — or more specifically, the leadership. There's a long and sordid history of such things that goes back well before GenAI.
I can sort of get how leadership has been losing its mind with all the ridiculous product launches and renames and force-installed apps and browser extension-installing malware, but that doesn't explain the countless instances of hardware bricks, critical errors like failing to recognize the C: drive, and other really weird and suspicious things that I can't imagine would've been driven by leadership. Maybe leadership is demanding everyone be super reckless? But why would anyone with experience even touch those areas of the operating system enough to break them that badly?? The mistakes they're making really do not seem like mistakes that would be made by even the most rushed possible senior engineers. Maybe they're letting completely inexperienced people touch super low levels and that's the problem? Or completely inexperienced machines...
I suspect they have used rounds of salary-based cuts to boost their PnL in the past, like some other large companies I've worked at, and that only bites you down the road because each time they do it they'll ask, "who do we have to keep?", but you're still losing experienced people and eventually you will get mid-level or junior engineers working on core code.
I don't remember where, but I once read that all the developers that knew and understood the inner workings of core Windows components have left Microsoft many years ago, and that this is part of the reason that they introduced a brand new Settings menu and haven't changed Control Panel since Windows 7. I don't know how reliable that report is so take it with a grain of salt, but it does make a lot of sense considering what's been happening to Windows over the past 10 years.
Note that he said written by, not assisted; and also that there's been some major QA issues with win11 the last year, enough for Microsoft to have made a public apology/commitment to improve...
So, no definitive evidence, but the rest of the breadcrumbs provide enough to say that yes it does appear to have suffered from it.
Given the Debian policy seems more geared towards aided/assisted an existing dev than replacing them and shipping because the code works on the golden path on a devs monster pc ... Well I'd still keep an eye on it but trust OSS OS engineers to have some competence at knowing if this works and adjusting the policy later if it proved to be wrong.
Apologies for not replying to you right away. I intended to follow up but HN wouldn't let me because my account is too new. No, it wasn't a random snipe. I used Windows extensively from 95-Vista and Win 10 for work. In my person user experience W11 is bafflingly bad, and the MS team are making design choices that honestly make me feel like Windows ME was doing more right in that area.
Now the argument that genAI is helping them find and fix bugs faster has a lot of merit because it can be pretty darn good at that. But for lack of a better phrase, 'The Windows 11 Experience' feels, as other users pointed out too, either vibe coded or like the dev teams went insane. I live and die by Debian in my servers and I really hope the same kind of thing doesn't happen to them.
the entire industry is experiencing this as model capacity increases. How does "all projects get critical security fixes now" relate to "crap apps and loopy services by literally millions of lines of slop code" ?
Those are 2 different questions. They wouldn't even be the same people involved.
Your appsec engineers will be the ones bug hunting with Mythos or whatever. Your regular engineers will be the ones implementing features. If the feature is a bad design and functions badly as a result, that is entirely orthogonal to whether it contains coding errors or bugs.
Also, there are bugs on the integration side that won't be caught running Mythos against source code, because it's not a source code issue. Even using Mythos for DAST is going to be very limited compared to how actual users will move through something as complex as a 'mature' OS like Windows.
I don't know if they truly believe that persons using CC are racist (like they examined the thing logically from bottom to top and came back with that conclusion) or if it's the new Goodwin --pulling the emergency brakes and damn the consequences.
It's as though people want to find the most dubious of non-existent connections and use that as leverage to besmirch something they don't like.
There are many things one can do where a person has no awareness of the tenuous connection but where you can have someone go back and then ex-post make that connection and declare that thing or person racist. It's a tactic.
Like one _could_ make the argument that factory automation in China is racist because without automation they would have to import labor from (some non-Chinese population). However, the Chinese never began automation with the intention of being racist.
Some may express societal challenges in ways that inappropriately and wrongly infer intentionality. We can acknowledge their point while strongly disagreeing with their characterization.
There are significant societal impacts of this AI buildout. Some are concerned externalities weigh more heavily on the poor and marginalized. I think state wide data center holds are part of this civil discourse.
I'd prefer we have more conservative pollution standards along with a reasonable tax on AI use that helps mitigate externalities. That's hard. Reasonable people can have fierce disagreements on what market interventions are indicated, and how extensive they should be.
no, you don't have to make up some non-idiotic argument that's kinda vaguely like the dumb one and substitute it in there. it's not necessary! nobody's making you do it and there's no benefit to anybody from doing it!
It used to be the case that you would see someone posting under an avatar like that and you would dismiss their argument right away without even reading it.
What's interesting is that they are trying to make a larger political point, but after boiling away all the nuance into such an aggressive and misguided statement, it makes me not want to engage at all.
Is there a term for this? Ensnarkification? I see it on X and bsky all the time.
It would be in foreign interest, yes. But all of this is no different from 50 years of the environmentalist movement. The snail darter was an invented species decades ago. So if it’s propaganda, it’s not invented so much as amplifying what we invented here.
Debian is open source, there is no incentive to be "responsible for it", oh poor me, someone got a bug. If it's paid for through a job your argument is sound.
"Responsible for it" just means nobody has to tolerate shitty patches even if the reason they're shitty is because you neglected to pay attention to them. And if you blatantly fail to understand your own code or engage with reviewers, nobody has to trust that your LLM knew any better.
Well said. No one should trust an llm without verification/validation. They're just not good enough to do that and they have no sense of responsibility or ability to take it themselves. LLMs are empty.
You can make the exact same argument with code written by humans. And if you were right we should see shitty bad code in open source projects like Linux, Postgres, etc. We don’t.
Are there examples of anyone discussing this and reaching other conclusions?
We've come to the same conclusion in our organization and while it felt like it needed to be discussed and stated, I've never heard of anyone coming to a different conclusion.
[EDIT: I was referring specifically to the idea that you have to stand by the code that you write. Is anyone deciding on a policy that says "the AI did it" is a valid excuse for breaking code?]
On the opposite side or the noteable spectrum, look up "Steve Yegge wants you to stop looking at your code." He said it in a video interview, though plenty of summaries online of exact wording and ideas. Though it's being argued that you could still be responsible for it without looking at it?
Extremes on both sides. I'd wager were moving in Yegge's direction though, like it or not.
> Though it's being argued that you could still be responsible for it without looking at it?
If you have a much test coverage as SQLite, I'd be tempted to trust it, and I think that's where we are headed. Someone still needs to define these guardrails though, so IMO the developers job is just mutating into something else, but is still necessary. Long term, who knows.
For me, it’s not a question of whether I like it, nor where we might move in the future, but purely what is proven currently. In my experience, as in my evals, any model, including notably Fable 5 and GPT-5.6 Sol can and indeed do produce code that does not consider many edge cases, can be hard to maintain (especially Sol though it’s output has become markedly better with recent changes to Codex) and sometimes introduce bugs with visibly apparent issues. Existing test coverage doesn’t necessarily prevent such issues when changes or additions are made. The idea that models tend to gravitate towards the house style without major CI based restrictions also has not born fruit in my book. More, I have found even the frontier models amazing at utterly deviating from established standards and tests, what lint, tc and co don’t catch the model will take to introduce code that feels and reads like it does not fits with the rest.
Models also still can have major task adherence issues, so even a perfectly well scoped, well considered prompt that covers all situations and coverage can, in many scenarios lead to output users may not expect or notice without reading code. Seen it a lot, just lost some blood and tears to a very straight front end implementation task that I ended up applying manually cause both Sol and Fable struggle to copy a few dozen HTML/JS/CSS snippets properly into a slightly obscure codebase, despite the reference being fully featured and even using the same token scheme, etc…
We also see such issues in what labs deliver in their own software products. We are not at the stage where a human shouldn’t sign off on code that they have tested and understood. A hypothetical future, I don’t really care for, we’d notice when labs stop shipping easily apparent bugs, though even then, I’d still feel there is a while in between that and not needing to assess the output anymore.
There is, in my mind, no need for this “narrative shifting”, overtone window (don’t get me started on the idea of applying that to what should be a purely technical discussion), convince the unbelievers nonesense that some spend their time on. If models could provide code that didn’t necessitate review, there’d be no one needing to argue that case. If and when they can, we’ll know it, but not because of those espousing this currently.
Sol and Fable are not doers, they are thinkers. Using them to "copy a few dozen HTML/JS/CSS snippets properly into a slightly obscure codebase, despite the reference being fully featured" is one of the most ineffective possible usage of those model. What you described is a job for luna.
Also I suspect you overprompt, with GPT-5.6 (sol, terra and luna), a lot's of what's used to be mandatory in the AGENT.md is redondant at best and frequantly actively harmful.
I also tried Luna (is my first line for such task in general because of the speed and efficiency, but not because Fable or Sol can’t be “doers”, in my evals both are superior in well scoped task adherence and implementation vs Luna and the like, have yet to find a task Luna can that Sol or Fable can’t) along with Opus 5 (cause the Max sub gives a lot of that I can freely use after Fable runs out for the week so I wasted three runs on that) and Ox Alpha/GLM-5.3 Flash (as that was free at the time). Sol (on High) and Fable (on Medium) were acts of 12h desperation, before I did it manually, after the three other models failed, first with a very simple prompt, failure, revert commits, then a very specific implementation plan with clearly scoped verification, failure, thus manual in 45 minutes. It was a major port of a new settings UX for a Firefox fork, all test baked, all with 1:1 replacement targets in the reference and the original. It was merely massive context wise and only 5.4 has ever behaved well across compactions in a manner that I could validate in evals. No model before or since gave me confidence in this regard and I’ll retroactively test with 5.4, somehow forgot to try that one.
I do not have an AGENTS.md in any of my repos at all, stopped using them around 5.2. I was a bit ahead of the curve with that, my evals very early showcased how limiting those tend to be, same why I never used MCP, were useless context bloat.
Will maybe make an edit explaining a bit further what the task was once I get to my computer.
I have a settings panel implemented in HTML/CSS/JS for a Firefox fork that "could/should have been a desktop environment". Bit of an odd project really, mainly out of a very specific conviction concerning modern applications, the way LLMs and task specific models are currently not leveraged well by any browser, my own tendency to have 400+ tabs open at a time across multiple projects, my opinion that it is the perfect place to finally apply a lot of UX opinions I have held for a while and push in a very distinct direction along with core critiques I have concerning PKM applications I haven't seen addressed despite trying every PKM application under the sun. Neither here, nor there.
So this "thing" is mainly a Firefox fork and most UI is basic HTML/CSS/JS (as is the case in upstream). Development is patch baked, CSS tokens must follow a defined and CI enforced standard, etc. LLMs can be very helpful in development, I got a small CLI tool for patch, token management and basic quality gates, which I started working on a few months ago to keep the most atrocious LLM output at bay. Has lead to the revieability of output improving meaningfully over markdown monstrosities, though OpenAI models still manage to sneak hard to parse output past it. This CLI tool along with some task specific scripts also ensures reuse of proven upstream infra like Places (Good lord dear Firefox developers, is Places nice to rely on), consistent regression testing (especially in memory constraint scenarios), etc. Basically, I can and do regularly make additions with LLM assistance, I review it, I discard and restart or improve upon it (rarely accept scoped changes wholesale. This to say, I got some experience in the use of models for coding assistance and I (thanks to the amazing docs and a lot of considerations for the architecture I want) do know what I want, how I want it and how to get there. Also got private LLM evals that often uncover which labs tend to perform suspiciously well in public benchmarks vs private ones and what models still struggle with along with why, so yeah, certainly can always improve but I got, I'd argue, enough of an idea to where my critique of LLM coding limitations has legs.
Which brings us to what I was trying to implement and how I went about it: Settings works. Fully featured (including a few cross-site-tracking specific clarifications that came from a HN interaction a few days ago), tab specific previews for what changes affect regarding themeing, well tested (manual and static), integrated to leverage what FF provides where possible.
It does (or rather did) look functional/God awful though. To the point where I was uncertain that certain previews could be easily parsed by new users. I thus opened Adobe XD, did some early mockup work, tried a few core concepts, settled upon two, then (using Claude Fable 5 low) created a plain export of the existing settings code from our furnace components and patch baked edits into regular HTML/JS/CSS files. I manually verified, this export worked, the tokens were in the correct format, the code reflected what Hominis applied (including what was required for stand-alone of course) and externally called features upon interaction did provide log output linking to the pre-existing functions that meant reimplementation based upon this should be easy.
I then took that to Claude Design using Fable 5 on High. I provided the code along with linked branding files (which due to the way branding patches are handled were simpler to provide separately) and my Adobe XD mockups. A few dozen iterations later, along with some exports and re-imports due to manual changes (some animations in tabbing/"focus mode" showcases needed to be "just so" and prompting would have been inefficient to get there), I had a new user experience I was far happier with. Simpler, yet better at communicating, far more visually appealing and resolving some concerns I had, I felt pleased and will admit, Fable 5 via Claude Design provided valuable output and did, what it does best, make iterating on multiple UI concepts next to each other to settle on a final option from many, far quicker.
I then exported and took that to GPT-5.6 Luna (I have € 23,- Codex only so am a bit stingy on when to use what). But so what? I had verified, the tokens were the same. The naming of elements remained consistent to what Hominis Settings used, the backend changes were practically none-existent. I had audited the output end-to-end, made some refactors and house style specific improvements to keep everything more auditable, everything seemed suited for a quick port. What could possibly go wrong?
Anyone whith pattern recognition will likely guess what. Basic 1:1 applying? No dice. The first attempt failed as, once the context window had compacted twice, the model started leaving the very clearly paved path laid out. Stylised favicon in the showcase? Gone. Hamburger menu in the showcase, compressed. Vertical tabbing change interlinked with the canvas section? Very funny. The model started no longer following the code, it started taking screenshots and applying what it could see from that, despite the original prompt (just checked) vey clearly stating a simple code port, section per section, with any deviations to be listed in a designated file I maintain for long running tasks.
Basically, Luna did implement changes to the settings that felt tangentially right and a casual observe may not notice all the regressions and deviations, but I did. So I stopped it.
Sol and Fable didn't fare much better. Sol did stay on target longer, but it went off the rails around the privacy tab, introducing functional regressions to the way I had implemented cross-site cookie blocking, which were never requested, nor should that code even have been looked at. I reset the repo and handed it over to Fable 5 (medium). I had a third of my weekly usage left on 20x Max, reset the day after at 3AM so no harm either way.
Should be plenty. Wasn't plenty. Since a while (I think Opus 4.7, but could be wrong), Anthropic models do decently well regarding long term, high token tasks. Up to 450k, I have been able to reliably reproduce consistent implementation. The model, using a few subagents (which should have reduced the risk of context window issues further), went to work and after a few hours (and about 20% of usage less), the model proudly presented its work. I was at work and by the time I came back, I was a bit miffed to find that the model had, in its wisdom, decided to not used the well established and consistently used mar to bind in branding icons. No biggie, easy fix, albeit a bit stupid. ESPECIALLY SINCE I SAW IN THE CLAUDE CODE TRACES THAT THE MODEL HAD SURPRESSED A WARNING ON THAT VERY FRONT. Whatever. Then I saw it had not wired in the existing browser data deletion and export logic. It hadn’t modified existing logic unlike Sol, so hey, that’s nice. But it had not wired up the existing settings when they did not have any immediate feedback in the implementation reference.
Ox Alpha, it just spanned in circles, didn’t seem to like our fireforge CLI and furnace componets, but it was worth a free try. Opus 5, the model most obsessive in checking its own work, took screenshots. A lot of sscreenshots including every few hundred ms to cover animations. Nice. BUT IT CREATED ITS OWN TOKENS INSTAD OF REUSING WHAT WAS PROVIDED. Thus, styling deviated heavily.
At this point you might ask why I don’t do it manually and I will in the end anyways, but I was surprised to find such a clear case of a seemingly straightforward task flummoxing multiple LLMs. This is aided by my unique code base (the upstream FF code is also gitignored which likely flummoxes some models trained heavily to leverage git to track changes), everything needs to be patch backed and follow a specific implementation style, etc. But I had more important things to do and I wanted to see whether I couldn’t get it to work yet.
Inspired by Opus 5, I wrote a new prompt, specifically laying out a visual comparison and code diff workflow. Only these changes, only in this manner, only move on ones you have gotten visual confirmation, specific cross checks. I included a hand written markdown outlining which change affects other settings sections (even though that is obvious reading the reference code), how to approach tokens, etc. Obsessively descriptive and (I feel) unnecessarily so, but why not. Best case, it works, worst case, I’ll spend an hour doing it manually. I had other things to do not behind a keyboard, so why not one last Hail Mary.
Fable 5, ever efficient when using visuals, used the last rest of my usage, though I did see some roundabout approaches after the fact that make me doubtful it’d have cracked this. Opus 5 went off the deep end taking ui-captures across the entire code base, which lead to a very liberal application of settings tokens outside settings.
Sol did take a night and got 40% there when I asked for a pause once the in flight slice had landed. It did port the UI/UX changes in a way that on the surface looked and felt correct. It did not touch the backend in unacceptable ways. And it did cross checks. Animations also behaved correctly, though it did apply a rule on backend usage a bit to strictly, incorporating that into a preview for search by turning that into an actual web search, not a UX demo. Dumb, but not fatal.
Great success, what am I complaining?
Well, the code. It had done what Sol likes to do and turned very cleanly written, readable code into a hard to parse mess. This included touching existing test files.
And at that point I said “fuck it, I’ll do it myself”. And I did. In less than an hour, listening to Paris Palamo, Lyre Le Temps, Sting, Sade, SynthV and some Nirvana.
If I didn’t look at the code and I didn’t have strict standards for the UI, but just considered what looks in line on the surface level/feels right/“vibes” and what “works”, many of these attempts would have been accepted, as their issues are rarely apparent on the surface. That’s part of the issue in my book and why I’m firm we are far from “don’t read code”/“don’t test”/“skip qa”…
It's not about the prompt, it's about the guardrails. Static types, compiled, massive test suite, etc. That what I mean by extreme level of test coverage like SQLite. You'd actually need to be an expert in C and SQLite and the SQLite test suite just to sneak a bug into it. Testing and other verifications are going to be an exciting area for the foreseeable future.
You can still write non-performant code even with tests, but you can also test performance!
Am about as far away from a C expert as one can be (and probably want to keep it that way for the time being), so happy to take your word on that front. Still feel, it'd be easy and in their interest for one of the major labs to provide a verifiable showcase/research paper on that front. Zig-to-Rust in Bun is the closest and that is very impressive, but I feel it doesn't necessarily map to new features/changes beyond porting. The compiler, browser, etc. all equally do not fill me with that much confidence, but perhaps in SQLite modifications could be hard for a model to mess up.
What I will say is that I feel valid in saying that the developer behind gas town (a shudder runs down my spine even having to think about that) is not working in a test suite anywhere comparable to SQLite, though in fairness, you never claimed that.
Again, you are likely not wrong that with an environment like SQLite, bugs may be hard to sneak in, but then again, isn't retaining that so important that it is a strong argument for developers auditing LLM output even more strictly, lest we loose the resilience we currently have?
That might be an interesting parallel. Maybe code becomes like legal documents. Binding but inscrutable, full of small mistakes and not really tailored for human ingestion.
As others have said there are other conclusions going both ways (though I do think most settle on as you said), though one very fair conclusion I came across is that it's not allowed because the whole issue of copyright is still somewhat unresolved, and though its fine right now, that could (probably wont, but could) massively backfire later.
The Asahi Linux project bans LLMs. Unfortunate as LLM reverse engineering and driver writing would bring Linux to more Mac models much faster.
The Zig project rejects LLM based contributions.
Some of these policies were introduced when LLMs were really bad at writing code and haven’t been revisited. Some groups don’t care about the quality and object on moral or copyright grounds.
Debian gives attribution to every single open source project in existence that is capable of running on Linux, and is Free Software. It is exactly the project that shouldn't worry about copyright.
The "moral" argument I haven't even heard. It's just people pouring out invective, likely imo because Ruby-monkey is not going to be a $150K job anymore. I have problems with these companies, but companies who are problematic can be targeted specifically, and somehow everybody started using Facebook's frontend framework and Microsoft's IDE, all on MacBooks, and this is what they're throwing a shitfit about. To me it's narcissism, not a coherent moral objection.
If you hate these companies (as you should), there are open models. But most didn't object to anything that didn't threaten their income.
Note that Debian is mostly an aggregation of packages. There's nothing wrong with Debian importing a package that was written by AI, if it's something that people want to install. The questionable copyright of that package does not taint Debian as a whole. Debian allows public domain packages, so it wouldn't even be a DFSG violation.
There's also nothing wrong with an AI-written install script (if it's correct) because those are likely too trivial to copyright anyway.
What are your specific worries? Mine is brain rot.
> I was referring specifically to the idea that you have to stand by the code that you write.
Any serious entity which has experts handling code will do so, yes.
My employer, for example, has various teams of actual developers and others with a significant number of “not really” devs who found their way into DevOps roles. The teams with seasoned developers hold the author responsible as to the integrity and quality of code, regardless of tools used. They won’t hesitate to call someone out directly for low-quality submissions in Teams channels. The teams that have a lot of “not really” devs will blame the model for issues that surface. Of course, they’re also pushing to not have to write any code directly by FY2028, but instead have models do it as part of an internal AI initiative. Somehow the idea of using AI to generate reports, process reports, write code, test and deploy got signed off.
I could imagine (in a commercial organization) a case for something like: "we're obviously going to be relying more and more on AI, so if bad code comes out of it, instead of just shaming the engineer, let's study together what happened -- what was the chat context, the model, the system prompt, etc... ? What seemed to cause the issue? What processes or systems could we put in place to improve it? Etc... -- and then use the learnings to improve AI use throughout the whole org."
"This works for me, but I need help understanding why, because maybe it would help others" is a legitimate position to be in--has been since long before LLMs. I think we miss out on something when we ignore that position.
I'm not saying that anybody should be obligated to review large volumes of low confidence code... just that we should not make policies that ignore shades of gray which, with some collaboration, could bear fruit.
The change with this justification absolutely exists and has existed for a long time, but this justification only works for small changes (in the past and still today). Don’t come to me with a huge refactor or new feature and this explanation, which is happening more and more recently (it’s an easy strawman to make and hard to prove, but I certainly see it in practice).
I think the key thing you are missing here is that most successful open source maintainers don’t lack expertise, they lack time. They are generally capable of improving their projects in any direction they want without help. Mentoring new contributors is basically always a loss in the short term as far as the maintainer is concerned. The project does get improved, but it generally takes longer than if they did it by themselves from scratch, and the improvements might be in an area they don’t much care about. The payoff for the maintainers only ever happened in the long term if the mentorship succeeded and they get a viable independent long term contributor.
Linus Torvalds regarding the Linux kernel is reasonably similar. He views AI/LLMs as just another tool in the development process. Think about life before and after modern IDEs that features IntelliSense circa 2000. It was night and day. It did not make programmers dumber -- it was a new tool.
Except LLMs actually are making programmers dumber. I personally know people, people whom I know for a fact were good programmers before, who have now completely stopped using their brains. When you ask them why they did something in the code, they say "I don't know, Claude did that and I didn't really question it". There was no such analogous phenomenon with IDEs.
They cared enough to do good work before, so I don't think that your explanation suffices here. From my observation (not just with their programming but in other interactions), it truly is that using an LLM has made these people less intelligent than they were before.
There was an increasingly scary mass of people in the industry that viewed the coding as a sort of therapeutic exercise, and would become quite obsessive about it. For those people LLMs are anathema because they take away what was the rewarding part of the job.
If you care primarily about the quality of the end result, as opposed to being attached to a particular process of achieving it, then you're happy about how things have gone.
You find it scary that people enjoy what they do? Simply caring about the end result is often not wise, ethical, or sustainable, and the quality thereof is dubious in any case, especially when you consider that the end result of developing software is never just the artifact.
Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy.
And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site.
People who simply enjoy coding (without treating it to be "therapeutic") are still unhappy because working with LLMs is just not the same, and not rewarding in the same way
> Treating coding as the therapeutic reward for other things (typically tolerating bureaucracy) and then indulging obsessions about it absolutely is unhealthy.
> And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site.
I know that experience, but I do have a different opinion on this:
Many such people studied computer science (a similar point holds for mathematics, physics and some engineering disciplines) because they love coding.
Unluckily, the job that they got does involve barely any clever coding, but rather
- tolerating and gluing together shitty code pieces that someone else wrote
- tolerating red tape
So, such people simply do in their free time what they love. And to come back to my point "similar point holds for mathematics, physics and some engineering disciplines": these people try to use their little free time to prove some novel theorems or put their shed full of machines like 3D printers, CNC mills, CNC lathes, laser cutters, self-built pick-and-place machines, ... to work on their own beloved engineering projects.
> If you care primarily about the quality of the end result, as opposed to being attached to a particular process of achieving it, then you're happy about how things have gone.
We must be living on different planets, because from everything I can see, software quality is at a historic low.
A friend of mine, really nice guy, is training as a lawyer at the moment. He has zero interest in law or justice, but heard that lawyers make a lot of money. Not too long about, programming went through a very similar phase. To be clear its not that I think programmers or lawyers shouldn't make good money, they absolutely should and it is deserved, its just it has the unfortunate side effect of attracting people who don't care about the field itself. For those people, they care as little as they can get away with and still be paid big money, and if LLM's allow them to do that at the cost of quality, they absolutely will.
I do think LLM's are making some genuine programmers less intelligent, but I think this type of person makes up a decent portion of its users too
I'm a person who is over-reliant on LLMs, doesn't know how most of the things in the codebase work, and is atrophying both in programming and in general cognition.
I don't want to speak for them, but perhaps this is a very real consequence of the "use ai or get left behind" talking point. Maybe they were effectively scared into it, and now are too far gone. They seem like a very reasonable person if they're admitting to being over reliant on LLMs, so I don't mean this as an insult
I'm not dumb. I care a great deal and I always have. I've just never been good at programming.
When I recently found a small bug in how NTP is implemented in Home Assistant OS that was affecting my use of it, I thought about just reporting that bug.
But I set the bot forth to work on corrective measures, instead.
The first proposed fixes were overbearing and awful. Maybe they'd have worked but it hurt my soul to look at them. I couldn't accept them -- not for my system at home nor for anyone else's.
Through a laborious process (that many here could have skipped entirely), I eventually got what I feel is a cromulent fix down to a few lines of changes in an init script.
I didn't write it. All I did was direct (and sometimes brow-beat) the bot, rejecting things over and over while optimizing at a high level until it produced an acceptable result.
I now have a fix that is tidy-enough that it can be applied to running systems. It is easy to understand what it does, and why it does it -- even for me. Perhaps I should submit a PR...
> They just don't care. They didn't before either.
...but this kind of blanket mentality really puts a damper on my willingness to do so.
It doesn't apply to everyone, but yes I know people who are over-reliant on LLMs and definitely getting dumber. With devs and non-devs too. I hate seeing this happen.
> Except LLMs actually are making programmers dumber.
Make that some/a lot, but not all.
There is a clear bifurcation. A lot of those that never cared really don't care now, but then you get others that can use it to crank that much harder than ever before.
If you put the same brain effort in but leverage LLMs you really can be dramatically more productive.
IDEs enable us to not bother memorizing the number and order of arguments, long names beyond the first word or two, etc. the impact is comparable, freeing some of the very limited space in our memory for more important things.
sure, students and juniors shoot themselves in the dick if they let LLMs do everything, but they're fucked anyway so it doesn't matter,
I’m genuinely curious why it matters to make abstract moral judgments about the differences between remembering function names and deep understanding of the syntax used in a function.
Why don’t we just care about results? Code quality, performance, clarity are all measurable. Why bother with philosophical positions on these?
How do you trust the results of a black box that are hard to verify? Most of us use proxies that are easier to check, like historical competence and maturity. For example, it's difficult to verify my compiler produces a binary that correctly implements the code I wrote. I can partially validate the result with testing, but when I send it out into the world to handle unknown inputs I'm trusting that the compiler has done its job correctly. I can have that trust because I know the compiler people (in aggregate) have thought very hard about correctness, and the project is mature enough that bugs are rare. If the GCC developers tomorrow were to start merging anything that passed the test suite and some other list of objective metrics, my trust would rightly decrease.
That's because you are used to it. I am old enough to have been there during the rise of things like intellisense and language servers, people were making the exact same arguments about them. That not knowing your API to the core makes you a bad programmer. I'm sure for IDEs themselves there were similar arguments and it goes all the way back to Socrates' warning against writing. These arguments always end with "but this time it's different". And inevitably each time it's not.
> That not knowing your API to the core makes you a bad programmer.
Seriously, this was a huge thing in C and C++, where you had to know/remember/know to look up very specific error codes and conditions in an API and if you didn't then it was very much considered to be a skill issue. This was maybe 15 years ago.
> Seriously, this was a huge thing in C and C++, where you had to know/remember/know to look up very specific error codes and conditions in an API and if you didn't then it was very much considered to be a skill issue.
It was not unless you were part of some very weird circle. There was always manuals and other references that listed everything about a platform or library. Then we got ‘man’ and ‘info’. And I remember being able to download the full docs of windows’ various documentation.
That’s like saying as a writer you were looked down at because you had to look at a dictionary every once in a while.
I'm not sure what you're saying, or how it is not what I'm saying? You're giving examples of places to read documentation, and I'm saying that the expectation was that behaviors caused by not checking documentation would be your fault. If that isn't your experience, cool, it was definitely mine when posting on forums online 15-16 years ago.
Why wouldn’t it be? If you were in charge of writing a letter and use words that hinders the purpose of the letter, thus resulting in a flawed communication, wouldn’t it be your fault? Especially when dictionaries are easily available?
>people were making the exact same arguments about them. That not knowing your API to the core makes you a bad programmer.
And they were correct. You're entirely right that this time it isn't different, but in the sense that the quality of both developers and code has been going downhill for decades. The only thing that has kept this industry alive is that hardware got more performant faster than developers became more inept.
The non-strawman version of Socrates warning, that writing-based cultures would lose memory, take recorded fact at face value and mistake knowledge for wisdom was true as well. Your post is an example of this, you read something about Socrates, you didn't investigate and were fine with the appearance of knowledge, and because books can't defend themselves you mistook that for understanding.
That's what he was concerned about, hordes of people with a vague assemblage of facts but no genuine capacity to critically think.
I am not arguing that things don't change and certain skills dont atrophy. I am arguing that the atrophied skills are compensated by new skills we develop. But your personal attack makes me feel like your purpose is to win, not to be right.
>I am arguing that the atrophied skills are compensated by new skills we develop
is there a lot of evidence for this? You can broadly put technology into two camps. Technologically that, as it becomes more powerful, demands more attention and skill from the user and just the opposite. A bow is more powerful than a stick but also more demanding to use. A car is more powerful than your feet but your population ends up obese. Almost every single piece of software, with the exception of maybe debuggers, who an astonishingly amount of seasoned developers do not utilize (I suspect for that reason), is a car and not a bow.
There's a study on English college students roughly ten years ago who were tasked to read the first few paragraphs of Dicken's Bleak House. They were even allowed to use a dictionary and the internet. A majority could not interpret the text. That's where we were at before LLMs. My rural working-class grandfather at an underfunded Catholic school had to translate Ovid from Latin into German in 8th grade. It wasn't even a personal attack, we're just this fried now.
> With AI people aren't reading, writing, or thinking about the code.
Writing, definitely. Reading, maybe. Thinking is another thing. I can think about code in a lot of ways just by reading a description of the code, or knowing how I directed the code to be written, etc. I think people are thinking about the code differently.
code didn't matter even before LLMs. we only ever cared about the product of it.
the current pace of LLM advancement only has to keep for five more years for handmade code to be considered a liability. I wouldn't worry about being able to recall obscure APIs or whiteboard leetcode. I'm far more worried about having to change careers at 40.
I've seen the result of "code doesn't matter" and it's difficult to change and maintain. I guess if your business is ok with frequent P1 incidents or ships a complete product and never touches it again, but I've never been part of one. I've also never been in a position that cared about leetcode or remembering APIs, so it's possible my experience is completely different from yours.
Number and order of arguments, long names, etc. are just bureaucracy. Knowing them doesn't mean you understand the codebase any better than if you rely on the IDE for it.
It's a bit like remembering the exact date an historical event happened vs. knowing at which point in history it did, what other events relate to it, etc. Neither makes you better or worse at knowing and understanding the history of the event.
I spend a ton of time mentoring Jrs in FOSS communities, but I confess as a startup founder myself I could simply not justify hiring anyone but self-directed seniors until we are profitable enough to set some money on fire for what would effectively be just a long term investment in creating a few new Srs. But Jr hiring will never again be what it was unless it gets subsidized somehow as partial charity.
You can just ask Claude why it did something in the code and it will tell you
Programmers just moved up a level , not dumber, we are now managers of a team of 'agent' programmers. The deliverable is now a functionality instead of a specific block of code
Repeatedly.
You are right that's one or the other. Probably both are contributing.
https://www.cnbc.com/2025/04/29/satya-nadella-says-as-much-a...
Note that he said written by, not assisted; and also that there's been some major QA issues with win11 the last year, enough for Microsoft to have made a public apology/commitment to improve...
So, no definitive evidence, but the rest of the breadcrumbs provide enough to say that yes it does appear to have suffered from it.
Given the Debian policy seems more geared towards aided/assisted an existing dev than replacing them and shipping because the code works on the golden path on a devs monster pc ... Well I'd still keep an eye on it but trust OSS OS engineers to have some competence at knowing if this works and adjusting the policy later if it proved to be wrong.
Now the argument that genAI is helping them find and fix bugs faster has a lot of merit because it can be pretty darn good at that. But for lack of a better phrase, 'The Windows 11 Experience' feels, as other users pointed out too, either vibe coded or like the dev teams went insane. I live and die by Debian in my servers and I really hope the same kind of thing doesn't happen to them.
The rumor is the opposite, that Microsoft has actually used AI to discover and fix common security issues at scale.
the entire industry is experiencing this as model capacity increases. How does "all projects get critical security fixes now" relate to "crap apps and loopy services by literally millions of lines of slop code" ?
Your appsec engineers will be the ones bug hunting with Mythos or whatever. Your regular engineers will be the ones implementing features. If the feature is a bad design and functions badly as a result, that is entirely orthogonal to whether it contains coding errors or bugs.
Also, there are bugs on the integration side that won't be caught running Mythos against source code, because it's not a source code issue. Even using Mythos for DAST is going to be very limited compared to how actual users will move through something as complex as a 'mature' OS like Windows.
https://bsky.app/profile/boxobark.ing/post/3mtr7j3tpok26
It's as though people want to find the most dubious of non-existent connections and use that as leverage to besmirch something they don't like.
There are many things one can do where a person has no awareness of the tenuous connection but where you can have someone go back and then ex-post make that connection and declare that thing or person racist. It's a tactic.
Like one _could_ make the argument that factory automation in China is racist because without automation they would have to import labor from (some non-Chinese population). However, the Chinese never began automation with the intention of being racist.
There are significant societal impacts of this AI buildout. Some are concerned externalities weigh more heavily on the poor and marginalized. I think state wide data center holds are part of this civil discourse.
I'd prefer we have more conservative pollution standards along with a reasonable tax on AI use that helps mitigate externalities. That's hard. Reasonable people can have fierce disagreements on what market interventions are indicated, and how extensive they should be.
https://pbs.twimg.com/media/HQ5MeeaXUAAIMLX?format=jpg&name=...
Somewhat insulting to those that actually lived (or live) under fascism.
Is there a term for this? Ensnarkification? I see it on X and bsky all the time.
I'm beginning to wonder if it might be the case that when my fellow citizens begin to act insane - might it be the result of foreign propaganda.
The examples I'm thinking of have definitely profited foreign interests, tho.
Look to see who profits.
Sure there is. Contributing to open source is a privilege, not a right. Abuse it, and find yourself unwelcome as a future contributor
When I am at home practicing my musical instrument or learning to paint, those aren’t paid activities, so I can’t demand high standards for myself.
When Habitat for Humanity is looking for volunteers to do electrical and plumbing on homes, they have to allow unlicensed random folks do it.
This is not how life works at all.
We've come to the same conclusion in our organization and while it felt like it needed to be discussed and stated, I've never heard of anyone coming to a different conclusion.
[EDIT: I was referring specifically to the idea that you have to stand by the code that you write. Is anyone deciding on a policy that says "the AI did it" is a valid excuse for breaking code?]
Yes. Very notably: https://ziglang.org/code-of-conduct/
> Though it's being argued that you could still be responsible for it without looking at it?
If you have a much test coverage as SQLite, I'd be tempted to trust it, and I think that's where we are headed. Someone still needs to define these guardrails though, so IMO the developers job is just mutating into something else, but is still necessary. Long term, who knows.
Models also still can have major task adherence issues, so even a perfectly well scoped, well considered prompt that covers all situations and coverage can, in many scenarios lead to output users may not expect or notice without reading code. Seen it a lot, just lost some blood and tears to a very straight front end implementation task that I ended up applying manually cause both Sol and Fable struggle to copy a few dozen HTML/JS/CSS snippets properly into a slightly obscure codebase, despite the reference being fully featured and even using the same token scheme, etc…
We also see such issues in what labs deliver in their own software products. We are not at the stage where a human shouldn’t sign off on code that they have tested and understood. A hypothetical future, I don’t really care for, we’d notice when labs stop shipping easily apparent bugs, though even then, I’d still feel there is a while in between that and not needing to assess the output anymore.
There is, in my mind, no need for this “narrative shifting”, overtone window (don’t get me started on the idea of applying that to what should be a purely technical discussion), convince the unbelievers nonesense that some spend their time on. If models could provide code that didn’t necessitate review, there’d be no one needing to argue that case. If and when they can, we’ll know it, but not because of those espousing this currently.
Also I suspect you overprompt, with GPT-5.6 (sol, terra and luna), a lot's of what's used to be mandatory in the AGENT.md is redondant at best and frequantly actively harmful.
I do not have an AGENTS.md in any of my repos at all, stopped using them around 5.2. I was a bit ahead of the curve with that, my evals very early showcased how limiting those tend to be, same why I never used MCP, were useless context bloat.
Will maybe make an edit explaining a bit further what the task was once I get to my computer.
So this "thing" is mainly a Firefox fork and most UI is basic HTML/CSS/JS (as is the case in upstream). Development is patch baked, CSS tokens must follow a defined and CI enforced standard, etc. LLMs can be very helpful in development, I got a small CLI tool for patch, token management and basic quality gates, which I started working on a few months ago to keep the most atrocious LLM output at bay. Has lead to the revieability of output improving meaningfully over markdown monstrosities, though OpenAI models still manage to sneak hard to parse output past it. This CLI tool along with some task specific scripts also ensures reuse of proven upstream infra like Places (Good lord dear Firefox developers, is Places nice to rely on), consistent regression testing (especially in memory constraint scenarios), etc. Basically, I can and do regularly make additions with LLM assistance, I review it, I discard and restart or improve upon it (rarely accept scoped changes wholesale. This to say, I got some experience in the use of models for coding assistance and I (thanks to the amazing docs and a lot of considerations for the architecture I want) do know what I want, how I want it and how to get there. Also got private LLM evals that often uncover which labs tend to perform suspiciously well in public benchmarks vs private ones and what models still struggle with along with why, so yeah, certainly can always improve but I got, I'd argue, enough of an idea to where my critique of LLM coding limitations has legs.
Which brings us to what I was trying to implement and how I went about it: Settings works. Fully featured (including a few cross-site-tracking specific clarifications that came from a HN interaction a few days ago), tab specific previews for what changes affect regarding themeing, well tested (manual and static), integrated to leverage what FF provides where possible.
It does (or rather did) look functional/God awful though. To the point where I was uncertain that certain previews could be easily parsed by new users. I thus opened Adobe XD, did some early mockup work, tried a few core concepts, settled upon two, then (using Claude Fable 5 low) created a plain export of the existing settings code from our furnace components and patch baked edits into regular HTML/JS/CSS files. I manually verified, this export worked, the tokens were in the correct format, the code reflected what Hominis applied (including what was required for stand-alone of course) and externally called features upon interaction did provide log output linking to the pre-existing functions that meant reimplementation based upon this should be easy.
I then took that to Claude Design using Fable 5 on High. I provided the code along with linked branding files (which due to the way branding patches are handled were simpler to provide separately) and my Adobe XD mockups. A few dozen iterations later, along with some exports and re-imports due to manual changes (some animations in tabbing/"focus mode" showcases needed to be "just so" and prompting would have been inefficient to get there), I had a new user experience I was far happier with. Simpler, yet better at communicating, far more visually appealing and resolving some concerns I had, I felt pleased and will admit, Fable 5 via Claude Design provided valuable output and did, what it does best, make iterating on multiple UI concepts next to each other to settle on a final option from many, far quicker.
I then exported and took that to GPT-5.6 Luna (I have € 23,- Codex only so am a bit stingy on when to use what). But so what? I had verified, the tokens were the same. The naming of elements remained consistent to what Hominis Settings used, the backend changes were practically none-existent. I had audited the output end-to-end, made some refactors and house style specific improvements to keep everything more auditable, everything seemed suited for a quick port. What could possibly go wrong?
Anyone whith pattern recognition will likely guess what. Basic 1:1 applying? No dice. The first attempt failed as, once the context window had compacted twice, the model started leaving the very clearly paved path laid out. Stylised favicon in the showcase? Gone. Hamburger menu in the showcase, compressed. Vertical tabbing change interlinked with the canvas section? Very funny. The model started no longer following the code, it started taking screenshots and applying what it could see from that, despite the original prompt (just checked) vey clearly stating a simple code port, section per section, with any deviations to be listed in a designated file I maintain for long running tasks.
Basically, Luna did implement changes to the settings that felt tangentially right and a casual observe may not notice all the regressions and deviations, but I did. So I stopped it.
Sol and Fable didn't fare much better. Sol did stay on target longer, but it went off the rails around the privacy tab, introducing functional regressions to the way I had implemented cross-site cookie blocking, which were never requested, nor should that code even have been looked at. I reset the repo and handed it over to Fable 5 (medium). I had a third of my weekly usage left on 20x Max, reset the day after at 3AM so no harm either way.
Should be plenty. Wasn't plenty. Since a while (I think Opus 4.7, but could be wrong), Anthropic models do decently well regarding long term, high token tasks. Up to 450k, I have been able to reliably reproduce consistent implementation. The model, using a few subagents (which should have reduced the risk of context window issues further), went to work and after a few hours (and about 20% of usage less), the model proudly presented its work. I was at work and by the time I came back, I was a bit miffed to find that the model had, in its wisdom, decided to not used the well established and consistently used mar to bind in branding icons. No biggie, easy fix, albeit a bit stupid. ESPECIALLY SINCE I SAW IN THE CLAUDE CODE TRACES THAT THE MODEL HAD SURPRESSED A WARNING ON THAT VERY FRONT. Whatever. Then I saw it had not wired in the existing browser data deletion and export logic. It hadn’t modified existing logic unlike Sol, so hey, that’s nice. But it had not wired up the existing settings when they did not have any immediate feedback in the implementation reference.
Ox Alpha, it just spanned in circles, didn’t seem to like our fireforge CLI and furnace componets, but it was worth a free try. Opus 5, the model most obsessive in checking its own work, took screenshots. A lot of sscreenshots including every few hundred ms to cover animations. Nice. BUT IT CREATED ITS OWN TOKENS INSTAD OF REUSING WHAT WAS PROVIDED. Thus, styling deviated heavily.
At this point you might ask why I don’t do it manually and I will in the end anyways, but I was surprised to find such a clear case of a seemingly straightforward task flummoxing multiple LLMs. This is aided by my unique code base (the upstream FF code is also gitignored which likely flummoxes some models trained heavily to leverage git to track changes), everything needs to be patch backed and follow a specific implementation style, etc. But I had more important things to do and I wanted to see whether I couldn’t get it to work yet.
Inspired by Opus 5, I wrote a new prompt, specifically laying out a visual comparison and code diff workflow. Only these changes, only in this manner, only move on ones you have gotten visual confirmation, specific cross checks. I included a hand written markdown outlining which change affects other settings sections (even though that is obvious reading the reference code), how to approach tokens, etc. Obsessively descriptive and (I feel) unnecessarily so, but why not. Best case, it works, worst case, I’ll spend an hour doing it manually. I had other things to do not behind a keyboard, so why not one last Hail Mary.
Fable 5, ever efficient when using visuals, used the last rest of my usage, though I did see some roundabout approaches after the fact that make me doubtful it’d have cracked this. Opus 5 went off the deep end taking ui-captures across the entire code base, which lead to a very liberal application of settings tokens outside settings.
Sol did take a night and got 40% there when I asked for a pause once the in flight slice had landed. It did port the UI/UX changes in a way that on the surface looked and felt correct. It did not touch the backend in unacceptable ways. And it did cross checks. Animations also behaved correctly, though it did apply a rule on backend usage a bit to strictly, incorporating that into a preview for search by turning that into an actual web search, not a UX demo. Dumb, but not fatal.
Great success, what am I complaining?
Well, the code. It had done what Sol likes to do and turned very cleanly written, readable code into a hard to parse mess. This included touching existing test files.
And at that point I said “fuck it, I’ll do it myself”. And I did. In less than an hour, listening to Paris Palamo, Lyre Le Temps, Sting, Sade, SynthV and some Nirvana.
If I didn’t look at the code and I didn’t have strict standards for the UI, but just considered what looks in line on the surface level/feels right/“vibes” and what “works”, many of these attempts would have been accepted, as their issues are rarely apparent on the surface. That’s part of the issue in my book and why I’m firm we are far from “don’t read code”/“don’t test”/“skip qa”…
You can still write non-performant code even with tests, but you can also test performance!
What I will say is that I feel valid in saying that the developer behind gas town (a shudder runs down my spine even having to think about that) is not working in a test suite anywhere comparable to SQLite, though in fairness, you never claimed that.
Again, you are likely not wrong that with an environment like SQLite, bugs may be hard to sneak in, but then again, isn't retaining that so important that it is a strong argument for developers auditing LLM output even more strictly, lest we loose the resilience we currently have?
Works for ToS and software and media licenses. Allegedly.
SourceHut bans LLM generated code from their platform https://news.ycombinator.com/item?id=49461724
The Asahi Linux project bans LLMs. Unfortunate as LLM reverse engineering and driver writing would bring Linux to more Mac models much faster.
The Zig project rejects LLM based contributions.
Some of these policies were introduced when LLMs were really bad at writing code and haven’t been revisited. Some groups don’t care about the quality and object on moral or copyright grounds.
Precisely why Debian Project's decision is both baffling and infuriating.
I hope Debian forks over this. They have severely lost their way.
The "moral" argument I haven't even heard. It's just people pouring out invective, likely imo because Ruby-monkey is not going to be a $150K job anymore. I have problems with these companies, but companies who are problematic can be targeted specifically, and somehow everybody started using Facebook's frontend framework and Microsoft's IDE, all on MacBooks, and this is what they're throwing a shitfit about. To me it's narcissism, not a coherent moral objection.
If you hate these companies (as you should), there are open models. But most didn't object to anything that didn't threaten their income.
There's also nothing wrong with an AI-written install script (if it's correct) because those are likely too trivial to copyright anyway.
What are your specific worries? Mine is brain rot.
i don’t think you understand just how niche you already are
https://lobste.rs/s/29pm2f/llm_generated_submissions_should_...
https://sourcehut.org/blog/2026-08-27-tos-changes-and-llms/
https://blog.codeberg.org/protecting-our-floss-commons-from-...
https://ziglang.org/code-of-conduct/#strict-no-llm-no-ai-pol...
https://lwn.net/Articles/1086041/
https://asahilinux.org/docs/project/policies/slop/
Any serious entity which has experts handling code will do so, yes.
My employer, for example, has various teams of actual developers and others with a significant number of “not really” devs who found their way into DevOps roles. The teams with seasoned developers hold the author responsible as to the integrity and quality of code, regardless of tools used. They won’t hesitate to call someone out directly for low-quality submissions in Teams channels. The teams that have a lot of “not really” devs will blame the model for issues that surface. Of course, they’re also pushing to not have to write any code directly by FY2028, but instead have models do it as part of an internal AI initiative. Somehow the idea of using AI to generate reports, process reports, write code, test and deploy got signed off.
I think the dust has kind of settled though for engineering teams on: You must use AI for your work, and you must stand by your work.
The meat between these two mandates are still being fleshed out.
I'm not saying that anybody should be obligated to review large volumes of low confidence code... just that we should not make policies that ignore shades of gray which, with some collaboration, could bear fruit.
You’re also responsibility not to write crap PRs.
If you care primarily about the quality of the end result, as opposed to being attached to a particular process of achieving it, then you're happy about how things have gone.
And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site.
This is quite distinct from enjoyment.
> And I've seen exactly this across multiple large and small organizations in multiple countries, in addition to being all over here and the red site.
I know that experience, but I do have a different opinion on this:
Many such people studied computer science (a similar point holds for mathematics, physics and some engineering disciplines) because they love coding.
Unluckily, the job that they got does involve barely any clever coding, but rather
- tolerating and gluing together shitty code pieces that someone else wrote
- tolerating red tape
So, such people simply do in their free time what they love. And to come back to my point "similar point holds for mathematics, physics and some engineering disciplines": these people try to use their little free time to prove some novel theorems or put their shed full of machines like 3D printers, CNC mills, CNC lathes, laser cutters, self-built pick-and-place machines, ... to work on their own beloved engineering projects.
We must be living on different planets, because from everything I can see, software quality is at a historic low.
I do think LLM's are making some genuine programmers less intelligent, but I think this type of person makes up a decent portion of its users too
Sorry to say this, but he doesn't sound like a nice guy.
I'm a person who is over-reliant on LLMs, doesn't know how most of the things in the codebase work, and is atrophying both in programming and in general cognition.
I used to care, a lot. And I still do.
Are you prioritizing other things? Do you think losing your cognition and programming skills won't have a negative effect on your project?
Those seem bad but maybe they fit into a bigger picture for you?
When I recently found a small bug in how NTP is implemented in Home Assistant OS that was affecting my use of it, I thought about just reporting that bug.
But I set the bot forth to work on corrective measures, instead.
The first proposed fixes were overbearing and awful. Maybe they'd have worked but it hurt my soul to look at them. I couldn't accept them -- not for my system at home nor for anyone else's.
Through a laborious process (that many here could have skipped entirely), I eventually got what I feel is a cromulent fix down to a few lines of changes in an init script.
I didn't write it. All I did was direct (and sometimes brow-beat) the bot, rejecting things over and over while optimizing at a high level until it produced an acceptable result.
I now have a fix that is tidy-enough that it can be applied to running systems. It is easy to understand what it does, and why it does it -- even for me. Perhaps I should submit a PR...
> They just don't care. They didn't before either.
...but this kind of blanket mentality really puts a damper on my willingness to do so.
Make that some/a lot, but not all.
There is a clear bifurcation. A lot of those that never cared really don't care now, but then you get others that can use it to crank that much harder than ever before.
If you put the same brain effort in but leverage LLMs you really can be dramatically more productive.
Just like when Boeing decided that their QA process should be abridged to save wasted time and money!
And that worked perfectly.
(edit: rereading I think maybe you don't support not reviewing all of LLM code you submit, but the above was written with another impression)
sure, students and juniors shoot themselves in the dick if they let LLMs do everything, but they're fucked anyway so it doesn't matter,
Why don’t we just care about results? Code quality, performance, clarity are all measurable. Why bother with philosophical positions on these?
https://devblogs.microsoft.com/cppblog/author/vcblog/
Seriously, this was a huge thing in C and C++, where you had to know/remember/know to look up very specific error codes and conditions in an API and if you didn't then it was very much considered to be a skill issue. This was maybe 15 years ago.
It was not unless you were part of some very weird circle. There was always manuals and other references that listed everything about a platform or library. Then we got ‘man’ and ‘info’. And I remember being able to download the full docs of windows’ various documentation.
That’s like saying as a writer you were looked down at because you had to look at a dictionary every once in a while.
And they were correct. You're entirely right that this time it isn't different, but in the sense that the quality of both developers and code has been going downhill for decades. The only thing that has kept this industry alive is that hardware got more performant faster than developers became more inept.
The non-strawman version of Socrates warning, that writing-based cultures would lose memory, take recorded fact at face value and mistake knowledge for wisdom was true as well. Your post is an example of this, you read something about Socrates, you didn't investigate and were fine with the appearance of knowledge, and because books can't defend themselves you mistook that for understanding.
That's what he was concerned about, hordes of people with a vague assemblage of facts but no genuine capacity to critically think.
is there a lot of evidence for this? You can broadly put technology into two camps. Technologically that, as it becomes more powerful, demands more attention and skill from the user and just the opposite. A bow is more powerful than a stick but also more demanding to use. A car is more powerful than your feet but your population ends up obese. Almost every single piece of software, with the exception of maybe debuggers, who an astonishingly amount of seasoned developers do not utilize (I suspect for that reason), is a car and not a bow.
There's a study on English college students roughly ten years ago who were tasked to read the first few paragraphs of Dicken's Bleak House. They were even allowed to use a dictionary and the internet. A majority could not interpret the text. That's where we were at before LLMs. My rural working-class grandfather at an underfunded Catholic school had to translate Ovid from Latin into German in 8th grade. It wasn't even a personal attack, we're just this fried now.
Writing, definitely. Reading, maybe. Thinking is another thing. I can think about code in a lot of ways just by reading a description of the code, or knowing how I directed the code to be written, etc. I think people are thinking about the code differently.
the current pace of LLM advancement only has to keep for five more years for handmade code to be considered a liability. I wouldn't worry about being able to recall obscure APIs or whiteboard leetcode. I'm far more worried about having to change careers at 40.
Number and order of arguments, long names, etc. are just bureaucracy. Knowing them doesn't mean you understand the codebase any better than if you rely on the IDE for it.
It's a bit like remembering the exact date an historical event happened vs. knowing at which point in history it did, what other events relate to it, etc. Neither makes you better or worse at knowing and understanding the history of the event.
We need to continue the tradition of elevating humans through mentoring or we won’t have a future scaffolding for work to be done.
Programmers just moved up a level , not dumber, we are now managers of a team of 'agent' programmers. The deliverable is now a functionality instead of a specific block of code