Artificial intelligence has significantly accelerated the code writing process; however, engineering leaders are facing a more complex question: what happens after coding is complete. At a roundtable dedicated to operations in the AI era, leaders from sectors such as logistics, food technology, healthcare, telecommunications, fintech, e-commerce, and higher education exchanged experiences on how to scale using AI while maintaining reliability, security, and control.
The general conclusion of the participants was that speed is no longer the main issue; now, managing this process is the key aspect. Ipsita Basu moderated the roundtable, and among the participants were specialists such as Mandjunat Nakshatri (Engineering Head at Mojro), Shobhit Suman (CPO HungerBox), Pawan Kumar A T (CTO Digii/DigiiCampus), Pranjal Nadani (Co-founder and CTO of Cautio), Kenil Paul (VP of Technology and Solutions at 6D Technologies), Rimjim Agrawal (Co-founder and CTO of BrainSightAI), Dhruv Rastogi (Chief AI Officer at MediAssist), Chandrakesh Pandey (Senior VP of Technology at Niyo Solutions Inc.), Achal Sharma (CTO of TechnoSport), Sunil Kumar (Engineering Director at Meesho), and Anshul Sharma (Engineering Director at Scaler).
The event was organized by groundcover and Data Signals with support from YourStory. On the organizing side were Paul Trebe (Head of Sales and Partnerships at groundcover) and Satish Dange (Founder of Data Signals).
Participants agreed that AI has reduced build time, but the pressure has shifted to subsequent stages. When agents generate large volumes of code, questions arise about who will review, test, and control dozens of daily deployments. Many leaders noted that their teams are now spending more time on concept development, context, and management than on the actual component writing. The effectiveness of agents directly depends on the quality of the context they receive, and few organizations possess repository knowledge, documentation, and templates in a format that an agent could reliably use.
During the discussion, a consensus was reached regarding a progressive approach: reversible, read-only tasks, such as data retrieval or report generation, can be delegated to agents with minimal difficulty. However, irreversible actions, such as data deletion or database updates, must remain under human control. Assessing the scope of impact is also crucial; if a faulty call could affect end-users or production systems, a human must handle it.
One participant described a 'four-eyes' model where AI performs reading and analysis, deterministic rules provide clear 'yes' or 'no' answers, and the final approval is given by a human. Another speaker proposed a risk assessment system based on severity and frequency of occurrence, allowing human oversight to focus on medium and high-criticality elements. Some drew a line through specialization, allowing engineers to freely use agents in their domain while keeping production responsibility with humans capable of troubleshooting at any time.
A more optimistic picture also emerged: instead of waking up an engineer, an agent can investigate an incident and provide a report by morning, leaving the decision to the human. Participants emphasized that trust will build gradually, similar to how it happened with online payments, and this boundary will constantly shift.
The issue of accountability received firm agreement: this duty cannot be delegated to a model. Leaders remain responsible for the actions of agents. One participant noted that AI acts as an intelligence multiplier, meaning errors amplify as quickly as good decisions.
The discussion on skill obsolescence sparked more lively debates. Some saw it as simply a shift in required competencies, analogous to how arithmetic changed with the advent of calculators. Others, particularly in healthcare, feared the loss of expertise needed to evaluate the results of AI work. One practical solution was the conscious definition of areas where AI handles drafts and where humans perform the work.
For leaders in the telecom and medical fields, data control is determined at the design stage. Models cannot simply operate in a public cloud if regulatory norms, requirements for tenancy separation, and residency rules apply, as one mistake can lead to serious fines. Others emphasized governance from the outset, covering data intake, what is used for training versus output, and methods for data masking or de-identification. Concerns about intellectual property and bias also led to a call to evaluate AI tools as thoroughly as new employees.
Observability permeated all discussed topics. Teams spoke about the need to track inputs, decisions, and task handoffs by agents to understand the cause of their actions and correct them. One e-commerce team learned the cost of insufficient investment: a rating change left all dashboards green until the business impact manifested days later, and root cause analysis took over a week. Since then, they created a change log, lineage system, system graph, and a debugging agent that suggests ranked hypotheses.
From an observability perspective, it can no longer exist separately from development. Paul Trebe stated plainly: 'You can no longer separate observability from development.' He added that agents require context-rich data to act correctly, and the agents themselves must be monitored, as AI traces can reach 500,000 lines, which realistically only other agents can parse.
No one presented a ready-made guide. Questions remain open regarding methods for measuring agent reliability and ROI, data and intellectual property protection, and maintaining sufficient sharpness in engineers to challenge AI outputs. Nevertheless, the conversation pointed to a general direction: enabling developers to move fast, but first building protective barriers. Human control must be maintained over irreversible and high-risk decisions, and automation should expand as trust is earned. Many participants argued that inaction is unacceptable, as competitors will not wait. The true test of the AI era is not how fast teams can build, but how confidently they can operate what they have built.



