Building software is much faster now. We build the same kind of technology we built ten years ago, in a fraction of the time. So for most companies the real question is no longer whether they can build something. It is how to incorporate AI into it without making the software more expensive and less reliable.
Short answer: For workflows where you know the input and you know the expected output, plain code beats AI inside the app. It is cheaper, it is deterministic and it does not need rechecking. The better place for AI is outside the app: build the platform as a harness, with APIs, MCP tools and CLIs, so any AI agent can use it like a person would, while humans keep oversight.
Where AI belongs in business software is a design decision
Where you put AI decides what it costs you, how predictable the results are, and how much your team has to check afterwards. Most teams default to adding AI to every feature because it feels like the modern move. We did the same, and it taught us a lot about where AI helps and where it gets in the way.
1. Try AI in the application layer, and see what happens
Our first assumption was that AI belonged inside the application. The idea sounded right. If the app had AI built in, inputs could be negotiated flexibly, so users would not have to give the system exactly the right data in exactly the right shape. And the outputs would be better, because the AI could shape them to the situation.
What that looked like in practice
Steps that used to be handled by code were handed to AI. Data came in, the AI interpreted it, and the AI produced the result the next step needed. On paper the workflow became smarter. In practice it became something we had to watch.
2. Notice why it breaks for fixed workflows
It broke because most business workflows are X in, Y out. You know what comes in and you know what should come out. For that kind of work, putting AI in the middle adds cost and risk without adding much value.
Tokens cost far more than code
Every time AI runs a step, you pay for the tokens. Code that does the same transformation runs again and again at almost no cost. When a step runs many times a day, the difference adds up quickly, and you are paying for flexibility the workflow never needed.
AI is non-deterministic
Give AI the same input twice and you may not get the same output twice. It made assumptions we did not ask for and added fluff we did not want. For a step whose job is to produce one exact, expected result, that is a defect, not a feature.
The automation turned into rechecking
Because the output could not be trusted blindly, the team had to check it. The automation that was supposed to save time turned into boilerplate rechecking. For X-in, Y-out work, code wins. It does the same thing every time, and you can test it once and rely on it.
3. Build the platform as a harness instead
The fix was to stop baking AI into the app and to build the platform as a harness. The application does what code does well: it stores the data, runs the business logic, and computes the metrics and outputs. Then it exposes all of that functionality through API endpoints, MCP tools and CLIs.
The AI agent engages with the app like a user
With a harness, the AI agent does not live inside the app. It uses the app the way a team member would. It reads the data, looks at the metrics, checks the output, and makes decisions from what the app tells it. The numbers it reasons about are computed by code, so they are correct and consistent. The AI does the part AI is good at: judgment, drafting, and deciding what to do next.
Bring whichever AI you want
Because the app only exposes tools, it stays agnostic about which AI uses them. You can bring any AI you like. Bots can engage through MCP almost like a person would. Team members can connect the terminal AI coding tools they already use through the CLI or the API. When a better model comes out, nothing in the app has to change.
Agents can work with each other through the app
AI agents, and the AIs your team members use, can talk to each other through the app. One agent researches and leaves a brief, another picks it up and does the work, and a person reviews it. The app is the shared place where that hand-off happens, so nobody depends on a private chat between tools.
4. Keep humans in the middle with audit logs and routines
A harness only works for a business if people stay in control. Everything an agent does through the app leaves audit logs and history, the same way a person's actions would. Humans stay in the middle. You can see what the agents did, decide which actions they may take on your behalf, and step in when something looks off.
Schedule routines for recurring work
Recurring tasks become routines. An agent can run a scheduled check or a weekly follow-up through the same tools, and every run leaves the same trail. You get the time savings of automation without giving up the record of who did what and when.
How we approach this at Dasnuve
When we build intelligent applications for clients, we start by separating the work. Anything with an expected input and an expected output goes into code, often as part of a broader automation effort. Then we expose the platform through APIs, MCP tools and CLIs so the client's AI agents and team can work with it. Our own content workflow runs this way: AI agents draft and hand work to each other through our platform, and a person approves every piece before it goes out. If you want to see how the tool side works, the Model Context Protocol documentation explains the standard many AI tools now use to connect to apps.
FAQ
Should every app have AI built in?
No. If a feature takes a known input and should produce a known output, code is cheaper and more reliable. It is usually better to make the app easy for AI to use from the outside, through APIs and MCP tools, than to put AI inside every feature.
When is plain code better than AI?
Plain code is better whenever the job is X in, Y out: calculations, data transformations, status updates, reports with a fixed format. Code gives the same answer every time and costs almost nothing to run. AI is better suited to decisions and judgment based on what the code produces.
Which AI should we use with a harness?
Whichever one your team prefers. A harness exposes the app through standard interfaces, so bots, AI agents and terminal AI coding tools can all use it. You are not locked into one vendor, and you can switch later without rebuilding the app.
How do we keep control over what AI agents do?
Give agents access through the app's own tools, and make sure every action leaves an audit log and history. Decide which actions agents may take on their own and which need a person to approve them. That keeps humans in the middle while the agents handle the routine work.
Where to start
Pick one workflow your team runs often and ask a simple question: do we know what goes in and what should come out? If yes, that part belongs in code, not AI.
Then look at how your team would reach that workflow from outside the app. If there is no API, MCP tool or CLI for it yet, that is the first thing to build. Once it exists, any AI agent your team chooses can start working with it, and you can watch every step it takes.