That's fair. My point is that most of what coding models need to learn to write code proficiently is largely baked in. things like syntax, useful code idioms, data structures and algorithms, important engineering concepts and design patterns etc... are already learned. Code, generally is easier to "bake in" in some ways than creative work because it is highly structured with known and absolute rules, whereas creative work thrives on the surfaces where rules and conventions are violated in some way. I work a lot with Claude Code, not just building, but analyzing how it builds and it is at the point where its failures largely arise from a misunderstanding of my instructions or implied goals, and in some cases a failure to understand basic reality, not on syntax or logic. In other words, it implemented the wrong idea really well (some clean up by humans required assuming any of it is useful). That said, the creative concept needs to come from the human. Case in point. I have a simple python based synthetic data generator. Claude uses it inefficiently because it is a new-ish repo it has not seen so it reads the lengthy README and ~60-70% of the code in the repo to learn it before using it. I had 2 solutions to this. One, create a CLI or MCP interface for models, or two, just create a skill file. I presented only the first idea and it returned only that it was possible if difficult given the complexity of how one creates influences on certain classes in the data. It COULD HAVE just said "It would be a lot easier to make a skill" but it lacked the creative capacity for this leap i guess. I jumped right to the skill idea two paragraphs into the explanation of the core challenges of creating an MCP and did not bother to read on before I suggested a skill. That is the current code barrier, not necessarily understanding syntax etc...