←back to thread

358 points andrewstetsenko | 1 comments | | HN request time: 0.657s | 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 #
lubujackson ◴[] No.44362323[source]
What you are saying is true. In a way, programmers still need to think about and wrestle with architectural complexity. And I agree the biggest overall gain is adding another layer of abstraction. But combine those two things and suddenly you have junior engineers that can very quickly learn how to architect systems. Because that will be the bulk of the job and they will be doing it every day.

Once you remove all the roadblocks with syntax and language blindspots, the high cost of refactoring, the tedium of adding validation and tests, the challenges of integrating systems... suddenly, the work becomes more pure. Yes, you need to know how to do advanced structural things. But you don't need to learn very much about all the rest of it.

And we very quickly get to a point where someone who can break down problems into tidy Jira tickets is effectively programming. Programming was never really about learning languages but making computers do things, which is a transferrable skill and why so many engineers know so many languages.

replies(1): >>44362747 #
1. andoando ◴[] No.44362747[source]
I think were still far from Jira -> tickets.

Even the simplest tickets sometimes that end up requiring a one line change can require hours of investigation to fully understand/stamp the effects of that change.

And perhaps I havent used the greatest or latest, but in my experience LLMs break down hard st anything sufficiently large. They make changes and introduce new errors, they end up changing the feature, or worst case just ouright break everything.

Id never trust it unless you have an extensive amount of good tests for validation