Microsoft’s Jay Parikh on AI Infrastructure, Model Choice and Agent Security

The CoreAI leader discusses power constraints, developer workflows, enterprise models and why he measures outcomes rather than generated lines of code.

JPJay Parikh게스트 · Microsoft
채널
Matthew Berman
게시일
2025년 11월 28일
영상
40:24
읽기
7분
원문
영어
YouTube에서 열기
스크롤하면 영상이 오른쪽 아래로 작아져 계속 재생됩니다. 자막은 읽기 언어를 따릅니다.
읽기 언어2개 언어로 읽을 수 있음
이 글은 아직 한국어 번역이 없어 영어 원문으로 표시합니다.
요약

30초 요약

In this November 2025 interview, Microsoft executive Jay Parikh tells Matthew Berman how CoreAI combines developer tools, infrastructure and security. He discusses in-person work, GPU and power constraints, model diversity, OpenAI and agent governance; his product descriptions and forecasts reflect Microsoft’s perspective.

  1. 1CoreAI’s stackParikh describes developer tools, Foundry and security as connected layers for builders.
  2. 2In-person workHe argues that team members learn and collaborate faster face to face.
  3. 3Power and GPU utilizationParikh acknowledges power constraints and emphasizes optimization, without reporting a utilization rate.
  4. 4A mix of modelsDifferent tasks may justify frontier models or smaller targeted models, depending on cost, speed and quality.
  5. 5Agent securityParikh describes identity, access policy and action tracing in Microsoft’s platform.
  6. 6Outcomes over linesHe argues that modernization and reduced technical debt matter more than counting generated code.

핵심 정리

  1. Parikh sees developer tools, agent deployment and security as connected layers of the CoreAI stack.
  2. He attributes his team’s in-person policy to faster collaboration and learning.
  3. Power, land, equipment, networking and conventional compute can all constrain AI infrastructure.
  4. Parikh acknowledges power shortages but does not give a Microsoft GPU utilization percentage.
  5. Enterprises may use different models and adaptation strategies for different workloads.
  6. Agent identity, access controls and observability are part of Microsoft’s stated security approach.
  7. Parikh favors measuring outcomes such as reduced technical debt over counting AI-generated lines.
전문

챕터별로 다듬은 전문 읽기

원본 자막만 보기
01

Building Microsoft’s CoreAI stack

Parikh outlines the combined organization, developer tools, Foundry and security. He argues for a consistent stack across deployment environments.

Matthew Berman interviews Jay Parikh, Microsoft’s executive vice president of CoreAI, about the developer stack, office culture, infrastructure, model choice and security. The conversation took place around Microsoft Ignite in November 2025; product claims, plans and forecasts should be read in that historical context.

Parikh says Microsoft formed CoreAI in January and presented its product strategy at Build in May. With models, frameworks and protocols such as MCP evolving rapidly, he sees the AI stack as unfinished. The goal is to help builders and enterprises assemble these pieces into useful applications.

He describes a layer of reimagined developer tools above Microsoft Foundry, which he calls an agent factory for building, deploying and observing agents. Security and trust must be present from the start, he argues, because agents may plan, call tools and access data in ways that are less deterministic than traditional software.

Deployment must also span cloud and edge devices, Parikh says, reflecting the needs of different sectors and geographies. Asked why Microsoft combined the teams, he says the common objective is to serve builders across the stack. He wants products, measurement and customer engagement to work together so developers are not left with disconnected, insecure or unobservable components.

02

Office culture and changing work

Parikh explains his team’s return-to-office rationale and discusses AI-driven prototyping, collaboration and changing roles.

Berman asks about CoreAI’s planned return to in-person work in the new year. Parikh argues that face-to-face collaboration helps people mentor one another, share discoveries about Copilot, and jointly learn how to provide context or scaffolding for difficult AI tasks. This is his rationale for the team’s policy, not evidence that every Microsoft employee had the same requirement.

Berman notes that many enterprises and individuals are still learning how to use AI, and asks whether that is also true inside Microsoft. Parikh says the company serves many roles, including HR, finance, engineering and security, and must evolve as quickly as the technology. He describes an internal program aimed at reducing administrative work and freeing time for creative product development.

