Copilot Is a Copilot, Not a Pilot: Inbal Shani on the Future of AI in Software Development

Inbal Shani, who joined GitHub as chief product officer about a year before the conversation, says her core conviction is that developer happiness and productivity depend heavily on the environment and tooling. She notes that AI has become table stakes, with roughly 92% of developers already using AI tools. The overhype, in her view, is that generative AI will replace humans; she argues AI cannot replace innovation or the creative spark, and successful AI still needs humans using tools to generate data. She describes generative AI as a tool, not a solution for everything.

Shani sees AI-driven testing as the most underhyped area in software development. As AI helps teams generate more code and become more productive, testing becomes more critical, not less. She lists unit, functional, load, performance, infrastructure, security and penetration testing as areas where AI could generate larger validation suites. Many testing activities are not even recognized as testing, she says, yet they matter more as every company becomes a software company in some form.

Shani repeatedly returns to the line that Copilot is a copilot, not a pilot: the human remains in the loop. The developer's job therefore shifts toward systems thinking, architecture and the connected experience rather than only writing code. She observes that this mindset is already common among senior developers but rarer among juniors. With an AI assistant handling simple code, junior developers can spend more time from the start understanding the system, environment and product they are building.

She also expects hardware development and compute optimization to become more integrated with the software lifecycle. AI has a large resource footprint, and meeting demand will require better CPUs, GPUs and optimized code. Integration with AI will become normal for every developer rather than a specialized skill, and developers will start shaping their thinking around these components early.

The adoption numbers are striking: Shani says Copilot has more than 37,000 organizations and more than 1.5 million developers using it. Survey data she cites shows developers writing code 55% faster, 85% feeling more confident in code quality, 15% faster code reviews, and 88% feeling less frustrated and more focused. She also points to Accenture retaining 88% of suggested code, while the host mentions Shopify having over a million lines of code written by Copilot.

Shani is explicit that companies cannot respond by cutting engineers. Giving developers time back lets them write more code, take a breath to avoid burnout, and spend more time on collaboration and creative thinking. She cites developer-experience research showing developers spend less than 25%—some say less than 20%—of their time writing code, while collaborating with around 21 people each week and handling meetings, builds and legacy code. The goal is to retain and support developers, not to shrink the team.

One common mistake is expecting adoption to happen magically: a company buys a tool and tells people to use it. Shani says organizations need to invest in change management and take people through the transition. The results vary because tools do not fly the same way in every company.

Another mistake is starting from the hype—"What should we do with AI?"—rather than from a customer problem. Shani's product team focuses on the problem first, then asks how AI can help solve it better. That working-backwards approach avoids plastering AI onto everything simply because it is available.

She describes GitHub's own path as an example. GitHub started from the goal of making developers more productive, identified that developers had too many tasks and too little coding time, and then asked which coding work could be automated. That led to incorporating OpenAI and ChatGPT into a tool designed around developer productivity, and she says customers often have a light-bulb moment when they hear this framing.

GitHub runs on GitHub, and Shani says the company dogfoods every feature before customers see it. The practice extends beyond engineering: finance uses discussions and pull requests to communicate AR numbers, and legal and HR also use the platform. The product team is an early adopter for capabilities like chat, recommendations and search, testing whether summaries and answers match what they need.

Nothing ships before it has spent enough months cooking inside GitHub, she says. If GitHub cannot use a tool, customers certainly cannot. This internal testing is part of how the company decides whether a capability is working.

The design philosophy behind Copilot follows the same working-backwards logic. Shani says the team put itself in the developer's shoes and asked how the experience should feel; if a tool requires extra steps, asking, or waiting, developers will not adopt it. In 2020, GitHub engineers worked with the design team and OpenAI GPT on the product, with a grounding principle that developers must want to use it. More friction creates more churn and complexity, so Copilot had to be seamless and intuitive.

Shani says there is no single metric to rule them all. Teams need a combination of measures—code quality, security, productivity, collaboration and time gain—that together point toward developer happiness. The hardest part is defining productivity precisely enough for many different users and workflows.

Different AI features need different success metrics. In GitHub Advanced Security, the right questions are how many secrets were prevented from leaking and how many code issues were found and fixed before shipping. Productivity is not the right metric for every component of the lifecycle.

Time is the easiest metric but also a misleading one, because developers can write bad code very fast. Shani wants teams to translate time into efficiency, productivity and eventually happiness. She suggests "time to value" as a business-facing measure: from assigning a developer a task, how long until the organization realizes the full value in revenue, adoption or time to market?

Shani sees sketch-to-app demos as a better collaboration tool than a production tool. Much of the challenge in building software is articulating ideas clearly, so AI can help tell the story of what a developer is being asked to build and reduce back-and-forth about details like button placement or color. She describes Copilot as potentially the best collaboration tool in the market and as a natural-language translator that creates a universal conversation language, much as math once did.

Developers use Copilot in very different ways, and Shani says there is no right or wrong way. She compares AI to earlier abstraction layers: she once worried that Java would take away her job because it bundled functions and libraries, and then Python added another layer. She still writes C when she needs efficient metrics on a very small CPU, but delegates other work to higher-abstraction tools; developers should keep the parts they enjoy and use AI for the parts they do not.

Shani's background is in niche AI, where experts spent years tuning models, building simulations, ingesting data and optimizing outputs. She watched AI become more democratized through conversational systems, but the generative AI boom still surprised her because she had been trained to believe AI required deep expertise. The shift made AI something everyone feels they must use, even if they do not know what AI is.

Her prediction is a hybrid future rather than LLMs as the end state. General-purpose generative models are limited by their training data and by trying to be everything for everyone, while aerospace, automotive and self-driving work will still require delicate, safety-regulated, customized models. She expects multiple LLMs to be combined, each with its own benefit, alongside niche models for specific use cases.

Shani credits GitHub's ability to innovate to bandwidth and a culture of failing forward. Teams need room to experiment, and the organization must accept that not every experiment will succeed. Copilot, GitHub Advanced Security and GitHub itself came from this kind of innovative thinking about what future developers will need.

The inputs to innovation are customer conversations, community feedback and open-source foundations running on GitHub. Teams pitch ideas, share research papers, and then GitHub decides how to fund them, allocate bandwidth or run a proof of concept. Innovation also comes from field, product, design and engineering teams, and Shani argues that trying to structure creativity into a fixed 15 minutes a day loses the organic spark.

GitHub Next is the company's research team of applied and research scientists looking three to five years out. They write papers, run experiments and build proofs of concept, with the job of inventing the future of software development. Copilot emerged from that team.

Shani says GitHub Next has avoided the fate of some corporate innovation teams because it has the right people and mindset, freedom, and a path to production from day zero. Failed innovation teams can become universities that write papers without shipping, or they get used too tactically and become another product team focused on the next six months. GitHub keeps a strong two-way relationship between GitHub Next and the product team so future thinking becomes real.

Shani describes the chief product officer role as broader than being head of product. A CPO needs business thinking, go-to-market strategy, sales play and an understanding of how engineering builds products. The job is less about writing requirements or painting a vision than about how all the company's components operate together.

She learned systems thinking from her first boss in aerospace: not just tuning one filter, but seeing how it connected to the control system, ignition and final display. She also emphasizes influence, because product managers must influence engineering to build and revenue teams to sell. She advises learning from leaders above, peers across the company, and people you manage, adopting skills that are missing from your own toolbox.

In the podcast's Failure Corner, Shani reframes failure as learning. Her biggest learning came early in her leadership career at TomTom, leading the location-based services team: she arrived with a go-go-go mindset and tried to fix everything without building understanding of why change was needed. The team told her she was moving too fast and needed to explain the why, and she also had to adjust her style to an international culture. She learned that being hired to drive change does not mean the team is automatically on board; a leader has to take people through the journey.

In the lightning round, Shani says she asks candidates about the most innovative thing they have done and why they consider it innovative, and about a time they disagreed with a manager and what they did. Those questions reveal character, willingness to stand ground, communication and influence. Her life motto is that if you do not take risks, you cannot create a future; comfort is not the goal, and stretching yourself means feeling uncomfortable.