Originally I felt that there was going to be a reinvention of the wheel, until I saw the "shape" of software development changing, and the tooling needing to support the new flexibilities in positions and process.

Software development is not as much de-risking at the front like it used to be before building.

Now teams can build lots of stuff that works great, except it's the wrong things.

Most things are becoming the understand the problem "shape".

Understanding the shape of the problem isn't something LLMs can always make as.. svelte as early on.

Word generators gotta generate..

▲

skydhash 3 hours ago | parent [-]

> Now teams can build lots of stuff that works great, except it's the wrong things.

That used to be called "time wasting". If you want to build software that will be used, you need to interview the users. Maybe a few things does require research to nail things right. But most software are user-facing, the research side is about optimization.

> Most things are becoming the understand the problem "shape".

Then should we be so reluctant about "trialing" invented solutions. It's the same thing with most AI projects, they're trying to justify the project after the facts while being very reluctant to get user insights.

▲

willchis an hour ago | parent | next [-]

We're trending towards just building the thing fast and getting feedback sooner on it. It's interesting to see end users actually trial a UI very early on instead of just being shown designs.

	▲	j45 2 minutes ago \| parent [-]
		In addition to that, solving for every approach to a problem to see what wins is also very interesting. The key, still, is shipping far less, too soon, to minimize cruft.

▲

j45 2 hours ago | parent | prev [-]

Time wasting is a definite concern - especially when vibe coding doesn't see the impeding brick wall(s) it's about to hit.

Vibe coding can be kind of a new type of cowboy coding. It could can be harnessed productively if done mindfully.

Interviewing users is critical, more importantly solving problems worth that people are lining up to pay to have solved before writing a line of code is critical.

Trialing solutions is always worth learning from, I usually ask about the problem that lead to building it. Sometimes that can be too narrow or vague of a story and you can learn how much of it is a solution looking for a problem, or vice versa.