←back to thread

358 points andrewstetsenko | 2 comments | | HN request time: 0s | source
Show context
hintymad ◴[] No.44362187[source]
Copying from another post. I’m very puzzled on why people don’t talk more about essential complexity of specifying systems any more:

In No Silver Bullet, Fred Brooks argues that the hard part of software engineering lies in essential complexity - understanding, specifying, and modeling the problem space - while accidental complexity like tool limitations is secondary. His point was that no tool or methodology would "magically" eliminate the difficulty of software development because the core challenge is conceptual, not syntactic. Fast forward to today: there's a lot of talk about AI agents replacing engineers by writing entire codebases from natural language prompts. But that seems to assume the specification problem is somehow solved or simplified. In reality, turning vague ideas into detailed, robust systems still feels like the core job of engineers.

If someone provides detailed specs and iteratively works with an AI to build software, aren’t they just using AI to eliminate accidental complexity—like how we moved from assembly to high-level languages? That doesn’t replace engineers; it boosts our productivity. If anything, it should increase opportunities by lowering the cost of iteration and scaling our impact.

So how do we reconcile this? If an agent writes a product from a prompt, that only works because someone else has already fully specified the system—implicitly or explicitly. And if we’re just using AI to replicate existing products, then we’re not solving technical problems anymore; we’re just competing on distribution or cost. That’s not an engineering disruption—it’s a business one.

What am I missing here?

replies(22): >>44362234 #>>44362259 #>>44362323 #>>44362411 #>>44362713 #>>44362779 #>>44362791 #>>44362811 #>>44363426 #>>44363487 #>>44363510 #>>44363707 #>>44363719 #>>44364280 #>>44364282 #>>44364296 #>>44364302 #>>44364456 #>>44365037 #>>44365998 #>>44368818 #>>44371963 #
foolswisdom ◴[] No.44362411[source]
People (especially people who don't have a lot of hands on tech experience, or students who also aren't into building things) get the sense that writing software requires learning a lot of arcane tools. And the idea is to promise that anyone who can write a specification should be able to make software (yes, handwaving away the learning to specify well, which is a real skill with many dependent skills). This was the promise of no-code, and then they realized that the no-code system (in addition to usually being limited in power) is actually complex and requires specialized learning, and more of that the more powerful the system is. The LLM will replace SWEs approach is another take on that, because you don't need to learn a system, you prompt in natural language, and the model knows how to interface with the underlying system so you don't have to. In that sense, vibe coding is already the culmination of this goal (despite weaknesses such as maintainability issues).

I've seen it written that the main reason managers tend to want to get rid of SWEs is because they don't understand how to interface with them. Using an LLM solves that problem, because you don't need a nerd to operate it.

replies(4): >>44362722 #>>44362965 #>>44363568 #>>44364404 #
1. drekipus ◴[] No.44362722[source]
Just use LLM to interface with nerds /s

Oh god please kill me

replies(1): >>44365185 #
2. junek ◴[] No.44365185[source]
Please step away from the lathe