In any kind of minimally-effective engineering team, engineers will only ever be working with and maintaining code that's "mission critical" in the sense you're describing here, there won't be any meaningful amount of "non-mission-critical" code worth considering or optimizing.
This is in some sense a didactic assertion: if it's not the case, then your engineering team isn't providing any value beyond what a bash script, gluing-together JIRA tickets and GitHub PRs via the LLM-du-Jour, could do autonomously.
Re:Becoming an AI-Native Engineer
by worldsayshi on Thursday June 12, 2025 @05:33PM
(#44263447)
I have never worked in an engineering organisation that lives up to that level of efficiency that you seem to describe. Once you scratch the surface there's always a mountain of things that would help people get more efficient that never gets prioritized.
But so much of the software we need to solve various problems is not mission critical. Like tooling. Or any low stakes software that can be easily replaced. Or some script that makes your life a little bit easier. Or maybe even a small gui app that helps you compose some specific configuration for that other software. Tools where the output is easy to verify and can stand on its own and can't be used by an attacker to exploit your systems.
If you put a lot of effort into tooling that you can throw away the moment better tooling appears you can make the mission critical software leaner.
> actually important for engineers to do in order to understand the system
It is one tool for it and an important one. But it is not the end all tool for understanding or trusting code. If that were the case you'd have to rewrite all code you ever had to maintain. You rely on a stacks of software all the time that you do not write.
AI indeed makes mistakes but so does humans so we have to validate the code we use with multiple such tools.