I don’t disagree with any of that, but I think the brutal truth is that the priority of most businesses was always that approximate, slipshod, business-driven development. The human engineering process was only coincidentally a check back against the worst outcomes of that philosophy, not intentionally one.

I certainly think that is true of the current moment, but where I think this is going is towards a model where the cost of human labor collapses, feature delivery slows (relative to the churn that is happening now), but becomes more predictable and less error prone (in terms of final delivery). I think that is the model that we see in manufacturing, and I think it's probably going to replicate in software engineering. New code (that a human didn't even look at, tbh) will be stress tested for correctness, progressively introduced and final delivery will be easy to forecast and most of the time will be delivered on time.

Yeah but all these firms are going to get destroyed by firms led by people who are more disciplined and enforce rigour in thought etc that’ll be pushed through discouraging over-use of llm’s.

Apple didn’t go from near bankrupt to where it is today without that discipline.

> more disciplined and enforce rigour

Eventually this will be automated as well. Discipline, rigor and correctness are not strictly human tasks.

We can hope. The markets are rarely rational to begin with and we live in a time where the biggest measuring stick for most companies is "what have you done in the last 3 months". There's not a lot of pressure on companies in today's marketplace to do the right thing over the "right now" thing or the fast broken thing or the dumb thing.

I don't know if it really plays out like that, though I hope so. Many businesses are mega successful in spite of incredibly poor or inefficient technical execution. I don't know if it really matters so long as customers get the thing they want for the price they're willing to pay.

I think this matters even less in higher tech companies, because they're not playing in the margins where an inefficiency can hurt. Though perhaps ironically, I think AI providers really are in a realm where technical execution at the margins will make or break them.

I agree as well. And now they can make slipshod products at 10x speed.

> We're in a cesspit of business driven development

In a business-driven world with business-driven governments writing business-driven rules, what's the alternative if you want to optimize for success?

Do slower and more considered business-driven development?

> We're in a cesspit of business driven development

It's not just businesses doing it either, I regularly see big PRs get merged on open source projects that seem fine on the surface but contain a 1000 paper cuts worth of bugs (not critical, but just enough to annoy you)

On top of that, the code wasn't idiomatic C++ (for this specific project) and the LLM completely ignored available APIs. Sure, it can be fixed, and maintainers should've caught it, but the amount of code being generated requires so much energy on everyone's behalf.

> too fast

Another aspect is that it reorders some of our problems.

In typical development, we're more likely to go back and forth about "is this really what we want to make" or "what could possibly go wrong if we do that", and ideally we do it before PR's get approved or anything is merged/deployed. Some portion of that is getting moved to "we'll see if anyone complains later". As they say, an ounce of prevention is worth a pound of cure.

Skill loss is real. BUT, I have been complaining about skill loss to my bosses for literally a decade. So AI is just one problem for me. I was coding less and less every year for some reason.

I'm not sure skill loss is such a huge issue, in other words. It might just be a sign that the nature of our work if shifting. Being able to recite the C++ standard and using all the 100s of features correctly will just not be as highly regarded as knowing good architecture instead?

There is an inescapable connection between the two. Knowing that stuff is not _equivalent_ to knowing good architecture, but it's hard to imagine what knowing good architecture would look like without being able to "think in code" through quite a few relatively narrow implementation details. Without that, you won't know the shape of the problem and how to architect around it.

Bingo. All the clamor for more speed is driving erosion in the biggest asset class for most of the companies adopting these "accelerant tools": knowledge.

Everybody cargo culting winner takes all VC plays is gonna deprive everyone involved from building the knowledge assets they need to compete while playing into the hands of the winner takes all VC plays providing the tools driving all of this.

Seems clever from the point of view of the soon-to-IPO vendors behind these tools, and also seems extremely naive of all the people, teams and orgs buying into this ecosystems.

My current play is to do deep dives into fundamentals and stealth a team of like minded people to start putting out packaged expertise to help escape this quagmire.

Author of the article here (had no idea someone shared it! Just found out through analytics).

I actually mention this exact thing it the article under the section "LLMs accelerate the wrong parts", which seems to be saying exactly what you're saying:

https://larsfaye.com/articles/agentic-coding-is-a-trap#llms-...

I would find it hard to believe there is any developer in history ever uttered the words:

"I really wish I had a tool that could generate code I don't understand, and at a rate faster than I can review".

I know what that feels like having been a manager of a team of coders who were generating code faster than I could fully understand and review. I imagine how much worse that would be with Agentic coders.