←back to thread

425 points sfarshid | 6 comments | | HN request time: 0.906s | source | bottom
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. thyristan ◴[] No.45013634[source]
Well, actually there could be a separate step: understanding is done during and after gathering requirements, before and while writing specifications. Only then are specifications turned into code.

But almost no-one really works like that, and those three separate steps are often done ad-hoc, by the same person, right when the fingers hit the keys.

replies(3): >>45014490 #>>45015853 #>>45023494 #
2. camgunz ◴[] No.45014490[source]
I can use those processes to understand things at a high level, but when those processes become detailed enough to give me the same level of understanding as coding, they're functionally code. I used to work in aerospace, and this is the work systems engineers are doing, and their output is extremely detailed--practically to the level of code. There's downsides of course, but the division of labor is nice because they don't need to like, decide algorithms or factoring exactly, and I don't need to be like, "hmm this... might fail? should there be a retry? what about watchdog blah blah".
3. naasking ◴[] No.45015853[source]
> Well, actually there could be a separate step: understanding is done during and after gathering requirements, before and while writing specifications. Only then are specifications turned into code.

The promise of coding AI is that it can maybe automate that last step so more intelligent humans can actually have time to focus on the more important first parts.

4. Ma8ee ◴[] No.45023494[source]
We used to call that Waterfall, and it has been frowned upon for a while now.

So we went full circle, again.

replies(1): >>45024624 #
5. thyristan ◴[] No.45024624[source]
Waterfall is a caricature straw man process where you can never ever go back to the drawing board and change the requirements or specifications. The defining characteristic is the part where design up front, you can never go back and really really have to do everything in strict order for the whole of the project.

Just having requirements and a specification isn't necessarily waterfall. Almost all agile processes at least have requirements, the more formal ones also do have specifications. You just do it more than once in a project, like once per sprint, story or whatever.

replies(1): >>45028077 #
6. Ma8ee ◴[] No.45028077{3}[source]
Waterfall certainly has processes for going back and adjusting previous steps after learning things later in the process. The design was updated if something didn’t work out during implementation, and of course implementation was changed after errors was found during testing.

Now that agile practitioners have learned that requirements and upfront design actually is helpful, the only difference seems to be that the loops are tighter. That might not have been possible earlier without proper version control, without automated tests, and the software being delivered on solid media. A tight feedback loop is harder when someone has to travel to your customer and sit down at their machines to do any updates.