Skip to content

Platform and developer productivity team

Owns the rules, the tooling and the execution environment that everybody else works inside.

Platform and developer productivity team

Who this is

The team that sets up the paved road: the linting, the CI, the templates, the agent configuration, the conventions that make one repository legible to somebody who has never seen it. Their output is other people's defaults.

How they work

They write a rule once and expect it to apply everywhere. With assistants in the loop, the rule has to be loaded by a machine that did not attend the meeting, in a repository the author has never opened, under a provider whose configuration file has its own opinions.

What goes wrong

Rules that exist and are never loaded. Provider files that disagree with each other because each was edited separately. A policy that changed in one place and stayed stale in the four projections of it. Enforcement that everyone believes is running and that nothing actually invokes.

20 moments

Every moment that names this one. Derived from the moments; this page keeps no list.

  1. found two agents fixing the same bug in two branchesTwo workers spend a day each on one defect because ownership was implicit and neither could see the other. cost: highcommon Why, and what to do →
  2. opened CLAUDE.md and AGENTS.md and found two different rulebooks for one repositoryEach provider reads its own hand-edited file, nothing relates them, and which contract applies depends on which tool is open. cost: highcommon Why, and what to do →
  3. found the rule for that directory in a README no session ever loadedA local rule is either in the always-loaded file, where every session pays for it, or beside the code, where nothing relates it to the path being edited. cost: highcommon Why, and what to do →
  4. read three roadmaps for one project and believed none of themA plan kept in prose is a snapshot, and every copy of it drifts on its own schedule; stored status is an assertion that stays true after the world moves. cost: mediumcommon Why, and what to do →
  5. watched the always-loaded instruction file grow past a thousand linesEverything important gets appended to the always-loaded file, so every session pays for every rule and reads none of them carefully. cost: mediumcommon Why, and what to do →
  6. watched one worker revert another worker's change, on purposeA worker sees an unexplained change in its path, judges it wrong, and removes it — correctly, on the evidence it had. cost: highoccasional Why, and what to do →
  7. changed a policy in one place and found the old one still in force in three othersA decision is updated at its source and the generated copies keep serving the previous version, with nothing reporting the difference. cost: highcommon Why, and what to do →
  8. found a rule everyone believed was enforced and nothing ever invokedEvery artefact of enforcement exists — the rule, the script, the test — and no path connects them, so the control is fiction. cost: highcommon Why, and what to do →
  9. found code that contradicted a decision the repository had written downThe decision was recorded and the implementation went the other way, because nothing relates a decision to the paths it governs. cost: highoccasional Why, and what to do →
  10. closed an issue whose acceptance criteria nothing had actually checkedCompletion is recorded as a state change in a tracker rather than as evidence in the repository, so the two drift immediately. cost: highcommon Why, and what to do →
  11. was asked how far the milestone had got and had to go and ask four peopleProgress is an aggregate that exists only in people, because the parts it aggregates were never recorded in a form anything can add up. cost: mediumcommon Why, and what to do →
  12. read a promise in the README that no test stood behindA sentence describing what the software does is written once and never connected to anything that would fail if it stopped being true. cost: highcommon Why, and what to do →
  13. shipped an interface change whose contract document still described the old oneA contract maintained by hand beside the code it describes goes stale on the first change that forgets it. cost: highcommon Why, and what to do →
  14. pasted a command from the documentation and watched it failExamples are written once, in prose, and nothing ever executes them again. cost: mediumcommon Why, and what to do →
  15. had a green pipeline over generated files that no longer matched their sourcesTests exercise the code and say nothing about the committed outputs derived from it, so the build is green and the artifacts are wrong. cost: mediumcommon Why, and what to do →
  16. found the same thing explained three times, slightly differentlyEvery hand-maintained copy of a fact drifts on its own schedule, and a reader cannot tell which copy is the current one. cost: mediumconstant Why, and what to do →
  17. published a page that promised more than any test could supportPublic material is written by a different act from the code, so it drifts ahead of the behaviour and nothing brings it back. cost: highcommon Why, and what to do →
  18. reviewed a well-written contribution that broke a convention it had no way to discoverAssistants let anybody produce plausible contributions at volume; the conventions that make one correct are still only in the maintainers. cost: highcommon Why, and what to do →
  19. could not reproduce a result because nothing recorded the state it came fromThe result is recorded and the conditions that produced it are not, so it is an anecdote rather than a measurement. cost: highoccasional Why, and what to do →
  20. was asked who made a change and under what policy, and had only a commitAttribution stops at the commit, so what authorised a change, what verified it and what governed it are unrecoverable. cost: highcommon Why, and what to do →