The next was to make file paths in agent conversations clickable. Agent Mode uses tools to read files and search codebases, and we render paths for referenced files in the UI. I made those paths clickable so that they opened in the ADE and added line numbers for better observability.

After shipping these features to our staging environment, I began to play around with them myself. This is another thing that’s really cool about working at Warp: you get to dogfood what you build every day (engineers at Warp start every PR by prompt).

Here’s where my troubles began. Warp’s text editor worked, but barely. Technically, you could edit a file in Warp. We supported the most basic functionality: opening a file, editing it, and saving your changes. But we were nowhere near parity with an IDE; I found myself wanting features like LSP, find/replace, and a better experience for viewing multiple files.

The Agentic Development Environment

But before building this, I needed to answer a fundamental question: why build an editor in the first place, instead of deeply integrating with IDEs like everyone else?

Our CEO Zach explains this well in his blog post: “In a world where developers write less and less code by hand, there’s no reason to spend your day in an interface built for hand-editing code" (aka, an IDE).

If developers start to increasingly code by prompt, then the bells and whistles that made us love IDEs become distractions from the core workflow of guiding an agent and editing diffs.

Plus, IDEs don’t lend themselves well to multi-agent workflows. Spinning up multiple agents inside a single IDE window feels wrong.

Warp’s ADE was designed for this: panes and tabs naturally support parallel work, agents can freely work across a user’s entire machine (IDEs are restricted to a single root folder), and the terminal itself, paired with first-class MCP support, provides a natural gateway for agents to access version control, issue tracking, and more.

Code, however, isn’t going away anytime soon. A true agentic development environment would need a set of code-editing capabilities that enabled developers to efficiently review and edit code alongside an agent.

Supporting find-and-replace

The first piece of this was supporting find and replace. There are a few reasons we thought this was important to build:

• For developers, the most primitive way to navigate through a file is by searching for entities, like variable or function names. Without a search interface, scanning files in Warp was unnecessarily painful.
• In Warp, you can make fine-grained edits to code diffs generated by an agent, which is a core differentiator from competitors like Claude Code and Codex. A common use case for this was code refactors, like changing variable names, which was cumbersome without the ability to replace all occurrences of a string.

I built this in June, roughly based on VSCode’s find and replace feature. You can view the docs here.

Rethinking code snippets in Warp

But building a better editor was only half the battle. The reality was that most Warp users still thought of us as an agentic terminal and were completely unaware that Warp had a native interface for editing files.

Thankfully, there was a bunch of prior art here. Over the years, we’ve shipped features like Rules, Warp Drive, and Agent Mode, each of which made Warp a better product. But with every new feature came new issues with discoverability: users that weren’t plugged into our socials or reading every changelog weren’t benefitting from these changes.

LLMs have been super useful here. In the past, we’ve used techniques like LLM-as-a-judge to identify conversations where new features could be helpful and nudge users toward adoption. Internally, we call these “aha moments” (examples include suggested code diffs and active AI).

Before thinking about how to create these “aha moments” for the editor, I first needed to understand why users left Warp for their IDE in the first place. As it happened, I was one of those users. I started by reflecting on my own behavior.

What I found was that besides manual coding, the main reason that I left Warp was to gather context around agent-generated code.

A good example was code blocks: agent conversations frequently included code snippets, but they were the most plain variety, with no information about where the code came from. I frequently found myself opening a new IDE window, searching for a keyword from the snippet, and then reading the file. There was clearly room for improvement here, and an opportunity to lead users to our built-in editor.

To solve this, our designer Peter redesigned snippets to include metadata (file paths, line numbers) and actions to open in Warp or add as query context. Building this became my next project.

Dealing with LLM non-determinism

At first glance, this seemed simple enough to build. But if there’s anything I’ve learned this Summer, it’s that working with LLMs is anything but. LLMs are highly non-deterministic systems, and there are unique challenges that come with this.

Building linked code blocks required us to prompt an LLM to output the file paths and line numbers of referenced code.

My initial approach was a prompt change that instructed the model to output all code snippets with a header like ```{language}:{path}:{line_num}. Some local testing quickly revealed that the agent didn’t reliably adhere to this format, often defaulting to the default code block header ```{language}.

