←back to thread

425 points sfarshid | 10 comments | | HN request time: 0s | 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 #
thyristan ◴[] No.45012049[source]
> [create prototype], then throw out the code and write a proper solution.

Problem is, that in everyones' experience, this almost never happens. The prototype is declared "good enough, just needs a few small adjustments", rewrite is declared too expensive, too time-consuming. And crap goes to production.

replies(4): >>45012519 #>>45012920 #>>45013141 #>>45016844 #
ceuk ◴[] No.45012519[source]
Watching was supposed to be a prototype become the production code is one of the most constant themes of my 20 year career
replies(1): >>45013426 #
1. jmathai ◴[] No.45013426[source]
Software takes longer to develop than other parts of the org want to wait.

AI is emerging as a possible solution to this decades old problem.

replies(5): >>45013571 #>>45013595 #>>45013834 #>>45015276 #>>45015788 #
2. zppln ◴[] No.45013571[source]
No, the org will still have to wait for the requirements, which is what they were waiting for all along.
3. thyristan ◴[] No.45013595[source]
Everything takes longer than ppl want to wait. But when building a house, ppl are more patient and tolerant about the time taken, because they can physically see the progress, the effort, the sweat. Software is intangible and invisible except maybe for beta-testers and developer liaisons. And the visual parts, like the nonfunctional GUI or web UI, are often taken as "most of the work is done", because that is what people see and interact with.
replies(1): >>45015071 #
4. dudefeliciano ◴[] No.45013834[source]
until the whole company fails because lack of polishing and security in the software. Think tea app openly accessible databases...
replies(1): >>45014580 #
5. spogbiper ◴[] No.45014580[source]
is there any evidence the tea app failure was due to AI use?
6. jmathai ◴[] No.45015071[source]
It's product management's job to bridge that gap. Break down and prioritize complex projects into smaller deliverables that keep the business folks happy.

It's better than houses, IMO - no one moves into the bedroom once it's finished while waiting for the kitchen.

7. ozim ◴[] No.45015276[source]
I don’t really see this as universal truth with corporate customers stalling process for up to 2 years or end users being reluctant to change.

We were deploying new changes every 2 weeks and it was too fast. End users need training and communication, pushback was quite a thing.

We also just pushed back aggressive timeline we had for migration to new tech. Much faster interface with shorter paths - but users went all pitchforks and torches just because it was new.

But with AI fortunately we will get rid of those pesky users right?

replies(1): >>45015717 #
8. thyristan ◴[] No.45015717[source]
Different situation. You already had a product that they were quite happy with, and that worked well for them. So they saw change as a problem, not a good thing. They weren't waiting for anything new, or anything to improve, they were happy on their couch and you made them move to redo the upholstery.
replies(1): >>45017579 #
9. YeGoblynQueenne ◴[] No.45015788[source]
Or as a new problem that it will persist for decades to come.
10. ozim ◴[] No.45017579{3}[source]
They were not happy otherwise we would not have new requirements.

Well maybe they were happy but software needs to be updated to new business processes their company was rolling out.

Managers wanted the changes ASAP - their employees not so much, but they had to learn that hard way.

Not so fun part was that we got the blame. Just like I got down vote :), not my first rodeo.