I find that deeply understanding code is nearly the same level of effort as writing it. That's what I don't really get about AI productivity claims as there is is really only one way to get the coveted 10-100X boost: stop looking at the code.

Of course that is perfect for MVPs, speed runs, getting the general shape of something before you commit to an implementation but for many classes of production code that is too high of a risk to take.

I'd like to hear other's experiences however. Has anyone found a way to get >10X productivity gains with AI in production code with AI?

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.

• frez1

  yesterday at 5:02 PM

  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.

You still need other humans to validate and check.

For any design docs, have them do a walkthrough with the team. If they have to speak to their plan live and answer questions, it will be obvious if they've put thought into it or not.

The same thing can be done for any PRs that have some depth to them like if they touch critical logic or involve complexity.

• emergent535

  yesterday at 7:36 PM

  More and more of the validation can be offloaded to AI, focus on faster feedback instead.

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.

> Company is pushing for AI-first

> But how do we enforce engineers to have a deep understanding of the code that they are shipping?

By not pushing AI-first mindset. When you start tracking token usage metrics, people will optimize for that metric.

If you don't push them, and tell to use AI as a tool, they will optimize for understanding the code

Code reviews don't catch bugs, tests do. AI writes docs fine if your tests work. Juniors learn by shipping, not memorizing patterns. Stop forcing explanations. Build systems that auto-rollback and alert you. That's engineering.Understanding every line is dead. Monitoring and fast feedback matter way more.

• adil_alaoui

  yesterday at 8:43 PM

  Nice approche when you say "Build systems that auto-rollback and alert you", I would say also to have a solid AI coding pattern stucture well explained in Claude.md/READ.me, Skills, Hooks, Plugins, MCP and LSP

• midhunsezhi

  yesterday at 9:08 PM

  using AI to reply to this thread is hilarious!

I think there are two different problems that get mixed together here:

1. Did the engineer personally understand this change? 2. Is this change allowed to affect critical parts of the system?

The first one is hard to enforce mechanically. You can require design docs, tests, PR explanations, walkthroughs, etc., but a determined person can route all of that through an LLM too.

The second one is more enforceable, and I think it matters a lot in the AI-coding world.

Not all code deserves the same review posture. A dashboard, script, prototype, migration helper, etc. should be able to move fast. But auth, billing, security-sensitive logic, and core business rules should not quietly depend on code that was “just agent output” or barely reviewed.

The pattern I’ve been experimenting with is explicit trust/review tiers in the codebase:

- low-risk / vibe-coded code can exist - agent-touched files get marked as lower-trust - humans can restore trust after review - CI enforces that high-trust code cannot import lower-trust code - critical directories can be required to stay high-trust

This doesn’t prove the engineer understood the code. Nothing really does.

But it does create review memory in the repo. If a file was touched by an agent, that state is visible in the diff. If someone promotes it back to a trusted tier, that promotion is also visible in the diff, and reviewers can ask “did you actually read this?”

I ended up building a small OSS tool around this idea called Tears: https://github.com/Thillel/tears

The slogan is a bit tongue-in-cheek, but it captures the point: vibe-code responsibly.

The framing of "enforce" is the problem. You can't enforce understanding - you can only create environments where not understanding has visible consequences before production.

What works in my experience:

1. Code review with "explain this to me" questions. Not gotchas, genuine "walk me through why this works." If they can't explain it, it doesn't merge.

2. On-call rotation for what you ship. Nothing motivates understanding like being woken up at 3am by your own code.

3. Pair programming on complex features. Not watching - actually driving together.

The real question is: are they shipping code they don't understand because they're lazy, or because the codebase is so complex that nobody fully understands it? If it's the latter, the problem isn't the engineers - it's the architecture.

nasıl yapılabilri

Trying to enforce "deep understanding" is optimizing wrong layer. Focus on: . Fast rollback . Good observability . Small PRs Understanding become emergent, not enforced.

• emergent535

  yesterday at 7:15 PM

  This is the way. More tests, and creating an architecture that allows an agentic harness to quickly deliver insights should be the priority. Knowing the details of the codebase is going to become an archaic way to manage large codebases.

• frez1

  yesterday at 5:04 PM

  Doing this without deep understanding can lead you down wrong paths that aren't easily fixable though.

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 ?