LLMs reward expertise

Maybe LLMs don't usher in the end of software engineering but they definitely end the whole "made with love (and coffee) in X". Nobody cares if you put effort into something software related. "Does it work? Yes? Ok build the next thing." Its the same with the notion of "taste" (see "sometimes tasteless computer code" from the Goedecke article), your colleague who is also a SE might respect your choices as good taste. But it ends there. This was also the case pre-LLMs I would argue. What is worse now is that communicating any uncertainty in decisions related to implementation will result in an immediate "Have you asked Claude?".

I’ve been curious on how to close this loop between engineering and design/product.

We don’t use react, which Claude design seems to trend towards. We use Phoenix / liveview.

We have a shared design system, which keeps the visual elements in line. And then just prototype on design, collab, discuss and arrive at what we want to ship. And then engineering take over and rebuild via hand / claude code.

But the tools aren’t directly connected.

The value has been in the separation. In iterating on the prototype without impacting the codebase, dev cycle, etc. And solving problems/unknowns earlier.

There were always tools for this, but Claude design just feels more accessible and therefore gets used more immediately.

And the fidelity of the outcome (and the assumptions it’s forced the make) are more valuable and faster to achieve than Figma.

Both the article and some of the discussions here share a lot of commonalities with doctors taking a medical history. There is a certain skill in guiding the conversation towards useful outputs, while not dictating the exact outputs to a patient who is eager to please with their responses.

E.g., medical history taking protocol always says to start with open ended (albeit structured) questions, and converge towards more closed/specific ones when you're sure you've extracted the broader surface and you now want to close in on a differential diagnosis.

If you start open and go with the flow but then just let the patient talk without any structure or subsequent attempt to converge, there's a risk that the patient might spend 60 minutes taking about their fluffy dog at home, which wastes time, and doesn't get you anywhere nearer the diagnosis. But, if you skip the open questions and go straight to yes/no diagnostic questions, you will definitely miss the fact that they have a dog at home that they're worried about, and that they'll be self-discharging against medical advice in the next hour to go tend to their dog.

So while to an outsider, the conversation might look effortless, in reality the doctor requires considerable skill to be able to strike a balance between open vs closed prompts, as well as the ability to critically sift through the outputs, and decide which outputs are relevant to pursue further and lead to a fruitful direction, versus those that can be safely discarded to remove potentially distracting noise from the conversation (and all while attempting to keep this interaction within a limited number of prompts due to operational time constraints).

This is true today and has been my experience as well -- both to write software as well as doing computational physics.

The interesting question then is to ask how long will this stay true? As the models get better will they eventually not need the human expertise to start adding value?

Curiosity and a tinkerer's / engineer's mindset is basically the only thing we can hire for right now