Saying "I don't look at the code" is not the flex you think it is.
I wouldn't want to fly on a plane where the pilot said "this plane has autopilot, so I don't look at the controls."
I wouldn't trust a doctor who said "I have no idea what's in this medicine, but it gets results."
I wouldn't hire a lawyer who said "I don't look at the arguments before I make them."
I wouldn't vote for a politician who said "I don't know why UBI works, but it makes people happy."
I wouldn't move into a building where the architect said "I don't look at the structural details. It has four walls and a roof so it's a functioning house."
If your business or side-project works without you needing to look at the code, great. I'm happy for you.
If you are directly responsible for a codebase or product as an engineer, I'd hope you'd be able to know how and why the code works the way it does. You don't need to write every line of it (I don't these days).
Understanding why code works the way it does doesn't require reading every line and memorizing it. Understanding the architecture and design principles does make you a better, more effective engineer, who can build and ship better products faster than the person who needs to have an LLM reinterpret the codebase for every prompt and bug fix needed.
The best makers I know are those who know how and why things work. They can think outside the box to come up with new innovations and solutions. They craft better products not by being first to market (that makes you an entrepreneur, not a maker), but by caring about the little things while the big things take care of themselves.
If you don't understand the code your LLM writes, take a few minutes to ask it to explain things for you. Change the code to understand what breaks when you make changes. I promise your next prompt will give you better results if your brain understands one percent more of how the code works.
