AI coding tools are making tiny software worth building

3D rendered ai text on dark digital background

Tailscale CEO Avery Pennarun has been programming for about 40 years. Lately, he’s been shipping new tools between meetings. The reason: AI coding assistants now handle the mechanical work, so he spends his time on the parts that actually require judgment.

His thesis is simple. There are millions of programs that never got built because the cost of building them outweighed the benefit. A dashboard used by seven people. A morning check on one data point. A temporary bridge between two internal systems. Each one useful, none of them worth a proper project, a team, and weeks of engineering time.

AI coding tools are shifting that calculus. A program only needs to save more time than it takes to build. A lot of small, repetitive problems are crossing that line for the first time.

Who benefits

Pennarun breaks it down by experience level. Someone with no programming background can now produce a simple tool. A junior developer can attempt harder problems, learn from mistakes faster, and work in areas previously reserved for senior engineers. An experienced programmer can finish things that would otherwise sit on a to-do list for months.

He also points out that some users will never look at code at all. They will ask a system to retrieve data, compare records, or connect two services. The system writes a small program in the background, runs it, and returns the result. Programming becomes part of using a computer whether the user calls it that or not.

The question every builder needs to ask

Pennarun offers a practical framework for deciding how much engineering discipline a new tool actually needs. Ask three questions before you build:

  1. Does anyone else depend on it?
  2. Can it change or expose important data?
  3. Would work stop if it disappeared tomorrow?

If all three answers are no, treat it like an experiment. Build it fast, skip the formal process, and expect to delete it. If any answer is yes, give it an owner, document its connections, limit its credentials, and make failures visible. The amount of engineering structure should follow the consequences, not the line count.

The real risk is not building a quick tool. The real risk is continuing to treat a tool like an experiment after people have started depending on it.

Stay on top of AI & Automation with BizStack Newsletter
BizStack  —  Entrepreneur’s Business Stack
Logo