AI Governance Can’t Be an Afterthought

At Apna, we build for the human workforce. Apna is one of India's fastest-growing unicorns, with over 60 million users on the platform. At that scale, we see India's workforce very closely. We see millions of people looking for better opportunities, employers trying to hire faster, different languages, different skill levels, and varying levels of digital access and confidence.

At Blue Machines, we build for the AI workforce. We focus on enterprise voice AI, clocking millions of minutes every day. We build more than just bots that answer questions. We build AI workers that can talk to customers, understand context, take feedback, improve over time, and execute real business workflows.

I have seen technology help humans find work, grow, and participate in the economy. And now, I see AI itself becoming a new kind of workforce that can work alongside humans.

So, for me, this moment is not just about using AI for productivity or writing code faster. It is about reimagining how companies operate and how work itself gets done.

You should also read

• A 34-year tech veteran says we’re getting AI wrong

• CTO Revamps Engineering Lifecycle—and Its Impact on His Team

• 12 Best IT Executive Newsletters to Subscribe to in 2026

The Architecture of Two Very Different Businesses

The architecture at Apna is built like a large marketplace platform. We have consumer systems, employer systems, data platforms, AI and matching systems, search, communication, fraud and trust layers, and now AI recruiter and AI interview-prep capabilities on top. The deployment model is cloud-first, highly scalable, and built for high availability because millions of users and thousands of businesses use the platform.

The engineering organization has over 100 people, working across product engineering, backend, frontend, mobile, data, AI, infrastructure, security, and platform teams. We focus not only on building features, but also on building reliable systems that can operate at massive scale.

Blue Machines is a different kind of technology organization. It focuses on enterprise voice AI and agentic workflows. We are building AI workers that can talk, reason, take actions, integrate with business systems, and improve through feedback. Today, we already operate at serious scale, with millions of voice AI minutes clocked every day.

Blue Machines' architecture is more real-time and AI-native. It includes voice infrastructure, telephony, speech-to-text, LLM reasoning, text-to-speech, workflow orchestration, integrations, analytics, observability, and evaluation systems. Product complexity is high because enterprise voice AI must work in production, in real conversations, with low latency, high accuracy, compliance safeguards, and clear business outcomes.

At Blue Machines, a core team of four engineers built a distributed voice orchestration platform in a matter of weeks. We also have a very accomplished research team working deeply on voice AI, agent evaluation, reasoning, latency, multilingual systems, and agent improvement over time. That research depth is important because enterprise voice AI cannot be solved only by stitching models together. It requires strong product engineering, strong systems engineering, and strong applied AI research.

Overall, the technology organization I lead sits at the intersection of large-scale platforms and AI-native systems.

How Well-Governed AI Improves the Software Lifecycle

AI can help engineers write code faster, but unless governance improves, it can also create more hidden bugs, missed edge cases, or poor abstractions.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Abhishek RanjanOpens new window

CTO at Apna and Blue Machines

Over the last year, AI has changed how we build, test, and release technology.

Previously, our release process was more traditional. Engineers built features, raised PRs, went through peer reviews, ran test cases, and then shipped them through the usual deployment pipeline. It worked, but velocity depended on human review cycles, manual QA, and team confidence in the release.

As AI-assisted coding became a bigger part of engineering, we adopted it — and we soon realized that speed improvements alone were not enough. AI can help engineers write code faster, but unless governance improves, it can also create more hidden bugs, missed edge cases, or poor abstractions.

So, we changed the operating model.

1. We added an AI-assisted PR review layer. Every PR underwent checks for risky logic, missing edge cases, API contract breaks, security issues, migration risks, and weak test coverage before human review. This reduced obvious misses before review.
2. We strengthened CI gates. A change could not proceed solely because the code looked fine. It had to pass unit tests, integration tests, linting, security checks, API contract tests, and regression suites for the affected product area.
3. We built stronger regression packs for critical workflows. For example, adding test cases for real user scenarios, edge cases, multilingual behavior, failure handling, and business outcomes.
4. We changed prompt governance. More on that in a moment.
5. We made canary releases mandatory for high-risk areas. Instead of releasing to everyone, we release to a small percentage of traffic, monitor errors, latency, conversion, drop-offs, agent quality, and customer impact, and then promote or roll back.
6. We added better observability. When something broke, we wanted to know exactly which code version, prompt version, model, workflow, or dependency caused it.

