Modernising enterprise software with AI, security and control
How structured AI-assisted delivery can move an existing application forward, with explicit security controls and evidence for acceptance.
Chris Baran
· 5 min read
On this page
An existing application can be useful to the business and difficult to change. People depend on its behaviour. Its deployment process may need attention. The team responsible for it also has other work to deliver. Adding AI to that situation creates an opportunity, but the useful question is specific: can we move this service forward while keeping its behaviour, access and release decisions under control?
For an oil and gas company, one engineer delivered application changes, AWS infrastructure and a repeatable deployment workflow over three weeks. AI supported the implementation, with the engineer directing the architecture, security requirements, integration and review. The result gave the business a repeatable way to change and release an existing service.
The commercial lesson is a delivery method: give AI a bounded part of a real problem, make the security requirements explicit, and ask for evidence that the resulting change meets them.
Start with the service people already use
The first decision is what must survive the change. For an established application, that usually includes the user workflow, its identity assumptions, the systems it connects to and the way an operator recognises success or failure.
A migration brief should name those obligations before choosing tools. “Run this application on AWS” leaves important questions unanswered. Which users can perform which actions? What information can the application read? What has to happen before a new version reaches users? Who can restore the previous version?
The work covered the application, authentication and deployment of an existing service. Defining that scope made it manageable for one engineer to deliver across disciplines while keeping the work tied to a business need.
Turn the design into work an agent can complete
We used Superpowers to turn the design into an implementation plan with explicit architecture decisions, constraints, tasks and verification steps. That gave the AI a clear assignment and the engineer a defined result to review.
That structure makes the work easier to inspect. A task can specify the files it may change, the behaviour it must preserve and the checks it must pass. An engineer can then review a small result against an agreed requirement. Problems discovered during review become a concrete revision, with a check that demonstrates the correction.
Repository instructions such as CLAUDE.md or AGENTS.md help a model follow those conventions. Actual tool permissions, credentials and deployment gates determine what it can do. Both belong in the delivery design.
This method also helps handover. The next person can inspect a design decision, its implementation and its acceptance evidence together, instead of relying on the conversation that produced the code.
Make security part of the acceptance criteria
Security requirements become more useful when they describe observable behaviour. “Use enterprise authentication” should lead to questions about the identity boundary and the permission needed for a particular operation. “Use least privilege” should identify the resources and actions the workload actually needs.
For a comparable modernisation, we would establish a control-and-evidence table at the start:
| Delivery decision | Evidence to request | What the business gains |
|---|---|---|
| Who can use a protected operation? | An allowed request and explicit rejection of unauthorised requests | Access decisions that can be explained and checked |
| What can the workload reach? | Infrastructure definitions and checks of the deployed boundary | A documented limit on the service’s access |
| Which version may be released? | A link between the tested artifact, the approval and the deployment | A release decision tied to a specific change |
| How is the service operated? | Health checks, useful diagnostics, recovery steps and a named owner | A clearer handover and a repeatable response to problems |
This table is a starting point for agreeing acceptance in a new engagement. It makes the conversation between engineering, security and the business concrete.
One engineer, three weeks, a repeatable AWS delivery process
One engineer took the work from design and initial implementation through integration and application refinement over three weeks. The scope brought together skills that often sit across application development, cloud infrastructure, security and delivery engineering.
| Stage | What was delivered |
|---|---|
| Design and planning | An agreed architecture, a defined scope and bounded implementation tasks |
| Implementation | Application and authentication changes, AWS infrastructure and the deployment workflow |
| Integration and refinement | Connections between the application and its delivery environment, followed by refinements to application behaviour |
The business gained a repeatable AWS delivery process for an existing service, with application and infrastructure changes managed together. A written design, implementation plan and verification steps made the work easier to review and hand over.
AI provided implementation capacity across those disciplines. The engineer remained responsible for the technical decisions, security requirements and review. That combination is the practical opportunity for enterprise teams: one person can take a broader piece of work through to a useful outcome.
What this means for your next migration
The starting point is a business change worth making: an application that needs a maintainable deployment path, a workflow held back by manual steps, or a service that needs clearer access controls. Define the outcome, put one engineer in charge and use AI to increase the implementation capacity available to that person.
The approach suits a service with a clear owner, accessible source, manageable dependencies and an agreed acceptance decision. It becomes harder when nobody can explain the current behaviour, the required access is unavailable or the proposed scope combines several unrelated systems. Those are useful findings to surface before committing to a build.
Our Enterprise AI Delivery Assessment starts with that decision. Over two weeks, we assess up to three candidate use cases and develop one detailed delivery recommendation, including architecture, security controls, governance and acceptance criteria. It is a paid engagement, with scope and a fixed fee agreed after a qualification call.
Bring an existing application or a delivery bottleneck. The first useful outcome is knowing what to change, how to bound the work and what evidence would make the result acceptable.