@cliffle@hachyderm.io I'm continually reminded of my own experiences progressing from n00b through to very senior engineering roles: there's a shift from your time being spent primarily on writing code (the fun part that attracted most of us to this stuff!), through to reviewing code when you take on the mantle of a small team lead, to reviewing summaries when you are responsible to leading more or bigger teams, because it is simply not feasible to review the total output of so many people/projects. As you go "up" you get further from the actual code and the fun/interesting bits. That shift in how the time is spent leads to a couple of common outcomes (if you'll forgive my over-simplication here):
a shift to management, accompanied by a reduction in technical sharpness because you're just not exercising those skills as much any more. But this is OK because the shift is (should be!) about helping people grow and be successful rather than direct technical contribution.a rejection of the management responsibility and a shift to re-focus on being an individual contributor. This can be hard in some orgs and may require what is effectively a demotion or a complete change in employment. (I've gone through this transition a couple of times myself)something I call "architect-itis" where someone is not prepared to embrace the management shift, but is also no longer exercising their technical skills at the right depth to remain sharp. They like thinking in the abstract and telling people what to do to build things "right". They're insulated from much of the realities of the system and the real world; they don't know how things actually work any longer and are slowly losing their ability to dig back in to do so, but because of their experience they can coast along for a long time before the harm that their power and influence causes becomes a notable problem.
Traditionally it could take years for someone to reach that fork and those outcomes, but the vibe-sled is "democratising" this experience and helping folks (and systems!) to literally speed run it and experience particularly the architect-itis role and side-effects more quickly and deeply than they would without it.
I know the LLM situation is more complex and nuanced than that, but the parallels stick with me: I think the potential for this sort of shit/slop-fest has always been there, but the tech makes it quick and easy to manifest it everywhere.
In my own evaluation of this tech, I have to work hard to resist the urge to gloss over a review. I have to continually remind myself that it has no ability to truly learn like a human would, so I cannot trust it to remember something from the review I gave a week prior, and I cannot choose to deliberately and strategically let a small issue slide to use as a learning experience for them (one of my tools for helping grow juniors!).
I got used to skimming code reviews with my human teams because I knew that between the rest of the team they'd find and comment on the majority of obvious issues and that meant that I could focus on a higher level or things that they might not spot. I cannot do this with LLMs.
That means that if I'm working solo with an LLM I have to read everything like a hawk, and that is draining. If the LLM is right often enough, then the slide to not reviewing will be hard to resist; it takes a certain kind of stubborn to counter our natural inclination to be lazy, and the odds are in the favor of the lazyness winning out.
With the above framing, I'd summarize this as: I feel like using an LLM for coding is a continual willpower check to save against architect-itis.
