A developer's post on Hacker News describes a scenario that is becoming familiar across the industry: a team mandating AI-assisted development, then losing the ability to distinguish good output from bad. The account, posted under the title "How to handle manager adding AI bs to our codebase/designs," reads like a case study in what happens when tool adoption outruns technical judgment.
The mandate and the immediate aftermath
The developer, who joined the company out of college about a year ago and describes being the team's highest performer by story points and defect rate, says the company pushed AI-assisted development across engineering to improve stock valuation. The intent was reasonable. AI tools can catch bugs, suggest improvements, and speed up boilerplate. The problem was not the tool itself but the team's response to it.
Teammates stopped reviewing AI output. The code they submitted became over-engineered, introduced technical debt, and generated defects that surfaced weeks later in regression testing. Because the original developer finished work quickly, they were repeatedly assigned to fix the resulting problems. Meanwhile, the teammates who produced the issues could not explain their own code when asked how it worked.
The design document problem
The situation escalated when a technical design document turned out to be half AI-generated text with fabricated details. The developer did not catch it immediately because they were unfamiliar with that part of the codebase, and assumed the document was accurate. After a day of implementation, they discovered that roughly half the document did not correspond to reality.
This is the pattern that should concern engineering leaders most. Design documents are the source of truth for implementation. If the design is wrong, everything built on top of it is wrong. An AI tool that generates a plausible-looking but inaccurate design document does not save time. It creates work. The developer in this case had to reverse-engineer what the system actually needed, then rebuild the implementation against a document that had already been approved by the team.
The manager loop
The most revealing part of the account involves the developer's manager. After the developer pushed a corrected pull request, the manager asked them to have the AI review the work. The AI produced a mix of hallucinated suggestions and valid points, such as updating documentation and adding error handling. The developer addressed the legitimate feedback and pushed again. The manager then came back with a different set of AI-generated suggestions, which turned out to include the same issues they had already discussed and rejected on a call. The manager had not tracked which suggestions were valid and which were not. They were treating every AI output as equally worthy of implementation.
This points to a management problem, not a tooling problem. A manager who cannot evaluate the quality of code review feedback is not equipped to lead a code review, regardless of whether that feedback comes from a person or a model. The AI did not cause the manager to stop thinking. The manager stopped thinking, and the AI gave them a way to stay involved without understanding what was happening.
The legacy code trap
The developer also notes that the AI frequently recommends patterns from existing code in the repository, some of it a decade old and poorly written. This is a known limitation of code-generation tools. They learn from what is in the codebase, not from what should be in the codebase. A repository full of legacy anti-patterns produces AI suggestions that replicate those anti-patterns. Without a human in the loop who understands why the old code is bad, the tool perpetuates it.
The broader pattern
The core tension is not about AI being good or bad. It is about organizational incentives misaligned with quality. The company wanted faster output. The team interpreted that as "let the AI do the work." The manager interpreted AI suggestions as code review. The developer who actually understood the system spent their time fixing problems created by people who did not.
This is not a hypothetical. It is happening at scale. The developer's account resonated on Hacker News because the details are specific enough to be credible and general enough to be universal. Any team that adopts AI tools without establishing clear review practices, ownership of output, and standards for what constitutes acceptable code will eventually face a version of the same problem. The tool is not the issue. The process around it is.