Tag: AI

A big thing happened the other week: Anthropic helped launch a $1.5 billion AI services company. OpenAI is also deploying enterprise agents with its own team and selected systems integrators.

$1.5 billion is not chump change. These companies are thinking about where the market is going, and they have realized that a capable model is not the only thing that matters. The implementation around the model is equally important.

Ode with Anthropic was announced in July as a standalone AI services firm. A week later, OpenAI introduced Presence, an enterprise deployment model that starts with a specific workflow and includes system access, policies, approvals, testing, and ongoing support.

While massive companies may be able to work directly with OpenAI or Anthropic, or at least afford to, most of us do not have that luxury. What is clear is that getting an impressive demo or proof of concept is not the hard part. The hard part is taking it to the next step, where the complex edge cases, data, users, and exceptions show up.

Small choices can turn into bigger problems

We were brought into an AI project where a fairly simple decision became a bigger problem later: the application was not locked to a specific model and release version.

At first, the AI application looked fine. It produced structured output and the rest of the automation could use it. As the provider changed the model’s behavior over time, the format changed and it began classifying some inputs differently than it had when the application was originally built. The output still looked reasonable to a person, but the rest of the automation relied on those expected formats and classifications, so it became unreliable.

This is easy to miss because the AI still appears to work. The problem only shows up when another system expects the output to be consistent, and there is no test in place to catch the change before it becomes an issue.

A model should be treated like any other production dependency. Pin the model and version where possible, keep a set of real test cases, test changes before they go live, and have a plan for upgrades. It is not exciting work, but it keeps a useful application from becoming unreliable over time.

A demo is not a workflow

We have seen the same thing with agents. An agent can look great in a demo because it can answer questions, summarize documents, or draft an action. Once it is used in a real business process, though, it needs to know where the right data lives, what to do when data is missing, when it should ask a person for help, who can approve an action, and what needs to be recorded later.

If that work is not planned ahead of time, the agent usually does one of two things. It takes actions it should not take, or it hands so much back to people that it does not save much time. In both cases, the model may be fine. The larger workflow was not thought through.

Building an AI agent is not the same as building a working process. The agent needs clear boundaries, the right access, a way to handle exceptions, and someone responsible for it when the process changes.

What good implementation looks like

A good implementation partner does more than connect a model to an API and call it innovation. They should help a company decide which workflow is worth changing, where the right data is, what the system is allowed to do, when people need to step in, and how to tell if the work is actually improving the process.

They should also be asking what happens when the model changes, the company changes a policy, or the data and workflow change. Those are normal parts of operating a business, and the AI application needs to keep up with them.

Sometimes an LLM is the right tool. Other times, ordinary software, better data integration, or a rules-based process makes more sense. Someone who has worked on these projects should know the difference.

AI makes it much faster to go from an idea to something that works, and that is valuable. But the problems with a weak workflow, bad permissions, unreliable output, or missing monitoring often do not show up until after the demo works. That is why implementation experience matters.

If an AI initiative is stuck between an impressive demo and something useful in production, do not assume it needs a bigger model or another tool. It may need a clearer workflow and people who know where these systems tend to fail.

AI code generation is one of the most useful things to happen to software development in a long time. We use it. It gets people from an idea to a working application much faster than they could have a few years ago.

That is a big deal. It is also not the same thing as getting from an idea to a well-operated application.

This week, one of our clients’ Snowflake cost alerts went off. A new application had spent more than $4,000 in a couple of days. The application had been built with Claude and it was doing what its owner intended it to do. The problem was how it was doing it: repeatedly polling Snowflake with a larger warehouse than the work required.

The code worked. The bill did too.

The alert was the important part

The client had anomaly alerts in place long before this application existed. Over years of normal use, those alerts had established a useful picture of what ordinary compute usage looked like. When the new application’s usage departed from that pattern, it stood out quickly.

That monitoring was not glamorous, and it was not new. It was operational knowledge turned into a guardrail. Without it, the polling loop could have continued until someone happened to notice an unusually large bill.

This is worth emphasizing because it is easy to see AI as the whole story. The model helped create the application. The monitoring, the historical baseline, and the people who responded to the alert are what limited the damage.

Working is not the same as economical

AI is good at getting to a plausible solution. It can write the query, connect the service, add a loop, and return the result. But it does not naturally care whether a process runs every minute instead of every hour, whether data can be cached, whether an existing system already solves part of the problem, or whether a warehouse is sized appropriately for the query.

Sometimes the generated solution will rebuild something that already exists. Sometimes it will choose a direct approach that is perfectly functional but wasteful at production scale. A polling loop is a simple example: it may make a feature feel responsive while quietly paying for repeated work that is unnecessary.

None of that makes the application useless, or AI a bad tool. A few years ago, a person without deep technical experience might not have been able to build and deploy this application at all. Now they can. That is real leverage.

But the leverage changes where the risk sits. Development time may go down while cloud spend, maintenance, security exposure, or reliability risk goes up. Those costs often arrive after the demo is working and the application is in use.

A short review can be a very good investment

The answer is not to ban AI-generated code or require every idea to go through a long development process. The answer is to put experienced eyes on the parts that determine how software behaves in the real world.

For a data-backed application, that review can be straightforward:

• What runs on a schedule, and how often does it actually need to run?
• Which queries execute, on what warehouse, and how much data do they scan?
• Can the application cache results, react to an event, or reuse an existing data set instead of polling?
• What is the expected cost at normal usage and at a failure mode?
• Which alerts will tell us when the application behaves differently from expected?

A review like this does not need to take longer than the work it is reviewing. In this case, it could have prevented a four-figure surprise. More importantly, it creates a habit of treating an AI-generated application as software that will be operated, not just code that needs to run once.

Keep the human in the loop

There is a familiar parallel with outsourcing. Lower-cost implementation can be a good trade when the work is understood and the output is reviewed. It becomes expensive when the apparent savings mean nobody owns the architecture, the quality, or the ongoing consequences.

AI assistance is similar. It can make capable builders out of more people, and that is something to embrace. But it can also produce slop, inefficiencies, security risks, and bugs that are easy to miss because the first version looks complete.

The goal should not be to slow people down. It should be to pair the speed of AI with monitoring that catches surprises and with people who understand the systems, costs, and tradeoffs behind the code.

This is the first in a series of examples from the gap between shipping software quickly and operating it well. AI can help you build faster. Make sure someone is also asking what the resulting system will cost to run.