We can often find ourselves stuck in the same conversations about how far we should trust AI with software development. Framed as an organization wide decision. We either trust the agents or we do not. We either monetise faster or we play it safe.
Framed like that, it is a bad question, since both answers are incorrect for most of your code.
One switch for everything error
However, the reality of any real system is that not all code is created equal. An internal script you created to throwaway, and a module driving a regulated customer facing process - these types of things are not the same thing, and treating them like they are will result in one of two forms of failure.
You need to crawl everywhere, even in the experiments and internal tools where caution buys you nothing if you set the bar for the whole organization where the riskiest code needs it.
When set to the level a piece of code is willing to tolerate as error, you are taking risks exactly where your mistake bubbles up either way through an interaction with a customer or reaches out to regulators.
We get out by getting away from a corporate level decision and instead making the decision at the module level.
Two tiers, one spectrum
Each module sits somewhere on a continuum between two levels.
Start tier, for prod internally facing tools, experiments and prototypes.
- It samples inputs for the comprehension gate, which is not applied to each and every change
- Rollback is optional but not a must-have for shipment.
- Observability is basic.
The focus is on speed and learning. Optimize for momentum, the cost of being wrong is low.
Target tier, for anything customer-facing, regulated or publicされている
- The comprehension gate operates on every single change.
- This means writing the rollback procedure in advance and preparing for testing it, rather than improvising while an incident occurs.
- Every runtime decision is replayable.
- A periodic inspection determines that an alternative model could fill-in, preventing a vendor failure from shutting the line.
The point is trust. That target has a large radius as well, so the bar is raised.
Ours is a spectrum, not a binary one. The best modules move along it as the role of that module changes; most of them just sit somewhere on it.
How do you decide what goes where in a module
Requires no intuition from you. A module has a reliable placement for four questions:
- Customer impact. How directly does this impact the customer: production-facing or solely internal?
- Reversibility cost. How easily can it be rolled back should something go wrong?
- Regulatory scope. Does this fall in a compliance boundary or out of a revenue boundary.
- Incident blast radius. Are the damages localized or widespread, should it fail?
TOP: Higher across all four perches inover the target uppe. Weak or mixed points to the start tier. And if the situation of a module changes, for instance an internal tool starts touching customers then that is what needs to be reviewed whether it should remain in which-tier or given more priority, and not simply based on a date on the calendar.
A point worth saying out loud
This is a part of us that matters to people not just architecture.
While keeping regulated or safety-critical code under strong human oversight and within a tightly controlled AI competency model is poor engineering practice, it is not a sign at all of the team lagging behind the rest of the organization.
Say it explicitly. Otherwise the people working on that code get judged according to those racing ahead at the start tier, and they appear to plod slowly by comparison, when in fact they are doing precisely what is required given the risk involved. The decision being named protects them and the quality of the work.
Tiering also breaks up the fight or die gambit. No need to decide if your company is "pro-AI" or "AI cautious." You can be heavily aggressive with autonomy where it's inexpensive to be wrong, and quite conservative where it's expensive within the same company during the very same week. That is not a compromise. It ties the level of interest to the level of risk which is what good engineering did for ever.
If someone were to ask you today what your modules belong in the start tier, and which belong in the target tier - would you be able to give an answer framework for that, or is it a gut call on each individual pull request?
No comments:
Post a Comment