I've worked with engineers who can happily write greenfield code that passes the spec, but fails on any inputs that are not clearly defined as valid. In an effort to fix this, they add layers and layers and layers of complexity and edge cases to the app logic, and intermix the actual app logic with handling invalid input. something like

    func isEven(s string) bool {
        num, _ := strconv.Atoi(s)
        return num % 2 == 0
    }

becomes:

    func isEven(s string) (string, error) {
        f, err := strconv.ParseFloat(s, 64)

        if err != nil {
            return "invalid", err
        }
        num := int(f)
        if num%2 == 0 {
            return "even", nil
        }
        else if num % 2 != 0 {
            return "odd", nil
        }
        return "invalid", nil
    }

Which is.... technically correct, instead of

    func isEven(num int) bool {
        return num % 2 == 0
    }
    func isEvenSafe(s string) (bool, error) {
        num, err := strconv.Atoi(s)
        if err != nil {
            return false, err
        }
        return isEven(num), nil
    }

Also the ones that can’t understand abstraction and are happy copy-pasters. Or the ones familiar with some paradigms (ex OOP) that brings it everywhere.

There are a lot of ways to accumulate tech debt so fast you’d think you’re in a code casino.

I’ve definitely seen way too much code like the examples above. Another side effect to this is it tends to leak all over and can result in exponentially more code. What would’ve been a 2-line change at the API boundary, becomes ten lines of manual edgecasing every time it’s used in business logic and results in impossible states that need even further typing and handling. And don’t forget the tests that now need to cover invalid inputs everywhere, not just the API boundary.

OP may be talking about cargo culting, but it actually just triggered two examples in my mind:

1. Someone who has only ever written code by tutorial, and has no idea of the architecture, performance considerations or usability implications of the code they're writing.

2. Someone who has got to a point in their career LLM Coding and is unable to write code without it because they don't understand what they're doing.

The problem occurs when one of these people:

- Is required to be good at the things they are not yet

- Proceeds as they always have because they are unaware of their skill gap

- (Optionally) gets promoted while things are still _just_ working

IME you hit these silent inflection points as a system begins to scale beyond the experience of the people involved. They survive for a while (Coyote time / the compass is still pointing north) until something happens (the whole thing falls off a cliff / starts to go south).