Kumar Chivukula and the Work After the Code

Kumar Chivukula had already learned how to keep complicated software operations moving. Then he became a founder, and discovered a different sort of technical difficulty: asking someone to buy what he had built. Investors gave him an assignment with very little room for interpretation. He needed to become the company’s best salesperson.

He describes that education candidly. Rejection was hard at first. Eventually, he learned to consider the customer’s priorities instead of taking the answer personally. An engineering leader can understand a problem perfectly and still arrive at a buyer’s desk on the wrong afternoon. The budget has its own calendar.

That passage from practitioner to seller helps explain Chivukula’s work at Opsera, where he is co-founder and CEO. He has spent years thinking about the distance between a useful piece of technology and a useful outcome. Inside a software company, that distance is full of tests, permissions, dependencies and handoffs. Inside a sales conversation, it is full of questions about cost, risk and whether anybody needs this today.

A familiar problem, in another building

Before Opsera, Chivukula worked at Adobe and then Symantec. His experience spans cloud infrastructure, IT strategy, DevOps and large SaaS platforms. These are jobs in which the finished product can conceal a considerable amount of organizational plumbing. A customer clicks a button; somewhere behind it, several teams have had to agree on what happens next.

Adobe’s transition from packaged software to subscription services put him close to the changing mechanics of delivery. At Symantec, where he ran hybrid cloud services, the problem returned in a different business. The founders’ account of that period describes an environment shaped by acquisitions, varied infrastructure and engineering teams with different tools. Acquiring a company apparently includes acquiring its preferences.

Chandra Ranganathan, his fellow Opsera co-founder, had also worked at Symantec. Their shared experience gave them a practical starting point: developers needed freedom to choose appropriate tools, while an enterprise still needed automation, visibility and control. Standardizing everything could be costly. Leaving everything disconnected carried a bill of its own.

Chivukula’s eventual company would address the connections. It was an idea suited to someone who had worked inside the machinery, where a release depends on many small things being ready together. The interesting engineering problem was the journey a change took through the organization.

Let the tools stay

Opsera began in January 2020. By October, it had emerged from stealth with a $4.3 million seed round backed by Clear Ventures, Trinity Ventures and Firebolt Ventures. Its opening proposition combined tool choice with no-code orchestration: teams could assemble delivery pipelines without writing all the connective software themselves.

In a November 2020 conversation, Chivukula and Ranganathan explained pipelines built through a drag-and-drop interface, with security and quality checks added at different stages. That detail matters. Security was part of the route from the beginning, rather than a separate destination everyone hoped to visit later.

For a reader outside software, imagine an editor moving a story through checking, production and publication. The writer’s document is only one part of the process. Someone has to know which version is approved, which checks have passed, and whether the people pressing publish are looking at the same thing. Opsera’s subject is the software equivalent of that coordination.

Chivukula was publicly introduced as CTO in the company’s early years. A January 2021 DevOps Huddle put him alongside Vishnu Vasudevan to discuss Kubernetes pipelines, migration and security. The session was deliberately small, limited to five to seven attendees. It is a revealing format for a business built around the details of other people’s systems: leave enough room for the awkward question.

The midnight-oil proposition

By February 2022, Chivukula was discussing Salesforce release management with Vernon Keenan. His argument was concrete: integrate the tools into a pipeline, connect the work to business value, and reduce the effort of getting a release out. The conversation included his claim that deployments could move from hours to minutes.

There is something agreeably unromantic about this ambition. Software has plenty of heroic language available. A release that does not require people to work late offers a quieter kind of satisfaction. The podcast discussion explicitly touched on avoiding “burning the midnight oil,” and on the contribution of Opsera’s employees.

That combination keeps the story close to a working day. A pipeline is an abstraction until it becomes somebody’s evening. A tool integration is a technical detail until its failure leaves a team waiting. Chivukula’s pitch connects those details to the people who have to live with them, and to the executive who must pay for the work.

A founder needs other people’s doors

The change from CTO to CEO widened his job. In October 2023, Opsera raised $12 million with Chivukula as CEO. The builder now had responsibility for explaining the business as well as the product.

His relationship with Clear Ventures illustrates the less visible work surrounding a startup. In a public testimonial, Chivukula credits its team with recruiting, hiring and customer introductions, alongside capital. Those are ordinary nouns with considerable consequences. A promising product still needs colleagues who can build it, customers who will test it, and introductions that get a conversation started.

In April 2025, Opsera announced a $20 million Series B led by Prosperity7 Ventures, with Hitachi Ventures participating. Chivukula’s accompanying post credited employees, customers, investors and partners, including GitHub, Microsoft, Databricks and AWS. The company also reported 200% revenue growth since its Series A+ round, a figure reported by the company.

The financing supported further AI capabilities and analytics. It also marked a change in the surroundings of his original idea. Software teams were acquiring assistants that could produce code quickly. The work of connecting tools, checking changes and understanding results was about to receive much more traffic.

The queue beyond the coding assistant

By July 2024, Chivukula was already discussing GitHub Copilot and developer experience with Vasudevan and Anna Daugherty. Their webinar considered measurements across the development process, including delivery speed, cycle time and developer feedback. The question extended beyond whether someone enjoyed using a new tool.

His 2026 writing presses that distinction further. In May, he argued that distributing AI coding licenses was insufficient to produce consistent value. Management, review processes and governance helped determine whether the additional output became useful software. Buying seats is easy to count. Establishing what changed after people sat down takes more effort.

In a June essay, he reached back to factory automation in the 1980s, contrasting the addition of robots with the redesign of production systems. He used that history as a warning about software’s current enthusiasm: adding automation to a flawed workflow can leave the underlying flaw comfortably employed.

His July article on AI-SDLC described a gap between machine-speed code generation and the ability to check it. Architecture, security analysis and compliance verification all remained part of the delivery problem. In that account, agents should help engineers find and fix problems while preserving the context of the wider system. A function that works in isolation still has to belong in the application.

“AI has fundamentally changed how software gets built, but speed alone isn’t enough.”

Kumar Chivukula, July 2026

Opsera’s January 2026 benchmark announcement made the same point through research the company said covered more than 250,000 developers. Among its reported findings: approximately 21% of AI tool licenses were underused. Chivukula’s interest in measuring outcomes has a practical financial edge. An unused license is a small monument to an intention.

Keep the context, change the machinery

The products announced under his leadership follow that concern into the workflow. In February 2026, Opsera introduced reasoning and autonomous remediation capabilities, describing agents that could investigate failures and apply fixes within policy boundaries. The company said its platform integrated with more than 150 DevOps tools.

In July, Forge reached the Cursor Marketplace. The stated aim was to bring enterprise requirements, architectural context and governance into a coding environment developers already used. In September, Opsera announced a headless Salesforce DevOps platform, with parallel pre-validation, metadata mapping and audit trails. The features address the same irritating possibility: a fast change arriving somewhere unprepared to receive it.

The succession of launches shows where Chivukula is directing the business. The original emphasis on connecting existing tools survives inside a newer language of agents, context and software factories. The company’s current account of Forge describes returning to customer conversations and rebuilding its approach as AI changed development.

That gives his career a recognizable continuity. He has moved from running systems to building a company that coordinates them, and from explaining pipelines to arguing about the economics of AI. Through those changes, he keeps returning to the work surrounding the visible work. The code may be finished. Chivukula is still interested in what has to happen before anyone can use it.