Noida, Sep 8 (APAC Media): AI has dramatically accelerated code creation, but enterprises are discovering that producing more code does not automatically mean delivering better software faster. Testing, security, governance, deployment and operations still have to keep pace. In an exclusive conversation, Sanjay Nagaraj, SVP, Global Engineering, Harness informs Rajneesh De, Group Editor, APAC Media & CXO Media that is precisely the problem Harness is known to be solving.
How would you trace the genesis and evolution of Harness from 2017 to date, covering both growth and funding?
Harness started with a fairly simple observation: writing code was getting easier, but getting that code safely into production was still far too difficult. Continuous Delivery was the first problem we tackled in 2017, but as we worked with larger enterprises, it became clear how connected the entire software delivery lifecycle is. That shaped our evolution from a single product into a much broader software delivery platform.
The growth followed. Harness reached a $3.7 billion valuation in 2022, followed by a $240 million Series E led by Goldman Sachs Alternatives in December 2025, valuing the company at $5.5 billion. Today, we work with 1,000+ enterprise customers, crossed $250 million in ARR in 2025 while growing over 50% year-on-year, and support 128 million deployments and 81 million builds annually, with 1,200+ employees across 14 offices.
What are the popular use cases of Harness’ Autonomous SDLC platform? What are the 16 product lines available in the Harness portfolio?
The easiest way to understand Harness is to look at what happens after a developer writes code. That code still has to be built, tested, secured, deployed, operated and optimised, and in a large enterprise each of those steps can involve different tools, teams and approval processes. As AI increases the amount of code being produced, that complexity becomes much more visible.
Harness brings those workflows together through four agents: Software Delivery, Security Testing, Runtime Protection and Cost Management. Underneath them is a broad set of capabilities spanning CI/CD, infrastructure and database changes, artifact management, application and supply-chain security, API and AI protection, cloud and AI cost management, engineering efficiency and more.
The important part is not simply the number of capabilities. It is that the agents can work across them with shared context, so software delivery becomes a connected system rather than a series of isolated tasks. AI is making code abundant. The scarce resource is everything required to turn that code into software you can actually trust.
How is the platform integrating Agentic DevOps, FinOps and Security Intelligence features?
The interesting thing about AI in software delivery is that the quality of an agent’s decision depends heavily on how much context it has. A deployment decision is not only a DevOps decision. It can affect reliability, security and cost at the same time. If each agent sees only one piece of that picture, you end up recreating the same silos we have spent years trying to remove from software delivery.
That is why we built Harness around a shared Software Delivery Knowledge Graph. It connects information about services, pipelines, deployments, incidents, security findings, policies and costs, so agents can reason against the environment they are actually operating in. An AI agent is only as good as the context it can see, and in an enterprise, that context spans far more than the code.
The other principle we care deeply about is control. As agents move from recommending actions to taking them, governance has to travel with the action. Permissions, policies, approvals and auditability need to be part of how the agent operates. That is ultimately how autonomous software delivery becomes something enterprises can trust in production. The future is not autonomous software without controls; it is autonomous software with controls built in.
How would you outline the benefits of a Harness Agent-Ready code repository?
Code repositories were designed around human developers: a person writes code, opens a pull request, someone reviews it and eventually it gets merged. AI coding agents change that operating model because they can generate changes continuously and at a scale that human review processes were never designed to handle.
So an agent-ready repository has to solve more than code storage. It needs to understand non-human identities, control what an agent is allowed to change, enforce policies before code is merged and help developers focus their attention where human judgement is actually needed. As agents become contributors, the repository becomes a control plane, not just a place to store code.
That is how we think about Harness Code Repository. Governance such as RBAC, policy enforcement and auditability is built into the workflow, while AI-assisted code review helps teams evaluate changes faster. As coding becomes increasingly agentic, I think repositories will evolve from passive systems of record into active control points for how humans and agents build software together.
How is Harness structured as a collection of “startups within a startup” to launch multiple “best-of-breed” products?
One of the hardest things for a technology company to do as it grows is preserve the speed and ownership that made the first product successful. Large organisations naturally create more coordination, but innovation usually happens when a small group of people understands a problem deeply and has the freedom to solve it.
That is the thinking behind our “startup within a startup” model. We do not think scale should mean trading speed for bureaucracy. So, teams at Harness have meaningful ownership of a product and are expected to think like company builders; understand the customer, build something differentiated, measure whether it is creating value and keep improving it. The wider Harness organisation gives them the platform, engineering capabilities, customer insight and go-to-market reach that a standalone startup would take years to build. Our goal is to give small teams the autonomy of a startup and the leverage of a large company.
For me, the important part is the combination of autonomy and accountability. Autonomy without accountability creates experiments. Accountability without autonomy creates bureaucracy. You need both if you want to keep building genuinely differentiated products as a company scales.
What best practices do you recommend for transitioning from mid-market to enterprise clients?
Moving into the enterprise is not simply about selling the same product to a bigger company. The environment changes. There are more teams, dependencies, regulation and a much larger consequence when something goes wrong.
That means you have to design for trust much earlier. Security, governance, auditability, reliability and integration cannot be things you add once a large customer asks for them. They have to be part of the architecture. At the same time, enterprise software has to make people’s jobs easier. If governance creates so much friction that developers work around it, you haven’t really solved the problem.
The other lesson is to focus on outcomes rather than adoption alone. Enterprises do not ultimately care how many features they switch on; they care whether releases are faster, incidents decrease, developers spend less time on repetitive work or costs become easier to control. If you can prove value in one meaningful workflow and build trust there, expansion becomes a consequence of value rather than a sales strategy. The best enterprise strategy is not to sell more features. It is to prove more value.
What are the key pillars of Harness’ GTM strategy and what are the initiatives undertaken as part of this strategy?
AI has solved part of the software creation problem. It has not solved the software delivery problem. The market we are building for is changing very quickly. AI has dramatically accelerated code creation, but enterprises are discovering that producing more code does not automatically mean delivering better software faster. Testing, security, governance, deployment and operations still have to keep pace. That is the problem we want Harness to be known for solving.
Our go-to-market strategy follows that idea. The first pillar is a platform broad enough to address the software delivery lifecycle rather than another isolated point problem. The second is meeting developers where they already work, including AI coding environments and the broader cloud ecosystem. The third is partnerships, because large enterprises aren’t going to rebuild their technology estates around one vendor.
You can see that in our work with Google Cloud, AWS, Infosys, Wipro, Kong and developer ecosystems such as Cursor. The goal is not simply distribution, but to make Harness part of an open ecosystem where enterprises can adopt AI while retaining the context, governance and control required to run it at scale.
How would you uniquely differentiate Harness from other agentic AI-ready software development platforms?
A lot of the AI conversation in software development still begins with generating code. We think the bigger opportunity is what happens once that code exists. It still has to be tested, secured, deployed, governed, operated and optimised, and those decisions are deeply connected.
That is where Harness is structurally different. Our agents operate across the software delivery lifecycle with a shared Software Delivery Knowledge Graph underneath them. That gives them context about the environment they are acting in rather than asking each agent to reason from an isolated tool or task. We do not think the future is a collection of smarter agents. We think it is agents that understand the entire system they are operating in.
The second difference is governance. Once AI moves from suggesting an action to actually taking one, permissions, policies, approvals, auditability and rollback become fundamental. Enterprises need autonomy without losing control. Ultimately, I think the winning platforms will be those that combine intelligence, context and action with the safeguards required to trust autonomous systems in production.
How is Harness expanding its R&D in India?
India is not an offshore extension of Harness. We are building teams here with real ownership of products, roadmaps and some of the hardest engineering problems we are solving as a company.
Bengaluru is already a significant development centre outside the US, but the more meaningful story is what is being built here. Teams in India are helping shape the roadmaps of some of our most important products, taking them from customer problems and architecture decisions through to development and delivery. That kind of end-to-end ownership is very deliberate.
We plan to grow significantly in India, and we want to bring in people who are excited by tricky technology problems and want the ownership to solve them. For us, the real measure of our India investment is not simply how large the team becomes, but the products built here, the problems these teams solve and the influence they have on Harness’s technology direction globally.
Also Read:
