I’ve been programming for about 40 years. Lately, I’ve started creating new programs between meetings. The difference is that I can now hand much of the mechanical work to an AI coding tool, then spend my time fixing the interesting parts.
They may not be the best programs. Some are a bit strange. But they are programs I didn’t have time to write before, and now I do.
The immediate effect is more output. The larger outcome is that many small jobs are crossing the line from not worth doing to being within reach.
Consider a dashboard for a small team. The code itself might be straightforward but then you need to connect it to three systems, handle authentication, put it somewhere people can reach, and keep it working after any of those systems changes its API. While the dashboard is useful, it isn’t useful enough to justify a project, a team, the hours or days of coding, and six weeks of meetings about the project and the team. So, it doesn’t get built.
There are millions of programs like this. A report used by seven people, so they don’t have to look things up by hand. A temporary connection between two internal systems. A tool that checks one thing every morning. A program for your house that watches a machine whose manufacturer thought a mobile app was an adequate substitute for an interface.
While creating these programs has always been possible, historically they were simply too expensive to make. But now AI coding tools lower that threshold and programs that were once skipped because they required too much effort are now doable. AIs don’t turn everyone into the world’s greatest programmer, but they do move almost everyone up a level or two.
Someone with no programming experience can now produce a simple tool. A junior programmer can attempt harder work, learn from mistakes faster, and explore new areas that were previously reserved for more experienced engineers. An experienced programmer can finish things that would otherwise sit on their to-do list for months; they can tackle months-long projects in days or weeks instead, without having to delegate.
Even people who will never look at code will create software this way. They will ask a system to retrieve information, compare records, or connect two services. The system will write a small program in the background, run it, return the result, and maybe throw it away. Programming becomes part of using a computer, whether the user calls it programming or not.
This creates a market below the software market we know today.
Traditionally, the software industry has optimized for products that can support large audiences: companies, engineering teams, sales organizations, and lots of customers who, in aggregate, will pay enough to justify building the product. That makes sense when software is expensive to build.
Software for narrow, specific use cases becomes economical once the cost of building it drops far enough. Most companies have thousands of tiny jobs that are too small to justify an engineering project or licensing expensive general-purpose software from someone else.
AI coding tools are pushing that threshold lower. A small, single-purpose program no longer necessarily requires a dedicated engineer or weeks of work. More of these programs will get built simply because they are now cheap enough to bother with.
That creates a different problem. Finding someone to write and maintain a narrow program used to be the primary bottleneck. Now, the challenge is recognizing when a “throwaway” tool has stopped being throwaway.
Its importance isn’t measured by user count or lines of code. The better questions are simpler: Does anyone else depend on it? Can it change or expose important data? Would work stop if it disappeared tomorrow?
Before building your next program, I recommend you ask three questions:
**1. **Does anyone else depend on it?
2. Can it change or expose important data?
3. Would work stop if it disappeared tomorrow?
If the answer to all three is no, treat it like an experiment, not a product. Build it quickly, skip the formal engineering process, and expect to delete it.
If the answer is yes, add only the structure you really need. Give it an owner, list its connections, limit its credentials, and make failures visible. Then, have a plan for how it gets repaired, replaced, or retired.
The amount of engineering process should follow the consequences. A disposable tool can stay disposable. A tool people depend on needs an owner, tighter access, and a plan for keeping it working.
Small tools that can be programmed in an hour don’t need to be formal projects. But once people start depending on your quick tool, treating it like an experiment becomes the real risk. That’s the moment to add proper management—once the value is already proven.
[For decades, companies rationed software because it took too much time and money to produce.]
Now a program only needs to save more time than it takes to build.
That makes a lot of small, repetitive problems worth automating for the first time.
Avery Pennarun is CEO and co-founder of Tailscale.