Pretty much, but it already starts at the prompting and context level.

Senior engineers either already know exactly where the changes need to be made and can suggest what to do. They probably know the pitfalls, have established patterns, architectures and designs in their head. Juniors on the other hand don't have that, so they go with whatever. Nowadays a lot of them also "ask ChatGPT about its opinion on architecture" when told to refactor (a real quote from real junior/mid engineers), leading to either them using whatever sloppypasta they get provided.

Senior devs earned their experience of what is good/bad through writing code, understanding how hard and annoying it is to make a change, then reworking those parts or making them better the next time. The feedback loop was impactful beacause it was based on that code and them working with that code, so they knew exactly what the annoying parts are.

Vibe-coding juniors do not know that, their conversation context knows that. Once things get buggy and changes are hard, they will fill up their context with tries/retries until it works, leading to their feedback loop being trained on prompts and coding tools, not code itself.

Even if they read the outputted code, they have no experience using it so they are not aware of the issues - i.e. something would be better being a typed state, but they don't really use it so they will not care, as they do not have to handle the edge cases, they will not understand the DX from an IDE, they will not build a full mental model of how it works, just a shallow one.

This leads to insane inefficiencies - wasting 50 prompt cycles instead of 10, not understanding cross-codebase patterns, lack of learning transfer from codebase to codebase, etc.

With a minor understanding of state modeling and architecture, an vibe-coding junior can be made 100x more efficient, but due to the vibe-coding itself, they will probably never learn state modeling and architecture, learn to refactor or properly manipulate abstractions, leading to an eternal cycle of LLM-driven sloppypasta code, trained on millions of terrible github repositories, old outdated API's and stack overflow answers.

>"they will fill up their context with tries/retries until it works"

Or until it does not. On numerous occasions I've observed LLMs get stuck in the endless loop of fix: one thing, break the other. Senior is capable of fixing it themselves and juniors may not even have a clue how the code works.

I was thinking about this last week.

I don't think this is necessarily a massive moat for senior programmers. I feel it's a not a massive jump to teach AI architecture patterns and good data modelling?

I feel that anthropic etc al. just haven't got to that training stage yet.

That then leaves you with the mental model problem. Yes, there then a large context problem, but again I was wondering if setting up an MCP that presented the AI a meaningful class map or something might help.

Essentially give the AI a mental model of the code. I personally find class maps useless as they tend to clash with my own mental model. But it might work with AI. The class map can obviously be built without AI, but then you might even get AI to go through the code function by function and annotate the class map with comments about any oddities of each function. The MCP server could even limit the size of the map, depending on what part of the code it's looking to change (working on the email sending, don't bother sending them the UI later).

I'm guessing someone's already tried it given some of the ridiculous .Claude folders I've seen[1] but I've seen no-one talking about whether it works or not yet in the discussions I follow.

[1] That I suspect are pointlessly over complicated and make CC worse not better