Ask HN: What will Software Engineering evolve to?
4 comments
Follow the money.
When software was first a thing: 50s-70s it was only about micro automation on giant mainframes. This was very inefficient, from a computing perspective, because computers were very expensive and not very powerful. They still paid for themselves many times over.
Then came the personal computer. In the 80s-90s desktop applications were the focus.
Then came the internet and now owning data at large data centers is the primary money maker since the later 90s. Data is king.
The data economy is on its way out. The LLMs are its last big attempt at inventing money, but it’s the tail end of an dying step in a larger cycle.
The thing that will replace the data economy is already here, but it’s not big business yet. It’s fragmented and still almost exclusively in the hands of hobbyists. But it’s rapidly growing in popularity and already denting the giant data economy without substantial revenue streams of its own.
What’s important to understand is that each of these big cycles aren’t just changes in technology. They are changes in consumption, which has consequences to adjacent economies. Media has, over the last 10 years, drifted into the data economy. So when the data economy is replaced by this next thing the media economy will also risk being replaced.
When software was first a thing: 50s-70s it was only about micro automation on giant mainframes. This was very inefficient, from a computing perspective, because computers were very expensive and not very powerful. They still paid for themselves many times over.
Then came the personal computer. In the 80s-90s desktop applications were the focus.
Then came the internet and now owning data at large data centers is the primary money maker since the later 90s. Data is king.
The data economy is on its way out. The LLMs are its last big attempt at inventing money, but it’s the tail end of an dying step in a larger cycle.
The thing that will replace the data economy is already here, but it’s not big business yet. It’s fragmented and still almost exclusively in the hands of hobbyists. But it’s rapidly growing in popularity and already denting the giant data economy without substantial revenue streams of its own.
What’s important to understand is that each of these big cycles aren’t just changes in technology. They are changes in consumption, which has consequences to adjacent economies. Media has, over the last 10 years, drifted into the data economy. So when the data economy is replaced by this next thing the media economy will also risk being replaced.
18 years in embedded. Yes to all three, with caveats.
1. The pattern is real. I write specs and prompts between meetings, agents deliver code by EOD. But deep focus blocks aren't dying, they're shifting from "writing code" to "thinking about architecture and verifying output."
2. Merging, yes. Decreasing value, no. The role is evolving from "person who writes code" to "person who defines what correct looks like." The engineers who thrive will be the ones who can do both — manage agents AND know when the output is wrong. That requires more expertise, not less.
3. Overfitted to Claude Code? Probably a bit. But the delegating to AI agents instead of typing code yourself is tool-agnostic. Cursor, Copilot, Claude Code, whatever comes next. The workflow shift is real regardless of which tool wins.
1. The pattern is real. I write specs and prompts between meetings, agents deliver code by EOD. But deep focus blocks aren't dying, they're shifting from "writing code" to "thinking about architecture and verifying output."
2. Merging, yes. Decreasing value, no. The role is evolving from "person who writes code" to "person who defines what correct looks like." The engineers who thrive will be the ones who can do both — manage agents AND know when the output is wrong. That requires more expertise, not less.
3. Overfitted to Claude Code? Probably a bit. But the delegating to AI agents instead of typing code yourself is tool-agnostic. Cursor, Copilot, Claude Code, whatever comes next. The workflow shift is real regardless of which tool wins.
First, this is the problem:
> ...now his advice it only get Claude Code and learn how to make it automate toil, and multiple claude agents to perform tasks instead of manually writing code.
Advice from creator of Claude Code is for you to continue to use Claude Code to spend more money on tokens instead of knowing what you are doing or what the code does.
I don't think that will help in the long run. In fact this over-reliance will help accelerate the decline in being able to find hard to reach bugs and will create a new class of bugs from AI agents.
> Do you also see this pattern emerging?
This helps experienced engineers and those who know what they are doing. For those who have no idea or have no experience then they tend to spend even more on tokens which is exactly what Anthropic needs you to keep doing.
> Do you think software engineering and managarial roles are slowly merging and the value traditional software engineering is decreasing?
They were already merging before LLMs, (managers that can code and SWEs that become managers) but that doesn't mean the value of traditional software engineering decreases. Software Engineering accounts for maintainance, security and time and usually producing more code to solve a problem just increases all of that and also the maintainance debt and the cognitive debt on the prompter.
The moment one needs to monetize that software, then software engineering becomes even more relevant (one feature can open another security issue) with or without LLMs.
> Are above advices overindexed on Claude Code, because Boris created it?
Possibly. But that does not mean it is good advice, especially from someone that is selling a product telling you to use it even more and you not looking at what it is doing.
It was said that Claude Code was Boris's side project that was built on a bad architecture and was difficult to maintain until the Bun developers were hired to fix those issues. Since they understood how the JS runtime works they knew how to fix those bugs when Claude got stuck, whilst also maintaining the Bun runtime.
The point is, it is still worth knowing what you are doing and learning about how it all works and not soley relying on a coding agent to do it all for you.
> ...now his advice it only get Claude Code and learn how to make it automate toil, and multiple claude agents to perform tasks instead of manually writing code.
Advice from creator of Claude Code is for you to continue to use Claude Code to spend more money on tokens instead of knowing what you are doing or what the code does.
I don't think that will help in the long run. In fact this over-reliance will help accelerate the decline in being able to find hard to reach bugs and will create a new class of bugs from AI agents.
> Do you also see this pattern emerging?
This helps experienced engineers and those who know what they are doing. For those who have no idea or have no experience then they tend to spend even more on tokens which is exactly what Anthropic needs you to keep doing.
> Do you think software engineering and managarial roles are slowly merging and the value traditional software engineering is decreasing?
They were already merging before LLMs, (managers that can code and SWEs that become managers) but that doesn't mean the value of traditional software engineering decreases. Software Engineering accounts for maintainance, security and time and usually producing more code to solve a problem just increases all of that and also the maintainance debt and the cognitive debt on the prompter.
The moment one needs to monetize that software, then software engineering becomes even more relevant (one feature can open another security issue) with or without LLMs.
> Are above advices overindexed on Claude Code, because Boris created it?
Possibly. But that does not mean it is good advice, especially from someone that is selling a product telling you to use it even more and you not looking at what it is doing.
It was said that Claude Code was Boris's side project that was built on a bad architecture and was difficult to maintain until the Bun developers were hired to fix those issues. Since they understood how the JS runtime works they knew how to fix those bugs when Claude got stuck, whilst also maintaining the Bun runtime.
The point is, it is still worth knowing what you are doing and learning about how it all works and not soley relying on a coding agent to do it all for you.
This is a natural pattern. Treat "coding is becoming accessible to everyone" as writing or reading has become accessible to everyone.
Coding was just a mechanism/tool developed to talk more efficiently to machines. We did it with binary, assembly etc once upon a time. Then it got easier and easier. Less people use the older mechanisms. But the tool was never the point of the story. Talking to the machine to get something done was the point of the story. Just like human language emerged to help move info from one 3 inch chimp brain into another so they could work together more smoothly.
At the end of the day the story is never about a specific tool like Software. It has always been about what problem the tool can be used to produce solutions.
Coding was just a mechanism/tool developed to talk more efficiently to machines. We did it with binary, assembly etc once upon a time. Then it got easier and easier. Less people use the older mechanisms. But the tool was never the point of the story. Talking to the machine to get something done was the point of the story. Just like human language emerged to help move info from one 3 inch chimp brain into another so they could work together more smoothly.
At the end of the day the story is never about a specific tool like Software. It has always been about what problem the tool can be used to produce solutions.
And there was an observation that the software enginering's maker's schedule is mutating towards a managerial type of schedule, where large focus blocks are being replaced with more context switching .
Boris mentioned that coding is becoming accesible to everyone, and gave an example of a manager that he works with, who now produces code several times every week, after 10 years without coding.
On the other hand, he did mention that he likes to code on the weekend due to its quiet time, ergo focus blocks.
I myself have also been noticed a personal trend where I tend to write prompt or plans to get my agents going in the interludes between meetings and chats, and eventually reach the end of the day with ready made code. I still require bouts of focus time to think hard about problems, but they seem to be slowly decreasing in amount of hours. Regardless, I dont think focus time blocks will go away for good.
My questions to you are:
- Do you also see this pattern emerging?
- Do you think software engineering and managarial roles are slowly merging and the value traditional software engineering is decreasing?
- Are above advices overindexed on Claude Code, because Boris created it?