The staff engineer who writes rules, not code
The shift from writing implementations to writing constraints is real and mostly correct. It is also invisible to every measurement system your organisation runs, which is how good versions of this role quietly starve and bad versions quietly proliferate.
A staff engineer spends a fortnight writing an architecture fitness function, a set of merge conditions and four executable checks that block a class of change the team kept getting wrong. Nothing ships. The sprint board shows one ticket, moved once.
The same fortnight, a senior engineer on the same team lands eleven pull requests.
At the end of the quarter, one of those two people has a legible record and the other has a story. I have watched this play out often enough to state the pattern with some confidence: the rules-writing role is real and valuable, and delivery organisations starve it by accident, because every measurement system in the building counts artefacts that this work does not produce.
My position: the move from implementation to constraint is right, and it will fail in most organisations for entirely non-technical reasons unless someone deliberately builds a way to see it. That is a delivery problem, not a philosophical one.
What the role actually produces
Be precise about the output, because “writes rules not code” is vague enough to be a rationalisation.
The valuable version produces executable constraints. A lint rule that makes a whole category of mistake impossible. A test that fails when a module gains a dependency it should not have. A merge condition tied to an acceptance criterion. A schema for how work items must be specified before an agent picks them up. Codified conventions that an agent reads and a check enforces, so that the same decision is not relitigated in review forty times.
The failing version produces prose. A wiki page nobody reads. A design review process. A set of principles. Governance documents with the word “should” in them.
The distinction is not seniority or intent. It is whether the artefact acts. A constraint that runs changes behaviour whether or not anyone read it. A constraint that has to be read competes for attention with everything else competing for attention, and it loses.
Rules that rot
- Live in a wiki, enforced by memory
- Phrased as principles, not conditions
- Nobody owns removing them
- Cannot be tested against a real change
- Accumulate, because deleting one requires an argument
Rules that pay
- Execute in the pipeline, on every change
- Phrased as a condition on an artefact
- Have an owner and an expiry review
- Produce a count of what they caught
- Get deleted when the count is zero
Take the objection seriously
There is a real argument against all of this, and it is not the one people usually make. It is not “senior engineers should keep coding to stay sharp”, which is a preference dressed as a principle.
The real argument is that rule-writing is an unusually comfortable place to hide. It has no user, no deadline that bites, and no falsification event. You can produce constraints indefinitely without ever finding out whether they were needed, because a rule that catches nothing looks identical to a rule that prevented everything. That is a genuinely dangerous property for a role held by the most expensive people in the organisation.
And rules proliferate. Every one is easy to add and politically hard to remove, because removing it means arguing that a risk somebody once cared about is now acceptable. Ten years of that and you have a pipeline where a two-line change takes four days, and nobody can tell you which of the twenty-eight gates it passed through were load-bearing.
Both of those are true. They are the reason the role needs a measurement, not the reason it should not exist.
The measurement that makes it fundable
The unit is not rules written. It is interventions caused.
Every executable constraint should be able to answer: how many changes did you stop in the last ninety days, and what happened to them. That number has three useful readings and all of them are actionable.
A high count means the rule is load-bearing and probably also that something upstream is broken, because a rule catching the same mistake weekly is treating a symptom. A moderate count means it is doing its job. A zero count means either the behaviour it prevents has been designed out, in which case delete the rule, or it never happened, in which case it was never worth having.
That gives a rules-writing engineer something a performance cycle can read: a portfolio of constraints with intervention counts, an expiry review on each, and a record of deletions. Deletions matter as much as additions, and I would look harder at a staff engineer who removed six gates this year than one who added six.
The sequencing that actually works
If you are a delivery lead trying to fund this, the failure is almost always doing it in the wrong order.
Start from recurring review comments, not from principles. Pull the last three months of review threads and find what gets said repeatedly by humans. That list is your rule backlog, already validated, already prioritised by frequency, and it has the enormous political advantage that everyone on the team has personally been annoyed by every item on it.
Write the check before the document. If the constraint cannot be expressed as a condition something can evaluate, it is not ready. That test alone kills most governance drift, because “we should think carefully about coupling” does not survive it and “no module in billing may import from reporting” does.
Give every rule an owner and a date. Not a review board. One name, and a calendar entry in six months where the default is deletion.
And protect the time explicitly. This work will not happen in the gaps between tickets, because there are no gaps, and an engineer with eleven merged pull requests and no constraints written will out-read on paper every time. If it is not on the board with a name against it, it is not funded, whatever anyone said in the planning meeting.
Where this breaks down
Interventions caused is gameable, and I have just handed you the recipe. An engineer optimising that number writes noisy rules that stop lots of harmless changes. Every metric attached to a performance conversation degrades, and this one degrades in a particularly annoying direction, because the cost lands on everyone else’s cycle time. It needs a counterweight, probably false-positive rate, and I have not seen anyone measure that well.
Some of the most valuable rules will never fire. The constraint that made a bad architecture impossible has an intervention count of zero forever, and by my own criterion you would delete it. That is a real hole in the measurement. My honest answer is that the deletion default is still better than the accumulation default, but I am trading a known failure for an unknown one.
The strongest objection is that this role is a symptom, not a solution. If your codebase and specifications were in good shape, you would not need a person whose full-time job is writing constraints to stop agents doing the wrong thing. The rules layer might be scar tissue around a problem better solved upstream, and an organisation that fully institutionalises it may be paying permanently for a temporary condition.
Rule-writing is not automatically senior work. I have framed this as a staff engineer’s job, and a lot of it is not. Codifying a recurring review comment is well-bounded, high-value work with a fast feedback loop, and handing all of it to the most expensive person in the building is both wasteful and a missed development opportunity for someone earlier in their career who would learn a great deal from doing it. The judgement about which constraints matter is the senior part. The construction usually is not.
And a team can absolutely be rule-poor and fine. Small teams with high trust and a shared history often need almost none of this, and imposing it wastes their time. The argument scales with the number of people and agents making changes, and below some size it does not apply at all.
The takeaway
The shift from writing implementations to writing constraints is real, and the version that works produces things that execute rather than things that are read. What kills it is not disagreement. It is invisibility: no artefact on the board, no line in the release notes, and a performance cycle that counts merged changes.
Fix the visibility and the role funds itself. Skip that and you will get the worst of both outcomes, which is a staff engineer producing documents nobody reads while the pipeline accumulates gates nobody can justify.
If you take one thing into next week: ask your most senior engineer which recurring review comment they are most tired of writing, and fund the executable version of it. That single conversation tends to produce a better rule backlog than a quarter of architecture planning.