Parikh offers product prototyping as an example: specify an idea in a document, ask agents to build five alternatives in parallel, and use customer feedback to improve the best elements. He believes this can broaden the creative search and accelerate feedback. He says cultural change and learning how to work differently arise in most of his customer and partner conversations.

Asked about the blurring of product, development and design roles, Parikh says AI tools let people contribute beyond their traditional specialties. A systems engineer might generate a UI concept; a product manager or designer might use Copilot to propose a bug fix. An engineer may still review the resulting pull request against code standards.

Parikh thinks the biggest differences are between individuals rather than job titles. He contrasts infrequent users who are delighted whenever AI works with frequent users who are frustrated because they push it on harder tasks. In his view, the latter group tends to experiment with models, context engineering, evaluation, fine-tuning and reinforcement learning.

Parikh describes some teams orchestrating groups of agents on complex tasks and using verification systems to check outputs. He says some teams treat code as an intermediate artifact and do not inspect every line, with verification agents feeding problems back to coding agents. This is his description of particular workflows, not proof that automated verification is sufficient in every setting.

03

Data centers, power and GPU use

The discussion turns to supply chains, infrastructure constraints and GPU utilization. Parikh emphasizes optimization without providing a utilization figure.

Berman turns to the Fairwater data center and asks whether power has become a greater constraint than GPUs. Parikh says the answer depends on ambition and location: power, land, transformers and other heavy equipment all affect expansion. Some jurisdictions have paused data-center growth while others are encouraging it, he says.

Hardware requirements also change from one generation to the next, including cooling, power and networking. Parikh argues that agent workloads raise demand for ordinary compute, storage and network capacity as they call enterprise tools and systems. Scaling AI therefore involves the whole system, not only GPUs.

Berman raises the AI infrastructure bubble debate and compares unused fiber capacity with claims about idle GPUs. He cites Satya Nadella’s remarks about power shortages leaving some GPUs waiting. Asked for Microsoft’s utilization, Parikh does not provide a utilization percentage; he instead emphasizes continuous measurement and optimization across CPUs, GPUs, memory bandwidth and networks.

Microsoft can learn from both first-party workloads such as Microsoft 365 and GitHub and third-party customer workloads, Parikh says. Its teams tune the hardware, software and application stack to get more use from the fleet. Berman presses again on whether there will be enough electricity over the next 12 to 24 months.

Parikh says physical capacity must be aligned with demand and that surpluses or shortages can occur. He acknowledges Nadella’s statement that power is short and says teams are seeking more power while optimizing existing infrastructure. He gives no specific forecast or figure for powered versus idle GPUs.

04

Model efficiency and enterprise choice

Parikh discusses smaller models, routing, enterprise data and open versus closed choices. He expects multiple specialized models to remain useful.

Parikh argues that improving utilization of already-powered GPUs can be faster and cheaper than waiting for new data centers. Because Microsoft operates a large fleet, even a fraction of a percentage point of improvement can release useful capacity, he says. This is a complement to building more infrastructure, which takes time.

On model efficiency, Parikh expects enterprises to use a mix: larger, slower and more expensive models for some tasks and smaller, targeted models for others. Teams may start with a large model and then fine-tune or distill a smaller one, while optimizing frameworks and runtimes. He says cost and latency improvements must remain within acceptable accuracy, security and safety tolerances.

Parikh describes Microsoft’s model router as a way for applications to select among models according to preferences such as cost, speed and quality. He presents it as a platform capability to reduce the burden on enterprises choosing models for different workloads. The interview does not independently test its routing performance.

He also argues that enterprise data and context can make applications more useful. Organizations can bring customer, supply-chain or marketing data alongside a model and adapt it through fine-tuning or reinforcement learning. He expects these combinations to support more complex workflows and potentially better returns, a claim dependent on the deployment.

Berman asks how customers should choose between open and closed models, including models from Chinese developers. Parikh says Microsoft wants to offer choice, claiming that Foundry listed 11,000 models at the time. He advises beginning with the customer’s objectives and experience, then using examples and proof points to find a suitable approach rather than treating the decision as binary.

