You have to basically tell them all the patterns they need to follow and give them lots of hints to do anything decent, otherwise they invent new helpers that already exist in the codebase, don't follow existing patterns, put code in places that aren't consistent.

They are great at quickly researching a lot, but they start from 0 each time. Then they constantly "cheat" when they can't solve a problem immediately, stuff like casting to "any", skipping tests, deciding "it's ok if this doesn't work" etc.

a few things that would make them much better:

- an ongoing "specific codebase model" that significantly improved ability to remember things across the current codebase / patterns / where/why

- a lot more RL to teach them how to investigate things more deeply and use browsers/debuggers/one-off scripts to actually figure out things before "assuming" some path is right or ok

- much better recall of past conversations dynamically for future work

- much cheaper operating costs, it's clear a big part of why they "cheat" often is because they are told to minimize token costs, it's clear if their internal prompts said "don't be afraid to spin off sub-tasks and dig extremely deep / spend lots of tokens to validate assumptions" they would do a lot better

> mentoring

Clarifying either business or technical requirements for newer or junior hires.

> reviewing code

See mentoring.

> or in meetings

So clarifying requirements from/for other teams, including scope, purely financial or technical concerns, etc.

Rephrase "clarifying requirements" to "human oriented aspects of software engineering".

Plus, based on the graphics debugger part of your comment, you're a game developer (or at least adjacent). That's a different world. Most software developers are line of business developers (pharmaceutical, healthcare, automotive, etc) or generalists in big tech companies that have to navigate very complex social environments. In both places, developers that are just heads down in code tend not to do well long term.