Skip to main content
Let’s make the central idea concrete in code: an AI component is a dependency behind an interface, swappable and fallible, exactly like a database or a cloud API. We will model a small, realistic DevOps task — classifying a log line’s severity— first the old way (specified rules) and then the new way (a learned classifier behind an interface). This compiles and runs with no network and no API key; it is about structure, not about calling a model yet.
The rule-based version is honest about its limits: anything the author did not anticipate returns UNKNOWN. It cannot generalize. A log line that means catastrophe but happens not to contain the word “panic” sails through as UNKNOWN . Now the learned approach. The key engineering move is that we do not call a model directly from our business logic. We define an interface — a contract — and depend on that. Today we back it with a mock.
Three production-relevant ideas are already visible in this small example:
  • The interface is the seam. Business logic speaks to Classifier , so the model is a pluggable detail. This is ordinary dependency inversion — the same discipline you apply to databases — and it is how you keep an unpredictable component from infecting the rest of your system.
  • context.Context is threaded through. A model call is network I/O. It must be cancellable and have a deadline. We honor ctx even in the mock so the shape is right from day one.
  • There is always a fallback. When the model is down, over budget, or too slow, the rules-based Classifier keeps the lights on. Degrade, don’t fail.
Last modified on June 8, 2026