Safia Abdalla

Safia Abdalla builds developer tools and cloud-agent infrastructure at Warp. Her work on Oz, Warp’s cloud agent platform, brings together isolated execution environments, coding harnesses, agent orchestration, and APIs. She approaches these systems through a lesson developed across open-source notebooks and Microsoft’s developer tools: useful tools accommodate how people already work and grow with them as their needs become more demanding.

Open-source tools and welcoming contributors

Abdalla began contributing to open source while studying at Northwestern University. An initial contribution to pandas led her into Jupyter, where she met mentor Kyle Kelley. When Kelley began nteract, she joined him in developing an accessible desktop experience for notebooks and became a maintainer of its applications, React components, and packages for interactive computing and data science.

Maintaining that software gave her experience with releases, issue triage, and maintainability. It also shaped her approach to leadership. She treats welcoming new contributors as part of a maintainer’s responsibility, particularly for people underrepresented in open source. Reviewing a small contribution can help someone gain the confidence and access needed to participate in larger technical decisions. Her work on nteract’s community connected the accessibility of the tools with the accessibility of contributing to them.

Building APIs and deployment tools at Microsoft

At Microsoft, Abdalla built web frameworks and SDKs for cloud services and became a principal software engineer. Her .NET 10 contributions included built-in validation for Minimal APIs, OpenAPI 3.1 support, and integration-testing improvements. She paid particular attention to preserving ahead-of-time compilation compatibility as features expanded. For validation, compile-time source generation discovers relevant types and produces registrations that runtime code can use, reducing the validation infrastructure developers must assemble themselves.

She also helped develop Aspire Pipelines, addressing the coordination involved in deploying an application’s services, databases, container images, and permissions. Early deployment support relied on sequential callbacks; the later pipeline execution model made steps and their dependencies explicit. Independent steps could run concurrently, while deployment logic retained access to the application’s resource model. Knowing which resources an application contains gives the pipeline information it can use to coordinate deployment, beyond simply executing a sequence of commands.

Concurrency also changed how developers needed to see progress. Abdalla revamped Aspire’s deployment activity reporter to handle concurrent updates and produce readable output in interactive terminals and CI logs. Making execution understandable is a recurring concern in her work: users need to know what a system is doing before they can diagnose problems or improve the process.

Packaging her own workflow into Grove

Her own tools reflect the same attention to everyday workflows. After adopting Git worktrees to organize simultaneous implementation, prototyping, and review, she packaged those patterns into Grove. The command-line tool lets separate tasks occupy separate working directories while sharing a repository, with support for worktree management, synchronization, and shell navigation. In her 2025 reflections, she described experimenting with Claude, Warp, and Copilot and treating software creation as an iterative process of shaping and revising an idea.

Building Oz for cloud-agent work

• Execution environments: At Warp, Abdalla applies this experience to agents doing work beyond a developer’s laptop. In her account of building Oz with the Warp team, she argues that platforms should absorb infrastructure complexity before it reaches users. A cloud agent needs an isolated environment in which to work, but teams also have existing infrastructure, security requirements, and deployment practices. Oz supports managed hosting and infrastructure teams bring themselves, allowing agent execution to fit those constraints.
• Harness choice: Harness choice introduces another challenge. Developers may prefer different coding agents or need different tools for different tasks, yet supporting those choices can fragment the platform experience. Abdalla describes giving harnesses consistent access to conversation storage and restoration, generated files, issues, and pull requests. The surrounding platform provides a common way to handle state and outputs while accommodating different harnesses.
• Agent orchestration extends that flexibility across a task. Substantial engineering work may need one agent to research and plan, another to implement, and a third to validate, potentially using different harnesses and models. Oz supports prompt-based delegation, with an orchestrator coordinating subagents, messages, and progress. Its APIs also expose agents, subagents, execution environments, and artifacts so users can assemble workflows beyond the platform’s own interface.

Putting agents to work at Warp

• Internal tools: Those APIs have supported internal tools built by non-engineering colleagues at Warp. One workflow analyzes incoming social mentions, identifies what a user wants, and proposes a response for a person to review. Other tools support product questions and competitive research. These examples illustrate Abdalla’s interest in giving people with domain knowledge the infrastructure to turn that knowledge into working software.
• Open-source contributions: Warp’s open-source repository provides a more extensive example of agent-supported contribution workflows. Abdalla describes the team using agents to investigate new issues, search the codebase for context, and ask contributors for missing details. Agents can help prepare specifications, implement changes, and review pull requests through multiple iterations. In the process she presented, human reviewers are notified after agent approval, concentrating their attention on contributions that have already passed an initial review gate. The team also uses new examples from incoming contributions to improve the agents. Her emphasis is on the work that makes a contribution understandable and reviewable, with humans participating in the process.

The software workshop model

Abdalla prefers a software workshop to a software factory as a model for these systems. She illustrates the distinction through a potter who designed both the details of a mug and the stations, preparation, and verification needed to reproduce it. A incorrectly sized thumb dimple was a reason to revisit a particular part of the process; observing apprentices at work informed changes to the workshop itself.

For software, that model means systems that respond to events, expose their execution for inspection, improve through feedback, and limit wasted work and token costs. Skilled judgment remains part of how the system develops. Abdalla’s goal is to remove repetitive work—from clarifying bug reports to supporting production monitoring—so more people can translate their intentions into software through a process they can understand and refine.