Recently, working on my own projects has changed my sense of what is worth attempting. Needs that I would once have set aside because of the work involved now feel within reach.

One of those projects is Kolab, a desktop application I'm building for musicians collaborating on music made in Ableton Live. Sending a finished recording lets someone listen. Continuing the music requires the editable project and the audio files it uses. Kolab is intended to make sharing successive versions of that working material easier: one musician shares a version, another brings it onto their computer, continues working and shares the next. A history helps them keep track of the work. The need comes from my own music collaboration. I know the difficulty because I've lived with it.

With AI assistance, I've been developing Kolab rapidly, to a quality I'm pleased with. During a recent period of startup-style work, I also became more comfortable trusting the agents' output. I know the architecture and can anticipate the shape a change should take. I don't know the details of almost any of the implementation. Occasional spot checks let me reconstruct a relevant piece quickly and see whether the architecture is being kept.

My roughly thirty years of engineering experience contribute to that confidence. But the agents are doing substantial work, and the combination has changed what I consider practical. I've begun to imagine other people gaining some of this freedom, using knowledge of their own work to shape tools around it.

That possibility feels larger than faster programming. It also brings to mind a story from my family.

The work can remain while opportunities change

The story passed down in my family is that, around the beginning of the twentieth century, people saw promise in my great-grandfather and sent him for advanced agricultural study. He went on to manage agriculture with large seasonal workforces. It was demanding, highly trained work, with substantial responsibility.

Then the work changed. As tractors and harvest machinery spread, particularly during the twenties and thirties, the opportunities he had prepared for became harder to find.^[1] He spent much of his later life unemployed or struggling to obtain work.

What stays with me is that someone recognised his ability and invested in his education. He had prepared seriously for work that was useful and demanding.

Agriculture still needs management and supervision. The continued existence of a responsibility doesn't preserve every opportunity to practise it. A person's competence can remain real while the arrangements that employed it change.

I suspect AI could produce a structural economic change of a similar kind. I don't know its eventual scale, and software differs from agriculture in important ways. But the family story makes it difficult for me to treat a continuing need for expertise as reassurance that today's employment arrangements will survive.

It also doesn't make me wish the new capacity away. The freedom I'm experiencing in Kolab is useful. I want to think about what could be built around it, including opportunities for people whose working lives are changing.

Tools shaped by the people using them

I've long felt that we ask people to spend a considerable part of their lives learning software. Photoshop has its conventions. Accounting applications have theirs. Some learning belongs to the activity itself. A simpler screen won't teach accounting. But some comes from learning how a product expects the work to happen.

Expensive development helps explain this. A supplier can support a product by selling it to many customers, combining their requirements into something broad enough to serve them all. Even thoughtful design must reconcile needs that don't fit neatly together. People adapt their work to the resulting compromise.

Imagine a small business taking orders through an existing stock system. Staff know which information they need together, what the usual orders look like and where exceptions arise. A particular interface could fit that working day while leaving the stock records in the established system.

Previously, the improvement might not have justified commissioning a developer. Explaining the process would itself take time. Staff might discover what was missing only after trying the result, beginning another exchange. If they can experiment directly, more of their knowledge can reach the tool without that repeated handover.

This mechanism has a history. Von Hippel and Katz described how suppliers can provide technical capabilities while users experiment with the aspects that depend on their particular needs.^[2] AI gives me a reason to expect that division of work to become practical in more situations.

Participation beyond experienced engineers is already being explored. Bo Xie describes building two health education applications with AI assistance, without a software developer, then identifies the need for technical assurance and institutional support.^[3] In a separate study, early Computer Engineering students with limited web development experience built small applications inside NoCodeGPT, an environment supplying important technical scaffolding.^[4] These are bounded examples, but they make the possibility concrete.

I strongly expect useful software activity to expand. People know countless details of their work that suppliers have little reason to examine. Some needs are too small for a roadmap, others too local for a general product. Cheaper experimentation can bring more of them within reach. People will also discover uses that I wouldn't think to build.

The calculation includes checking, integration and continuing care, as well as initial implementation. AI can help with understanding and repair too. A tool for one event may be valuable and temporary; an ordering system needs support for as long as people depend on it. The opportunity grows as more of that total cost falls.

Some tools will extend existing products, some replace purchases, and some address needs previously left to manual work. More useful activity needn't mean more software spending or more engineering employment. Those outcomes can move differently. What I expect is a wider range of needs becoming worth addressing.

My wife Maria and I watch renovation programmes. People buy run-down houses, do substantial work themselves and employ specialists for particular jobs. I find that a useful picture of how this software activity could be supported.

Staff could shape the ordering screen while an engineer helps establish its access to important data. Security, deletion and recovery deserve attention from the beginning. A review tells us what has been checked; later changes may need another look.

Professional attention should follow use and consequences, whoever produced the code. That leaves room for people to make modest tools without requiring an independent audit of every experiment.

Supporting the work and the people entering it

