The phrase of the day is “prompt engineering”—developing the skills to make LLMs productive for generating code, tests, and documentation.
But we have a bigger challenge on our hands: the need for better *substrate* engineering. A substrate is the layer an organism grows and lives on and is supported by. For LLM-based tools, that means the frameworks and programming languages we use every day.
Put it this way: Would you trust LLM-generated C code to be free of memory vulnerabilities? As a rule, human-authored C has many vulnerabilities. By definition, so will Copilot-style tools. The programming language itself is no help here, and LLM-based tools can only be as good as the data they were trained on. What’s more, they can only be as good as the frameworks and programming languages they target. So in a world where these tools let programmers author far more code, far more quickly, our foundations matter more than ever.
We need to start investing much more in migrating to better programming languages, building better tooling, and authoring new frameworks where correctness is built in. What does that look like for your engineering organization today?
