Human abstract language, particularly the English language, is a pretty low-fidelity way to represent reality and in countless instances it can fail to represent the system to any useful or actionable degree.

Interfaces are hard, abstraction is hard. Computer science has been working on making these concerns easier to reason about, and the industry has put a lot of time and effort into building heuristics (software / dev mgmt / etc frameworks) to make achieving an appropriate abstraction (qua ontology) feasible to implement without a philosophy degree. We, like biological systems, have settled on certain useful abstraction layers (OOP, microservice arch, TDD, etc.) that have broad appeal for balancing ease of use with productivity.

So it should be with any generative system, particularly any that are tasked with being productive toward tangible goals. Often the right interface with the problem domain is not natural language. Constraining the "information channels" (concepts/entities and the related semantics, in the language of ontology) to the best of your ability to align with the inherent degrees of freedom, disambiguated as best as possible into orthogonal dimensions (leaning too hard on the geometric analogy now). For generating code, that means interacting with tokens on ASTs, not 1D sequences of tokens. For comprehending 3D scenes, a crude text translation from an inherently 2D viewpoint will not have physics, even folk physics, much in mind except by what it can infer from the dataset. For storing, recalling, and reciting facts per se, the architecture shall not permit generating text from nonverifiable sources of information such as those vector clouds we find between the layers of any NN.

These considerations early in the project massively reduce the resource requirements for training at the expense of SME time and wages to build a system that constrains where there are constraints and learns where there are variables.