Configure pre-commit hooks for AI code quality — lab audio overview

Host: Welcome back. You're in DevOps Foundations for GenAI Engineers — a course about the engineering practices that keep artificial intelligence projects running smoothly in production. This chapter is about Git workflows for AI teams. Git is the tool engineers use to track every change to their code. And the specific skill in front of you right now — catching bad code before it ever gets saved into the project — is one of the highest-leverage habits a team can build. Expert: Picture this. You're at a mid-sized company — maybe sixty engineers, a handful of data scientists, and a growing AI team shipping features that use large language models. Things are moving fast. Someone merges a change that accidentally commits an API key to the shared project history. Someone else pushes a prompt template — the instructions that shape how the AI behaves — with a broken piece of configuration. A third person commits code that doesn't match the team's style, and now every file in the review has noisy formatting changes mixed with real logic. Each of these problems is small on its own. Together, they slow the team to a crawl. The fix isn't more discipline from humans. It's automation that runs before any change is ever saved. That's what this exercise teaches you to build, and it's the foundation of every serious AI team's daily workflow. Host: This is your starting point for the chapter. The chapter overview walked through the big picture of how AI teams use Git. Now let's get specific. So what exactly will we build? Expert: You're going to build a small Python tool that sets up automatic quality checks — checks that run the instant an engineer tries to save a change to the project. The umbrella name for this system is "pre-commit hooks." A hook, in this world, is just a small script that fires automatically at a specific moment. "Pre-commit" means it fires right before a change is committed, which is the moment a change becomes part of the permanent project history. So your tool generates a configuration file — a plain text file that lists which checks to run — and then validates that the configuration is correct. You'll wire up five kinds of checks. First, a fast code style checker for Python called Ruff — it catches formatting problems and obvious bugs. Second, a type checker called Mypy, which makes sure that when your code says a value is a number, it actually is a number. Third, a checker for YAML files — YAML is a format used for configuration, spelled Y-A-M-L — and the checker is called yamllint. Fourth, a secrets scanner called detect-secrets, which looks for anything that resembles a password or API key and stops the commit before it leaks. And fifth, a check that makes sure every JSON file — another configuration format — is well-formed. On top of those five, you'll build one custom check of your own. It validates prompt template files — the text files that hold the instructions you send to a language model — against a strict shape definition. The library for defining that shape is called Pydantic, a popular Python tool for describing exactly what a valid piece of data looks like. Host: That's a lot of moving parts. What's the one concept someone has to really internalize before any of this clicks? Expert: The key idea is this: a pre-commit hook is a gate, not a suggestion. When an engineer tries to save a change, the hook runs, and if anything fails, the save is blocked until the problem is fixed. That's the whole magic. It means bad code physically cannot enter the shared project history. The mental shift is from "we should remember to check this" to "the system will not let us forget." Your job in this exercise is to be the author of those gates. You decide what passes and what gets stopped at the door. Host: Before someone starts, what trips people up in this kind of exercise? Expert: The tricky part is the custom prompt template check. It's tempting to write something that just opens each file and eyeballs it for obvious problems. That won't pass. The check has to do two things cleanly. First, it reads each prompt template file. Second, it compares that file against the strict shape definition you wrote — the Pydantic one — and fails loudly if anything is missing or the wrong type. The pitfall is silent failure: if your check accidentally passes files that are actually broken, the whole gate is useless. So test it deliberately with a file you know is wrong, and make sure your check catches it. If a broken file sneaks through in testing, fix the check before moving on. Host: Bring it home for us. What will someone be able to do after finishing this, and what's coming next? Expert: After this exercise, you'll be able to set up automatic quality gates on any AI project — gates that catch style issues, type mistakes, broken configuration, leaked secrets, and malformed prompt templates, all before a single change is committed. This is a building block your team can drop into every repository it owns. It's the floor — the baseline of hygiene that lets your team move fast without breaking production. Next, you'll extend this thinking outward. You'll set up a system that automatically opens requests to upgrade the libraries your project depends on, running on a schedule in the cloud. It's the same philosophy — automation instead of discipline — applied to keeping your dependencies fresh and secure. Good luck with the exercise, and thanks for listening.