Deterministic Solutions

We’ve become so comfortable asking AI to solve our problems that sometimes we forget there are better ways to get things done. We ask ChatGPT to analyze data, process files, calculate results, or automate repetitive tasks. It’s convenient, often surprisingly effective, and requires almost no technical knowledge. But when we need to do the same thing again, we simply write another prompt, upload another file, and hope for another good result.

What if we’re approaching this the wrong way? What if, instead of repeatedly asking AI to solve a problem, we used it to build something that solves the problem once and for all? We’ve spent years trying to make software easier to use through natural language, but perhaps we’re overlooking one of AI’s greatest strengths: making software easier to create.

Imagine you have a CSV file containing thousands of transactions. You want to identify duplicates, calculate totals, and flag suspicious entries. You could upload it to an AI assistant, explain what you need, and get an answer in seconds. Everything looks reasonable, the numbers seem correct, and you’ve saved yourself a fair amount of work.

Now imagine doing the same thing next week with a different file. You upload it again, write a similar prompt, and receive another set of results. Maybe this time the model interprets duplicates slightly differently, ignores a particular edge case, or produces a different report format. You adjust your prompt, try again, and spend additional time verifying whether the output is correct. You’ve automated part of the work, but you’re still repeating the process of explaining and validating it.

The underlying problem is that large language models are generally non-deterministic by nature. As OpenAI explains in its documentation, identical requests can produce different outputs, and even techniques designed to improve reproducibility don’t guarantee identical results ^[1]. That flexibility is useful for many tasks, but it can become a disadvantage when we need precise calculations, predictable behavior, and consistent results.

And non-determinism is only part of the problem. Different answers aren’t necessarily incorrect, and identical answers aren’t necessarily correct. The bigger concern is that we’re relying on a probabilistic system for work that may have perfectly well-defined rules. According to the 2025 Stack Overflow Developer Survey, 66% of respondents who answered the relevant question reported frustration with AI solutions that were “almost right, but not quite” ^[2]. Anyone who has spent time debugging AI-generated output will probably recognize the experience.

It gets sillier. Some people build a calculator that solves math equations with AI underneath. It’s just for fun, but it’s a perfect example of using AI the wrong way: instead of building a deterministic solution once, they hand the same problem to a model every single time. Give it a try below. Notice that the answer doesn’t arrive instantly, and that it isn’t always right.

Arithmetic is about as rule-bound as problems get. A few lines of code solve it instantly and correctly, every single time.

Now imagine approaching the same CSV problem differently. Instead of asking AI to analyze the file every time, you ask it to write a small script that reads the data, detects duplicates according to explicit rules, calculates the totals, and produces a report in a predefined format.

You review the implementation, test it against a few known examples, and verify the results. Once the script works, you can run it whenever you need. There’s no need to explain the task again, no prompt to refine, and no model interpreting your instructions differently on each execution. Given the same input and environment, the script follows the same logic and produces the same output.

Of course, deterministic doesn’t automatically mean correct. A bug in your code can consistently produce incorrect results, and changing inputs or external dependencies can introduce unexpected behavior. But unlike a conversational response, traditional software gives you explicit rules that can be inspected, tested, fixed, and reused. When something goes wrong, you can investigate the implementation rather than wondering how the model interpreted your latest prompt.

Building small tools isn’t a new idea. Developers have been writing scripts, command-line utilities, and internal automation for decades. The reason we don’t build software for every little problem is simple: creating software traditionally requires time and effort, and that effort isn’t always justified by the value of the task.

Even a relatively small utility involves understanding the requirements, writing the implementation, handling edge cases, and verifying that everything works. If you need something only once or twice, spending several hours building a reusable solution might be difficult to justify. It’s often easier to do the work manually or use an existing general-purpose tool, even if the process is somewhat inconvenient.

AI coding tools are changing that calculation. Many small utilities that previously required meaningful development effort can now be generated quickly, sometimes from a single description of the problem. You still need to understand what the software does and verify its correctness, but the cost of getting from an idea to a working implementation has dropped significantly.

And there’s another reason why this is such an interesting time to build software: AI subscriptions can offer extraordinary value for their price. For around $20 a month, you can access capable AI coding assistants, and depending on how heavily you use them, the equivalent model usage could cost significantly more if purchased through pay-as-you-go API pricing. Subscriptions aren’t unlimited, and the actual savings depend on usage limits and the models involved, but the economics can be remarkably favorable. I’ve explored this in more detail in my note on why AI subscriptions can be cheaper than pay-as-you-go.

