That and they do not necessarily generate better code. They tend to generate code that is repetitive. It misses opportunities for extraction and refactoring, the result is bloated and hard to read code (because those blocks are there literally instead of with a usable name) and they tend to over-comment where it doesn't add but is 'safe' because it is obvious (effectively re-writing code as comments) and fail to document where documentation would be essential. There also typically isn't any real plan to what is written, as long as 'the tests pass' it is all good.

You can fix a lot of this stuff by shepherding the whole process but it can get quite tedious. I'm impressed by the number of people that are letting Jesus (one of these days an AI provider is going to name their AI that way :) ) take the wheel and I wonder how long they will manage to support the output. So far the score isn't very good. I've gotten good mileage out of these tools by letting them loose on very narrowly scoped pieces of code that are written in isolation. As soon as the codebase gets larger than 100K LOC or so managing the whole thing becomes an exercise in putting up barriers to avoid spillover from a tiny issue into a much larger one.

▲

mettamage 3 hours ago | parent [-]

I agree, I do like them for creating believable interaction prototypes though.

▲

jeanpah 3 hours ago | parent [-]

I agree too, the problem arrives later when the prototype must scale

▲

jacquesm 2 hours ago | parent [-]

This is not unlike hardware: making prototypes, assuming the principles are valid to begin with is relatively easy. Making a prototype that is a good precursor for a production run that's not going to result in a large number of rejects is stupendously hard. You can't fake your way through that. This is one of the reason many Kickstarters are doomed to failure, it's one thing to have a device working on your table in the lab, a completely different thing to produce that device reliably over and over again with negligible QA failures.

That's why some of these projects really impress me (for instance: that phased array antenna on a Raspberry Pi features here a short while ago: https://scalerf.com/). The amount of skill required to pull something like that off is off the scale, and they make it look so easy.

▲

jeanpah 2 hours ago | parent [-]

Exactly, i have been involved in hardware projects and every word You said was my exact experiece. The prototype in theory is perfect, in practice everything just explodes.

In software, instead, i find really dificult to show a customer a vive coded app and explain to then that it's only a step. It seems like they only understand the visual part of the process.

	▲	jacquesm 7 minutes ago \| parent [-]
		Part variance alone is enough to make a marginal design turn into a nightmare. I've seen this with a friend of mine who designs circuit boards for a living, many decades of experience. He got an order for what he assumed to be a run of the mill circuit, with one little twist: most of it was analog. His bad luck was really simple: the first version more or less worked. By the time they were ready for production a lot of expensive lessons were learned. And that 5% part that you stuck in your first version may have contributed just as much to the success of your prototype as it will contribute to the failure of your 0 series... Hardware still is hard. For now. But I've seen some pretty impressive boards roll out of AI assisted workflows so there too the barrier to entry is dropping. But the failures at scale are so much more expensive (think product recall) that the companies in that space are a little bit more careful about firing the people that keep the lights on. Programmers were always seen as that pesky bottleneck between management's greatest ideas and the income streams associated with them that there is a very large number of managers that believe 'the time' has finally come. The wake-up will be a harsh one, unless the frontier model makers keep pulling rabbits out of their hat.