I spent some time debugging this issue with some teammates and came up with a thesis: since models are trained on large corpora of data, they might respond better to formats that exist within their training set. So instead of creating a custom format for parameterizing metadata about the code block, I asked Agent Mode (an LLM) what formats it knew for doing this. After some back-and-forth, we came up with a format that used the info string to carry this metadata. It looked something like ```{language} path={path} start={line_num}.

This solved my issues with instruction following, but there remained another issue that comes from working with LLMs: hallucinations. Internal users noted conversations where the agent would hallucinate files and line numbers, so I added deterministic checks on the agent’s work before rendering it in the UI.

We shipped linked code blocks in July and they've been a huge success!

A new code editing experience

Linked code blocks made me use Warp’s editor more heavily, and I often found myself editing multiple files side-by-side. But the existing process for this was clunky: each new file opened as a vertical pane, leading to a bunch of clutter on the screen. Opening more than 2 files side-by-side was an unpleasant experience.

I aired my grievances with the current approach, and within an hour other internal users chimed in and confirmed that this was a pain point. Peter shipped some early designs for a new “tabbed editor” inspired by VSCode’s file viewer, and we were off to the races!

This design presented several challenges. At the time, Warp only supported workspace tabs, which held groupings of panes and their data. Creating a tabbed editor required us to introduce a new concept of “tabs within tabs” (i.e., file tabs could exist within other workspace tabs). There was little prior art for this, in Warp and elsewhere.

Solving this involved a few design decisions. We decided that each workspace tab should contain no more than a single editor pane to avoid any ambiguity on where to place new files. We also chose not to repurpose the existing keyboard shortcuts for navigating the workspace tab group to avoid confusion and keep this backwards-compatible. Finally, we wanted the tabbed editor to work nicely with our existing drag system, so we added functionality for users to drag a file into its own workspace tab or merge it with an existing one.

The result was a much cleaner file-editing experience that felt native to Warp’s existing interaction patterns. We shipped this feature in August and it’s been a favorite among both internal and external users.

Gallery of other features I built

Cmd-L to add selected text from an editor pane as context

Toggle default layout for opening files in Warp

Takeaways

Engineers at Warp are given an incredible amount of ownership. This is clear from my experience: as an intern, I led the charge on improvements to our code editor, which became a key part of our recent launch.

At Warp, even though my job title was “software engineer”, I often worked across product and engineering, ideating, building, and iterating on new features. This led to several important takeaways.

Engineering

When I started at Warp in May, I was very much a code-first engineer. This is what school, and most software roles, train you to be.

This was challenged during one of my first 1:1s at Warp with Ian. I started off by asking what’s probably a very normal question at most companies: what parts of the codebase should I try to touch during my internship?

Ian, and later other engineers at Warp, pushed me to think in terms of impact rather than technical complexity. We think the most important things to consider are function and iteration speed (from our CEO Zach: “good product usually implies good code”). During every design jam and code review, I was pushed to maximize for low effort and high impact, which was a meaningful shift from how I’d previously thought about software engineering.

Like the company itself, Warp’s engineering practices are built to help developers ship better code, faster. To that end, design and development is a highly iterative process: I demoed early iterations of features that I was building at standup. Gathering feedback mid-stream helped me adjust while changes were simple.

Warp is also heavily biased against unnecessary meetings to preserve IC time. We’d use Slack threads and short design jams to align rather than lengthy design docs. This actually helped me ship more code: I merged over 40 PRs during my 12 weeks at Warp, which was a direct consequence of Warp’s focus on shipping fast, prioritizing impact, and cutting bloat.

Product

At Warp, every PR starts by prompt, in the ADE. As a result, our engineers (and in fact, employees across all functions) are power users and have intuitions about how the product can be improved for them, which usually generalize to some subset of our users.

We have an internal Slack channel where people post product ideas, many of which end up getting productized. Several of the features that I worked on, including the tabbed editor and selection-as-context, came from messages that I sent to this channel.

Engineers are also expected to be advocates for their work. Every feature that I shipped was accompanied by a demo to our Preview community, where I solicited feedback and iterated on the product prior to a full release.

Interacting with this community helped me realize that most users didn’t know about our code editor, leading to my work on linked code blocks and a launch video that I helped make with our developer advocate Jess.

But perhaps the biggest takeaway about product at Warp is the speed at which we go from idea to prototype. Most of the features I built started from a Slack message. Teammates would chime in on a proposal, our designers Peter and Dave would whip up some designs, and we’d align on an implementation. It usually took me less than a day to gather what I needed to start initial work on a feature, which led to huge productivity gains.

Final Thoughts

After a few weeks at Warp, I’ve come away with a much better sense of how to build and grow product from the ground up.

For a Series B startup, working at Warp looks remarkably similar to starting your own company: we form opinions about the future of software, build for that vision, and iterate relentlessly. I learned that meaningful growth happens at the intersection of uncertainty and ambition.

As I enter into my final year at Georgia Tech, I’m convinced that I want to continue exploring what’s possible with LLMs. They represent the most transformative technology of our time, and there remain many unsolved problems around user experience, reliability, and learning. Working on these problems at Warp was deeply invigorating, and I’m excited to continue to do so.

Now for some pictures: