Editor's Note: This blog is adapted from a session by Naveen Kumar Bhansali, Co-Founder of Blitz AI, and Adjunct Faculty at IIM Bangalore, at thegeekconf Mini 2026. Drawing on his experience working with enterprises and AI products, Naveen explores how AI is changing software development, productivity, and enterprise adoption. He looks at the growing importance of context, the challenges of bringing AI into legacy systems and production environments, the shift from human-in-the-loop to agent-led workflows, and how companies may need to build products, software, content, and interfaces for AI agents.
Naveen Kumar Bhansali began the session by reflecting on how much the technology industry has changed during his more than 20 years in the field. He previously worked at EMC Square, which later became part of Dell Technologies, where he worked as an advisory consultant across big data, data science, and AI in Europe, Africa, South America, and Southeast Asia. He left in 2019 to start a consulting firm. In 2021, he raised funding for Blitz AI, a no-code AI platform, and in 2024, the company reached positive cash flow.
Today, Naveen advises companies including Siemens, Wells Fargo, and Target. He also teaches AI-related subjects at IIM Bangalore. His work with these companies has given him a close view of how AI is changing the way organizations build software, measure productivity, and think about their future.
Watch the Full Talk, Straight from TheGeekConf Mini 2026:
Shift in Software Engineering in Past Three Years
IT services companies and software engineers have been among the groups most affected by the changes in AI.
He traced the shift through the last few years. Between 2021 and 2023, developers were writing code and documentation using local text editors. From 2023 to 2025, developers started using tools such as chatbots and coding assistants to support development. Within the following year, coding agents entered the workflow.
The terminology has continued to change from prompt engineering to context engineering, harness engineering, loop engineering, and graph engineering. His point was not to focus on the names but on what they represent: the developer is moving further away from writing every instruction and closer to directing systems that can perform parts of the work. He has seen the difference in his own client work. Development can happen faster, but speed alone does not tell you whether productivity has improved.
“If I am developing something faster, that is one thing. Real productivity is another.”
AI Is Moving From Licenses to Outcomes
Naveen then turned to a change that he considers important for anyone working with AI products: how AI usage is being priced.
He pointed to June 1 as a turning point in how AI tools were being priced, as the industry moved toward pay-per-use models based on tokens. Previously, users could pay a fixed monthly fee and use a product within the limits of that subscription. With token-based billing, the amount of usage directly affects the cost.
He used a simple example. If a client receives a monthly token quota and uses it within the first few days, the team cannot continue treating the tool as an unlimited resource for the rest of the month. The cost is now tied to consumption.
This changes the economic incentive for engineering teams. When companies paid for a Copilot or Cursor license, they were paying for access. With token-based billing, the question changes to what the company gets from that usage.
That also changes how teams should think about optimization. Clients often ask him how they can write better prompts and reduce token usage. His response is to use the model itself to improve the prompts.
“If writing an optimized prompt uses a model itself, ask the model what is good,” he said.
But he does not see token reduction as the main source of ROI. The bigger question is whether teams understand what an agent needs and can orchestrate the entire workflow around that context.
For his own projects, he looks at the outcome, impact, and the value created. Cost still matters, but customers now want to know what they received for the money they spent.
Enterprise Adoption Has a Context Problem
The speaker pointed to claims about AI-generated code and AI-assisted development. He mentioned claims that a large share of new production code is being authored by Claude and that almost all developers at Spotify use AI coding assistants.
But he cautioned against treating those numbers as representative of every enterprise.
From his experience working with enterprise customers and speaking with leadership teams, he sees a gap between AI adoption and autonomous agents. Coding has reached a higher level of maturity because coding agents are available and can work with software development tasks. Governance remains a major constraint.
He described seeing employees take photographs of company documents and upload them to publicly available chatbots. He said this creates a data leakage risk because the document may contain information the company cannot afford to expose.
For enterprises, he sees governance as one of the biggest constraints on moving toward autonomous agents.
Legacy Systems Make the Gap Wider
Naveen then shifted to the difference between greenfield and brownfield projects.
Greenfield projects give teams more freedom because they are building something new. Enterprise customers, however, often have legacy code and brownfield projects. That is where he sees a larger gap, especially in software development. Code written over many years may not have complete documentation or clear lineage. Teams may not know why certain parts of the system work the way they do or how different pieces depend on each other.
His point was that the legacy environment creates a context problem. An agent cannot reliably work with a system when the organization itself does not have a complete understanding of that system.
AI Needs Systems, Data, and Context
One of the biggest gaps he sees in enterprises is readiness across data and systems.
He explained the relationship in simple terms: systems produce data, data provides context, and AI needs context to produce useful results.
“AI without context is nothing,” Naveen said.
He gave a simple example. If someone asks an AI system for a tablet for diabetes and then takes the tablet home, the instruction is incomplete. Which home? What is the person's blood pressure? What other information matters? Without that context, the answer cannot account for the situation. Organizations today are either building models or building the context around those models. Enterprises often struggle because their systems and data are not ready to provide that context to AI in a connected way.
He referred to Google's journey as an example. Google began its Google Brain initiative in 2009, and Sundar Pichai described Google as an AI-first company in 2019. His point was that even a company built around data took years to reach that stage. Companies need to recognize the work required to prepare their systems and data.
Production Changes the Rules
The speaker brought up a problem familiar to software teams, which involved the difference between a project that works in development and one that survives production. He referred to the claim that 95% of projects do not make it to production. He described development environments as comfortable because everything is under control. Production is different.
Traditional software development also had an important expectation: once software was released, future versions were expected to maintain backward compatibility.
AI models change that expectation.
An AI application depends on models that are probabilistic. Model providers do not guarantee that a model will behave the same way after an update. When a model changes, prompts and application behavior may also need to change. That makes production operations more difficult as the application is no longer built around a fixed piece of software.
Four Stages of AI Adoption
Naveen said he uses four stages when advising companies on AI strategy: adoption, adaptation, acceleration, and amplification.
He began with the adoption stage.
If a company gives employees tools such as Cursor or GitHub Copilot and asks them to use AI in their daily work, it is still in the early stages of AI adoption. Companies often measure success through time saved per developer.
He considers this to be the wrong metric.
He gave another example from his client work. Before June 1, some employees were being measured on how much they consumed from their AI tools. That creates an obvious problem: people can consume tokens without creating useful output.
His alternative metric is productivity per token.
But even productivity needs to be defined from end to end. A developer can deliver a feature in one hour, but if the customer takes a week to provide feedback, the development speed does not remove the bottleneck.
Naveen compared this to travelling from his starting point to Bangalore in one hour and then spending another two hours in Bangalore traffic. The first part of the journey became faster, but the total journey did not.
The same applies to AI-enabled development. Shipping faster does not matter if the rest of the workflow cannot keep up.
The First Goal Is Capturing Context
Companies cannot skip the adoption stage. They need to use AI tools, learn how they work, and use humans to build the context the systems need.
At this stage, he recommends ensuring human oversight in the middle and AI around them. The goal is to use human decisions and feedback to give AI a better understanding of the customer's context. Once that context is captured, the organization can move to the next stage.
From Human-in-the-Loop to AI-in-the-Middle
In the next stage, the roles change. AI moves into the middle, while humans move around it.
The reason is simple: humans become bottlenecks when agents need to execute work at scale.
Companies should stop asking only, “How does AI fit into our existing process?” The better question should be, “What process would we design if agents were the default worker?”
The success metric also changes.
In the first stage, humans make the decisions, and AI helps them make better decisions. In the next stage, some decisions can move to agents because the agents have learned enough context to make those decisions.
This metric suggests how many decisions are made by humans versus agents. If humans make all 100 decisions, AI is still supporting the human decision-maker. If agents can make 70 decisions and humans make 30, the organization has moved further toward agent-led work.
Google Maps Shows What Context Looks Like
Naveen used Google Maps to explain how this transition works.
When Google Maps was first introduced, people still asked other people for directions. They would check the route on the map and then lower the car window to ask someone on the street whether the route was correct.
Over time, Google Maps gathered enough information about roads and routes that people stopped asking for directions.
Today, people can follow Google Maps without having to check the route with someone standing on the road.
Naveen said this is the model companies should consider with agents. The early stage uses humans to provide context. Once the system has enough context and users trust its decisions, more decisions can move to the agent.
The Next Stage Is Speed at Scale
Once the organization reaches the point where agents can make decisions, it moves to the acceleration stage.
Here, the goal is to increase output without increasing the size of the team.
Throughput increases while headcount remains flat.
He clarified that this does not mean stopping jobs. It means that teams can handle more work and expand what the business does. The denominator changes as well. Instead of measuring how much work happens across 100 decisions, the organization may be handling 10,000 or 100,000 decisions.
Most of the companies he works with are not at this stage yet. They are still working through the context problem.
Companies Are Starting to Build for Agents
He then shifted from internal enterprise workflows to the wider internet.
He said that companies receiving funding today are not only building products with AI. They are building products for AI and agents. He pointed to changes in web traffic as an example. If humans are responsible for a shrinking share of online traffic, companies have to consider how customers discover them when those customers are no longer searching websites themselves.
That leads to a new role for agents.
“Today, the customer is the king, but the agent is the kingmaker,” Naveen said.
He compared this to recruitment. A resume may be read by a human HR professional, but if an agent cannot parse the document, the human may never see it. The same logic applies to companies. If customers ask AI systems questions instead of searching directly, companies need to make sure their products and information can be found and understood by those systems.
From SEO to Being Found in AI Answers
He described companies working on what he called generative engine optimization or answer engine optimization. The question is no longer only how a company ranks when someone searches for a keyword. It is how that company appears in the answer generated when a customer asks an AI system a question.
He described one approach in which a company identifies the questions it wants to be associated with. Agents can then generate additional questions, gather questions from platforms where people discuss topics, and build a question bank. The company can then create content designed to provide information that AI systems can use when generating answers.
This changes the purpose of content creation. Blogs are no longer written solely for human readers; they also need to be understandable and useful for internet AI agents.
UX Is Moving From Humans to Agents
If people increasingly interact with chatbots instead of typing into traditional interfaces, he asked why every interaction still needs to be designed around a human clicking through a UI. He compared the change to the transition from the software development life cycle to what he called the agent development life cycle.
In traditional software, the software engineer controlled the interface. Users had to learn how the application worked. They had to fill out mandatory fields before submitting a form and follow the application's workflow.
With conversational AI, that relationship changes.
Instead of learning the application's interface, the user can describe what they want in natural language. The next step could move beyond typing and voice. He referred to research suggesting that users may eventually interact with systems through thought rather than typing or speaking.
The larger point is that software itself is becoming designed for agents.
From App Stores to Agent Stores
Software distribution is also changing.
Instead of building only for app stores and human users, companies need to consider systems in which agents discover and use software on behalf of people.
He connected this shift to multi-agent systems and agentic commerce.
In commerce, the customer may interact with an AI system while that system communicates with the merchant and payment processor. The customer does not need to visit every merchant's website or application directly.
That means companies need to make themselves discoverable and usable by agents.
Protocols Will Connect Agents, Merchants, and Services
He discussed the emergence of protocols intended to support communication between AI systems and services. He used the example of a customer asking an AI system for the best running shoes for a marathon in Bangalore and taking the city's climate and road conditions into account.
The AI system needs to discover products and interact with the companies that provide them. If a company does not expose the interfaces or protocols the agent needs, the agent may not be able to discover or interact with that company.
This is why companies need to think about designing for agents rather than only for human users. The same shift applies to communication between agents. Protocols are being developed to allow agents and services to exchange information and execute tasks across systems. For companies, the goal is to make it possible for an agent to access the customer's context across applications and complete an end-to-end interaction.
Documents Are Being Rebuilt for AI
The shift also extends to documents. PDFs were designed to preserve document structure and formatting for consistent viewing and printing, while documents have traditionally been created around human reading and editing. But if documents are primarily being consumed by AI systems, their structure needs to support machine reading. He referred to efforts to create AI-native document formats and knowledge standards that can provide structured information to models.
The purpose is not to make documents better for printing. It is to make enterprise knowledge easier for agents to understand and use. This is part of a larger change: the internet, software, documents, commerce, and user interfaces are being redesigned around agents.
Amplification: Doing Work That Was Not Possible Before
The final stage was amplification.
He referred to Elon Musk's statement that the goal is not only to make existing work faster but to do work that a team could not have done before, even with unlimited time.
He used the example of building a data center in space. The idea is not simply to complete an existing task faster, but to to attempt something that would be difficult for a human team to execute using traditional methods.
That is where the speaker sees the larger potential of agents: as a way to expand what a human team can attempt and achieve.
Agents Are Becoming Part of the Workforce
He closed by saying that AI is no longer optional for organizations that already depend on computers and mobile devices for their work. Companies are building AI to improve how humans work, but the practical impact is already changing roles across product, architecture, development, and testing.
For product and project managers, the delivery unit also includes a fleet of agents. And for architects, the responsibility extends beyond system architecture to the topology of the agents working within the system.
For developers, the role shifts from writing every line of code to deciding which agent should be trusted with which task. For testers, the question becomes whether the agent made the right decision.
His final recommendation was simple: teams should start treating agents as part of the workforce. Just as managers train and develop junior team members, they need to develop the agents working with them.
