You can’t abstract away the need to capture requirements in a symbolic language. It doesn’t matter which programming or formal language you choose to specify your requirements in, but it cannot be natural language.
When people install npm packages, they typically only install ones the community trusts. These packages have clear APIs, open source, good docs, test coverage, security checks, and, importantly, usually no undocumented side effects.
Engineers introduce these packages into their own projects that have far fewer of the above guarantees than OSS, are built under pressure from deadlines, and have a constantly churning set of maintainers.
I think from the perspective of a business its own code does call for greater scrutiny than its dependencies.
> It's your job to explain to them the consequences of shipping code faster than the people whose job it is to understand it can do so.
The problem we’re collectively running into is that nobody knows if this actually poses a problem anymore. We’ll find out in 5-10 years, but businesses and clients can’t wait that long.
As a side note, I don’t think it’s fair to blame the “management” for setting expectations around AI use. They’re driven by market forces. If competitors are producing slop and customers are gobbling it up, then from a business perspective it _is_ a mistake to abstain from AI use.
What I’m finding quite fascinating is that we’re in a weird spot right now where we’re both expected to produce slop AND understand it / be responsible for it. Seems unreasonable.
I think the most important takeaway is that it takes time for these problems to manifest. If you start with a particularly coherent codebase it will take years for slop code to degrade it to a point where engineers are noticeably less productive.
I didn't downvote you, but if I had to guess why you were downvoted it's because it's very obvious to many working software engineers that decoherence is a real problem. In many ways that's what this OP was all about; not just loss of joy in programming for its own sake but loss of the ability to design deterministic, fully-understood systems that won't require constant off-the-books maintenance eating into your free time.
Time. The limit is time. With or without agents there’s an X number of lines of code my brain can digest per work day. But rate of production of code is effectively unlimited or heavily influenced by people who let go of at least some percentage of understanding. This forces the rest of the team to also let go to keep up. Without guardrails around the rate of code production, _teams_ tend toward 0% code understanding. Individuals working on solo projects or in tiny teams that can enforce social contracts are not affected.
Proponents of LLM coding agents would claim you don’t need reproducibility. As long as the final output passes tests/lint, it’s (allegedly) good to go.
Trying to turn it around by once again claiming that ai is an existential threat and will take everyone’s job right before brutally murdering every human.
These companies don’t appear to give a single fuck about public perception. Only their investors and the government (in anticipation of the biggest bailout in human history).
> I've found I can produce 10x more code than I could otherwise, of lower quality than I would otherwise, but the speedup is worth it.
The speedup of slop production being “worth it” is what we, as a society, are having trouble evaluating at this point in time. In all likelihood it’s worth it only in the short term.
And yet those companies aren't collapsing because it became easier to rewrite their software, but because llms themselves have replaced a core part of their business (such as translation or simple art).
Seems like so far the market is not convinced at all that SaaS companies as a whole are any more disruptable than before.
That and talking to a lot of users, Duolingo reduced the quality of their service moving to LLM generated content -- a lot of people moved to other apps.
reply