As Software Becomes Easier to Build, How Does Our Work Change?

Recently, I used Codex to build iOS versions of meowdoku and sudoku for my own use. I wanted to change the screens and controls I disliked in the existing apps. Being able to keep adjusting them as I played was satisfying. It also left me with mixed feelings as someone who builds software for a living. If customers and the people doing the day-to-day work gain the same ability, how will our work change?

A person considering intersecting stairways and doorways leading in several directions — As more paths open up, we find ourselves reconsidering which direction to take.

AI coding tools have something in common with meal kits. You can start with prepared ingredients and still adjust the result to your taste. In software, building and modifying something yourself is becoming a more accessible option alongside finding a product or commissioning development. As with my puzzle apps, sometimes it may be enough for the features one person needs to work well.

These efforts extend beyond small personal apps. As of October 14, 2026, ArtCraft lists 13 open-source applications spanning image and photo editing, word processing, spreadsheets, and CAD. Its creator describes using AI to build the first seven alternatives to Adobe applications. This is the work of an experienced developer, and the apps are still in early alpha or under development. Even so, it is worth noticing that functionality across several professional software categories is available as source code and installable applications.

AI is also being used to understand existing software. REA connects AI agents to binary and application analysis tools, helping them investigate behavior and use the findings in reimplementation. I have not confirmed that REA was used to build ArtCraft. The two projects illustrate separate uses of AI in implementing and analyzing software.

An available application is not necessarily a complete replacement. PhotoCraft explicitly says it is not yet a Photoshop replacement for daily professional work. But not every user will need every feature of the original. Once the features needed for a particular task are available, adapting an open implementation may become an option. If people who understand their own work gain the means to implement tools for it, might they take on some of the work they previously commissioned?

Providing commercial software raises another concern. From disk copy protection to license keys and online activation, various mechanisms have restricted unauthorized copying and use. Windows activation, for example, checks that a copy is used on devices permitted by its license. But controlling the use of an original program and preventing someone from implementing similar features in different code are separate problems. Feature reimplementation is not new, but if AI reduces the time and cost involved, it may also change how long a product can retain the distinctive features its creators worked hard to develop.

How, then, can I protect the features I build? Is it possible to show users how something works while preventing others from implementing similar behavior? As a user, I enjoyed removing the friction I experienced in an app and making a tool that suited me. As a builder, I realize someone could do the same with software I provide. Those of us working in the software industry may find ourselves experiencing both sides at once.

Developers gain opportunities to implement more, product planners to test ideas directly, and small organizations to attempt a wider range of projects. We can welcome those possibilities while wondering how the value of our experience and technical skills will change. New roles may emerge through deeper systems expertise, understanding people’s work, or helping software run reliably. It is still difficult to say which directions will provide lasting value.

I do not yet have an answer. As more people build their own tools, they may need more expert help, or the tools may provide much of that help themselves. Even with the same tools in hand, the changes we encounter will differ with our work and our customers. As software becomes easier to build, I expect we will keep reconsidering what our work means.

Further Reading