What I said in 2025 still stands: AI benefits two groups of people the most. The senior engineers who use AI to double or even triple their productivity, and the juniors who use AI as a learning tool. However, unlike in 2025 when the leads asked everyone to adopt AI and hash tag “vibe-coded” for all code changes, the theme has changed 180 degrees. Instead, the YouTube, or at least in my org, is now promoting “craftsmanship” and programs to prevent AI slops.
AI slops are code changes (or design artifacts) that are produced without much supervision and even shipped without proper review. AI slops are the opposite of “craftsmanship” where the author takes time understanding his/her own works and takes pride in it.
This might come as a surprise as people on X seemingly have given up reviewing codes, claiming the code review is dead and we no longer should review codes as reviewing is the new bottleneck in software development. This is certainly not true at Google or YouTube; code review is very much alive. However, the reviewing burden is indeed increased, and so is the worry of “AI slops”.
For the past year, contrary to people’s initial fear of mass layoffs of software engineers, the hiring has in fact not stopped. Our team has grown twice the size. With this many new hires and new grads comes a new surge of “AI slops”. I first saw them in the design docs. They are usually very long with jargons. Usually there won’t be many diagrams as AI cannot yet produce good ones. This makes the design doc even harder to read. Sometimes I point out something that I cannot understand, the author will explain that he is not sure either: AI wrote it.
In the end, as a reviewer I no longer bother to read everything. I skip reading design alternatives that only have fancy titles without much detail; shallow ideas that only make the page longer.
Same thing goes with AI codes from the new hires. They are usually very long (especially the unit tests). The author sometimes has difficulty explaining the codes.
To prevent these “AI slops” and shallow learning for the new hires, new mentoring programs are proposed. For example, “reverse shadowing” suggests the mentee/author has an online session explaining the codes to the reviewers to demonstrate their understanding of the codes. “AI pair programming” suggests having a three-way group chat with AI for mentors/seniors to monitor the AI chat session and timely correct the design direction.
“Shallow learning” doesn’t just happen to the junior engineers, it is now easier than ever for anyone to take the easy road and accept whatever AI suggests. I now have to remind myself frequently to understand and investigate deeply whenever AI comes up with an idea or codes that I don’t fully understand. This is not only to avoid hallucination, but also to discover hidden pitfalls and for my personal technical growth. How is its idea better than my idea? What are the pros and cons of using this methodology? Can this apply to all situations or just the scenario I mentioned. Instead of delegating thinking to AI, we want to use AI as a tool to learn and discover new ideas.