upvote
Sounds like exponential growth of crappy software. I'm not saying that before we didn't have mass produced crap in SE, but now it will turn into explosive overflow.
reply
We are living in a ZIRP-like era where builders at the fastest pace layer have misattributed their velocity to exponential gains in model capability. In fact, they are surfing on decades of careful effort to build a robust foundation of highly reusable software libraries.

This strategy will seem to work really well until the economy that enabled that foundation to form is hollowed out. Then, there will be a reckoning (but we will have no choice but to march forth from there).

reply
It's not just software libraries. Specs, applications (the browser!), expectations, device integrations, operating systems, etc. So much that starting from scratch seems impossible.

I'm not agreeing or disagreeing with you, but my brain cannot comprehend how machines can advance such interconnected systems while keeping humans in focus.

Perhaps I shouldn't have watched the Animatrix again.

reply
"but we will have no choice but to march forth from there".

If you haven't seen it, I think you would appreciate the film Margin Call.

reply
> This strategy will seem to work really well until the economy that enabled that foundation to form is hollowed out. Then, there will be a reckoning (but we will have no choice but to march forth from there).

There will only be a reckoning if models don't get much better.

If they do get much better you can just have them refactor, fix bugs in, or replace the existing codebase.

The concept of tech debt is sort of meaningless if you anticipate intelligence gains in models to continue.

reply
This is a great point. LLMs can't speed up human decision processes and alignment.
reply
"exponential growth of crappy X" applies to every industry that went from being an artisanal craft to being mass produced with little or no human input. and we live much better lives than we did before the industrial revolution.
reply
I think some industries have notably high quality output. Automobiles, aerospace for example.
reply
most industries have high cost of entrance unlike software, so decision makers are way more careful on how to move forward.

In software + GenAI now every housewife can build some App over evening.

reply
You could say the same when higher level languages getting popular. Previously programming was the domain of Math, Physics, EE doctorates. These days we even have a few months coding bootcamp
reply
I still can't tell from the outside whether it sounds like a great time to be in security because of the vulnerable slop being churned out, or a terrible time because the people paying to make it don't care.
reply
Crap is fine if it gets the job done. I think software as an industry will change to more ephemeral construction.
reply
Paper plates of software development.
reply
I am more and more inclined into not believing this crappy software theory.

Especially as teams invest in proper agentic harnessing.

We have had a champion in our team that has invested a lot of time into it over the last 4 months, and if anything, quality has improved, not decreased. Architecture is more coherent, codebase has been cleaned up, agents find information quickly, code produced is very solid and my role is more and more checking that the output meets the requirements. But I cannot confidently say that I would've done a better job than AI more often than not I have to admit it does a better job than mine.

The mistakes are less and less technical and merely in the domain mapping. And AI is still not creative as I am for finding solutions quickly to unlock stakeholders' issues. Also, AI is still not creative as I am for finding the proper solutions for advanced technical problems. But it does a better job than me, even on that front, one shotting few solutions in a fraction of a time it would've taken me to test one idea myself.

Mind you, I don't like AI and I think it ruined the job, I don't like working this way, it's exhausting, way more work on one side, way less fun and fiddling with technical parts.

And yet, I have the genuine belief that few years from now we'll be cloning open source repositories that are already optimized/harnessed and tested for agentic loops and best practices left and right with software engineers mostly overseeing the domain translation and putting their 2 cents on the non-boilerplatey parts of the product (which, in general, are a small part of the surface).

I think that the next years of my career will be mostly spent in setting up and writing the harnessing and domain mapping part. Then I will move to another sector, not because I necessarily believe I won't have a job, but because I want to vomit thinking that's going to be my job.

reply
It makes no sense. I mean, T2 covered this:

"Watching John with the machine, it was suddenly so clear. The terminator would never stop. It would never leave him, and it would never hurt him, never shout at him, or get drunk and hit him, or say it was too busy to spend time with him. It would always be there. And it would die to protect him. Of all the would-be fathers who came and went over the years, this thing, this machine, was the only one who measured up. In an insane world, it was the sanest choice."

