I am finding this, professionally, not so dramatic - but mostly because the industries in which I've consistently shipped code at scale involve review as a first principle, as in no un-tested, un-reviewed code gets shipped, because: safety critical/realtime requirements and certification specs, say so.

And having AI code to review is no different than any other code that ever was to review, so the review tooling is - as it necessitates - also benefited by lugubrious application of .. more AI. But: all AI is human reviewed.

So it's not a big impact. We just don't ship code that isn't 100% human reviewed, If that's insurmountable: you're doing it wrong. Use AI to make code readable again.

And then, also, put AI back in its box. Don't give devs 100% full-time API access to subscriptions: give them actual hardware to use, to go 100% local.

Local AI is, thus, the best AI, folks. Don't use more than you can run locally, is a great way to keep AI code properly maintainable.

The industry will prove this, itself, sooner or later: If you can't put your AI in its box for safe-keeping, you're doing it wrong, anyway... and should've already learned this practice as a habit, decades ago, vis a vis future-proof tooling... (See also: not logging everything you do with an AI? Big fail.)

Sure, the absolutely intoxicating addiction of Big Metal AI™ is going to put a lot of consumers in a deep, deep pit of Neo-Illiteracy - however: 'good' AI code is actually just good code.

▲

jefftk 5 minutes ago | parent | next [-]

> And then, also, put AI back in its box. Don't give devs 100% full-time API access to subscriptions: give them actual hardware to use, to go 100% local. Local AI is, thus, the best AI, folks. Don't use more than you can run locally, is a great way to keep AI code properly maintainable.

This glosses over the large capability app between local options and frontier options. Which applies in many ways, but includes drafting more maintainable code. I would definitely not want to limit my devs to what we can run on our own hardware.

▲

nicoburns 3 hours ago | parent | prev [-]

> I am finding this, professionally, not so dramatic - but mostly because the industries in which I've consistently shipped code at scale involve review as a first principle, as in no un-tested, un-reviewed code gets shipped,

> And having AI code to review is no different than any other code that ever was to review

If your company is sticking to "everything needs (human) review" then you wont run into most of this. This issue is that a lot of companies are using AI as an excuse to remove that review process (either partially or entirely).

	▲	MomsAVoxell 2 hours ago \| parent [-]
		Yes, that is very real to me, the AI "revolution" is more of a battle between traditional devs trying to replace their managers with AI, and professional managers trying to get rid of the devs the same way. There is a wide degree and scope of knicker-twister'ing in these trenches. Everyone can write code these days. Trouble is, all code has to be SIL-4 code now, because, human, you will never know if your compiler trusts your AI until you trust your compiler. This rule will be true for decades into the future, I'm willing to wager... But, ultimately, software has to follow certain rules, or it just doesn't work. Proper workflows - involving review - are needed. Because security is pretty much over, otherwise. Folks are finding it easier to make their own software now, too - rather than use others. I predict an end to the app stores - or at least, the primary interface is going to end up being "describe the app you want to use today" instead of picking words from a list ..