Map a path. Wire a handler. Sync Tyk. Update Cerbos. Deploy three repos.
Again.
If you have ever shipped an API platform, you know this loop. You have probably done it on autopilot. That is exactly the problem.
Do it twice and you shrug. Do it three times and a good engineer starts asking uncomfortable questions. Why are we still clicking? Why does every endpoint feel like a small science project? Why does onboarding a customer still touch four systems that do not talk to each other?
For a CISO or CTO, the bill arrives as policy drift, slow access reviews, and audit evidence scattered across repos nobody wants to open. For a business leader, it is packaging delays and no clean answer to "who touched this data, when, and under what contract." For a startup sprinting toward SOC 2 or ISO 27001, it is the gap between "we have APIs" and "we can prove we meant every one of them."
At Human Managed, we stopped treating that repetition as background noise and started treating it like raw material: specification-driven development, custom agent skills, and a Plan-Build-Review rhythm that gives machines a contract instead of a vibe.
Your brain checks out before your servers do
Cognitive load theory is not soft stuff. Working memory is finite [1]. When the same administrative decisions show up every week, paths, policies, gateway limits, data mappings, your brain eventually runs the numbers and decides the task is not worth full attention [2]. That is not laziness. It is a motivational shift: repetition gets routed to muscle memory, shortcuts, or avoidance.
Frank Bunker Gilbreth said it in 1947: put a lazy person on a hard job, and in ten days they will find the easier way. Stewart Butterfield said the software version: "There's a lot of automation that can happen that isn't a replacement of humans, but of mind-numbing behavior." The World Economic Forum's jobs work describes the same handoff, from doing the task to designing and overseeing the system [3].
So yes, automate. But not everything. Fixed automation for one job. Programmable flows when the steps are known. Software automation for digital chores. Intelligent automation when context matters. Jensen Huang, 2022: "Software is the language of automation. And AI is the engine of automation." Endpoint provisioning at platform scale usually earns a bot. The one-off exception your sales team swears will never repeat again? Probably not.
The shift you want is from human-doing to human-managing. Less typing the same handler scaffolding. More deciding what should exist, who gets access, and when an endpoint has outlived its purpose.
Every endpoint is six decisions wearing a trench coat
Before we automated anything, we forced ourselves to write down what "add an endpoint" actually means. On our stack, it is never one step. It is six:
Workbench context (hm.works, invicta.io, and the rest)
Identity: service and resource names
Authorization: resource policies evaluated in Cerbos
Gateway layer: Tyk paths, rate limits, CORS
Data layer: connection to the source system
Data mapping: table or view, sometimes with schema validation
Each choice is reasonable in isolation. Across teams it becomes a relay race with no baton. Data teams expose physical and logical views and push config without touching core API code. Frontend teams wire new endpoints through configuration. Sales and ops define packaging, contracts, effectivity dates. Speed is useless if you skip the security gate on the way out, especially when regulated data and compliance evidence depend on consistent access controls.
Here is the request path that actually runs in production: client over HTTPS, Tyk at the edge, FastAPI for business logic, Cerbos before anything protected touches Snowflake, PostgreSQL, BigQuery, or whatever backend a workbench needs. The runtime path is stable. The admin work around it was not. That mismatch is where platforms bleed time.
We mapped the lifecycle. We did not finish it.
We grouped the administrative loop into three phases:
Phase 1: Path and service mapping. Versioned paths such as /v1/service/assets, each bound to a dedicated handler.
Phase 2: Automated request handling. Request schema validation, real-time Cerbos authorization, cache checks before expensive fetches.
Phase 3: Deployment and synchronization. Refresh Tyk definitions, sync service-specific authorization policies, release across the three core repositories.
Inventing endpoints was never the hard part. Fragmentation was. Subscriptions, onboarding, gateway configuration, and authorization lived in separate silos with weak handoffs. Integrated lifecycle management would give you granular usage metrics: which organizations touched which data points, and when. That is how you decide to decommission a legacy path instead of letting it rot in production because nobody remembers who still calls it. It also points toward ERP-style asset management if you want one system of record for what is exposed, to whom, and under which contract.
Some of this runs today. Onboarding handoffs and legacy retirement are still open work. We are not going to pretend otherwise. The direction is clearer than the finish line.
Vibe coding is how architectures go feral
Generative coding without a contract produces inconsistent artifacts and architectural drift. You have seen it. The handler works. The tests are weird. The docs describe a different API than the one in Tyk. Three PRs later, nobody can reconstruct the original intent.
We moved to specification-driven development: define structure, constraints, and behavior before generation. SpecKit for greenfield work. OpenSpec for brownfield changes. BMAD-Core if you want to simulate a multi-agent agile team and you are comfortable conducting that orchestra.
The specific kit matters less than the contract. Specs live as versioned Markdown and YAML frontmatter. API docs, client libraries, and tests are generated from that source. Change the spec, trigger updates across downstream artifacts. Sync over syntax, not hope.
Abdul Jaweed on our team put the grounding problem plainly in 2026: "To ground the LLM and reduce hallucinations, it is better to use skills and plugins." We use the Vercel skills CLI as a primary action layer, pulling standard cloud skills from Vercel and domain-heavy skills from Tessl through one interface.
Here is the rule we actually use: twice is a pattern worth writing down. Three times is a candidate for a custom skill. When the same boilerplate shows up three times in an AI-assisted workflow, encode it. Individual tricks become team commands. Your environment gets sharper the longer you work in it. That is compounding, not magic.
Sharpen the axe before you generate code
Specification work sits inside Plan-Build-Review. Peter Drucker said it better than most sprint retros ever will: "Follow effective action with quiet reflection. From the quiet reflection will come even more effective action."
Define what and why before how. Set goals, scope, risks. Define out-of-scope early. Saying no to advanced multi-user support or external integrations at the start beats rescoping mid-build when you are already emotionally attached to the wrong design.
Knowledge feeds the plan. Research dumps in OneNote or Superhuman Docs (formerly Coda), cited where possible. Zettelkasten-style linking, unique IDs, cross-references, turns fragments into something you can reuse. Niklas Luhmann ran the extreme experiment: roughly 90,000 index cards, 50+ books, 550+ articles, all connected by branching IDs. You do not need Luhmann's volume. You need his discipline. Obsidian, LogSeq, or Markdown with frontmatter all work. Structure beats tool choice.
Objectives should be specific enough to test. Spec-Kit can express them as Given-When-Then behavior specs. Metadata frames the rest: Dublin Core for document categories, Diátaxis for tutorial versus reference versus explanation, RACI for ownership, status from draft through archived. Keep research, knowledge, and specification documents separated. Draft notes should not become accidental source of truth because someone published the wrong folder.
Automate with restraint, or you will automate the mess
Automation is a tool, not a moral obligation. We look for configuration-first wins before heavier AI or infrastructure. Success is complexity removed from daily workflows, not a leaderboard of bots deployed.
If you run a similar stack, start with the noisiest admin loop. Name the six endpoint decisions. Write the spec before the handler. Encode the third repeat as a skill. Keep humans on policy, pricing, and interpretation. Machines run. Humans managed. That is not a tagline for us. It is the design constraint.
We are still wiring pieces of the autonomous lifecycle. Fragmented onboarding and legacy endpoint retirement are not solved problems. But the question worth carrying out of this is simpler than it sounds: if your team has done the same administrative sequence three times, what are you waiting for? A spec? A skill? Or another quarter of the same clicks?
References
[1] J. Sweller, P. Ayres, and S. Kalyuga, Cognitive Load Theory. New York, NY, USA: Springer, 2011.
[2] M. Inzlicht and B. J. Schmeichel, "What is ego depletion? Toward a mechanistic revision of the resource model of self-control," Perspectives on Psychological Science, vol. 7, no. 5, pp. 450–463, 2012.
[3] World Economic Forum, "The Future of Jobs Report 2023," 2023. [Online]. Available: https://www.weforum.org/reports/the-future-of-jobs-report-2023/
