←back to thread

425 points sfarshid | 1 comments | | HN request time: 0s | source
Show context
VincentEvans ◴[] No.45005596[source]
There will be a a new kind of job for software engineers, sort of like a cross between working with legacy code and toxic site cleanup.

Like back in the day being brought in to “just fix” a amalgam of FoxPro-, Excel-, and Access-based ERP that “mostly works” and only “occasionally corrupts all our data” that ambitious sales people put together over last 5 years.

But worse - because “ambitious sales people” will no longer be constrained by sandboxes of Excel or Access - they will ship multi-cloud edge-deployed kubernetes micro-services wired with Kafka, and it will be harder to find someone to talk to understand what they were trying to do at the time.

replies(16): >>45005632 #>>45005830 #>>45009697 #>>45009999 #>>45010075 #>>45010738 #>>45010794 #>>45011192 #>>45011626 #>>45011943 #>>45012386 #>>45013129 #>>45014577 #>>45014613 #>>45014836 #>>45015644 #
Cthulhu_ ◴[] No.45011626[source]
> and it will be harder to find someone to talk to understand what they were trying to do at the time.

This will be the big counter to AI generated tools; at one point they become black boxes and the only thing people can do is to try and fix them or replace them altogether.

Of course, in theory, AI tooling will only improve; today's vibe coded software that in some cases generate revenue can be fed into the models of the future and improved upon. In theory.

Personally, I hate it; I don't like magic or black boxes.

replies(3): >>45011979 #>>45012891 #>>45014377 #
worldsayshi ◴[] No.45011979[source]
The prevailing counter narrative around vibe coding seems to be that "code output isn't the bottle neck, understanding the problem is". But shouldn't that make vibe coding a good tool for the tool belt? Use it to understand the outermost layer of the problem, then throw out the code and write a proper solution.
replies(2): >>45012049 #>>45013469 #
camgunz ◴[] No.45013469[source]
Coding is how I build a sufficiently deep understanding of the problem space--there's no separating coding and understanding for me. I acknowledge there's different ways of working (and I imagine this is one of the reasons a lot of people think they get a lot more value out of LLMs than I do), but like, having Cursor crank code out for me actually slows me down. I have to read all the stuff it does so I can coach it into doing better, and also use its work to build a good mental model of the problem, and all that takes longer than writing the code myself.
replies(2): >>45013634 #>>45016942 #
1. lwhi ◴[] No.45016942[source]
That thinking and understanding can be done before coding begins, but I think we need to understand the potential implementation layer well in order to spec the product or service in the first place.

My feeling is that software developers will need end up working this type of technical consultant role once LLM dominance has been universally accepted.