Earlier quoted context omitted.
I never found there to be much soul and humanity in the job to begin with. Coding personal projects has soul, but for me at least the demands of high-velocity sprint-based software development to match business needs removed most of the soul and humanity long before AI got good at coding. And I mean, I totally understand why it has to be like that. In most businesses, you do better by shipping decent software fast th…
That's an interesting perspective. It's hard for me to relate to it because I haven't worked in a job where I just have to ship code 'for work' in so long. Being a more or less one-man software company, all my work projects, but especially our products, feel like personal projects. However, if I were just having to do things for the man, I might have a rather different take on all this.
LLMs are eroding my software engineering career and I don't know what to do
621–630 of 1001 posts
Re: LLMs are eroding my software engineering career and I don't know what to do
#622For context, I use Claude and Codex (side projects, Max and Pro plans respectively) and Gemini at work.
The key takeaway I have is: These tools have let me climb up the value chain ladder.
Even with Claude (Max plan, Opus 4.8, High Effort), it makes tons of mistakes, assumes a lot, misses nuance and doesn't really think through every aspect of the problem from every angle. Limited memory, lack of full context and a lack of experience with real world distributed systems means that the initial solutions they offer need a lot of iteration and refinement. Just like any junior engineer would need to do.
So, you might feel that with a LLM, "this should just be an hour" but it usually becomes a 2-week exercise for me.
Which brings me to what I tell my team repeatedly: "the only person with the big picture is you." I ask them to focus on thinking, ideating, refining. Do quick PoCs, talk to customers, discern what they are trying to achive, and what you can do to solve those problems. Work with Gemini (we can only use Gemini at work) to iterate until you are comfortable with the full solution end to end with all the nuances. Then let the agent code.
This moves you up the value chain from being a programmer to a problem solver. That's what software engineering has always been about: solving problems. Don't be discouraged. In fact, I am having more fun, am more energized and loving my craft even more now with LLMs. I am able to write down my thoughts, iterate on them and create a one-pager for ideas fast and get them to my team for them to think about. Sure, probably half of them we discard because it's usually not a "now" problem but we put that in our backlog to dust off when the first customer asks for it.
Re: LLMs are eroding my software engineering career and I don't know what to do
#623Earlier quoted context omitted.
Posting this under a burner so I don't dox myself: I work in FinTech on a regulated product. We have access to Mythos. Mythos identified part of our codebase that it confidently asserted was not complaint with a particular regulation and we were at grave risk by allowing it to operate the way it was. Except this was not the case, it had of course hallucinated what the regulation actually required (I know this because…
I have worked on highly regulated areas in finance (risk). Compliance is a highly creative art, often requiring lots of out-of-the-box thinking and non-obvious solutions. The people I found worst at this were IT. They tend to over-interpret regulation, and super-restrict beyond what is needed for actual de-facto compliance. My guess is the model makes the same mistakes as the programmers: taking 'rules' literally, un…
My experience as IT in modern banks was the opposite. The legal department were absolute assholes when it came to software features. And I'm talking absolutely 100% ok features, like paying your bills from the banking application.
The least fun, trigger happy, cover their buts people I've ever seen.
Like all they could ever say was NO. I guess they were heavily incentivized to just say NO to everything.
Re: LLMs are eroding my software engineering career and I don't know what to do
#624Earlier quoted context omitted.
Why is it such a dramatic statement for Boris to claim that he no longer writes code? Are people on HN still typing out functions by hand one character at a time? It would be like a developer in 2020 claiming that he only writes assembly because compilers can’t be trusted. No one is taking that person seriously. If you chose a career in tech you made a decision to work in one of the fastest moving fields in human his…
> Now it’s time to get over it, learn the new tools and adapt. If the AI is producing what you tell it to, why are you needed?
Re: LLMs are eroding my software engineering career and I don't know what to do
#625My career path is suprisingly similar to the author's. Weirdly enough, what he takes as the first pillar to fall is the one I see most undamaged currently. LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. They're great at refactoring, translating between languages, tracing bugs on existing code even, but there is…
LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. This is domain expertise - software engineers are not needed for that. Ofc often senior sws are expert in it, but they aren't necessary . Traditionally its been useful for frictionless production to have engineers to be able to do maybe 90% of their work without con…
Our engineers frequently need to be on the loop with product and stakeholders: Due to real world messiness, many times the only true answer to "how does this currently work" is in the code. Enabling product and stakeholders to fetch that knowledge would be a giant time saver, so we've experimented with LLMs.
I recommend you try this exercise: place a non technical person in front of a complex business' codebase with an agent in between and get them to extract or shape business knowledge through it.
I'm serious, it's not a rethorical device, genuinely do try with a coworker or a friend. It will teach you a lot seeing how the way they approach the problem is different to yours.
All our attempts failed miserably.
Re: LLMs are eroding my software engineering career and I don't know what to do
#626I see many comments saying, "AI can't do X with 80-100% accuracy; therefore our professions are in good hands." While I don't want to sound overly pessimistic, the models are improving at a rapid rate. If asked ~3 years ago where the state of the models are today, it would sound like sci-fi if answered, "the models are creating full MVP apps in ~30 minutes with one prompt". The hurdles the models are facing now, like…
Re: LLMs are eroding my software engineering career and I don't know what to do
#627My career path is suprisingly similar to the author's. Weirdly enough, what he takes as the first pillar to fall is the one I see most undamaged currently. LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. They're great at refactoring, translating between languages, tracing bugs on existing code even, but there is…
This. Once you're building something that genuinely hasn't been built before, LLMs cannot be trusted with any architectural decisions. I'm building a product based around various physics simulations, so it's purely first principles, but without active research, thinking, and challenging, it produces computational code literally hundreds of orders of magnitude slower WHILE implementing absurd fallbacks and shortcuts t…
Re: LLMs are eroding my software engineering career and I don't know what to do
#628My career path is suprisingly similar to the author's. Weirdly enough, what he takes as the first pillar to fall is the one I see most undamaged currently. LLMs routinely fail at our business specifics: Local tax regulations, particularities of the accounting process, specifics of our ledger implementations. They're great at refactoring, translating between languages, tracing bugs on existing code even, but there is…
This. Once you're building something that genuinely hasn't been built before, LLMs cannot be trusted with any architectural decisions. I'm building a product based around various physics simulations, so it's purely first principles, but without active research, thinking, and challenging, it produces computational code literally hundreds of orders of magnitude slower WHILE implementing absurd fallbacks and shortcuts t…
Re: LLMs are eroding my software engineering career and I don't know what to do
#629There's no doubt that LLM increases our efficiency, be it producing prototypes, generating production code, debugging our systems, or more. So, if there's no more demand or reduced work hours, some of us will lose our jobs. I certainly hope the Jevon's Paradox kicks in faster, as in months instead of years, let alone decades. If we don't consider the potential loss of our jobs, on the other hand, isn't it great that…
It was about knowing how to fit the new use case into an existing code base, respecting the architecture, and sometimes rearchiteting the solution. How easy the latter was is really dependent on whether the code/arcitecture respected the low coupling, high cohesion principle.
Now, some of this can be coerced into LLMs but it takes work and careful study of the changes. Sometimes they get it right, many times they do not. So, you have to go back and forth with them. If you know what they should have produced.
SWE is far from dead. We just let too much slop into the codebase because we're overwhelmed by it and not incentivized by leadership to care. Code quality will likely drop to the point where even the leadership will notice and it will normalize again. There's nothing like a high profile customer calling out a problem that was vibe coded. It has started already and will be happening more and more.
Don't worry, the hype will be over in some time.