We hear some version of this question almost every week: if AI can build an application, fix errors, and make changes through a conversation, why hire a development team?
It is a fair question. People are building useful tools that they could not have built on their own a few years ago. A small automation or a working prototype may be well within reach.
At Canviz, we use AI too. The reason to involve an experienced team is the judgment around the work: understanding the business rules, making technical choices, and establishing whether the result is ready for people to rely on.
A reporting project we were brought into illustrates why that matters.
The report worked with the old data
A client had a business-critical quarterly report that took roughly 120–140 hours to prepare. The work involved combining information from several sources, manipulating it in Excel, and checking the results.
They used Claude to help build a reporting solution in Power BI, providing previous reports as examples. It reproduced the historical results and offered a way to remove a substantial amount of manual work.
Because accuracy mattered so much, the client planned to check the first two quarterly runs manually. Those checks were a good decision. When later quarters brought different data and changing variables, the results were no longer correct.
Our review found fixed values and fallback logic in the AI-generated solution that did not hold up under those changes. The person building it understood the reporting work, but did not have the development experience to recognize those issues in the underlying implementation.
The earlier reports were useful examples. They had not established that the solution correctly represented all the rules needed for future reports.
A result that matches last quarter is a starting point. The next question is whether it will still be right when the inputs change.
Knowing what to check
An experienced developer can miss a problem too. A job title does not guarantee correct software.
What helps is a process that brings engineering experience together with the people who understand the business. For a report like this, that means agreeing on the calculation rules, identifying what changes between periods, and checking results against independently established expectations.
The team should ask what happens when a source is incomplete, a category changes, or an unusual transaction appears. It should also decide when the report needs to stop and flag a problem instead of quietly supplying a fallback value.
AI can help create and run those checks. But tests built around the same mistaken assumption as the original code may simply confirm that the code behaves as written. Someone needs to question the assumption itself.
This is also why “the AI says it tested everything” needs a follow-up: what did it test, and what did those checks establish?
The decisions behind a working screen
The same issue comes up outside reporting.
An AI tool may ask how users should sign in and recommend an approach. An experienced team can evaluate that recommendation against the company's existing accounts, access restrictions, customer needs, and support arrangements. A choice that makes today's prototype easy may create unnecessary work later.
Changes need that same attention. You might ask AI to remove a button and see it disappear. That confirms the visible result. It does not tell you whether the underlying action was removed, whether it should remain available elsewhere, or whether another part of the application still depends on it.
Keeping old code is sometimes intentional. Leaving it without understanding its purpose can make later changes harder to follow and test.
These are ordinary software engineering concerns. AI makes it easier to produce and revise code, which makes a clear understanding of those changes especially valuable.
How we approach the work with AI
Our approach starts with understanding the requirements and agreeing on a direction. We use AI to help develop a plan, review that plan, implement changes, and test the result. Engineers remain involved in the decisions and review throughout.
There is room to experiment and change direction. When requirements change, the plan and documentation need to reflect the new decision so the next round of work starts from a shared understanding.
The checks should suit the application. For reporting, that could mean tracing a number back to its source and testing several reporting periods. For a customer portal, it could mean confirming that one customer cannot access another customer's records. Testing whether a page loads would not answer either question.
AI can contribute to this process as well as to implementation. Anthropic's own guidance on verification loops describes using repeatable tests and checks to help Claude verify and revise its work.
The value of an experienced team includes choosing meaningful checks, reviewing the evidence, and addressing gaps before the business depends on the software.
How much help does your project need?
A full development team is not necessary for every tool. For some businesses, a focused addition to existing software is enough. The level of involvement should reflect the consequences of a mistake and how easily someone can detect and recover from it.
Building it yourself may be reasonable
For a prototype, a personal tool, or a small automation with easily checked results, working directly with AI can be a practical approach. Keep the scope manageable, understand what information it can access, and check the output before relying on it.
A focused review may be enough
You may already have something useful and want help checking the calculations, access controls, or structure before more people start using it. That can call for a limited engagement rather than a complete rebuild.
Ongoing engineering involvement may be warranted
When software supports important decisions, serves customers, connects several systems, or handles information people should not all be able to see, it needs a delivery and support process appropriate to those responsibilities.
Size alone is a poor guide. A small calculation used in a major business decision can deserve more scrutiny than a large demonstration application.
Bring what you have already built
If you have used AI to build something useful, that work can be a valuable starting point. It helps explain the problem, the workflow, and what you want the software to do.
We can help assess what is working, where the uncertainties are, and what level of help makes sense. That might be a review, targeted improvements, or a team to take the application further.
Talk with Canviz about what you are building, including the parts you are confident in and the parts you would like another set of eyes on.