Many experienced engineers I talk to recognise that the real system takes shape during development. Making and trying something exposes assumptions and reveals exceptions we hadn't thought to ask about. That is close to how I develop my own projects, and it feels effective. Cheaper implementation makes more of these investigations practical.

This is what I value in iteration: learning about the work and changing the software as we learn.^[5] A working prototype gives the customer and engineer something to examine together.

The customer still reasonably asks when it will be done and what it will cost. I've occasionally seen agile work organised well enough to support useful forecasting, but that hasn't been my usual experience. My impression is that some organisations increasingly expect fixed commitments and sequential delivery while retaining agile language and ceremonies.

Planning remains necessary. A budget and a bounded next step let the customer decide whether further work is worthwhile. Completed work helps us forecast the next increment. That increment can be finished while the wider product is still taking shape. Promising a final scope and date before enough has been learned asks us to know more than we do.

A consultancy could help an organisation work this way. Suppose the business approaches it about the ordering tool. Junior engineers could work closely with staff, using AI to build and revise a prototype. Staff bring knowledge of the work; the juniors help turn it into something they can try together. Mistakes and incomplete behaviour can still reveal what a useful system needs to do.

If learning the customer's work and obtaining feedback set the pace, an experienced engineer's faster implementation may make relatively little difference. Juniors could make patient exploration more affordable. Seniors can also ask better questions and recognise a misleading model. They could help establish the starting architecture, basic checks and boundaries, then offer guidance as questions arise.

As the organisation begins to depend on the result, senior attention could increase around integration, verification and deployment. The junior would remain involved. Discovering that orders may be fulfilled in stages could change the model even then. Some implementation might be replaced; the understanding gained would survive. Users would continue learning after release, and support would change with the work.

The relationship has precedents in citizen development and fusion teams.^[6] Shared foundations and repeatable checks could spread costs across projects, while local rules still need examination. Customers could pay for successive pieces of useful work, training and continuing care, becoming more able to adapt their tools. A consultancy selling implementation hours would have to adjust how it earns as those hours became less necessary.

The junior's contribution to discovery belongs in that calculation, alongside their cost, senior attention and the work needed for dependable use. Supervision takes paid time; a senior with AI could sometimes complete the engagement more cheaply. But juniors could earn their place through useful customer work while developing future capability. Firms would have to organise and fund both.

Continued involvement could teach a junior to explain, predict, diagnose and change a system. Assisted output alone doesn't establish that competence. Staff seeking a useful tool have different learning needs. AI may help with teaching too, but broader responsibility requires experience beyond a succession of small prototypes.

My great-grandfather's story keeps another responsibility in view. We need to care for the systems people depend on, and also make room for people entering or adapting to the work. Being able to produce more doesn't settle how they will find that room.

I would like to help create a future in which staff and a junior engineer can sit together, try an ordering screen and discover a better way of doing the work. The customer gains something useful. The junior gains experience, with someone available to help them understand what they've made and carry it into dependable use.

I can picture that becoming an ordinary kind of work. How we make room for it is a question worth taking seriously.

Sources

SLU, “Så traktoriserades Sverige”, 2017, on Per Thunström's research into Swedish tractor introduction in 1905–1930, including renewed adoption late in the twenties. The Smithsonian's Hiram Moore Collection documents a successful combined harvester in 1834. The change described concerns adoption, not invention. These sources establish context, not the cause of my great-grandfather's unemployment; that connection comes from the family story.
Eric von Hippel and Ralph Katz, “Shifting Innovation to Users via Toolkits”, Management Science 48(7), 2002, pp. 821–833. Applying its account of user experimentation over supplied technical capabilities to AI is this essay's inference.
Bo Xie, “When End Users Can Build: AI-Assisted Application Development and the New Accountability Gap in Digital Health”, DIGITAL HEALTH 12, 2026. A Perspective describing two educational applications, not validated clinical interventions. Xie lacked formal software engineering training but had overseen technical work; the account is not a representative adoption study.
Mauricio Monteiro and colleagues, “NoCodeGPT: A No-Code Interface for Building Web Apps With Language Models”, Software: Practice and Experience 55(8), 2025, pp. 1408–1424. Fourteen early Computer Engineering students participated; nine completed all assigned user stories. The environment supplied architectural guidance, predefined login and registration features, execution and rollback. This establishes limited feasibility with support, not unrestricted production competence or retained learning.
Ken Schwaber and Jeff Sutherland, The Scrum Guide, November 2020. Describes inspection, adaptation, scope renegotiation and forecasts informed by previous performance and capacity. This states the intended approach, not its prevalence or effectiveness. The observations about agile working are personal testimony.
Microsoft, “Fusion Development in Power Platform”, documentation updated 9 November 2022. Describes collaboration between business users, professional developers and lifecycle specialists; platform guidance rather than independent evidence of outcomes.

Kolab and the renovation programmes are personal testimony. The business, ordering tool and supervised junior work are hypothetical.