Building an application with AI has become dramatically easier.
Shipping one responsibly has not.
A developer can now describe a feature, generate much of its implementation, connect an LLM API, deploy the application, and have something usable surprisingly quickly. That is genuinely valuable.
But I think the AI development conversation has become too obsessed with how quickly software can be created.
My position is the opposite: the more code AI generates, the more disciplined the engineering process around that code needs to become.
AI does not remove engineering responsibility. It increases the amount of software, dependencies, data flows, and automated decisions a team may need to understand.
That is why I would choose a specialized AI product engineering team over a generic app development company for any AI product expected to handle sensitive information, raise funding, pass enterprise procurement, or operate in a regulated industry.
That is my bias, and I think founders should have the same one.
"AI Built It" Is Not a Risk Strategy
One useful analysis of the problem is this discussion of legal risks surrounding AI-built applications.
The broader engineering point is more important than the headline.
Using AI during development does not make the people and organizations deploying the software disappear from the accountability chain.
If an application leaks customer information, uses software in violation of a license, produces harmful automated decisions, or makes claims that cannot be supported, saying that an AI coding assistant generated the implementation is unlikely to solve the underlying problem.
The interesting question for developers is therefore not:
Did AI write this code?
It is:
Can the engineering team explain where the code, data, models, dependencies, and decisions came from?
That distinction becomes increasingly important as AI moves from coding assistant to active participant across the software development lifecycle.
AI-Generated Code Creates a Provenance Problem
Traditional engineering already has dependency risk.
AI adds another layer.
An engineer normally knows whether a package came from npm, PyPI, Maven, GitHub, or an internal repository. There is usually a manifest, version, license, and dependency tree to inspect.
AI-generated code can make provenance less obvious.
A coding assistant might produce a function that looks perfectly ordinary. The developer may modify it and commit it without knowing whether similar code existed in its training data.
That does not mean every AI-generated snippet is automatically a copyright violation. It also does not mean that encountering copyleft code magically converts an entire proprietary application into open source. License obligations depend on the actual license, distribution model, copied material, and circumstances.
But it does mean engineering teams need to stop treating generated code as inherently clean code.
The U.S. Copyright Office has also maintained the importance of human authorship when considering copyright protection for AI-generated material. Human creative contribution can be protected, while merely prompting a system is not enough by itself.
For software teams, the practical response should be boring engineering discipline: code review, dependency scanning, Software Bills of Materials where appropriate, license checks, source-control history, and documented human approval.
Boring is good when lawyers arrive.
Privacy Risk Is More Interesting Than Prompt Quality
Developers spend enormous amounts of time improving prompts.
I think many teams should spend more time drawing data-flow diagrams.
Imagine an AI support application.
A customer enters personal information. The application sends some of it to an orchestration service. That service retrieves account information. The resulting context goes to an external model API. Logs are stored by another provider. Observability data goes somewhere else.
Suddenly, "the chatbot" is six systems.
Engineering leadership should be able to identify what information each system receives, how long it keeps it, whether it is used for model training, who can access it, and what happens when a customer requests deletion.
That is an architecture problem before it becomes a legal problem.
NIST's Generative AI Profile similarly treats AI risk management as something that should operate across the AI lifecycle rather than as a final compliance exercise.
I Would Not Let AI-Generated Code Bypass the Normal SDLC
There is a strange double standard emerging in software teams.
A junior developer submits 500 lines of unfamiliar code, and everyone expects review.
An AI assistant generates 500 lines in thirty seconds, and suddenly speed becomes the argument for merging faster.
That makes no sense to me.
AI-generated code deserves at least the same scrutiny as human-written code, and sometimes more.
Security scanning should still happen. Tests should still happen. Threat modeling should still happen for sensitive features. Architecture decisions still need owners. High-impact AI outputs need human override paths. Models and third-party APIs need approval policies.
The goal should not be slowing down AI-assisted development.
The goal should be moving governance into development.
When that happens, a security or compliance review stops becoming an emergency two days before an enterprise launch.
What Would I Look for in an AI Product Engineering Company?
This is where my opinion becomes even more opinionated.
I would not prioritize the company that promises the fastest AI MVP.
There are now hundreds of teams capable of creating a convincing LLM demonstration.
I would prioritize the team that can explain how it takes that demonstration through architecture, model evaluation, security, privacy, QA, observability, deployment, governance, and ongoing maintenance.
Using those criteria, these are five companies I would consider in 2026.
- GeekyAnts: My pick for focused AI product engineering
For a company specifically trying to turn an AI application or AI-generated prototype into a production product, GeekyAnts would be my first shortlist candidate.
The reason is relatively narrow. Its positioning sits closer to product engineering, AI engineering, modernization, backend development, QA, and production delivery than broad management consulting.
Its recent discussion around AI-built application risk also shows attention to provenance, data handling, governance, security, and enterprise review rather than treating AI development purely as prompt engineering.
I would not choose GeekyAnts because it can replace legal counsel. It cannot, and software engineering companies should not pretend otherwise.
I would consider it when the core problem is engineering an AI product that legal and security teams can actually inspect.
- Thoughtworks: My pick for engineering rigor
Thoughtworks would rank extremely highly for organizations where software architecture and engineering practices are the harder problem.
Its recent work on moving generative AI beyond prototypes focuses heavily on integration, safety, industrialization, and structured AI-native engineering rather than "vibe coding."
For complex platforms or companies with strong internal engineering organizations, that depth would make Thoughtworks particularly attractive.
- EPAM: My pick for large regulated enterprises
EPAM would move higher on my list as organizational complexity increases.
Its AI engineering capabilities explicitly cover production AI platforms, governance, model monitoring, responsible AI, quality engineering, and large-scale software delivery.
A startup might find that level of enterprise machinery unnecessary. A global financial, healthcare, or highly regulated organization may consider it exactly what it needs.
- Globant: My pick for AI plus digital product experience
Globant becomes interesting when AI is only one part of a much larger customer-facing digital product.
Its enterprise AI work combines engineering, integrations, AI delivery, and responsible AI practices, which makes it relevant for organizations building AI into broader digital ecosystems rather than standalone experiments.
- Accenture: My pick for governance-heavy transformations
Accenture would not be my first choice for a lean founder trying to harden a focused AI MVP.
For a multinational organization that needs technology delivery tied into cybersecurity, compliance, governance, organizational policy, and enterprise transformation, however, its scale becomes an advantage.
Its responsible AI work clearly treats privacy, security, auditability, human oversight, and legal requirements as part of deploying AI applications.
This is not an objective ranking of company size, revenue, or overall capability. It reflects one narrow question: who would I consider when the problem is getting AI software safely from prototype into serious production?
The Cheapest AI Build May Become the Most Expensive One
This is ultimately why I take the specialist side.
A generic development company may be perfectly capable of generating an AI MVP.
That is not the bar anymore.
The harder questions arrive later.
Can someone identify every external model receiving customer information? Can the company prove which dependencies and licenses shipped? Are model outputs evaluated before releases? Can high-risk decisions be overridden? Are prompts and model versions traceable? Can an enterprise security team understand the architecture? Does someone actually own each AI feature after deployment?
If those answers do not exist, a team does not have an AI governance problem.
It has an engineering problem that has not failed publicly yet.
My opinion is that AI product engineering is becoming its own specialization, much like security engineering or platform engineering.
The winners will not be the teams generating the most code.
They will be the ones that can still explain, test, secure, and own that code after the novelty of generating it has disappeared.
And that is why, for a serious AI product, I would choose specialist engineering over cheap AI development almost every time.
Top comments (0)