Re:A year after the 100% AI mandate nobody understands our code
by trymas on Tuesday November 10, 2026 @05:28AM
(#50438343)
Why this is flagged? Because it's deemed AI-generated? No one is sympathetic to this?
I am (un)lucky to be in a team that for a ~year did not write code by hand almost at all. It's literal vibes, by true sense of the word, i.e. no one truly knows what's up - we only know what we have talked about with LLM.
Some anecdotes:
- I wouldn't consider any project/service done in last year - a success. Everything turned up either in trash bin or unused by anyone. Some things get usage, but it's hardly usable, inefficient and clearly an AI slop;
- Code is definitely a mess. PRs are often too big of what you'd think it would make sense, i.e. hiding one feature under one flag was a `+260 -60` size PR. Any minor change is hundreds lines of code change;
- We are locked to an LLM, only LLM will be able to fix a bug if hotfix is needed;
- We inadvertently step on each others toes or rewrite subsets of features, i.e.: is someone asks "How feature X works?" , we as a team have multiple different answers. This is because it's easy to (re)write some features and no-one cares too deeply. Developer A implemented feature in Way A, then Developer B got an idea and rewrote half of the feature in Way B, etc. In the end all developers think that same feature works in multiple different ways. In "old days" there would be at least some discussions or knowledge sharing as usually you would consult with developers who implemented something about some of its details;
- IMHO it's a management issue that swallowed AI pill, though for some reason they're happy, because PR output is only increasing. A team produces in a week: dozens PRs a year ago, then ~50-100 after `claude` subscriptions, to 500+ PRs now. For them it's literal 10-20x improvement, even though there's no value added to product IMO. And this metric is the only that matters if you want to keep the job (something about metric becoming a goal...);
I am not anti-AI luddite. I try to use it as a learning assistant on my free time and try to find some middle ground for coding (i.e. between ease of coding and understanding what's being created).
I am (un)lucky to be in a team that for a ~year did not write code by hand almost at all. It's literal vibes, by true sense of the word, i.e. no one truly knows what's up - we only know what we have talked about with LLM.
Some anecdotes:
- I wouldn't consider any project/service done in last year - a success. Everything turned up either in trash bin or unused by anyone. Some things get usage, but it's hardly usable, inefficient and clearly an AI slop;
- Code is definitely a mess. PRs are often too big of what you'd think it would make sense, i.e. hiding one feature under one flag was a `+260 -60` size PR. Any minor change is hundreds lines of code change;
- We are locked to an LLM, only LLM will be able to fix a bug if hotfix is needed;
- We inadvertently step on each others toes or rewrite subsets of features, i.e.: is someone asks "How feature X works?" , we as a team have multiple different answers. This is because it's easy to (re)write some features and no-one cares too deeply. Developer A implemented feature in Way A, then Developer B got an idea and rewrote half of the feature in Way B, etc. In the end all developers think that same feature works in multiple different ways. In "old days" there would be at least some discussions or knowledge sharing as usually you would consult with developers who implemented something about some of its details;
- IMHO it's a management issue that swallowed AI pill, though for some reason they're happy, because PR output is only increasing. A team produces in a week: dozens PRs a year ago, then ~50-100 after `claude` subscriptions, to 500+ PRs now. For them it's literal 10-20x improvement, even though there's no value added to product IMO. And this metric is the only that matters if you want to keep the job (something about metric becoming a goal...);
I am not anti-AI luddite. I try to use it as a learning assistant on my free time and try to find some middle ground for coding (i.e. between ease of coding and understanding what's being created).