AI-Assisted Development: Are You Building the Right Applications?

The shift: business teams can take a more active role

Business teams know where work gets stuck. They deal with the repeated data entry, the missing information, and the approvals that sit in somebody's inbox.

Traditionally, turning that knowledge into software involves describing the problem, submitting a request, and waiting for IT capacity. Along the way, important details can get lost. Sometimes users only see the proposed solution when substantial time and money have already been spent.

Traditional low-code has made it easier for those teams to participate directly. AI extends that possibility. Appian Composer, for example, supports turning requirements into interactive application plans and assisting development.

That gives the person closest to a problem a practical way to explore a solution and put it in front of others.

A prototype makes assumptions visible. People can walk through a process, challenge the sequence, and point out the awkward exceptions. A colleague can say, “That looks useful, but we would still have to update the spreadsheet afterwards.” Suddenly, the team has uncovered a requirement that a polished brief might have missed.

I see considerable value in business teams doing this work. I also believe enterprise applications need IT involvement and governance before they reach production. Understanding a business process and understanding how to run a secure, reliable enterprise service are different skills. Successful delivery needs both.

The upside: faster learning, better demand and backlog relief

The immediate attraction is speed. Business teams can explore an idea without first securing a fully staffed delivery project. Trained builders can also take on suitable, lower-risk work within agreed standards, giving specialist developers more capacity for complex requirements.

For IT leadership, another benefit is better-informed demand.

Consider a team asking for an application to manage approval emails. During prototyping, they realise most of those emails exist because people cannot see the status of their requests. A shared status view could remove much of the traffic. They may also discover that one approval step has no clear purpose.

Those findings should change the solution. They might reduce its scope, improve its value, or remove the need for some functionality altogether.

AI can make it easier to get something tangible in front of users. The organisation still needs to give people time to question it. A convincing interface can otherwise create enthusiasm for an idea that has barely been tested.

Before committing to delivery, I would want clear answers to a few questions. Whose problem are we solving? How does the work happen today? What should improve? What evidence do we have that the proposed approach will help?

This creates a stronger foundation for adoption too. Users who shape a solution have opportunities to influence decisions and resolve concerns early. They understand why it works as it does, they can help colleagues understand its benefits and define the most important metrics that signify value in the real world.

That involvement should continue through development, testing, and release. Ownership grows through participation; it cannot be assumed simply because someone attended a demonstration.

The measures of success should follow the original problem: less manual effort, shorter processing times, fewer errors or better service. Actual usage matters as well. An application delivers little value if people quietly return to their previous workarounds.

The risk: useful experiments becoming unsupported dependencies

A prototype can become operational surprisingly quickly. Someone adds real data, another department asks for access, and a convenient connection is made to a core system.

Soon, the organisation depends on something with unclear ownership, limited testing, and no agreed support arrangements. Its creator moves roles, and IT inherits the consequences.

Inconsistent standards add to the burden. Different teams may create conflicting business rules, duplicate data or integrations that are difficult to maintain. AI assistance still requires human review, particularly where generated behaviour affects permissions, decisions or sensitive information.

Why IT Governance Matters in AI-Assisted Development

CIOs need a clear route from exploration to production, with agreed access controls, data policies and release procedures. Separate development, test and production environments allow experimentation while protecting live services.

I would start with approved tools, safe data, and an environment where business teams can experiment within understood boundaries. Each initiative should have a named business owner and an intended outcome.

IT should be available early to advise on architecture, integrations, and data. Before release, there should be proportionate checks for security, accessibility, testing, performance, and operational support, with clear accountability for technical approval.

The business owner must remain accountable for priorities, adoption, and benefits after launch. IT needs visibility of the application and a sustainable arrangement for maintaining it.

Good governance also needs to be usable. If the approved route is slow or confusing, people have an incentive to work around it. Clear expectations, reusable patterns and timely advice help make responsible delivery easier.

Building the Right Applications with AI and Low-Code

As AI makes building more accessible, enterprises have a chance to involve more people in discovering useful solutions. The strongest opportunity is to combine that business insight with technical expertise, test ideas early, and keep measuring their impact.

Building quickly is valuable. Knowing why something deserves to be built - and whether it improves people's work - will determine the return.

Frequently Asked Questions

How does AI-assisted development help business teams?

It lets teams explore ideas, test assumptions and put early versions in front of colleagues before committing to full delivery.

Why does governance matter in AI-assisted development?

Experiments can become operational services quickly. Clear ownership, security controls and support arrangements help avoid unsupported dependencies.

When should IT become involved?

Early enough to advise on architecture, data and integrations, and before an application moves into production.