AI at the gates: when the people who know the business can build

A conventional software engagement can require a client to spend considerable time explaining the business before anyone can show them something useful. Processes become requirements, requirements become a specification, and the specification becomes software. Each handover creates an opportunity for detail to be lost or misunderstood.

Some of the hardest detail to communicate is also the most valuable: the exception an experienced operator recognises, the question a customer always asks, or the judgement that makes a process work in practice.

With AI-assisted building, a client can express an idea and respond to something tangible. They can change the sequence, test an exception and see what happens. An operations manager could try a different intake process using fictional enquiries, discover which questions are missing and revise it before asking anyone to integrate it.

That can reduce the effort spent translating domain knowledge into instructions for a software firm. It also allows requirements to develop through use. A working example gives both the client and an engineer something concrete to discuss, including where the current approach fails.

I start by asking how an organisation communicates with customers, how those conversations become revenue, and where the pain points sit in both. Those questions help keep experimentation connected to an outcome.

A financial-planning engagement provides useful context. In-house counsel’s work reviewing legislation and distributing guidance had become a bottleneck. The preparation workflow was unversioned and lacked traceability. Staff also needed to find updated guidance and apply it in ways tailored to the end client.

The work addressed preparation and use together. Benefits included shorter lead times, better access to financial tooling and its context, and improvements in education, knowledge dissemination and retrieval. It also supported more cost-effective outcomes.

The relevance to AI-assisted building is the domain knowledge involved. The people preparing and using guidance understand different parts of the problem. Giving them a more direct way to express and test a workflow can help bring those requirements into view.

Direct participation works best when people know where they can safely experiment. A sandbox is a separate environment where an idea can be tested within agreed limits. The limits should be explicit: which tools are approved, what information can be used, who can access the work and what it can connect to.

The experiment still needs a useful test. Can someone complete the task? Which exceptions break it? Does it remove a step or create more checking? Keep enough history to understand what changed and recover a working version.

A successful experiment provides evidence about the idea and reveals what needs further work. Its next step should be a deliberate decision.

Connecting a prototype to live systems changes its responsibilities. It may now expose confidential information, alter records or become something staff and customers depend on.

Before that happens, someone needs to examine the wider system. Where does authoritative data live? How will access be controlled? Could the new tool duplicate or contradict an existing process? What happens if an integration fails, or two people update the same record?

For a guidance workflow, I would also look for source references, version history, ownership, approval and a route back to a specialist.

Engineering judgement remains important here. A convincing demonstration gives limited evidence about security, reliability and how a tool will behave across the rest of the organisation.

This changes where a fractional CTO can contribute. Clients can take more ownership of expressing and exploring what they need. Technical leadership establishes the architecture, boundaries and route through which useful work can become a dependable part of the business.

That includes deciding when an existing system should be configured, when a small custom tool is justified and when an experiment should stop. It also means making the production requirements clear early enough that people can work towards them.

Neon Light’s Discover, Diagnose, Design, Deliver approach gives that work a practical structure.

Discover the business objective, the workflow and the systems it touches. Diagnose the constraint and the consequences of getting it wrong. Design a proportionate response, including room for the client to experiment. Deliver through an agreed route to live use, then check whether it improves the work.

The depth of investigation should match the uncertainty and risk. A narrow issue may need a focused session and a contained trial. A tool touching sensitive information or critical operations needs more.

The opportunity is to let the people who know the business shape more of its software directly, with technical support that makes their work safe to use and practical to maintain.