Berman asks whether a single omni-model will eventually handle everything. Parikh does not rule it out forever but does not expect one model to be best at every task soon. He anticipates continued demand for different sizes and customized models across fields such as healthcare, finance, climate and industrial processes.

05

OpenAI and Microsoft AI

Parikh describes partnership-based product work alongside Microsoft’s own models. He explains how CoreAI and MAI teams collaborate.

On OpenAI, Parikh says Microsoft both incorporates technology from the partnership into its products and develops its own models through Microsoft AI. Product work can involve post-training and combining models, while the MAI team pursues Microsoft’s own model capabilities. He presents these as parallel efforts.

Asked how CoreAI works with Mustafa Suleyman’s MAI team, Parikh describes collaboration on infrastructure, algorithms, evaluation, safety and trust. Work is divided according to the teams best placed to do it; for example, software-development models may be closely tied to GitHub Copilot and developer-tool teams.

06

Agent security and measuring outcomes

Parikh discusses unknown threats, agent identity and observability. He closes by favoring outcomes such as reduced technical debt over counting generated lines.

Berman raises model-weight theft, poisoning and AI-enabled hacking, and asks which attack vector worries Parikh most. Parikh says unknown threats are especially concerning: known threats can have mitigations, while the technology’s speed and continuing advances may challenge established security practices.

Parikh says security is built into Microsoft’s agent platform. As he describes it, an agent receives an identity tracked in Microsoft Entra, with policies and access controls, and can be deactivated if it misbehaves. He also describes tracing tool calls, data access and human approvals for an agent’s actions; these are product claims rather than independently verified guarantees.

For his contrarian view, Parikh rejects lines of AI-generated code as a useful primary metric. He prefers to ask what an organization can do now that it could not do before. He points to financial-services teams with years of technical debt: if AI helps them modernize code and infrastructure and improve security, those outcomes matter more than the volume of generated lines.

같은 채널의 다른 글

슬라이드 12장34:21EN
Matthew Berman· 2026년 10월 27일Matthew Berman Examines Anthropic’s IPO Filing, AI Growth and GovernanceMatthew Berman, Sam Altman · Forward FutureThe presenter reviews the S-1’s financial metrics, compute strategy and voting structure while questioning the tension between rapid AI development and safety.AnthropicAI Safety엔터프라이즈 AI+2
0:26EN
Matthew Berman· 2026년 10월 25일Sam Altman on Human Values and Problem-Solving in an AI WorldSam Altman · OpenAIIn a short interview excerpt, Altman considers the enjoyment of solving hard problems and the human role in interpreting results.Human-AI CollaborationFuture of WorkAI Strategy
슬라이드 2장0:36EN
Matthew Berman· 2026년 10월 25일Kimi K3.1 and a Rubik’s Cube Solver DemonstrationMatthew Berman · Forward FutureMatthew Berman shows a scrambled virtual cube being solved and gives the Kimi K3.1 test a favorable assessment.평가(Evals)코딩 에이전트Open-weight models
슬라이드 2장0:21EN
Matthew Berman· 2026년 10월 24일An AI-Generated Kimi Benchmark Chart Used Invented ScoresMatthew Berman · Forward FutureMatthew Berman asks for a graph of Kimi K3.1 Pro benchmarks, then discovers that the displayed figures are illustrative placeholders.Benchmarks평가(Evals)Generative media
슬라이드 6장25:50EN
Matthew Berman· 2026년 10월 24일Kimi K3.1 Pro Tested: Strong 3D Demos, Uneven Results and Competitive PricingMatthew Berman · Forward FutureMatthew Berman tests the open-weight model on coding, 3D rendering and visual explanations, then compares benchmark results and prices.Open-weight modelsBenchmarksAI cost & performance+1
슬라이드 2장32:20EN
Matthew Berman· 2026년 10월 23일Who Is Local AI For? The Costs, Trade-offs and a Hybrid FutureMatthew Berman · Forward FutureMatthew Berman weighs data control and independence against hardware cost, setup complexity and inference speed.Local inferenceOpen-weight modelsAI cost & performance+1