From AI Experiments to Working Outcomes: A Practical Approach to Enterprise Delivery

Your organisation has a software backlog, systems that are difficult to change and specialist knowledge spread across documents and people. You can see opportunities for AI, but a useful demonstration still leaves a delivery question: which piece of work can you take through to an accepted, maintainable result?

That is the question behind our approach to AI-assisted software development and migration. Start with a real delivery problem, define the boundaries, and use AI to carry substantial work forward within them. Senior engineering judgement connects the work to its purpose, determines how it will be verified and decides when it is ready to use.

Two projects make that approach tangible. Rebuilding this website demonstrates migration and continuity. Building otarimx5050.com demonstrates how software and AI-assisted research can make specialist knowledge usable—and support a practical outcome in an unfamiliar technical field.

Give AI a defined body of work

A useful starting point is a task with a clear owner, accessible source material and a result that can be checked. That might be a migration candidate, a neglected internal tool or a technical reference library that people struggle to use.

The questions are concrete: what must the result do, what must remain intact, which information can the tools access, and who will accept the work? Answering them creates room for autonomy while keeping the work connected to a business need.

We used Claude and GPT models across our development work, with the Superpowers plugin structuring brainstorming, specifications, implementation plans, scoped tasks, review and verification.

In our experience, those boundaries enabled the LLM to work autonomously for more than 10 hours and produce highly accurate results. An agreed scope, a written plan and explicit checks gave it substantial work to carry forward without a person prompting every individual change.

The specifications and repository instructions also helped carry intent between sessions and tools. The source and tests recorded the implementation. Human judgement remained responsible for scope, visual quality, acceptance and the decision to go live.

Explore Superpowers on GitHub →

Proof one: migrate a working system and preserve its value

Our earlier website architecture used WordPress to author content, exported it as static files and delivered it through Amazon S3 and CloudFront. We wanted to evolve that site directly with AI development tools, working on its source rather than its generated pages.

We moved to Next.js, structured MDX content and reusable React components, retaining the AWS delivery foundation. Content, implementation, infrastructure definitions and development instructions now live in a version-controlled repository that people and agents can inspect and change.

This is what we mean by “LLM-native”: a source structure suited to working with these tools. Visitors do not need an AI model to read the website. The durable asset is the repository, including the decisions and checks that help another developer maintain it.

The migration had to preserve eight articles, the About and legal pages, images, established links and the character of the marketing site. Content comparisons, redirect checks, browser reviews and a cutover runbook supplied evidence against those requirements.

Review also found mistakes. The About page’s “Simplify. Scale. Succeed.” labels were omitted in one implementation, then restored and protected by a more specific test. Visual feedback drove further revisions to the homepage and About page. A passing build alone could not determine whether the result still served the business.

For an enterprise migration, the same discipline starts with identifying what must survive and how to prove it. The appropriate architecture depends on the users: a developer-oriented workflow is not automatically a suitable replacement for a CMS used by an editorial team.

Proof two: turn technical knowledge into a practical outcome

The Otari project grew around the restoration of a reel-to-reel tape recorder. Its website became a working resource for the restoration itself.

With limited formal training and study in electrical engineering, I used the site and the AI-assisted research behind it to complete a full recap and calibration of the recorder, without an expert guiding me through the work. I was able to enter a deeply technical subject, develop the understanding needed for the task and apply it to a physical machine.

Building the software, organising source material and learning the subject reinforced each other. The site brings together:

• Digital manuals and brochures, structured as navigable editions.
• Zoomable vector drawings with original-scan comparisons, so readers can inspect both the clearer drawing and its source.
• Source annotations, which distinguish printed errors from explanatory corrections.
• Interactive electronics explainers and search, helping readers explore concepts and find relevant material.

None of the Otari site’s copy was edited directly in an editor. We reviewed the output and sent prompts back to the LLM for specific revisions; the LLM made the changes. Human editorial judgement operated through direction and revision prompts.

You can explore the document library and interactive audio explanations. They show a path from scattered source material to a resource that supports learning and practical work.

For an enterprise, possible applications include maintenance documentation, technical onboarding and specialist reference tools. The opportunity is to make existing knowledge easier to find, understand and apply, with source evidence and domain review appropriate to the task.

Bring the method into an enterprise environment

These projects provide inspectable examples of the method. An enterprise engagement adds its own integrations, information controls, operational dependencies and acceptance requirements. Those need to shape the work from the beginning.

We would establish four things before delegating implementation:

1. A bounded outcome: a named user, a specific problem and acceptance criteria agreed with the business owner.
2. Approved access: which code and data the models may see, which tools are permitted, and what actions require authorisation.
3. Verification: checks against source material, functional tests, domain review and evidence that the result works in its intended setting.
4. Operational ownership: deployment and rollback arrangements, documentation, and a team able to maintain the result.

Those decisions connect engineering, security and governance to delivery. They also help identify where an agent can work autonomously and where a specialist or owner needs to decide.

The outcomes described here do not establish a percentage saving against conventional delivery. They do demonstrate completed work, extended autonomous execution within defined boundaries, and source that can be inspected and maintained.

Start with an Enterprise AI Delivery Assessment

Bring us a stalled software initiative, a migration candidate or a technical knowledge problem. The assessment is designed to establish whether AI-assisted delivery is appropriate and define a bounded first step.

We would work through the intended outcome, existing system and source material, dependencies, data constraints and the evidence needed to accept the result. The output would be a recommended first scope, its success measures, required controls and a pilot plan covering review, rollout and handover. Where a smaller improvement is a better choice than migration, that belongs in the recommendation too.

This gives a technology leader a concrete delivery decision to make before committing to a broader programme. Software migration is one starting point; new development and document modernisation are others.

Discuss an Enterprise AI Delivery Assessment.

For the implementation detail behind the examples, read the technical companion: migrating from WordPress to Next.js with AI.