On Friday, we became aware of what we believe to be an active and narrow-banded exploitation of a vendor in Warp's infrastructure. We detected the operation within hours and were able to remediate and mitigate the impact. We have been in touch with the vendor about the vulnerability. Everyone who uses Warp places a lot of trust in us and that’s not something we take lightly. I’m very sorry that this incident has occurred. The attack appears to have come from an agent swarm using a very sophisticated penetration and escalation technique, likely starting with a hole in a vendor dependency, and ultimately accessing a limited amount of agent trace and telemetry data. We have been working over the weekend and we have notified anyone who we have positively identified as impacted. As of today, we believe an upper bound of roughly 1% of Warp users may have been impacted. We are working closely with the team at Crowdstrike to do a more extensive and comprehensive investigation and have engaged law enforcement. Anyone who has been impacted will receive instructions from us on action they need to take. We will continue to post updates as we learn more.

verification is the biggest bottleneck for coding agents right now according to @addyosmani. we @warpdotdev have put a lot of thought into building a good computer-use tool for Warp Factories. every agents gets a computer to navigate the apps they built, take screenshots and recordings, and post them back for human review. 3-4mins of activity get edited down to 15 clips stitched together with cursor clicks, mouse animations, and key presses. we've been able to dramatically cut our time to merge and unlocked faster iteration + review cycles, especially for projects that are hard to mock out locally!

Software factories should be configured as code. With Warp, your factory lives in a repo as markdown and YAML files, so your agents, automations, runners, benchmarks, and even custom model routers are all in one place. Here, I walk through a typical Warp factory config and show how it lays the foundation for self improvement! It's pretty awesome DX.

We should stop keeping all of our agent conversations local. They should be stored in a shared place. This lets you do some powerful things: - Schedule self-improvement agents to review runs and pull out failure modes worth fixing - Replay past conversations against different models for benchmarking I met a team of devs zipping up Claude and Codex sessions from their computers and shipping them to a shared S3 bucket. That's... a start 😄 But really, all agent sessions should happen on a single source (like a cloud runner) so that conversation traces are stored together by default. It's why Warp Factories uses cloud sandboxes and makes sessions available via API. We also added an inbox view to see which conversations need your attention, which is quite convenient:

Here's my take on what a software factory really is This is my talk from @aiDotEngineer NYC, and I decided to record a version for everyone to watch on X. tl;dr - software engineering is becoming factory engineering, and there's new work (especially factory benchmarking) that engineers should start focusing on.

Software factories can be a real culture shift. The biggest change for us was moving from individual agents on everyone's machines to one central agent setup (a factory) that we can build as a team. I wrote some learnings on how to navigate that.

We benchmarked some agent orchestration pipelines at @aiDotEngineer. Which would you pick?

I've been thinking about what a true, closed-loop software factory will look like. One where agents know what to fix, what costs to optimize, and the big one: what features to actually build. We're not there yet. But maybe we're getting close...