How do we enable our engineers on Codex, Claude Code and Cursor?
AI harness & platform engineering
Sold asAI Engineering Transformation · Enablement, guardrails and CI · typically 6–12 weeks
Vendors build the harness. 1AYM sells architecture, skills packages, guardrails and CI on Codex, Claude Code and Cursor, so AI-assisted changes take the same path to production as every other change, and so the company can move work between those tools without rewriting the operating layer. We do not build a proprietary harness in place of Claude, ChatGPT or Cursor. Those vendors maintain the runtime; we make it usable, governed and portable across the estate.
What the engagement covers
The client already has vendor harnesses. The missing piece is the layer that makes them safe to depend on across teams: how work is structured, which skills are shared, what the model may touch, and how a change is reviewed and shipped.
Architecture
Which harness is used for which job, how the company's systems sit relative to it, and what is shared rather than rewritten per team.
Skills packages
Reusable skills the vendor harness can load, so a workflow is owned once and used on Codex, Claude Code or Cursor as the work requires. To evaluate managing those reusable skills, agents and plugins in a product, explore a guided 1AMS pilot.
Guardrails
Repository rules, permissions and the actions that need a person, enforced in the path to production rather than as a policy slide.
CI and review
The same gates every other change already passes, so AI-assisted work is not a side channel.
Enablement
Training and the operating model your engineers keep when the engagement ends.
Built on the tools already in use, not instead of them
Engineers are already in Codex, Claude Code or Cursor, with or without a policy. The engagement starts there. It maps those workflows to how the teams actually ship, then adds the architecture and the gates, rather than asking anyone to abandon the vendor harness for a house-built substitute.
That sequencing keeps the work honest: every control exists because a real repository and a real release process demanded it.
Whether to standardise on Codex or Claude Code is a separate decision. Our side-by-side of Codex and Claude Code for a business covers the entry seat price, what moves across in a switch and where each tool keeps its controls.
If GitHub Copilot is already in place, our comparison of Claude Code and GitHub Copilot sets out where each runs, how each is billed and which admin controls each gives you.
Where Codex arrives as part of a company-wide ChatGPT Enterprise workspace, its permissions are set in the same rollout as everyone else's access, and our plan for rolling out ChatGPT Enterprise shows where the engineering track fits in the first 90 days.
What you get
- Architecture for how vendor harnesses are used across the estate
- Skills packages reusable on Codex, Claude Code and Cursor
- Repository guardrails and permission model
- CI gates and the review path to production
- Enablement, documentation and an operating model your team owns
Start here if
- Engineers are already using Codex, Claude Code or Cursor, and nothing consistent sits around that
- Each team has invented its own skills, permissions and review rules
- AI-assisted changes reach production by a different path from everything else
- A second vendor harness is arriving and the first one's setup cannot move with it
Frequently asked questions
Does this lock us into one model provider?
No. The architecture is written to sit on the harness rather than inside one vendor's product, so Codex, Claude Code and Cursor remain the runtimes, and the skills packages and guardrails go with you when the mix changes.
Can we keep the tools our engineers already use?
Yes, that is the starting point. The engagement maps Codex, Claude Code and Cursor to how the teams ship, then adds architecture, skills and CI around them.