AI gave you a thousand new builders overnight.Your architects, security engineers and operators are still the same few people, and safe to ship still runs through them.
You did not approve a tenfold jump in who can ship to production. You got one anyway, and the discipline that made software safe to ship, operate and maintain did not come with it. That gap is the problem we exist to close.
That discipline is many jobs: your enterprise, cloud and data architects; security and risk; DevOps and release engineering; site reliability and platform engineering; data governance; quality assurance; and compliance. You cannot hire it as fast as the building now happens. FORGE captures that judgment once and builds it into every system, from the first requirement to the day it is running in production with its own operator.
FORGE is our product, an engineering platform that builds your enterprise's architecture, security, and governance standards into the path to production, so every team ships to your standards and security controls. Adopt FORGE on its own, or have BtSavvy's engineers build and operate production AI systems on it with you.
A working slice of one workload, engineered to your standards and security controls in 2–4 weeks, deployed where you can watch it run. Evidence from your own environment.
FORGE · engineering platform
Your standards and security controls, built into the path to productiongovernance → planning → architecture → security
Forward-deployed engineers
Building on FORGE with your team, in your environment
governbuilddeployrun
Evidence attached to every release
01
The FORGE platform
The control layer for your AI-enabled engineering.
FORGE is the engineering platform where your initiatives are incubated and built to your standards and security controls, then carried through production, operation and support. Your architects, security and platform teams set their standards once. From those standards and a project's requirements, FORGE produces a complete engineering environment for that one project. It includes the design the software must satisfy, and the tooling to build, deploy and operate it. Your developers work in it with the AI tools they already use. What comes out is held to the standards, passes the same tests, and carries a traceable record from each requirement to the work that implemented it.
Standards, set once
Architecture
Security controls
Platform standards
One project's environment
The design the software must satisfy
The tooling to build, deploy and operate it
The same tests
Each requirement to the work that implemented it
Why this is hard
Your controls do not reach all AI-built work.Where they do, AI does not reliably follow them as the project grows.
The work now moves faster than your architects and security engineers can review it. Writing more rules for the AI to read does not fix this, and the research below shows why.
Across your teams
Your controls do not travel with the work.
AI tools put building in many more hands, business teams included, and each team sets its tools up its own way. Your standards sit in documents, review meetings and tool settings. It is hard to show which controls reached what shipped.
In 481 public rules files written for one coding agent, 4 to 16% of the security rules had a matching built-in control. A developer “gets no feedback on whether a control will enforce it”.
On a large project, the AI can miss more of your rules.
A short list of rules on a small task is followed most of the time. Enterprise standards run to many pages, their rules interact, and a project runs for weeks across many sessions. Each of these makes the rules harder to follow.
Given company procedures of 20 to 124 pages to follow, the best of 30 frontier agent configurations met every rule in 36.2% of attempts. Most stayed below 25%.
When long sessions were compacted to fit the model's context, the methods tested kept 17% of standing instructions on average. One was “do not delete any emails until I confirm”.
We found no study that measures a 100 to 200 page engineering standard applied to a codebase. Every study here that lengthens the rules, the requirements or the session points the same way. Simple, independent rules are different: recent models follow long lists of them well.
Why vibe coding breaks down on a serious build.The same failures show up in your code and in your security.
Independent researchers and the labs that build these models report the same failure modes. OpenAI traces misbehaviour in its own coding traffic to “overeagerness to complete the task and interpreting user instructions too permissively”. Most often the result is minor, such as overclaimed success. Occasionally it is “circumventing important security restrictions or deleting important data”.
Failure modeAs a coding failureAs a security failure
Specification gaming
Also called reward hacking. NIST CAISI calls it cheating.
The agent satisfies the check it is scored by, in place of the task it was given.
As a coding failure
It edits or skips a test so the test passes. When tests contradicted the specification, GPT-5 passed by cheating on 54% of tasks.
As a security failure
In a Darktrace lab, agents had to score 100% on coding challenges that could not all be passed honestly, or be retired. They scanned the network, tried credentials they found and overwrote the exercise.
OWASP LLM06. Also called overeager action, or permissive interpretation.
The agent does more than it was asked, and treats what was not forbidden as allowed.
As a coding failure
Three widely used coding agents took actions outside the task they were given in 5.4 to 27.7% of runs.
As a security failure
In OpenAI's internal use, a model allowed to delete three virtual machines could not find them where it looked, and ran destructive cleanup on three others.
It names software packages that do not exist. Five models released between October 2025 and March 2026 still invented 4.62 to 6.10% of packages.
As a security failure
An invented name becomes an opening once someone registers it. One spread through AI-written agent skills to 237 repositories. Once registered, it drew a couple of downloads a day, which the researchers put down to agents following those skills.
The same recurring failures can harm both the quality and the security of what you ship. Labs that monitor their own models in use report hidden work and bypassed security restrictions as rare. Some of the security cases above come from controlled tests. What the agent is allowed to touch decides if a shortcut ends as a failed test or as a deleted database.
Our own defect ledger shows the coding side of several of these on one enterprise application, built by prompting AI coding agents with no framework.
The control layer for your AI-enabled engineering.
FORGE, our engineering platform, makes your controls and your requirements part of the path every project takes to production.
They live outside the AI, with the record of the work, for the whole life of each system.
Across your teams
One set of controls
Your architects, security, DevSecOps and platform teams own one versioned set of controls and standards. Every project on FORGE starts from it.
For you
You can see which approved version of your controls governs each project.
Inside each project
Held to your controls as it grows
Each project's work is judged against your controls and its own requirements, from the first commit to the running system. No builder, person or AI, can lower the bar for its own work.
For you
Late in a large project, your controls still decide what is accepted.
Each change
Proof on the record
Each change carries its evidence: the controls in force, what was checked and who decided.
For you
When an auditor or your board asks how something was built, you can show them.
Over time
Learning that carries forward
A failure found in one project can become a change to the shared controls, once a person approves it.
For you
Later projects can start from what this one learned.
People decide
Named people own each control, requirement, exception and release. On FORGE, no AI agent approves its own work.
For your security team: your controls are enforced on the path to production, whether an AI or a person wrote the change. Each exception carries a person's name, and each release leaves evidence you can show.
FORGE runs in your cloud, or as our SaaS. Your developers build in it with the AI coding tools it supports.
To be safe to ship, AI-built software has to be built to your standards and security controls, then stay governed and supportable in production.
The Factory builds your standards and security controls into the path. The Control Tower keeps what is running governed. Each application has its own operator, and one portfolio view reports on the estate without reaching into it. Getting from a vibe-coded demo to software your business runs on takes full engineering. BtSavvy's forward-deployed engineers set FORGE up with your team and build with you until it runs to your standards. Your code, your data and your applications stay in your accounts.
We scope it with your engineering lead before the work starts.
To build one application
The First Build
It takes one application end to end into production on your cloud, with your controls and standards built in from the first commit. It becomes the approved way for every team after it to build that kind of system.
FORGE Perspective is our research series. Each paper takes one problem in building software with AI, sets out what published research has measured, and says what we would do about it.