The article highlights the key aspect which is often forgotten or neglected: the challenge of a large enterprise transformation project (like platform development and adoption) is no more technical than it is political and organizational. The greatest technical vision will fail if there is no efficient decision making structure, political kinetic energy, or process authority around it.
The problem is simple: everyone underestimates the size of the operations/maintenance effort required. The team was simply too small.
The team is too small because no-one wants to pay for it. Every team that uses it has their own budget to do their own things. Because these teams do application development instead of platform development, they underestimate and undervalue the work involved. They are literally not competent when it comes to evaluating the cost of the platform.
You’re being facetious when saying you’re just using this tool.
You make this tool and are marketing it in this post, end of story. At least own it, the way you’re marketing here doesn’t even make me click on the link.
The point about agents finding tools through AGENTS.md and skills rather than a portal matches my week. We added an AGENTS.md to every repo and rewrote our setup tutorial as a skill an agent can follow, and that took an afternoon.
The guardrail half was harder, and it failed in a way the article doesn't cover: silently. We require every commit in a PR to be signed. It was written down and enforced by a required check. A contributor's PR still sat for six days, because on a fork the check waited for a maintainer to approve the run and told the author nothing. Nobody was blocked by policy; they were blocked by a guardrail that didn't speak.
We changed the check to comment on the PR with the exact commits, the reason and the two commands that fix it. A guardrail that fails without telling anyone is as bad as a golden path nobody can find.
The team is too small because no-one wants to pay for it. Every team that uses it has their own budget to do their own things. Because these teams do application development instead of platform development, they underestimate and undervalue the work involved. They are literally not competent when it comes to evaluating the cost of the platform.
You make this tool and are marketing it in this post, end of story. At least own it, the way you’re marketing here doesn’t even make me click on the link.
The guardrail half was harder, and it failed in a way the article doesn't cover: silently. We require every commit in a PR to be signed. It was written down and enforced by a required check. A contributor's PR still sat for six days, because on a fork the check waited for a maintainer to approve the run and told the author nothing. Nobody was blocked by policy; they were blocked by a guardrail that didn't speak.
We changed the check to comment on the PR with the exact commits, the reason and the two commands that fix it. A guardrail that fails without telling anyone is as bad as a golden path nobody can find.
Hello, Mr. Opus