Most business software is improved far away from the place where the problem is discovered.
A user notices something wrong on a screen.
Then the context starts escaping.
Someone takes a screenshot. Someone sends a message. Someone opens a ticket. Someone explains the page again. Someone asks for the record ID. Someone tries to reproduce the issue. Someone translates the business problem into technical language. Eventually, maybe, the change reaches a developer or an AI agent.
By then, the most important thing has often been lost:
the exact work context.
The screen mattered.
The record mattered.
The user role mattered.
The workflow mattered.
The business intent mattered.
That is why business software should be edited where work actually happens.
The closer software improvement stays to the real workflow, the less context the company loses.
The old improvement loop is too indirect
Enterprise software is full of indirect improvement loops.
The user sees a problem in the app, but the change process happens somewhere else.
The discussion happens in chat.
The decision happens in a meeting.
The requirement happens in a ticket.
The implementation happens in an IDE.
The review happens in Git.
The approval happens in another tool.
The user sees the result days or weeks later and decides whether the original problem was solved.
Every step can be useful.
But the distance between the workflow and the change process creates friction.
That friction is not only about speed. It is about fidelity.
The further a change moves from the place where it was discovered, the easier it is to lose nuance.
Screens carry business context
A business screen is not just pixels.
It is a working context.
A product editor is not only a form. It has permissions, validation, status, audit history, publishing rules, stock behavior, pricing constraints, and operational intent.
A support screen is not only customer data. It has case history, permissions, urgency, internal notes, next actions, and service expectations.
A dashboard is not only charts. It reflects what a specific role needs to understand now.
When someone suggests a change, the suggestion should remain tied to that context.
Not as a screenshot.
Not as a vague ticket.
As a contextual improvement attached to the actual application workflow.
That is the product idea behind putting the Studio close to the customer application.
Editing in context does not mean editing without control
There is a legitimate concern here.
If business users can suggest or edit software closer to the live application, does that create chaos?
It should not.
The answer is not uncontrolled editing.
The answer is governed editing in context.
Small companies need speed and low bureaucracy. Large companies need approval layers, permissions, auditability, environments, and review.
The product should support both.
That means an edit can start where the user sees the issue, but still move through the right path:
- permissions decide who can suggest, edit, approve, or publish;
- comments stay connected to the page and workflow;
- AI can help transform intent into a concrete change;
- local drafts can be saved before they become source changes;
- pull requests can preserve version control;
- publishing can be automatic or manual depending on policy;
- audit trails can keep the organization accountable.
The key is not to remove governance.
The key is to stop separating governance from context.
The Studio should feel embedded, not detached
The Studio should not feel like a separate world where users have to reconstruct the application from memory.
A better model is to load the Studio as a client-side layer, through the customer’s own application environment.
The user remains close to the screen.
The comment remains close to the UI element.
The suggestion remains close to the business record.
The AI agent receives better context.
The eventual change can still go through GitHub or GitLab, review, and publishing.
This is important for the Collab.codes model.
The Studio is not just a code generation surface. It is part of the creation and maintenance loop.
It should reduce the gap between:
- noticing a problem;
- explaining the problem;
- proposing a change;
- reviewing the change;
- publishing the result.
That gap is where a lot of enterprise software work gets slow.
AI maintenance needs context, not just prompts
AI can help maintain software.
But AI works better when it is not guessing from disconnected instructions.
There is a big difference between:
Change the product screen.
and:
On this product editor, for this role, in this workflow, make this field clearer before catalog publication.
The second instruction carries context.
It gives the AI agent a better target.
It also gives reviewers a better way to evaluate the result.
This matters because Collab.codes is not aiming for a world where every change requires manual programming. The direction is AI-assisted creation and maintenance, with humans controlling intent, review, and publication.
For that to work, the system has to preserve business context all the way from suggestion to change.
Version control still matters
Editing where work happens should not mean bypassing engineering discipline.
Version control still matters.
Review still matters.
Publishing policy still matters.
The difference is where the change begins.
In a Collab.codes-style workflow, the change can begin in the application, be drafted locally, and later move into a pull request. The repository can belong to the customer. Publishing can be automatic for simple environments or manual for organizations that need approval.
That gives teams a better balance:
the immediacy of contextual editing, with the discipline of Git-based delivery.
It is not “move fast and ignore control.”
It is “move close to the work, then promote the change through the right path.”
Why this matters for business software
Business software is never finished.
Rules change.
Teams change.
Products change.
Customers change.
Regulation changes.
The software has to keep evolving.
If every improvement requires people to leave the application, lose context, write tickets, wait for interpretation, and rediscover the original need, the product gets slower over time.
The companies that move faster will not only be the ones that generate software faster.
They will be the ones that improve software closer to where work happens.
That is a different kind of speed.
It is not just development speed.
It is organizational learning speed.
The future is a tighter loop
The future of business software maintenance should be a tighter loop:
notice, suggest, draft, review, publish, learn.
The user should not have to leave the work context to explain the work context.
The AI agent should not have to guess what screen matters.
The reviewer should not have to reconstruct why the change exists.
The company should not have to choose between speed and control.
That is why business software should be edited where work actually happens.
The application is not just the thing being changed.
It is the best place to understand the change.
— Wagner, CEO at Collab.codes