Ask HN: How to enforce engineers to understand the code they are shipping

Everyone is using AI for everything now. Company is pushing for AI-first and encourages the adoption of AI in every part of our work.

AI for planning, AI for RFC, AI for writing code, AI for creating PRs. Sure we can have harnesses and tests to ensure nothing breaks. But how do we enforce engineers to have a deep understanding of the code that they are shipping?

Our team has the usual suggestions: write a plan first, write test cases first, etc. But in this age, how do you verify that the engineer did not simply delegate these tasks to an LLM first?

Also genuinely worried about junior engineers' growth if this is the future.

We also have the problem that a (junior) engineer may not have the skills to understand the AI code.

When you writes code yourself, you only use concepts you have come across previously. But if you generate an AI solution, it may well use concepts one has not previously come across.

What do we expect a junior engineer to do then, if they do not have time to learn the concepts used ? Do we really think they will reject the AI code and implement their own, more familiar, solution ?

I think this is company culture. You're asking how to make your engineers give enough of a damn about their output to spend the extra time understanding it.

Did they do this before AI? Does the company really, truly care about software quality or are they just trying to ship features?

Things like

- in depth code reviews

- encouraging sharing knowledge and helping others

- dedicating time to address technical debt

- giving engineers freedom to explore technologies and solutions

- following best practices for software dev

- hiring the right people

This is one of those things you can't enforce, but your leadership can encourage it by setting examples. If your company does not care about understanding the software by carving out time and explicitly encouraging it, then employees won't either.

Im the pre-AI era you could ask engineers to write a document and that proves they've thought/ not thought a problem space out. having docs be an important part of your company culture was essentially the forcing function for everything else.

With AI, docs are now very cheap to produce and not immediately proof of thought.

e.g. if you see something that doesn't make sense you can't just ask the author to write a doc for it anymore, because they'll just feed that to an LLM.

AI can do a lot, but engineers still gotta actually know their code. Have them explain it in reviews or docs, do some pair programming, or just walk through their thinking. Tests catch bugs, but understanding comes from being able to justify why stuff exists and how it works. Especially for juniors, this is how they actually level up, AI or not.