Vikas Mittal, Principal Architect building real-time AI platforms for retail enterprises at Walmart Global Tech.
getty
It seems like everyone is using AI to improve their enterprise operations. We're no different. Not too long ago, our business team had an urgent need ahead of a major event, but the requirements were still evolving. They knew the outcome they wanted but not yet the full shape of the final feature. Because we already had the backend APIs in place, we used AI to speed up the UI layer and quickly built a working prototype around one important use case.
That speed mattered. It allowed us to put something usable in front of the business team far earlier than a traditional delivery cycle would have allowed, and it reduced a significant amount of manual work at a time when they needed relief quickly. We hosted that prototype in a shared workspace, and it gave the team something practical they could use while we continued shaping the broader solution.
What stood out to me was that the prototype did more than solve an immediate need. Once users had something real in their hands, they started thinking differently. Instead of discussing requirements in the abstract, they began reacting like actual users. They could see what automation might replace in their legacy process, and that gave them much more clarity about where the final product should go.
What that prototype made clear to me is that speed and readiness are not the same thing. It solved an immediate business problem, but it was never the finished answer.
Like many fast prototypes, it came with real limitations. It handled the primary positive use case, but it was not designed to support the full range of inputs, edge cases or production-scale load. It had not been tested thoroughly, and it had not gone through the broader checks we would expect for a production feature, including security review, visual QA and performance validation.
That gap matters. AI can accelerate implementation, especially when time is short, but it does not automatically think through every operational, architectural or user-level implication. Someone still has to define those expectations clearly, identify where the design may fail and shape the solution around real-world constraints. In my experience, that is where human judgment becomes even more important.
One lesson I have learned is that raw model capability is only part of the story. General-purpose tools like Claude can be very helpful for coding tasks, problem solving and generic development questions. But in an enterprise environment, useful answers often depend on context that a public model simply does not have.
In our case, internal retrieval-based tools add that missing layer. They can pull from company knowledge across requirements documents, Jira, GitHub and other engineering artifacts. That matters because many implementation decisions are shaped by things outside the code itself. A developer may need to understand internal CI/CD expectations, deployment YAML patterns, repository structure, parent POM dependencies, Docker base images, approved JDK versions, VM standards, hybrid cloud constraints, configuration management practices or secret management requirements before a feature is truly ready to move forward.
A public coding assistant may help generate the code, but an internal knowledge-aware tool can help align that code with the environment it has to live in. In my experience, that makes AI much more useful in enterprise engineering.
That experience also changed how I evaluate AI-generated output. I no longer look at speed alone. I look at whether the result is actually ready to live inside a real product environment.
In the prototype phase, requirement fit was the first priority. We built around the primary positive use case, and that was enough to solve an immediate business problem. But that did not mean the solution was complete. It had not been tested thoroughly, it did not align with our company’s standard UI components and themes and it had not been built with the full set of authentication and security expectations required for production. It also was not passing the deployment gates we would normally expect before releasing something into a live environment.
Before you trust AI-generated code, you want to know whether it fits the real requirement, whether it holds up beyond the happy path, whether it aligns with enterprise standards and whether it can clear the quality and deployment controls that protect production systems. If those things are missing, then what you have is a useful starting point, not a finished solution.
AI helped me give the business an early look at what the product could become and how it might solve an urgent need. It accelerated the development process and helped us put a usable tool in people’s hands much earlier than we otherwise could have.
But it did not change the standards the final product had to meet.
In my world, AI does not replace company policies, CI/CD standards, deployment gates, QA and UX signoffs, performance and load testing or the broader engineering excellence benchmarks that make software dependable over time. Observability, robustness, disaster recovery and cost still matter. So do security and operational readiness.
That is why I see AI as an accelerator, not a shortcut. It can help teams move faster, explore sooner and learn earlier. But it still takes disciplined engineering to turn that speed into something the business can trust.
Forbes Technology Council is an invitation-only community for world-class CIOs, CTOs and technology executives. Do I qualify?
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。