As long as you've indicated what you want, the machine will try to do what you ask of it. It won't get tired because "the codebase is too big", or it has gotten bored of the pattern, or it wants to introduce a new technology.

It just does the thing you asked of it. (note, that yes, I get that as a codebase size increases, it might make it more difficult to fit into context, but that only applies if it needs to read a large percentage of the project to implement the task, which shouldn't be the case.

reply
I'm confused, what does not make sense?
reply
> We have had a champion in our team

there are good actors, which are empowered by AI to produce positive impact, but often there are N times more bad actors, which push crappy code to close feature requests fast, increase performance LoC-like metrics, etc.

reply
Anyone remember the old days when a new frontend framework came out every 3 months. That has pretty much stopped. No one cares anymore.
reply
Oh you wait until LLMs come up with frameworks that allow multiple LLMs to collaborate effectively. Then you’ll have new frameworks every 3 days.
reply
> when a new frontend framework came out every 3 months.

> No one cares anymore.

I never cared about this.

I think this captures something that I've been searching for the words for. (Maybe I should have gotten an LLM to write the words for me.) Some of the biggest AI boosters are the kind of dev that would have cared about the new frameworks of the last 3 months. They had a "the framework does all the thinking for me" attitude already, so it is easy for AI to slot into that.

reply
New front end frameworks came out every 3 months, but realistically no one was using anything that wasn't made by Facebook, Google, or Evan You.
reply
It’s even discouraged now as LLMs wouldn’t have the documentation built in
reply
But I think the eventual goal is that documentations won't even be needed. LLM should just itself understand the nuances of frameworks by analyzing their codebase.
reply
That's because I roll my own frontend framework for each project and every week for existing projects /s
reply
> We are going to get near instant software from prompt, multiple ones and then choose the best one.

If you extract the spec from first implementation and reimplement from scratch you get a free testing oracle. Where they diverge you send the agent to decide which one had a bug.

reply
The exponential is leading to full compute-in-memory within a few years which will be 100 times more efficient. Which means at least 10 times larger models that are much smarter in addition to extremely fast.

It's going to skip the code entirely for small businesses and just render UIs straight from context data and prompts at interactive speeds. Kind of like Google's Genie does with games but much more accurately.

reply
I'm not sure. Engineers could still develop software the old way, you know taking months to deliver something like, let's say, Obsidian? Or Ghostty? Taking care of every single line of code, of dependencies, of good architecture. Truly the old way. And if the product is good it will succeed.
reply
> And if the product is good it will succeed.

it needs to win marketing landscape, hyper-overcrowded by thousands of competitors, slop-gened over weekend.

reply
Could you imagine Obsidian being posted on HN today, if it weren't really popular already? There's no way a tiny team working on a note taking program would make it out of new, no matter how good it was. I wouldn't click the link, myself.
reply
> Discussions about choosing a library with the best syntactic sugar method naming is just as crazy as suggesting we type in assembly.

I have a more hopeful take. As AIs improve and get faster we can more quickly and iteratively improve code which we may have historically avoided due to the work involved.

I know i've made several refactors that would have otherwise been insane lifts. Not only because the work involved but because sometimes you don't know if it will work, and so you have a sort of double friction; you don't know if it will even succeed. With an AI you can just throw it at the refactor to see if it runs into a problem all while you're having a coffee break or w/e.

In general AI is going to enable humanity to be more extreme versions of itself. For good and bad. I suspect more bad than good, though.

reply
Our bottleneck is going to be verification.
reply
And they will all suck! I can't wait.
reply
And how are you going to determine which is the best? Going through all the possible combinations of users and usage? So mostly it shifts the work from generation to validation.
reply
The models might be so fast that they can autocomplete your prompt before you even finish it, and generate dozens of possible applications before you're even done asking.
reply
You won't. Because 80% of the complexity is just "knowing what to build". You will get something that gives you a prototype in 1 min, then you break it, then you get a slightly better prototype one one side, but newly broken in another way, and you're going to repeat over and over.
reply
And for any non-trivial application, the space of possibilities grows so quick that you'll never even be able to _touch_ all the moving parts of the application and verify them.
reply