[jake-coworker]

I generally agree - I think anyone who's seriously experimented with agentic coding has encountered both:

1 - Surprising success when an agent can build on top of established patterns & abstractions

2 - A deep hole of "make it work" when an LLM digs a whole it can't get out of, and fails to anticipate edge cases/discover hidden behavior.

The same things that make it easier for humans to contribute code make it easier for LLMs to contribute code.

[bmitc]

Basically, nothing has changed except the increase in noise. So all the suits who refuse to understand what software is have yet again decided to make things worse for professionals and for people who actually know what they're doing.

[lopsotronic]

The departments / roles that LLMs most deeply need to be pointed at - business development, contracts, requirements, procurement - are the places least likely get augmented, due to how technology decisions are made structurally, socially.

I've already heard - many times - that the place that needs the LLMs isn't really inside the code. It's the requirements.

History has a ton of examples of a new technology that gets pushed, but doesn't displace the culture of the makers & shakers. Even though it is more than capable of doing so and indeed probably should.

[Garlef]

Not sure: The LLMs seem to be okay at coding recently but still horrible at requirements and interface design. They never seem to get the perspective right.

One example I recently encountered: The LLM designed the client/consumer facing API from the perspective of how it's stored.

The result was a collection of CRUD services for tables in a SQL db rather than something that explained the intended use.

Good for storage, bad for building on it.

[Teever]

Can you expand on what you think software is in this context?

Why do you think taht the suits refuse to understand what it is?

[bmitc]

Although I appreciate the question, I don't necessarily want to get into the discussion about what software is here. This is mainly due to the lack of time I currently have.

As an elaboration, software seems to be this thing that everyone thinks they know about. This is extremely common in my experience in that scientists (particularly physicists and engineering-based scientists), hardware engineers, "the suits", as it were, and more think that code is just this dumb, simple thing that you slap on top of things like algorithms, hardware, feature requests, etc. They continually fail to realize that the overhead and interruptions that happen when software is onboarded is entirely because it is software engineers that understand how to design and think about systems and that it's the software engineers who end up discovering that no one has done requirements gathering, performed holistic systems thinking, understood edge cases, thought about user workflows, etc. This is even though that they think this work is already "done" and "just needs software" now.

I'm still struggling to understand why this is the case for software.

So my point was that everyone who isn't a software engineer has this opinion that it's going to automate the software engineer away, and yet, they have failed to _actually ask the professionals in this domain_ as to what they think. The decision has been made because, again, software is just this thing that is the last mile for things that have already been thought about and are "done". They think that automating software will get rid of the pesky software engineer who gets in the way between the thing that's "done" and this last mile being completed.

[rvz]

To the "suits" AI means "efficiency".

Efficiency also means to them, "less costs" and when they talk about "costs" they mean "headcount" which that is employees.

Put it together and the suits want to reduce headcount using AI.

To them, "clean code" is a scam and a waste of time that doesn't yield them quick returns, but a weak reason for software engineers to justifying their roles.