AI-customisable interfaces: who maintains the extensions?

AI-customisable interfaces: who maintains the extensions?

Software can let users change colours, columns or keyboard shortcuts. With AI, the request becomes more ambitious: “add the panel I am missing, right here, while I work.” bb, “The IDE that builds itself”, makes that idea tangible. But a company adopting it must answer a less spectacular question: who will fix that panel after the next update?

An AI-customisable interface should adapt the workspace without fragmenting the business system. Users can choose how to view and prepare their work; access rights, calculation rules and approvals remain shared. Every new capability needs an owner, tests and a rollback path before it becomes a shared tool.

Start with bb: change the tool from inside the tool

bb presents itself as a development environment that can control, customise and automate itself. An IDE is the environment where a developer works on code. The point of this example is not to generate another application alongside it, but to extend the environment already in use.

The request worth examining is specific: type a command inside the application to obtain a new interface or capability without rebuilding the whole application. That freedom stays within an environment and its available primitives — the elements and operations the software allows people to assemble. This advanced user’s wish does not establish that every user wants to become their own tool designer.

The official bb website gives a concrete example: ask to bring your Linear issues into bb. Its presentation shows the creation of a plugin, a sidebar panel, a bb linear command and a “skill” explaining to agents how to use it. It also states that several product features are themselves plugins. The official repository describes a product still under active development.

What this example establishes: the vendor describes a workspace extension through a plugin, not just a visual preference. We have not installed bb or run this integration end to end; the presentation does not measure its reliability in a business setting or the time it might save. It does provide a useful starting point for defining maintenance responsibilities.

Apply the idea to business without inventing a customer result

Illustrative scenario, not an observed customer case: a support lead handles requests in a business application. As with bb’s Linear example, she wants useful information brought into her workspace: “add a panel showing my pending requests, their deadlines and the next commitment I need to meet.”

If the data and filters already exist, the change may remain a matter of screen composition. If the panel needs a connection to another tool, stored access credentials or a new follow-up action, it introduces another dependency. An apparently identical prompt can therefore mean two different jobs: displaying authorised data differently, or adding a capability to the system.

The panel must not decide for itself what counts as overdue. That definition comes from the contract and support rules. Nor should it display another team’s cases because AI generated an overly broad query. The application must enforce permissions on the server, even when a button or filter is hidden on screen.

Personalisation helps when it saves the support lead from switching between views. It becomes costly if every colleague gets a different definition of “urgent”, a copy of the follow-up rules and an ownerless connector. Requests therefore need classifying before AI produces them.

A decision grid: independent, reviewed or shared

This grid is a design proposal for a business tool, not a list of guarantees provided by bb.

• Users can change independently: panel order, display density, columns, shortcuts and filters over data they can already access. Provide a reset and a standard view; prevent a setting from hiding a mandatory alert.
• Requires review: a new calculated panel, metric formula, connector, generated extension, export or follow-up action. A business owner checks its meaning; a technical owner checks access, dependencies and behaviour. A new formula can remain personal without becoming an official definition.
• Remains shared: permissions, data scope, definitions of official metrics, approval rules, action logs and accessibility requirements. Changes to these rules go through the product and business process, not an individual user’s prompt.

Classification depends on the actual effect, not the wording. “Change this button” can mean a display preference; replacing payment confirmation with immediate execution changes a business rule. If a personalisation changes who can act, on what or with which consequences, it is no longer a free-form preference.

A2UI: composing a catalogue is not loading a plugin

A2UI illustrates another approach. The protocol lets an agent describe an interface declaratively: it sends a description of components that the client renders using its own interface elements, rather than executing arbitrary code generated for that interface. The agent composes from a catalogue of preapproved components.

This distinction matters for maintenance. A team can restrict combinations to cards, lists and forms it already knows how to test and make accessible. With a plugin extension, it must also examine the extension’s code, dependencies and granted capabilities. A2UI and bb plugins are different mechanisms; the existence of a catalogue does not establish that bb uses A2UI.

A catalogue limits generation freedom; it does not guarantee system security. An approved component can display improperly authorised data or trigger an inadequately controlled action. The server must still enforce permissions and business rules. Component quality, data bindings and allowed actions all need testing.

Who takes over when the interface breaks?

The real cost often appears after creation: an API changes, a field disappears, a plugin becomes incompatible or its author leaves the company. The team must be able to identify affected users and disable the extension without blocking request handling.

Before distributing a generated capability, create a short record covering:

• Ownership: who responds to an incident, approves business changes and maintains the code or catalogue? Writing the prompt does not automatically make someone the maintainer.
• An identifiable version: components or plugin, data sources, dependencies, requested permissions and compatible platform version. Keeping the prompt helps explain intent, but does not replace the delivered artefact.
• Useful tests: calculations, missing data, denied access, slow responses, errors and repeated actions. Test keyboard use, a screen reader where relevant and the screen sizes people actually use.
• An update rule: check extensions when the underlying platform changes; retire those without an owner instead of letting them become silently critical.
• A rollback path: restore the standard view and previous version. If an extension has written to the system, restoring the screen is not enough: those writes and any compensating actions also need handling.

For our support panel, acceptance checks include ensuring that an agent cannot see requests from an unauthorised team, that a missing deadline is not presented as a fulfilled commitment and that a connector outage leaves the standard workflow available. These criteria give “ready” a testable meaning.

Test value before widening the freedom

Start with one workspace and one task. Measure total time, rework, errors and required support with the current view, then with the personalised view. Include checking, correction and maintenance time; minutes saved on screen may be absorbed elsewhere. Our guide to choosing a first AI project for an SME explains this full-cost approach.

Also test with someone who did not write the prompt. Can they understand the panel without its creator? Can they recover the standard view and flag questionable data? User testing an AI prototype helps observe a task without confusing a guided demonstration with independent use.

If several people request the same panel, it may belong in the shared product. If only one person needs it but it requires a fragile connector, simpler personalisation may be preferable. The aim is not to multiply versions, but to bring the tool closer to the work without scattering responsibility.

Scope a customisable interface with SAY Digital

Considering letting users adapt a business tool? SAY Digital can help define useful freedoms, shared rules and a testable pilot. Before development starts, the scope should identify the workflow, accessible data, each extension’s owner and the conditions for returning to the standard version.

Let’s discuss your tool and what needs to remain shared (booking page in French).

Sources

• bb — official presentation: plugin-based customisation and the Linear integration example. Vendor presentation, not an independent benchmark.
• bb — official repository and README: agentic environment, access surfaces and development status.
• A2UI — official documentation: declarative descriptions and a catalogue of preapproved components, a mechanism distinct from plugins.

Sources consulted on 28 October 2026. Documentary analysis; the support scenario and decision grid are illustrative proposals. No deployment or measured productivity gain is claimed.