Thread

Software Engineering Is Dead. Long Live Product Engineering

26 points · 13 comments · cliffclimber

Loading the complete thread in the background. This saved snapshot is available now. Refresh

pmarreck · 1791139700 · focus · HN ↗
Which is why I began a software project a year ago that was only possible with AI.
I'm hoping the year lead time is profitable, once I release it (soon!), but we'll see.
betteryet · 1791139757 · focus · HN ↗
Software Engineering is not dead, damn it. Anything research and original is not dead. Are these things fantastic at connecting concepts, producing digital work products, and putting out hypotheses? Sure. But proper original thought is still firmly in the realm of humans. Though speed of propagation of new ideas probably did change massively.
1. flowerlad · 1791140111 · focus · HN ↗
  > Anything research and original is not dead.
  Even if are right here (and I think you are), software engineering can still be dead.
2. almogo · 1791140125 · focus · HN ↗
  In a way, many “novel” ideas are mathematical restructurings of existing ideas. I think we’ve seen a fair number of examples by now, especially in the realm of mathematics, of LLMs producing these novel ideas. I’d imagine Lee Se-dol would agree.
  1. flowerlad · 1791140310 · focus · HN ↗
    > LLMs producing these novel ideas
    We haven't seen that in software development though. Chris Lattner, inventor of the Swift programming language recently took a look at a compiler entirely written by Claude AI. Lattner found nothing innovative in the code generated by AI [1]. And this is why humans will be needed to advance the state of the art.
    [1] <a href="https://www.modular.com/blog/the-claude-c-compiler-what-it-reveals-about-the-future-of-software" rel="nofollow">https://www.modular.com/blog/the-claude-c-compiler-what-it-r...
    bewareofscams · 1791140675 · focus · HN ↗
    [dead]
    ranger_danger · 1791140879 · focus · HN ↗
    Was said Claude AI prompted to even attempt to look for anything "innovative" or just make more of the same? The same can be said of humans if one isn't already intentionally trying to do something different.
    almogo · 1791142094 · focus · HN ↗
    That is a useful data point. I think there’s interesting points in both directions, but probably what’s the most important is that it’s a field of humans have been researching and optimizing very heavily for a while. Whatever fruits there are to reap our probably quite difficult to find.
3. ranger_danger · 1791140768 · focus · HN ↗
  > But proper original thought is still firmly in the realm of humans
  Copying isn't just how design works, it's how everything works. Humans are imitation machines.
  We create new things by collecting, regurgitating and mutating stuff we experience, just like LLMs. In a vacuum man has no ideas outside of base impulses.
  Hence why originality is a novice belief. The closer you get to any field, the more you realize the stories around who made all the breakthroughs are BS media narratives. Most if not all steps forward in any field have hundreds of people clawing at similar ideas concurrently.
4. catunionist · 1791169359 · focus · HN ↗
  Software engineering isn't dead, but it's provocative to say it is.
yourapostasy · 1791139974 · focus · HN ↗
[delayed]
chasd00 · 1791140222 · focus · HN ↗
The line between Computer Science and Software Engineering is pretty blurry and the term "Software Engineering" has been controversial from the get go. Bolting together established enterprise patterns may be dead but creative problem solving with automation and the science of computers surely is not.
j45 · 1791140244 · focus · HN ↗
Software development evolves. Every decade. Or faster. Always has, and always will.
gosugdr · 1791140348 · focus · HN ↗
[dead]
trentnix · 1791140623 · focus · HN ↗
It’s not dead, but it’s starting to feel nostalgic. There will always be a few (of us) who still read the code, like the old school “operator” from The Matrix. And maybe the software geeks that still read code will be better for it, but that will eventually be just at the boundaries.
lordnacho · 1791144484 · focus · HN ↗
I think for most things by far, product is king. If you're in a deep tech space, then no. Perhaps if you're making rockets, or compilers. But most other things become "make some engineering judgements about what we need to build, based on what the business side is asking for".
Now, it was already like that to an extent. To be crude, the job was "decide what needs to be made, and make it". People would be on various splits between the two, typically on the "make it" end if they were junior.
Initially, I thought about what effect this would have on hiring. Perhaps we would get a lot more people who were not so great at implementation, since we are hiring for judgement?
Let's consider Berkson's paradox.
Let's say that there's a correlation between implementation skill and engineering judgement, eg r=0.5, a rugby-ball shaped cloud that points up and to the right. The basis for this being that you maybe learn good judgement from implementing things, something like that.
Before AI, selection on the sum scores (judgement + implementation) would give you a set of engineers whose correlation was deflated from the underlying correlation. It could even go negative (in fact it would if the underlying correlation was zero, but we assumed it was positive). This is the original Berkson's paradox, selection makes the correlation coefficient lower. There would be less of a connection between someone's (who had been hired) judgement and implementation skill than 0.5, it would tend downwards, possibly landing at zero.
Now, let us imagine that AI means the implementation side becomes less important. We will veer towards hiring people based on engineering judgement, rather than coding skill. Suppose we add a parameter on (judgement + lambda * implementation).
What actually happens is, if lambda tends towards zero, we are selecting on a line that is only judgement. But that means actually, the deflating effect of the selection is lowered, and we get a correlation between our variables that is closer to the underlying set (it won't necessarily be all the way back, since we restrict the range).
So then actually, somehow, people we hire who are good at judgement will also be good at implementation. Somewhat unexpected.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.