I spent four days last week trying to do the wrong thing well. We use Claude.ai as part of our internal content workflow. It works well. The instructions, examples and tone guidance we have refined over several months help us produce strong first drafts that are clear, natural and consistent with our voice before they go through human review.
So, when I decided to rebuild part of that workflow using Claude Code and turn it into a multi-user system with automated tracking and saving, the logic seemed sound. Claude Code is powerful, flexible and directly controllable. Surely it could manage the workflow and produce the content just as well. I found that it could manage the workflow but when it came to the content was another matter altogether.
The drafts produced through the automated process were technically correct. They followed the instructions, they met the word counts and respected the required structure and formatting, but they felt rather flat. The language was bland, the tone felt distinctly automated, and the content passed every structural test and still failed the most important one: it was not something a person would particularly want to read.
When I ran the same brief directly through Claude.ai, the output was noticeably stronger. It was more natural, more readable and much closer to the tone we had developed over time.
Four days to learn a lesson that now seems obvious: even when AI tools use similar underlying technology, the environment around the model can materially change the result.
Two AI Environments, Two Different Strengths
Claude Code is designed for software-development work. It can work with files, codebases, scripts, tools and development environments. It is well suited to structured tasks such as building applications, automating processes and coordinating repeatable technical workflows. That made it the right tool for building the application around our content process.
It helped us create the workflow structure, manage the logic, handle tracking and automate how information moved through the system. With clearly defined tasks and appropriate human review, it performed really well.
The problem was not that Claude Code was incapable of generating written content. The problem was that our automated workflow was not reproducing the same context available in Claude.ai. The model received the instructions, but not necessarily the full combination of project knowledge, previous examples, conversational history, tone guidance and iterative human feedback that had shaped the stronger output.
Claude Code understood the structure of the brief but it did not consistently reproduce the voice.
Claude.ai, used directly, had access to a richer working context. That made it easier to refine ideas conversationally, challenge weak wording and shape the output until it sounded like something we would genuinely publish.
The difference was not simply one tool being better than the other. It was a difference in the task, the environment and the context surrounding it.
The Practical Lesson for choosing AI Tools
Both tools are useful when they are applied to the work they are best equipped to support. My mistake was assuming that because they share a foundation, they would be interchangeable.
We see this pattern in AI adoption more broadly. A business tries one AI product, discovers that it does not perform a particular task as expected and concludes that AI does not work for that use case. Often, the issue is not the underlying technology. It is the way the tool, context and workflow have been matched to the task.
A screwdriver used as a hammer does not prove that screwdrivers are useless.
The practical distinction is this: Use an AI environment designed for execution when the work requires access to code, files, tools and repeatable development processes. Use a conversational or content-focused environment when the quality of the result depends heavily on voice, accumulated context and iterative human feedback.
The model matters but so do the instructions, examples, interface, review process and surrounding workflow.
What We Actually Built vs What We Kept
The application itself was still worth building. Claude Code was the right tool for creating the workflow, managing the underlying logic and automating the process. That part of the project worked. What needed to change was the final content-generation step and the context supplied to it.
We have updated the workflow accordingly. The application still handles the structure, tracking and orchestration, while the content-generation process remains in the environment that currently produces the strongest writing for our needs.
Four days was not a bad price for learning that an AI system is more than the model behind it.
The surrounding context can be just as important.
AI tools are not generic. Matching the right tool to the right task is the same discipline we apply when we are recommending technology to clients. It is worth applying to your own operations before you conclude that something does not work.
Applying The Same Discipline to Business Technology
AI tools are not generic, and they should not be evaluated as though they are. Matching the right technology to the right task is the same discipline we apply when recommending systems to clients. A tool can be powerful and still be poorly suited to a particular job. A technically successful implementation can still produce the wrong business outcome. And an investment that appears to have failed may simply have been configured, positioned or applied incorrectly.
Before concluding that an AI tool does not work, it is worth asking: Was it the wrong tool? Was it given the right context? Was the workflow designed around the outcome we actually needed? And, was a human still responsible for judging whether the result was good enough?
If your organisation is working through how to apply AI across its operations, or finding that technology investments are not delivering what you expected, the answer may not be to abandon the technology. It may be to reconsider the job you have asked it to do.
We would be happy to discuss your current approach and help identify whether the issue lies with the tool, the context or the workflow around it.
