I am big on reproducibility (nix aficionado) and determinism (flagging test failures are a red-alert, all-hands-on-deck situation in my world) and correctness.
I am also big on testing (the correct things). And nine-nines (big on Elixir).
And... I'm also big on agent-assisted dev. Which requires pretty much every check in the book to stay productive in. And that's fine to me. I've seen bugs that I wouldn't have made myself. And I've also seen my own bugs fixed. They've all gotten fixed in short order. I don't see why this is a problem.
Raise your personal standards.
Thing is, the unreliable-software situation was already untenable before agents (in poor hands) made it worse.
I don’t think the author (or many people) doubt that one can (and some will) find a way that does not “suck”
But it’s pretty clear that most people are not. For whatever reasons (mgmt pressure, trying to get ahead, skill issues, etc) they half ass it, accept the 10% (silent) fail rate and blame the bad outcomes on the AI as if that absolves them. Or, adopt the attitude that 10% fail is fine, and people who say otherwise are being picky, or are anti-ai luddites or whatever. You should accept that things will suck.
If you took a bad but functional AI generated service and transported it back to 2018 it would have been at worst just mediocre. People do seem forget how dreadful devslop was in the past. I'd take an AI generated mess to disentangle every time over a spaghetti codebase that grew organically in the hands of careless managers.
I don't like the idea of shaming people for making OSS vibe-coded tools for niche hobbies, so I don't want to name names, but there is ABSOLUTELY some stuff on Github now that can be used to get the job done but has UI/API/code performance, consistency, and quality issues, that would've been unfathomable for the average OSS project in 2018. Because it's the sort of stuff that only happens when there isn't a human in the loop to point out some very-obvious swings-and-misses. Like "you don't need a third button here doing the same thing as these other two" or "this button literally does nothing in 3/4 of the modes, but it's never shown as disabled" or "this takes 5 times longer than it needs to and blocks the main UI thread because work is all happening sequentially."
In the past it wasn't really common at all to add 10 features in an evening without actually trying to use those 10 features by hand yourself.
Personally I think it's wonderful that tools for these spaces exist when they didn't use to. But it's also ludicrous to say that anyone with Claude can replace even mediocre homemmade stuff in any dimension other than "being worth building even a bad tool" or "getting to semi-usable faster." Currently you still benefit massively from knowing what's going on behind the scenes, and from knowing "software engineering 201" type stuff around what sort of testing would be helpful where, vs accepting model-default-output everywhere.
> there is ABSOLUTELY some stuff on Github now that can be used to get the job done but has UI/API/code performance, consistency, and quality issues, that would've been unfathomable for the average OSS project in 2018
I will take time to address you comment fully, there are lots to unpack, but I'd like to stop here and point out that comparing "absolutely some stuff" from today to the "average 2018 project" might be unfair. If you are going to compare the bottom of the pile of synthetic code, you should do the same with organic code of back then lest you draw an unfair comparison.
> If you are going to compare the bottom of the pile of synthetic code, you should do the same with organic code of back then lest you draw an unfair comparison.
Make it the bottom 70% AI vs. the bottom 10% human if you want to. You're still going to be well within a sea of AI-slop because the volume is that large. The big thing about bad human code is that it tends to still be compact; I can read in some minutes the intention and what does(n't) work.
For each vibe-coded project I gotta do a tiny expedition just to get the basic idea of what's going on. let alone figuring out if things actually work as intended.
> The big thing about bad human code is that it tends to still be compact
I envy the environment you've worked before, because you definitely had a better experience than mine. My first job was working on a product -- not a prototype you see, an actual product with paying customers generating over 100k USD monthly for the company -- that was completely designed by interns from the ground up. Once we received a pull request on a part of the system that dealt with calculation reports that made snapshots of the relational db into MongoDB. This application was in PHP using an outdated CakePHP framework -- which was outdated for a good reason since it used to introduce breaking changes in minor releases (citation needed, but who's got the time these days...) -- and the merge request that once-employee left us to figure out how to merge was a single 400 lines function. You can extrapolate from it to infer the quality of the snapshots we were taking and you probably wouldn't land too far from the horrors we've seen.
So pardon me, but my experience shocks violently with your affirmation.I think you underestimate what the bottom 10% really is.
Volume has nothing to do with it, this is discussing code quality. But if you mind me saying so, blame this ridiculous amount of codeslop volume on greedy managers and corpocrats. Developers are artists, they usually ship shitcode when they're under pressure
volume has everything to do with this. We used to make fun of how overengineered projects can be with stuff like HelloWorld Enterprise Edition, and now we just shrug at that because it's made fast?
No it's because shrugging it off or not is the topic of another discussion. Code quality and noise ratio and absolute noise volume are completely orthogonal in a sense that you can discuss code quality separately to how you deal with a large volume of slop. This discussion is about the former and you are forcing it to be about the later, which is interesting but unrelated.
Good to know your opinion my friend. I think they are, the incentives are for them to hide it and play the corporation ladder climbing game instead, if you think about it.
I certainly do believe that some developers are artists, see for example the IOCCC, and more who are or would like to be artisans, but by and large our colleagues' hearts are closed to the Muses.
Idk, I tend to look at this towards learned helplessness. There sure are the intelligent opportunists trying to ride the hype tides around tech, but we can't really say much when the environment don't foster creativity. How many brilliant devs are out there rotting away at meaningless jobs because they have debt?
As far a I can tell, most didn’t bother to see if it worked for the system,p. They just needed to have it compile in their system and then they’d call it done.
Are the managers of these hypothetical places still interested in keeping the high standards and good design? Enshitification isn't inherent to the technology, if this is what you are deriving from the counterexample, it's a business strategy my dude.
> This is not new, but LLMs further tilt the balance
You speak as if llms had their own minds. Every time anyone talks about AI doing this or that they further reinforce this idea that there isn't a person behind all this. There's always someone watching.
With that said, when you say that llms tilt the balance, who specifically do you say that's driving llms to do that?
When someone says that something tips the balance of a situation, it is not ascribing a mind to that thing. For example, a bomb does not have a mind (nor does anyone think one does), but it is an undeniable fact that the atomic bomb tipped the balance of WW2. I think you are reading too much into the expression.
There's no anthropomorphizing warheads in nuclear warfare, so you can't really compare these two without the risk of ignoring the context and cultural relationship people have with these techs.
It means an ambitious manager can take on more work by having the team slop out. They move up (very effective leader!), standards fall, other managers have to match the changes. The bill comes due years later after they have moved on (and up).
But as more and more things depend on increasingly deep software stacks, everything goes to utter shit if the individual systems don't become more reliable.
That's a problem of customers stop paying for the product. If the don't then it's a philosophical discussion. I don't like the dilemma because I've been in a company that went bust from years of bungling it couldn't recover from and I wouldn't want to repeat the experience.
Yeah, a good reason to be touchy about AI is that it tips the balance of power to lazy people who don't want to work or think. On the scale of our whole society. Imagining the ideal responsible use by most others is folly. No matter how responsible and conscientious you, the reader, are with your use of it.
I see lots of people having totally checked out, since management cares less about nines and more about tokens consumed. Plus everybody figures theyll be laid off if not tomorrow next quarter or two, and their career will be unviable within 5 years.
I don't condone this view, but i understand where they are coming from!
> Thing is, the unreliable-software situation was already untenable before agents (in poor hands) made it worse.
I have definitely seen more bafflingly-poor OSS software that just plain doesn't work frequently now than before.
But it's mostly software that wouldn't have existed before because it's trying to do super-niche things. So on the "hobby" side of things, whatever.
But from a "trying to develop software as a business that you want to be a going concern," quality from people who should know better is less tenable than it used to be.
Thing is, the unreliable-software situation was already untenable before agents (in poor hands) made it worse.
Yes but that's the big thing, now isn't it? These are nice tools, used wisely. But their unwise use, oh boy...
The problem is one needs to be in a situation where the incentive is towards quality rather than speed. But that situation rather rare now - thirty years ago, Microsoft won the office wars with crap that had features. And nothing has fundamentally changed in web development since the LPad crisis.
The problem is those companies whose incentive is to allow bugs where it's the involuntary users who suffer will bite you no matter what quality you make your own software.
If the anti-AI people have skill issues because they're holding it wrong then when the output is crap it's the fault of the person with no skill issues who is using It correctly. It can't be both ways.
What is the point you are trying to make with this? That we can't distinguish AI's doing original work from copied work? Because there's plenty of evidence that they can do original work.
Sure, nobody knows the exact future. But you still plan for what's probably going to happen. I don't know if social security is going to be around when I retire, and all the experts are saying it's probably not going to be. So, I'm planning a retirement without. Similarly, all the experts are saying AI (<- that word is not "LLM") is probably going to improve. I personally think it's irrational to ignore experts.
I think that a person (me) who has worked directly with frontier AI for over a year now for many hours a day may have gained some expertise in what this technology is capable of and thus what is dangerous about it, but I wouldn't speculate too hard on what superintelligent AI would or could do because we have not yet seen such a thing nor is there even an established criteria as to what that would look like or how it would be valued and in what capacity (hint: humans are still the final evaluators of what is valuable)
The simple fact that I have to write every control scheme in the book to keep the thing on the goal path (and not lapsing into laziness or dishonesty) is itself possibly a safety feature, if you look at it that way
> The simple fact that I have to write every control scheme ...
Look three years ago for a reality check of the progress. The LLM you're using now isn't the LLM you'll be using in 5 years. It probably won't even really be the same architecture, just like those from 3 years ago are VERY different than the full systems we use today (harnesses and all). What you're doing was literal science fiction not long ago.
They are doing that because they are entities without principles or ethics.
The solution is to create controls around them. Many, many controls.
The Sarbanes-Oxley era already solved this problem for untrustworthy humans. It's directly applicable. I created a concept I call MFIC ("Mechanically-Falsifiable Independent Control") to encapsulate this principle.
I know a local bar where there are 4 bartenders who have all been there over 25 years.
Recently I started asking them "How many pregnancies do you suppose you have caused throughout your career?". The most common response was to laugh but all of them also said "I know of a few at least".
> surprise, it’s generative AI. The ongoing devaluation of the work of artists and makers
Who themselves can use AI to make even more radical art with far less effort, but refuse to do so because of some kind of... I don't know, a mental block? Perhaps we need better AI-accelerated artist tooling instead of one-shot garbage.
> Every programmer I know has basically gone insane over the last couple of years
Meanwhile, I feel more enabled than in my entire 35+ year career programming. But I also never got pushed into it, and don't have to deal with coworkers who use it badly because I'm solo currently. I do feel bad for people on teams for whom AI has caused much consternation.
> peer pressure is very real
Caving into peer pressure as a coder? Not something I have ever done, unfortunately. If you want to entirely reject AI assistance, then just own it and don't whine about it.
> even disregarding all the environmental
The environmental arguments are non-evidence-backed nonsense. Meanwhile, there's plenty of evidence that this whole idea comes from Chinese bot influence campaigns trying to politically polarize AI in the United States in order to slow us down so that they can surge ahead and economically win. And unfortunately, it's working. Case in point.
> It isn’t fun for me
I STILL don't understand this POV. Prior to AI, I had a massive backlog of ideas that I simply did not have the time or energy to work on. I now can, and have now built out a lot of those ideas (see my github). I'm chewing through that backlog like a chainsaw. Is all of the produced code perfect? No. Do I insist on lots more tests and controls to ensure it is as close to that as controls can get it? Yes. Has it yet to produce unfixable bugs? No.
> I use my interactive git branch switcher every single day
I love making those little tools too! And now I can make 10 of them in the time it used to take me to make 1 of them myself! Your tool is a neat idea! You still own that idea! And I can also rewrite it in Rust or Zig now with AI since I hate Go, and I don't think that's a bad thing!
> I’ve spent years learning how to make games, and it’s been hard, and now it feels like that might have been a waste of time
Your understanding and experience is not going away. In fact, it's needed to steer your AI accelerator.
> It also happens to be developed entirely without generative AI
That is a conscious choice made flying in the face of the evidence that it could have been built a lot faster with AI assistance and YOUR guidance. What's wrong with delivery speed, again?
> there are only really three paths open to me
This is a fallacy. Let's call it the false trichotomy fallacy. You have already resigned yourself to be unhappy about this since none of your options include "joy", so your brain automatically gathers evidence to support that belief... and you need to realize this, because it is dangerous. You now literally won't be able to perceive evidence TO ACTUALLY be happy about it- I call this "epistemic blindness", or we could just call it "doom framing". The key thing to understand is that you control the framing by choosing it, and that your chosen framings automatically and artificially limit your perceived options.
I can prove this to you- Think back to the first time you encountered AI work assistance. Was your feeling good, or bad? Has it ever switched? I'm going to guess that it started early and never switched. Why is that? Because you (or your brain, via its confirmation-bias-seeking) immediately decided to remember evidence supporting your initial feeling, and forget or ignore evidence against it!
But yes. If you must completely ignore AI to keep your sanity based on your own self-limited set of possible options (none of which result in happiness), then please, just go ahead and do so and just own it. Just don't whine about it, because that attitude (victimization via false self-perceived lack of agency and putting all blame on externalities) is toxic.
I am also big on testing (the correct things). And nine-nines (big on Elixir).
And... I'm also big on agent-assisted dev. Which requires pretty much every check in the book to stay productive in. And that's fine to me. I've seen bugs that I wouldn't have made myself. And I've also seen my own bugs fixed. They've all gotten fixed in short order. I don't see why this is a problem.
Raise your personal standards.
Thing is, the unreliable-software situation was already untenable before agents (in poor hands) made it worse.
reply