Ask HN: Coding is a solved problem. What is left for experienced engineers?
A person who does not know how software works will still struggle. They may not know what to ask, what is wrong, or how to tell whether the result is good.
But for a decent engineer who has already built real systems, I think the situation is very different. They can move across domains, ask the right questions, inspect what the agent is doing, and keep pushing until the system works.
They may take more steps than a senior engineer who already knows that domain well, but I do not think that gap is very large anymore. The important part seems to be knowing what to ask, what to check, and what you are actually trying to build.
I have been an engineer for years. At this point, I do not see much value in sitting alone and building more projects just to prove that I can build software.
That has also changed how I look at the past eight months. I spent that time building, learning, and trying to get better. Looking back now, much of it feels like time spent getting better at a problem that has already been solved.
And so I have come to a harsher conclusion: I wasted a lot of that time. What I have done feels bad, and I do not see what is left for me to do in this direction.
Maybe I am completely wrong. If I am, please feel free to roast this argument. I would genuinely like to know where the reasoning breaks.
46 comments
[ 3.1 ms ] story [ 65.6 ms ] thread> And so I have come to a harsher conclusion: I wasted a lot of that time. What I have done feels bad, and I do not see what is left for me to do in this direction.
Unless you didn't actually build, learn and improve, how could it have been a waste?
Do you really not value becoming a more capable person, in and of itself?
For problems with a closed feedback loop, I don’t think you need to spend nearly as much time learning every implementation detail. A person who never invested that time can often produce the same result with the right tools. That’s the part I’m struggling with.
1. Understanding user requirements/pain points is very important and many get it wrong.
2. Doing the architecture of the system within the org env/cloud/infra is often wrong by LLMs (for now).
3. Debugging when things go wrong. What to log, how to log it, and how to ensure not logging much or logging sensitive data.
4. Guide junior engineers, so they are not just accepting what LLMs are spiting.
On point 2, yes, again, there is a bit of friction. I would divide this into two cases based on what I have seen. Let’s say you don’t know coding and you are building a product for a decent number of users. Most people who don’t know coding get things wrong. I have seen that. But I have also observed that if they had asked better questions, much better questions, they would have gotten most things right.
The other case is when you are dealing with a large enterprise. That is a different game altogether, but not everyone faces that kind of problem.
Point 3 is completely solved. Most companies have integrated agents into the development cycle itself. If something goes wrong, you review it and merge it. The only bottleneck is when it is connected to external factors.
Point 4: an environment with proper `SKILLS.md` and `AGENTS.md` files writes better code than most senior engineers . Trust me, I am not even lying here.
Comment activity and contents, you are clearly unemployed troll
I hate people like you so much
We need a war to clear the underbrush desperately
I curse you
From what I can tell we ain't actually there yet. We will be sure, but at this point in time my human perspective and input is everything that keeps my stuff from going generic.
And also for maintaining you'd still need a skilled engineer to avoid the AI taking stupid decisions.
I know it's only a question of time tho
did you see value in doing this, before LLMs? if so, why?
All decent goals for good engineers.
On the data and interface side, build out better free teenage friendly accurate planetary dashboards showing mineral and energy resources, usage, trade, etc.
But define “proficient” here. What does that really mean in this context? A junior engineer, sure, you can tell they’re fucked for now, but for how long does that matter if the models keep getting better?
Only a small number of people will get the chance to work at that level as the field changes. I think there will be a radical shift from here.
Altman and Dario know this well. That is probably why the tone has changed from “engineering will disappear” to “engineering will change.” But I think we have already reached the inflection point where a large part of the work is getting automated.
Craftsmanship has already started moving somewhere else. Where exactly it moves depends on the kind of work, and I do not think everyone will figure out what the new end goal is.
I don't know the future and can't say if you're wrong or right. But I do wonder what "more code, faster" is meant to address exactly.
In my point of view, it depends how you describe your role. If you're a "coder" then yes, you can't compete with machines. I do have to tell you that we're in a bubble and probably in the shrinking phase of an economic cycle so it's all difficult now but you can't predict the future from this temporary phase.
And this is a problem which we all share. Because prices are so outrageous, we have to do heavy computations with limited memory and storage while maintaining privacy. So there's a lot to do here with software, including creating easy to use and verify privacy-enforcing computing environments for specific purposes, and writing computational software which is more efficient so that we are not beholden to "cloud providers". Talk to folks in offices unrelated to tech. There is a lot of stuff you can be doing for them.
But my belief is that experienced engineers would be needed for their judgement and ability to steer and verify the LLM output. This would be more valuable than the implementation specifics which LLMs are better at (in well bounded problems).
Paradoxically, I don't think one develops these skills without deliberate practice (putting in the reps). So I don't think the time you spent learning is totally wasted.
Working on more complex problems still takes a lot of time, the models get lost, often jumping into a "solving loop" where the same solutions are being tested over and over again. You still need to guide the model, guide the loop otherwise it's lost or it's shipping a wrong solution, often even something different. Don't you now spend much more time on reading the results? iterating? Nothing changed, it's just a different way you're getting to the right place. Without a good software engineering knowledge you can't do a bulletproof, secure and high grade software. We're still far from doing a single prompt and getting a great grade output.
We might be heading that direction so personally I'm focusing on improving my soft skills, improving my general knowledge about the business, many skills around software engineering (closed to the client side, closer to the business) that until now were useless (at least I thought so).
This is an amazing time for experienced software engineers, learn more than before, try new things and this god mode will bear fruit!