[quotemstr]

The thing about talking to computers is less the formality and more the specificity. People don't know what they want. To use an LLM effectively, you need to think about what you want with enough clarity to ask for it and check that you're getting it. That LLMs accept your wishes in the form of natural language instead of something with a LALR(1) grammar doesn't magically obviate the need for specificity and clarity in communication.

[bananaflag]

Agree that one needs clarity, but how does that differ from my example with the manager and the engineer? The manager also (ideally) learns in time that, when they are more clear, the engineer does the work better.

[elasticeel]

Do they though? Our do they learn that having a good engineer means they can assign ambiguous tasks and the software developer can reason through good decision making and follow up with clarifying questions.

LLMs need to get better at asking clarifying questions and trying to show the initial solution might not work. Even when they get better at that, this article states that managers not capable of thinking through the answers well enough will fall short and this is the space that developers live in.

[skydhash]

TLDR: Clarity in software engineering means detailing all the constraints, which no user (apart from lawyers and engineers) usually do, as the real world has constraints that software does not.

The hardware offers so little guarantees that the whole OS job is to offer that. All layers are formal, but usefulness doesn't comes from that. Usefulness comes from a consistent models that embodies a domain. So you have the hardware that has capabilities but no model. Then you add the OS's kernel that will impose a model on the hardware, then you have the system libraries that will further restrict it to a certain domains. Then you have the general libraries that are more useful because they present another perspective. And then you have the application that use this last model according to a certain need.

A good example is that you go from the sound card to the sound subsystem, the the alsa libraries, to pipewire, to an audio player or a media framework like the one in the browser. This particular tower has dozens of engineers that has contributed to it, and most developers only deal with the last layers, but the lesson is that the perspective of a user differs from the building blocks that we have in hand. Software engineering is to reconcile the twos.

So people may know how the things should look or behave on their hand, but they have no idea on what the building blocks on the other hand. It's all abstract. The only thing real is the hardware and the energy powering it. Everything else needs to be specified with code. And in that world that forms the middle layer, there's a lot of rules to follow to make something good, but laws that prevent something bad are little. It's not like physical engineering where there are things you just cannot do.

Just like on a canvas you can draw anything as long as it's inside the boundary of the canvas, you can do anything in software as long as it's inside the boundary of the hardware. OS in personal computers adds a little more restrictions, but it's not a lot. It's basically fantasia in there.

[medi8r]

There are a lot of people who can't program but can do specifity. Researchers and lawyers for a start. It does widen the pool and there might be suprising people who never coded who can now build. Maybe people previosuly dismissed as not academic or "blue collar".

Paradoxically this may mean there are more jobs for programmer and programmer-likes alike as new cottage industries are born. AI for dentists is coming.