A lot of businesses are discovering something awkward about AI.
It was supposed to save time, and now somehow everyone is spending half the day babysitting it. Someone gives the AI a vague task. The AI makes a plan. Then it revises the plan. Then it asks for context it should have been given in the first place. Then it wanders into a corner, confidently misunderstands the job, burns a pile of tokens, and eventually a human has to come back in and explain reality to the very expensive robot intern.
This is usually not a model-quality problem. It is a task-design problem.
AI can absolutely be a multiplier. We use it heavily at Panda Rose. We have trained teams on how to use it effectively, we have given courses and seminars to all sorts of businesses from small shops to banks and large industrial clients. They have all seen the benefit. Internally, We use it in writing, planning, coding, debugging, research, documentation, technical exploration, and software delivery. We have also worked on systems where AI sits inside the actual workflow, not off to the side as a novelty button someone added because the demo needed jazz hands.
But there is a large difference between smart AI and token-maxxing.
Token-maxxing is when people confuse more prompts, more context, more agents, more loops, and more model calls with better work. Sometimes the AI is not thinking harder. Sometimes it is just wandering expensively. Agentic AI is powerful when it has a job. It gets expensive when it has a vibe.
The smarter approach is to put AI where it actually belongs: the parts of the work that are messy, interpretive, inconsistent, language-heavy, or hard to reduce to clean rules. The rest of the system should still be boring, reliable software.
Boring is underrated. Boring pays the bills.
Normal software should still do normal software work
There is a strange temptation right now to put AI into everything. Inventory? AI. Scheduling? AI. Reports? AI. CRM updates? AI. A button that used to say “Submit”? Probably AI-powered now, because apparently buttons needed venture capital.
Please no.
If a process is deterministic, use deterministic software. If the rule is clear, write the rule. If the calculation is fixed, calculate it. If the data needs to be stored, store it properly. If permissions matter, use permissions. If something needs an audit trail, log it. If the workflow has known states, model the states. If a report needs totals, do not ask a language model to “think about the vibe of the numbers.” That is how dashboards become non-deterministic and untrustworthy statistics, or in the worst case, pure fan fiction.
AI should not guess your inventory count. Your inventory system should handle inventory. AI can help interpret the messy note explaining why the count changed, but the count itself belongs in ordinary software with records, validation, timestamps, users, and accountability, not in a large vaguely defined statistical model.
You see, this is where a lot of businesses get themselves into trouble. They use AI where a script, a database query, a validation rule, or a basic integration would be cheaper, safer, and more reliable. Then they wonder why the system is expensive to run and hard to trust.
We have found that the best AI architecture often has a lot of normal software around it.
That is the advanced part. (And what I’ve taught in our advanced seminars)
AI belongs at the messy edge
The useful place for AI is usually where the work gets messy.
Messy descriptions. Staff notes. Customer emails. Support histories. Operational exceptions. Intake forms with half the information missing. Product descriptions written three different ways by three different people who all swear their version is obvious. Warehouse notes that make perfect sense if you were standing there, and much less sense once they reach a spreadsheet.
That is where AI can earn its keep.
AI can help classify messy input. It can summarize context. It can extract structure from inconsistent text. It can draft a response for a human to review. It can identify missing information. It can help turn a conversation into requirements. It can suggest likely next actions inside a controlled workflow. It can help staff navigate ambiguity without turning every exception into a custom-coded branch of a haunted decision tree.
We have worked on operational systems where the clean part of the process was obvious: records, statuses, quantities, users, timestamps, validation, reporting. That part should stay boring. Another part of the process involved messy descriptions, exceptions, shorthand, handwriting, context, and judgment calls that trained staff understood but that did not collapse neatly into a simple rules table.
That is where AI made sense.
The warehouse system still ran the warehouse. AI helped with the interpretive layer where the input was too variable for a brittle pile of if-statements, and that distinction matters. AI should not replace the system. It should help the system understand the parts that ordinary software should not pretend are tidy.
This connects directly to the way we think about business analysis and custom software development. You have to understand where the work is clean, where it is messy, where the rules are real, and where the “rules” are actually tribal knowledge wearing a badge.
Basic programming makes AI dramatically more useful
One of the most underrated AI skills is basic programming.
That does not mean every business owner needs to become a software developer, start arguing about tabs versus spaces, and develop a strong emotional attachment to their terminal theme. Nobody needs more of that at family dinners. However, understanding enough programming to know when a task should become a script can make AI dramatically more useful and dramatically cheaper.
Unfortunately, a lot of people use AI like a slot machine with grammar. They paste in data, ask for a transformation, copy the result, and then do the same thing again next week. Then again next month. Then again every time the same annoying task returns from the swamp. That may feel productive at first, but it is still token-maxxing. The AI is doing the same reasoning repeatedly because nobody turned the repeatable part into a tool.
A smarter approach is to use AI once to help create a deterministic script.
If the job is “take this messy CSV, clean the columns, normalize the dates, remove blank rows, validate the totals, and produce a report,” AI may be useful for helping write the script. After that, the script should do the work. The business should not be paying tokens every time the same cleanup is needed. The script does not get bored, forget the instructions, hallucinate a new column, or decide today that the date format is more of a lifestyle choice.
Use AI to help build the tool. Then let the tool do the repeatable work.
This is smart AI.
A business may not need an AI agent to process the same spreadsheet every week. It may need a small script. A company may not need a chatbot to reformat exported data. It may need a repeatable data transform. A manager may not need to paste the same report into AI every Friday. They may need a tool that pulls the file, checks the numbers, generates the summary, and flags the exceptions.
AI can help write those tools faster. It can explain unfamiliar code. It can help debug errors. It can help turn a manual process into something repeatable. Once the deterministic work is captured in code, the AI can step out of the way. That is cheaper. It is also safer.
Normal code follows the same instructions every time. It can be tested. It can be logged. It can be version-controlled. It can be reviewed. It can run without a model deciding to become creatively helpful. This is one of the places where people who know even a little bit of programming get a huge advantage with AI. They do not just ask AI to do tasks. They ask AI to help them build reusable tools that do tasks.
That changes the economics completely.
A boring Python/NodeJs/Powershell script that saves three hours every week is not boring to the person who gets those three hours back. A small automation that prevents bad data from reaching a report is not boring to the person who no longer has to explain why the numbers changed. A repeatable tool that turns a messy export into usable information is not boring to the business that stops paying people to be copy-paste middleware.
This is the kind of thing Panda Rose looks for when we review workflows. Sometimes the answer is AI. Sometimes the answer is a script. Sometimes it is an integration. Sometimes it is a proper internal tool. Sometimes it is fixing the process before writing a line of code.
The trick is knowing the difference.
That is where enterprise integration starts earning its keep.
Agentic AI needs a leash
Agentic AI is where things get interesting, and also where people start lighting money on fire with enthusiasm… great enthusiasm.
A useful agent can call tools, follow a process, keep track of state, hand work off, check results, ask for clarification, and return structured output. OpenAI’s current Agents SDK documentation talks about tools, orchestration, handoffs, guardrails, human review, state, integrations, and observability. That is the right direction because it sounds much more like software architecture than chatbot theatre.
Anthropic’s article on building effective agents is also worth reading because it emphasizes simple, composable patterns over giant magical frameworks. That should not be revolutionary, but apparently we are all relearning that simple systems are easier to understand than haunted chandeliers made of API calls.
A good agent should know its job, know its tools, know when to stop, and know when to ask for help. Coincidentally, that is also a good description of an employee who does not make everyone tired.
Bad agent design usually has the opposite pattern. The agent gets a vague mission, a pile of tools, a giant context window, and permission to “figure it out.” Then everyone acts shocked when it uses too many tokens, makes strange choices, produces a novel interpretation of the business process, and requires constant supervision.
If your agent needs babysitting all day, you may not have an agent. You may have an expensive intern with a token budget.
This is why agentic AI needs constraints. It needs clear inputs and outputs. It needs tool permissions. It needs logging. It needs cost controls. It needs review points. It needs fallback paths. It needs a reason to exist beyond “we heard agents are the future and wanted one before the next board meeting.”
More steps do not mean more intelligence. More agents do not mean more strategy. More tokens do not mean more wisdom.
Sometimes more tokens just means the architecture is confused.
Codex, Claude, and the clear-task problem
The same principle applies when using AI for programming.
Tools like OpenAI Codex, Claude Code, and other coding agents are becoming genuinely useful. Codex is now positioned as a coding agent that can help write code, understand unfamiliar codebases, and adapt to an existing project’s structure and conventions. That matters. These tools are moving beyond autocomplete and into real development assistance.
But the work still has to be framed.
A vague request to a coding agent creates the same babysitting problem as a vague request to a human developer, only faster and with more confidence. The agent needs to know the goal, the files, the constraints, the tests, the expected output, the style of the codebase, and what counts as done.
A good prompt is not magic words. It is task design.
The visible prompt is the tip of the iceberg. The real work is deciding what task you are giving away, what judgment you are keeping, what the output must survive, and how you will know whether it worked.
This is why experienced developers get more out of AI coding tools. They know how to break work into sane chunks. They know how to review output. They know what tests should exist. They know when the agent has solved the local problem while creating a future maintenance crime scene.
AI can help write code. It can help write tests. It can summarize errors. It can explain unfamiliar libraries. It can generate documentation. It can scaffold a first pass. That is all valuable.
Typing code was never the whole job.
The real job is understanding what should be built, what should not be built, and how the thing will survive contact with users, data, edge cases, permissions, deployment, and the sentence every developer loves to hear: “Oh, we forgot to mention this only happens twice a year, but if it fails, accounting cannot close the month.”
That sentence has destroyed more optimism than any framework choice ever will.
We wrote about this broader habit of choosing the right tool instead of blindly following fashion in A Parable for Software Development. The same instinct applies here. AI is a tool. Sometimes it is the right tool. Sometimes the right answer is a boring script and a grown-up review process.
AI can make bad processes worse faster
The research backs up the caution here. BCG’s work on the “jagged technological frontier” found that people can create real value with generative AI in the right tasks, but can also destroy value when they trust AI outside the areas where it is competent. That is exactly what we see in practice: AI is powerful, but placement matters.
Microsoft Research has also studied how generative AI affects critical thinking in knowledge work, and one of the uncomfortable themes is that people’s confidence in AI and confidence in their own task knowledge change how much critical thinking they apply. The tool can speed up work, but it can also move judgment into review, verification, and task stewardship. That means the review process is not a polite afterthought. It is part of the work.
The boring translation is this: if your workflow has bad data, unclear ownership, no review process, and no one who understands the edge cases, adding AI will not magically create discipline. It may just produce a more modern-looking mess.
AI can make a bad process look advanced. That is the dangerous part.
A workflow with bad data, unclear ownership, and no review process does not become mature because a model is now involved. It becomes harder to debug. The problem is no longer just “who entered the wrong thing?” Now the problem is “what did the AI interpret, what did it call, what did it assume, what did it return, and why did everyone trust it?”
This is why observability matters. OpenAI’s agent docs include integrations and observability for a reason. When AI participates in a workflow, you need traces, logs, review points, and enough visibility to debug the system when it does something weird.
Because it will do something weird.
That is not cynicism. It is just Tuesday.
AI is a multiplier, so choose what it multiplies
AI can absolutely be a multiplier. Used well, it can make capable people faster, give small teams more reach, help developers move through mechanical work faster, help analysts structure messy information, and help businesses turn repeated friction into tools.
Remember though, multipliers multiply what they are attached to.
Attach AI to a messy process nobody understands, and it can multiply confusion. Attach it to bad data, and it can multiply bad decisions. Attach it to a vague task, and it can multiply supervision. Attach it to someone who knows enough to define the job, review the output, and turn repeatable work into deterministic tools, and it can multiply skill.
This is why basic programming, business analysis, and systems thinking matter so much.
Programming teaches people to separate repeatable logic from judgment. Business analysis teaches people to understand the work before automating it. Systems thinking teaches people that the AI component is only one part of the whole machine.
That combination is where AI starts to become genuinely useful.
This also connects to a broader pattern we have written about before. In The Best Developer in the Room Is Often the One Asking About the Warehouse, the point was that real software work starts where the work actually happens, not where the meeting claims it happens. AI does not change that. If anything, it makes it more important.
In AI Is a Force Multiplier. So What Exactly Are You Multiplying?, the point was that AI makes capable people more capable when the process and judgment are strong. This article is the next layer: put AI where the work is messy, use normal software where the rules are clear, and use AI to help build reusable tools when the task keeps repeating.
That is the difference between smart AI and token-maxxing AI.
How Panda Rose thinks about AI workflows
At Panda Rose, we are interested in AI that survives contact with the business.
That means we start with the workflow. Where does the information come from? Who touches it? What is clean? What is messy? What is repeated? What is interpretive? What should be deterministic? What should be reviewed? What happens when the AI is wrong? What should be logged? What should become a script instead of a model call? What needs a human because the human is the quality control?
Those questions matter more than picking the shiniest tool.
Sometimes the answer is a small script. Sometimes it is an integration. Sometimes it is an internal tool. Sometimes it is an agent with bounded tools and review points. Sometimes it is custom software development around a messy workflow. Sometimes it is enterprise integration because the real problem is that three systems do not talk to each other. Sometimes it is business analysis before anyone should be trusted near a keyboard. Sometimes it is managed IT support because access, permissions, devices, and security are part of the workflow whether the sales deck wants to admit it or not.
AI also connects to websites and marketing, but the same discipline applies. A website chatbot that cannot answer the actual question is decoration. An AI-assisted content workflow that produces generic sludge is just faster mediocrity. AI can support website development, SEO, and content strategy, but someone still has to understand the business, the audience, the claims, and the risk of sounding like a beige LinkedIn post with a contact form.
We have written before about leveraging AI without losing your soul, and that principle still matters. The useful version of AI does not flatten the business into generic output. It helps people do better work with less sludge in the way.
That is what we want for clients.
The question before adding AI
Before adding AI to a workflow, ask a few uncomfortable questions.
Is the task deterministic or interpretive? Is the input clean or messy? Does normal code solve this better? Are we asking AI to repeat the same work every week when a script should exist? What should the AI produce? Who reviews it? What happens when it is wrong? Can we log the decision? Can we control the cost? Does this actually make the business better, or does it just make the demo more exciting?
That last question matters. Some AI demos are extremely good at creating enthusiasm and extremely bad at surviving Monday morning.
The best AI systems are usually not the ones with the most AI in them. They are the ones where the AI is placed precisely, surrounded by boring reliable software, and reviewed by people who understand the work.
AI should go where the work gets messy.
Normal software should handle the parts that need to be boring.
Humans should keep the judgment that actually matters.
If your business is experimenting with AI and finding that it creates as much supervision as productivity, talk to Panda Rose. We can review the workflow, identify where ordinary software should handle the clean work, where AI can help with messy interpretation, where a script would save tokens forever, and where human review still protects the business.
AI can be a multiplier.
Let’s attach it to something solid.