This makes experimentation much more affordable. When the marginal cost of generating another small utility is low and much of your coding assistance is already covered by a subscription, there’s less reason to hesitate before trying an idea. You don’t need to justify every little experiment with a potential return on investment. Sometimes it’s enough to have a problem you want to solve and a few minutes to explore a solution.

This creates an interesting opportunity. We can afford to build software for increasingly small and specific problems. A script to rename hundreds of files, a utility to compare exports from two systems, a command to validate configuration across repositories, or a simple dashboard for data you occasionally need to inspect. These tools don’t need to be particularly clever or sophisticated. They just need to solve the problem they were created for.

There’s a tendency among developers to think about software in terms of applications, services, and products. We imagine user interfaces, authentication, databases, deployment pipelines, and all the other things associated with building something that people will use. That mindset can make even a relatively simple problem feel like the beginning of a much larger project.

But a micro-tool doesn’t need any of those things. It might be a 30-line Python script, a small Node.js utility, a shell command, or a basic HTML page that runs entirely in your browser. It doesn’t need a name, a logo, or even a GitHub repository. Sometimes a disposable script that performs one operation correctly is all you need.

And there’s nothing wrong with building software that you’ll use only once. If AI can help you generate a small utility, and you can verify that it works before throwing it away after getting the result, that might be a perfectly reasonable use of your time. Software doesn’t have to be maintained forever to provide value.

I’m not suggesting we start overengineering every small task. Quite the opposite. Some problems are so simple that writing a script, even with AI assistance, would take longer than solving them directly. Others are ambiguous, creative, or difficult to express as explicit rules. In those cases, asking an AI assistant might still be the better approach.

There’s no reason to treat AI and deterministic software as competing approaches. In many cases, the strongest solution combines them, allowing each to handle the work it’s best suited for.

AI is useful when requirements are unclear, inputs are unstructured, or a problem requires interpretation and flexible reasoning. Traditional code is often a better choice when the rules are known and the same operations must be performed consistently. The distinction isn’t always absolute, but it’s a useful way to think about designing solutions.

For example, AI might help you understand an unfamiliar document format or decide which information needs to be extracted. Once you’ve identified the relevant fields and established clear rules, a conventional parser or validation script can handle the repeatable parts of the process. You keep the flexibility where it provides value and remove unnecessary uncertainty from everything else.

This is also consistent with Anthropic’s advice on building effective AI agents. Their engineering team recommends starting with the simplest solution that works and adding complexity only when necessary. They also distinguish predictable, predefined workflows from more flexible agent-driven approaches ^[3].

We should apply the same thinking to our everyday work. Before building an elaborate agent that repeatedly reasons through a task, consider whether a simple function, script, or predefined workflow would accomplish the same thing more reliably.

There’s another interesting consequence of making software dramatically cheaper to create. When you start building small utilities for your own problems, you’ll occasionally discover that other people struggle with exactly the same things.

Something that began as a disposable script might turn out to be useful to your colleagues. You improve it, add a few features, and share it with a wider audience. Eventually, you might discover that people outside your company have the same problem and would happily pay for a convenient solution. What started as a tiny personal utility could become a micro-SaaS or even the foundation of a startup.

Of course, building something useful doesn’t automatically mean you’ve discovered a business opportunity. Distribution, customer needs, willingness to pay, and ongoing maintenance still matter. But the barrier to experimenting with ideas has become much lower, and you don’t necessarily need to commit weeks or months of development time before discovering whether something has potential, especially now that writing the code itself has become cheaper.

The entrepreneurial opportunity isn’t necessarily in creating the next revolutionary AI product. Sometimes it’s in recognizing a boring, repetitive problem that thousands of people face and building a simple, reliable tool that makes their lives easier.

AI has given us an extraordinary ability to create software, and I think we’re only beginning to understand what that means. For years, the effort required to build something forced us to choose carefully which problems deserved a software solution. That limitation is becoming less significant, especially for small, well-defined tasks.

The next time you find yourself writing a prompt for something you’ve already done before, consider whether a small tool could solve it more reliably. It doesn’t need to be impressive, reusable by thousands of people, or even worth keeping after you’re done. If it saves time, reduces mistakes, or makes a process easier to repeat, it has already done its job.

Use AI to build the solution, not necessarily to be the solution.

There’s never been a better time to build small, deterministic tools than now.