The impact has been very visible. Our release velocity significantly increased. Teams that previously shipped larger, bundled releases now move to smaller, more frequent releases. In some areas, release frequency increased by almost 2x to 3x because checks are more automated and confidence is higher. And it's how a team of four built a distributed complex platform in a matter of weeks.

The number of production issues also decreased because every release is smaller, better tested, and easier to roll back. We see a meaningful drop in production bugs, especially where automated regression and canary releases are now mandatory. Today, defects are almost 40% below the original baseline.

AI alone gives speed. AI with governance gives speed and quality.

Why Prompts Must be Treated Like Code

Abhishek Shares

For AI systems, we also began treating prompts like code…This has been an important improvement. We know which prompt was live, what changed, what improved, and whether customer outcomes got better.

For AI systems, we also began treating prompts like code.

We now version, review, test, promote prompts across environments, and roll them out in stages. Prompts are no longer treated like small configuration updates. They undergo test conversations, edge cases, multilingual checks, latency checks, compliance checks, and business-outcome checks.

We can release a new prompt or agent workflow to a small percentage of traffic first, observe the results, and then promote it if the metrics look better.

This has been an important improvement. Previously, it was hard to know whether a prompt change improved the agent or just changed its behavior. Now, we can compare versions more objectively. We know which prompt was live, what changed, what improved, and whether customer outcomes got better.

The bigger change is that the entire technology system became more automated, more measurable, and more governed.

An Agentic Engineering Release Workflow

We use an agentic engineering release workflow, with humans involved at key points.

This workflow does not work for every release. For very complex platform changes, deep architecture changes, or sensitive systems, we still use a more traditional, human-led process. But for some product areas, especially faster-moving workflows, it has become the default way of building.

Here's the workflow:

1. The process starts when a product requirement or engineering problem arrives. An AI planning agent reads the requirement, breaks it into tasks, identifies dependencies, flags risky areas, and suggests an implementation plan. The engineer reviews the plan, corrects assumptions, and decides the final approach.
2. Then a coding agent generates code, refactors modules, writes boilerplate, and creates unit and integration tests. A review agent checks the PR for risky logic, missing edge cases, security issues, API contract breaks, and test gaps.
3. Next, a testing agent creates regression scenarios and validates edge cases. For AI workflows, it also runs prompt evals, conversation tests, multilingual checks, latency checks, and business outcome checks.
4. The release agent then recommends whether the change is safe for canary deployment based on test results, impact area, past failures, and observability readiness. But humans still approve critical promotions, especially if the change affects revenue, customer experience, security, or core infrastructure.
5. Once released, the monitoring agent watches for errors, latency, conversion, drop-offs, agent quality, and customer impact. If something looks wrong, it recommends rollback, opens an incident, summarizes logs, and creates a first RCA draft.

This workflow is agentic, but not blindly autonomous. AI agents plan, code, review, test, release, monitor, and summarize. Humans approve, challenge, prioritize, and own the final decision.

Where Claude Code and Cursor Excel

My favorite tools are Claude Code and Cursor, depending on the workflow.

Cursor excels when engineers want AI deeply integrated into their IDE for day-to-day coding, refactoring, understanding the codebase, and faster implementation.

Claude Code proves extremely useful for more agentic tasks: understanding larger codebases, making multi-file changes, generating tests, fixing issues, and iterating like an engineering partner.

Why AI Provides Leverage While Humans Provide Judgment

We now rely heavily on AI for anything that improves speed, coverage, or consistency, but not for tasks requiring judgment, accountability, or long-term tradeoffs.

For example, AI now helps us in code review, test case generation, regression coverage, documentation, debugging, log analysis, and even incident triage. It can quickly identify risky code paths, missing edge cases, possible security issues, or patterns in production failures. In AI systems, it also helps us compare prompt versions, evaluate conversations, and understand where an agent is failing.

But the final decisions remain human. Here are a few examples:

• Architecture choices must remain human because these involve tradeoffs around scale, cost, reliability, team capability, and long-term product direction.
• End-to-end RCA can be assisted by AI, but humans still need to connect the dots, validate the hypothesis, and decide the fix.
• Backlog prioritization stays human because it requires customer context, business strategy, and judgment on what really matters.
• Security reviews use AI, but expert judgment is necessary. AI can flag issues, but it can also create false positives or miss business-context risks. Humans retain ownership because the risk and accountability are too high.

Real-World Examples of AI Failures in Technical Judgment

…AI still struggles. It can read logs, summarize traces, suggest fixes, and speed up debugging. But in complex distributed systems, it can miss causality, timing, and system-level context.

Share This Quote on:

• Share on Twitter
• Share on LinkedIn
• Share on Facebook

Abhishek RanjanOpens new window

CTO at Apna and Blue Machines

Here are a couple of examples of the importance of human judgment.

The first involved millisecond-level latency spikes in our voice pipeline. AI correctly commented on the issue and identified that latency in one path could become a problem. But the code it suggested was wrong. It looked clean, but it would have created a different bottleneck under load. A human engineer stepped in, understood the runtime behavior, and fixed it properly.

Another example came during production triage. Multiple downstream systems were failing, and AI kept analyzing those systems independently, suggesting optimizations. But we already knew the real issue was an upstream dependency that failed first. AI was confusing visible failures with root cause.

This is where AI still struggles. It can read logs, summarize traces, suggest fixes, and speed up debugging. But in complex distributed systems, it can miss causality, timing, and system-level context.

Why Teams Are Becoming Leaner with More Breadth

AI has changed the hiring profile more than the org chart.

Previously, we hired for narrower functional depth: backend, frontend, QA, DevOps, data, etc. Those skills still matter, but now I value engineers who can operate across the stack, use AI deeply, and move from problem to production with much less handholding.

The best engineers now are not just writing code. They are designing workflows, using AI for implementation, generating tests, reviewing outputs, debugging faster, and thinking about release quality.

So the hiring bar shifted toward high-ownership, high-judgment engineers. People who can ask the right questions, verify AI output, understand systems deeply, and ship independently.

It has also reduced the need for large teams in some areas. A smaller team with strong AI leverage can now do work that previously required many more people.

Why AI Makes It Harder to Train Fresh Engineers

Abhishek Shares

I do not think banning AI or forcing people to code like it is 2010 is the answer. That would be wrong. But I also do not think we have fully solved how to build deep engineering judgment when AI does so much of the upfront work. For now, my best answer is to make understanding visible.

How do we train fresh engineers in the AI era? I do not have a perfect answer yet.

When we started, IDEs helped us. Then, Google helped us. Then, Stack Overflow helped us. But in all those phases, you still had to struggle through the problem. You had to understand the answer, adapt it, debug it, and learn why it worked.

With AI and vibe coding, we can skip that struggle. A fresh engineer can generate working code without really understanding the system, the tradeoffs, or the failure modes. That worries me.

I do not think banning AI or forcing people to code like it is 2010 is the answer. That would be wrong. But I also do not think we have fully solved how to build deep engineering judgment when AI does so much of the upfront work.

For now, my best answer is to make understanding visible. Engineers should be able to explain why the code works, where it can fail, what tests matter, what happens at scale, and how they would debug it in production.

How to Manage Token Usage

Cost has been a challenge of AI as well.

Token usage looks harmless early on, but once AI enters coding, reviews, testing, debugging, and agentic workflows, the cost can grow very quickly.

So now, we must measure ROI by workflow and use smarter orchestration. Not every task needs the most expensive model.

The future involves using the right model for the right task.

Why CTOs Must Move Quickly — With Controls

Here's my advice: Build fast. Experiment fast. Put AI into real engineering, product, support, sales, operations, and internal workflows. Don't pretend it doesn't work. It does work, sometimes surprisingly well.

But don't become blind believers. AI is powerful, but it is not magic. You need control, governance, testing, observability, and clear ownership. Otherwise, you will just create faster chaos.

The right mindset is neither “AI will replace everything” nor “AI is overhyped.” The right mindset is “how do I use this to make my organization 10x more capable?”

Follow Along

Follow along with Abhishek Ranjan on LinkedIn. And check out his Hacktivate newsletter.

More expert interviews to come on The CTO Club!