Honestly people need to wake up to this industrial level theft, and get some laws in place. If someone did this by hand you'd call it either a DDOS or IP theft, even if license is permissive. Just cos its from a machine doesn't excuse.

I think this is going to be todays 'cheap outsource' culture. Good enough to keep shareholders happy, an apparent boost in productivity, before tanking the reliability of the company.

Remember when we used to scorn stackoverflow developers, or PRs that were more than a few lines long. An every morning git pull is now bigger than my terminal buffer, its complete chaos. Numbers game to keep the new metrics world gamification going. Its dire.

1. AI is exposing the harsh truth that 99% of the code out there has always been throwaway code. Yet good developers, void of any engineering skill, treated it like the 1% that wasn't and called their hygiene and practices engineering.

2. Way too many developers that have made their careers or internet fame out of their technical proficiency understand that the shift is unavoidable. See Antirez implementation of Arrays in Redis or his Dwarfstar project. Virtually every line of these projects has been AI authored. And yet they are terrific projects with extremely strong architecture. And not a single line was edited in vi (his favorite editor).

There's a difference between everything being vibe-coded where you don't look at the code and don't understand anything and using your agent like a very fast pair programmer.

It looks like Antirez did the latter. From https://antirez.com/news/164:

> In the first month I just wrote the specification document...Thanks to AI, the specification evolved a lot, via back and forth of feedback, intellectual challenges about what was the best design, what was the right compromise, what was too engineered and what not.

> You know what was the biggest realization of all that? For high quality system programming tasks you have to still be fully involved

Judgement will be required even moreso now. There will be critical parts of the system where it's important that engineers know them well. But there's a lot of work around the core that isn't that critical to know in detail. For these types of things, I've found it's just important to understand the gist to make sure things aren't going off the rails. But for the core pieces, it's important to understand the details of what's happening.

I agree that we have to keep understanding our code and we have to understand the systems we build.

I think the deeper issue is that AI can generate so much code that reading it simply doesn't scale.

Even if AI were to produce perfectly written code that didn't have any bugs that human review needed to catch, it would still be too much code to read in order to understand everything. The machine can write much faster than I can read.

Extending this argument further, it also becomes impossible to onboard young people to codebases if we maintain an expectation that reading all the lower level source code is how they come up to speed. I don't think this was ever an actual expectation in the industry, although we may have short-handed it that way in conversation.

So IMHO we need to come up with higher level visualizations and other ways to compress the knowledge that we used to get out of reading source code. We basically need to create new higher level projections off of our semantic understanding of the project.