←back to thread

We put a coding agent in a while loop

(github.com)
425 points sfarshid | 1 comments | 24 Aug 25 16:18 UTC | HN request time: 0s | source
Show context
VincentEvans ◴[24 Aug 25 16:36 UTC] 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_ ◴[25 Aug 25 08:35 UTC] 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 ◴[25 Aug 25 09:34 UTC] 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 ◴[25 Aug 25 09:44 UTC] 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 #
sdeframond ◴[25 Aug 25 12:02 UTC] No.45012920[source]▶
> Problem is

How much is it a problem, really ?

I mean, what are the alternatives ?

replies(1): >>45013030 #
thyristan ◴[25 Aug 25 12:17 UTC] No.45013030[source]▶
The alternative is obviously: Do it right on the first try.

How much of a problem it is can be seen with tons of products that are crap on release and only slowly get patched to a half-working state when the complaints start pouring in. But of course, this is status quo in software, so the perception of this as a problem among software people isn't universal I guess.

replies(1): >>45014110 #
sdeframond ◴[25 Aug 25 14:15 UTC] No.45014110[source]▶
Sure.

How about the tons of products we don't even see? Those that tried to do it right on the first try, then never delivered anything because there were too slow and expensive. Or those that delivered something useless because they did not understand the users' need.

If "complaints start pouring in", that means the product is used. This in turns can mean two things: 1/ the product is actually useful despite its flaws, or 2/ the users have no choice, which is sad.

replies(2): >>45014611 #>>45014757 #
1. bonoboTP ◴[25 Aug 25 14:59 UTC] No.45014611{3}[source]▶
Exactly. There is a reason for the push. The natural default of many engineers is to "do things properly", which often boils down to trying to guess all kinds of possible future extensions (because we have to get the foundations and the architecture right), then everything becomes abstracted and there's this huge framework that is designed to deal with hypothetical future needs in an elegant and flexible way with best practices etc. etc. And as time passes the navel-gazing nature of the project grows, where you add so much abstraction that you need more stuff to manage the abstraction, generate templates that generate the config file to manage the compilation of the config file generator etc.

Not saying this happens always, but that's what people want to avoid when they say they are okay with a quick hack if it works.