Hacker News Reader

Comment by ldjkfkdsjnv | Hacker News Reader

Software engineering will be completely solved. Even systems like v0 are astounding in their ability to generate code, and are very primitive to whats coming. I get downvoted on HN for this opinion, but its truly going to happen. Any system that can produce code, test the code, and iterate if needed will eventually outperform humans. Add in the reinforcement learning, where they can run the code, and train the model when it gets code generation right, and we are on our way to a whole different world.

View on HN

"Coding" might be solved, but there is more to software engineering than just churning out code - i.e. what should we build? What are the requirements? Are they right? Whats the other dependencies we want to use - AWS or GCP for example? Why those and not others - whats the reason? How does this impact our users and how they use the system? What level of backwards/forwards compatibility do we want? How do we handle reliability? Failover? Backups? and so on and so on.

Some of these questions change slightly, since we might end up with "unlimited resources" (i.e. instead of having e.g. 5 engineers on a team who can only get X done per sprint, we effectively have near-limitless compute to use instead) so maybe the answer is "build everything on the wish-list in 1 day" to the "what should we prioritize" type questions?

Interesting times.

My gut is that software engineers will end up as glorified test engineers, coming up with test cases (even if not actually writing the code) and asking the AI to write code until it passes.

Testing in general is quickly being outmoded by formal verification. From my own gut, I see software engineering pivoting into consulting—wherein the deliverables are something akin to domain-specific languages that are tailored to a client's business needs.

Indeed, reasoning in the small and reasoning in the large are different skills. Architecture abstracts over code.

Generally the product decisions are not given to the engineers. But yeah, engineers will be tuning, prodding, and poking ai systems to generate the code to match the business requirements.

> Any system that can produce code, test the code, and iterate if needed

That isn't every problem in software engineering.

It is not that you get downvoted because they don’t understand you, it is because you sell your opinion as fact, like an apostle. For example what does it mean that software engineering is solved?

Check his profile.

> about: I believe in the creation of a machine god

Sounds about right.

I wonder if he’s a machine himself?

it's known idiom, it means: optimal algorithm is found; like in "tic tac toe is solved problem".

If I squint I can see some connection between Go (game) and (Software) Engineering (field).

Prophets are always beaten by average citizens, because prophecy is always unpleasant. It can't be otherwise. At the same time, you can't tell right away whether a person is really a prophet, because it becomes known much later. That's probably why beating them (the simplest solution) turns out to be the most observed.

> because prophecy is always unpleasant.

Not necessarily. 'Gospel' is translated as good news. The unpleasant news tends towards those within the power structure that the prophet challenges.

> it is because you sell your opinion as fact.

The guy's making a prediction. Classifying it as some kind of religious zealotry isn't fair to his point or him.

What about brownfield development though? What about vague requirements or cases with multiple potential paths or cases where some technical choices might have important business consequences that shareholders might need to know about? Can we please stop pretending that software engineering happens in a vacuum?

Isn't what you describe eventually just a context contraint problem?

The thing with vague requirements is that the real problem is that making decisions is hard. There are always tradeoffs and consequences. Rarely is there a truly clear and objective decision. In the end either you or the LLM are guessing what the best option is.

Yes, decisions are but they need to be made. Ideally shareholders will be given as much context so they can decide. This communication is as vital as having good programming skills imo. Your beautiful code means nothing if it does not adequately solve the business problem

> What about vague requirements or cases with multiple potential paths or cases where some technical choices might have important business consequences that shareholders might need to know about?

If the cost of developing the software is 0, you can just build both.

or you can build 20 different versions. Your non technical person won't be happy about this though. They wanted 1 software system not 20 nor 2. Just one

Everyone will just turn into a problem solver until there are no more problems.

lol

There's cope in the comments about possibility of some software adjacent jobs remaining, which is possible, but the idea of a large number of high paying software jobs remaining by 2030 is a fantasy. Time to learn to be a plumber.

Some huge percentage of all venture capital in the united states is moving towards solving this problem

Reply on news.ycombinator.com