Extreme Harness Engineering for Token Billionaires: 1M LOC, 1B toks/day, 0% human code, 0% human review — Ryan Lopopolo, OpenAI Frontier & Symphony
Latent Space: The AI Engineer PodcastEpisode Description
Summary
Ryan Lopopolo from OpenAI discusses 'harness engineering,' a methodology where AI agents write and manage an entire codebase with zero human-written code, achieving massive productivity gains. He explains how his team at OpenAI Frontier built an internal tool, Symphony, using this approach, focusing on making humans the bottleneck by automating the software development lifecycle and encoding institutional knowledge into agent-readable formats. The conversation also covers the evolution of AI models, the concept of 'ghost libraries,' and OpenAI's vision for the Frontier platform to enable widespread enterprise AI transformation.
Chapters
Topics
People
Key Concepts (29)
References (50)
Transcript (109 segments)
I do think that there is an interesting space to explore here with codecs, the harness as part of building AI products. Right? There's a ton of momentum around getting the models to be good at coding.
We've seen big leaps in, like, the task complexity with each incremental model release where if you can figure out how to collapse a product that you're trying to build, a user journey that you're trying to solve into code, it's pretty natural to use the Codex harness to solve that problem for you. It's done all the wiring and lets you just communicate in prompts to let the model cook. You have to step back.
Right? Like, you need to take a systems thinking mindset to things and constantly be asking, where is the agent making mistakes? Where am I spending my time?
How can I not spend that time going forward? And then build confidence in the automation that I'm putting in place so I have solved this part of the SDLC.
Alright. We're in the studio with Ryan Lopopolo from OpenAI. Welcome.
Hi. Thanks for visiting San Francisco, and thanks for spending some time with us. Yeah.
Thank you. I'm super excited to be here. You wrote a blockbuster article on harness engineering.
It's probably going to be the defining piece of this emerging discipline.
Thank you. It is it's been fun to feel like we've defined the discourse in some sense.
Let's contextualize a little bit this first podcast you've ever done. Yes. And thank you for spending it with us.
What is where is this coming from? What team are you in? All that jazz.
Sure. Sure.
new product development in the space of OpenAI Frontier, which is our enterprise platform for deploying agents safely at scale with good governance in any business. And the role of me and my team has been to figure out novel ways to deploy our models into package and products that we can sell as solutions to enterprises.
And you have a background. I'll just squeeze it in there. Snowflake, Brex, Stripe, Citadel.
Yes. Yes. So then the link kind of customer entire life.
Yes. The exact kind of customer that you want to So I'll say I was actually I didn't expect the background. When I look at your Twitter, I'm seeing the opposite of stuff like this.
like, buckling in your laptop on your Waymos. Yes. And then I look at your profile.
I'm like, oh, you're just, you're correct in the other end too. So perfect mix. Perfect mix.
I it's quite fun to be AI maximalist. If you're gonna live that persona, OpenAI is the place to do it. And it's Token is what I say.
Yeah. It certainly helps that we have no rate limits internally, and I can go, like you said, full send at this thing. Yeah.
Yeah. So the OpenAI Frontier and your special team within OpenAI Frontier. We had been given some space to cook, which has been super, super exciting.
And this is why I started with kind of a out there constraint to not write any of the code myself. I was figuring if we're trying to make agents that can be deployed into end enterprises, they should be able to do all the things that I do. And having worked with these coding models, these coding harnesses over six, seven, eight months, I do feel like the models are there enough, the harnesses are there enough, where they're isomorphic to me in capability and the ability to do the job.
So starting with this constraint of I can't write the code meant that the only way I could do my job was to get the agent to do my job. And like a just a bit of background before that. This is basically the article.
over a my a million lines of code in the total code base. You say it was Senex more like, it was 10x faster than you would have if you had done it by end. Yeah.
That was the mindset going into this. Right? Right.
That's right.
with some of the very first versions of Codec CLI with the Codec Mini model, which was obviously much less capable than the ones we have today, which was also a very good constraint. Right? It's quite a visceral feeling to ask the model to build you a product feature and it just not being able to assemble the pieces together, which kind of defined one of the mindsets we had for going into this, which is whenever the model just cannot, you always pop open the task, double click into it, and build smaller building blocks that then you can reassemble into the broader objective.
And it was quite painful to do this, honestly. The first month and a half was 10 times slower than I would be. But because we paid that cost, we ended up getting to something much more productive than any one engineer could be because we built the tools, the assembly station for the agent to do the whole thing.
But yeah. So onward to g p d five, five one, five two, five three, five four to go through all these model generations and see their kind of quirks and different working styles also meant we had to adapt the code base to change things up when the model was revved. One interesting thing here is five two, the codex harness at the time, did not have background shells in it, which means we were able to rely on blocking scripts to perform long horizon work.
But with five three and background shells, it became less patient, less willing to block. So we had to retool the entire build system to complete in under a minute. And this is not a thing I would expect to be able to do in a code base where people have opinions.
But because the only goal was to make the agent productive, over the course of a week, we went from a bespoke make file build to Bazel to Turbo to NX and just left it there because builds were fast at that point. Interesting.
Talk more about Turbo to NX. That's interesting. Because that's the other direction that other people have been doing.
Ultimately, I have not a lot of experience with actual front end repo architecture. You're telling me that Jessica built us this guy. So I'm like, I know the NXT team.
Know Turbo from Jared Palmer, I'm like, yeah, that's an interesting competitor comparison. The hill we were climbing, right, was make it fast. Is there a micro micro front ends involved?
It's like, how how complex? React. Electron based single app sort of thing.
And must be under a minute. That's an interesting limitation. I'm actually not super familiar with the background shelf stuff.
Probably was talked about in the five three release.
commands in the background and then go continue to work while it waits for them to finish. So it can spawn an expensive build and then continue reviewing the code, for example. Yeah.
And this helps it be more time efficient for the user invoking the harness. And I guess and just to really nail this, like, what does one minute matter? Like, one or five?
Okay. We want the inner loop to be as fast as possible. Okay.
One minute was just a nice round number and we were able to hit it. And if it doesn't complete, it kills it or some something? Oh, no.
We just take that as a signal that we need to stop what we're doing, double click, decompose the build graph a bit to get us behind back under so that we can enable the agent to continue to operate. It's almost like you're it's like a ratchet. Like, it's like you're forcing Yeah.
because if you don't, it'll just grow and grow. That's right. And you mentioned that Like, current like, the software I work on currently is at twelve minutes.
It sucks.
and then you spend two, three weeks to bring it back down to the lower end of the envelope and stop. But because tokens are so cheap Yeah.
which means we can simplify in a way and rely on a lot more invariance as we write the software. Lovely. You mentioned in your article, like humans became the bottleneck.
Right? You kicked off as a team of three people. You're putting out a million line of code, like 1,500 PRs.
Basically, what's the mindset there? So as much as code is disposable, you're doing a lot of review. A lot of the article talks about how you wanna rephrase everything is prompting.
Everything is what the agent can't see. It's kind of garbage, right? You shouldn't have it in there.
So what's like the high level of how you went about building it and then how you address, okay, humans are just PR review. Like, is human in the loop for this? We've moved beyond even the humans reviewing the code as well.
Most of the human review is post merge at this point, but Wow. Post merge. Merge.
That's not even review. That's just let's just make ourselves happy by reading it.
the model is trivially paralyzable. Right? As many GPUs and tokens as I am willing to spend, I can have capacity to work on my HUD base.
The only fundamentally scarce thing is the synchronous human attention of my team. There's only so many hours in the day. We have to eat lunch.
I would like to sleep, although it's quite difficult to stop poking the machine because it makes me want to feed it. You have to step back. Right?
Like, you need to take a systems thinking mindset to things and constantly be asking, where is the agent making mistakes? Where am I spending my time? How can I not spend that time going forward?
And then build confidence in the automation that I'm putting in place, so I have solved this part of the SDLC. And usually what that has looked like is like, we started needing to pay very close attention to the code because the agent did not have the right building blocks to produce modular software that decomposed appropriately, that was reliable and observable and actually accrued a working front end in these things. Right?
So in order to not spend all of our time sitting in front of a terminal at most doing one or two things at a time, invested in giving the model that observability, which is that that graph that's in the post here. Yeah. Let's walk through this.
Traces Which and existed first? We started with just the app and the whole rest of it from vector through to all these login metrics APIs was, I don't know, half an afternoon of my time. We have intentionally chosen very high level, fast developer tools.
There's a ton of great stuff out there now. We use Mies a bunch, which makes it trivial to pull down all these Go written Victoria stack binaries in our local development. Tiny little bit of Python glue to spin all these up, and off you go.
One neat thing here is we have tried to invert things as much as possible, which is instead of setting up an environment to spawn the coding agent into, instead we spawn the coding agent, like that's the entry point, just codecs. And then we give codecs via skills and scripts the ability to boot the stack if it chooses to, and then tell it how to set some end variables so the app in local dev points at this stack that it has chosen to spin up. And this, I think, is like the fundamental difference between reasoning models and the four ones and four o's of the past, where these models could not think, so you had to put them in boxes with a predefined set of state transitions.
Whereas here, we have the model, the harness be the whole box, and give it a bunch of options for how to proceed with enough context for it to make intelligent choices.
So sales So like a lot of that is around scaffolding. Right? Yes.
Previous agents, you would define a scaffold. It would operate in that loop, try again. That's pivoted off from when we've had reasoning models, they're seeming to perform better when you don't have a scaffold.
Right? Let them and you go into like niches here too, like your spec.md and like having a very short agent.
agentmd? Yes. Yes.
Yeah. So you even lay out what it is here, but I like the table of contents. I think stuff like this, it really helps guide people because everyone's trying to do this.
This structure also makes it super cheap to put new content into the repository to smear both the humans and the agents. You you reinvented skills.
One big agent and Skills from first principles. Oh, skills did not exist when we started doing this. You you have a short one one hundred line overall table of contents, and then you have little skills.
Right? Core beliefs, MD, tech tracker. Yeah.
Yeah. The skill is over.
this is basically a tiny little scaffold, like a markdown table, which is a hook for Codex to review all the business logic that we have defined in the app, assess how it matches all these documented guardrails, and propose follow-up work for itself. Before beads and all these ticketing systems, we were just tracking follow-up work as notes in a markdown file, which we could spawn an agent on a cron to burn down. There's this really neat thing that, like, the models fundamentally crave text.
So a lot of what we have done here is figure out ways to inject text into the system. Right? When we get a page because we're missing a timeout, for example, I can just add codecs in Slack on that page and say, I'm gonna fix this by adding a timeout.
Please update our reliability documentation to require that all network calls have timeouts. So, I have not only made a point in time fix, but also like durably encoded this process knowledge around what good looks like. Yeah.
And we give that to the root coding agent as it goes and does the thing, but you can also use that to distill tests out of, or a code review agent, which is pointed out the same things to narrow the acceptable universe of the code that's produced. I think one of the concerns I have with that kind of stuff is you think you're making the right call by making it's persisted for all time across everything Yes. But then you didn't think about the exceptions that you need to make.
Right? And then you have to roll it back. Part of it is also Sometimes it can follow instructions too.
It's somewhat a skill. Right? So it determines when it uses the tools.
Right? Like, it's not like it'll run at every call. It'll determine when it wants to check quality score.
Right? Yeah. And we do, in the prompts we give these agents, allow them to push back.
When we first started adding code review agents to the PR, it would be Codec CLI locally writes the change, pushes up a PR. On those PR synchronizations, a review agent fires. It posts a comment, we instruct Codex that it has to at least acknowledge and respond to that feedback.
And initially, the Codex driving the code author was willing to be bullied by the PR reviewer, which meant you could end up in a situation where things were not converging. So Yeah. Had He's just a thrash.
We had to add more optionality to the prompts on both of these things. Right? The reviewer agents were instructed to bias toward merging the thing, to not surface anything greater than a p two in priority.
We didn't really define p two, but we gave it You did define p two? We gave it a framework within which to score its output. And then Greater than p zero is worse.
Right? Yes. The secret p two is sort good.
P zero is you will the code base if you merge this thing. Right? But also on the code authoring agent side, we also gave it the flexibility to either defer or push back against review feedback.
Right? It happens all the time. Right?
Like, I happen to notice something and leave a code review, which could blow up the scope by a factor of two. I usually don't mean for that to be addressed exactly in the moment. It's more of an FYI.
File it to the backlog, pick it up in the next fix it week sort of thing.
the coding agents are gonna bias toward what they do, which is following instructions. Yeah. I do wanted to check-in on a couple things.
Right? Like Sure. All the coding review agent, it can merge autonomously.
I think that's something that a lot of people are comfortable with. And you have a list here of how much agents do. They do products, code and tests, CI configuration and release tooling, internal dev tools, documentation, eval harness, review comments, scripts that manage the repository itself, production dashboard definition files, like everything.
Yes. And so they're just all churning at the same time. Is there, like, record that that any human on the team pulls to stop everything?
Because we are building a native application here, we're not doing continuous deploy. So there is still a human in the loop for cutting the release branch. I see.
a blessed human approved smoke test of the app before we promote it to distribution, these sorts of things. So you're working on the app, you're not building, like, infrastructure where you have, like, nines of reliability, that kind of stuff? That's correct.
That's correct. Okay. And also, like, full recognition here that all of this activity took in a completely greenfield repository.
There's should be no Sure. Sure. That this applies generally to This is a production thing you're gonna ship to customers.
Of course. Yeah. Of course.
So this is real. And, like, one of the things there is you mentioned you started this as a repo from scratch. The onboarding first month or so was pretty it was like working backwards.
Right? And then you have to work with the system. And now you're at that point where, you know, you're very autonomous.
I'm curious, like, okay, so what how human in the loop is it? So what are the bottlenecks that you wish you could still automate? And part of that is also like, where do you see the model trajectory improving and offloading more human in the loop?
We just got 5.4. It's a really good Fantastic model, by the way.
Yeah. Yeah. It's the first one that's merged top tier coding.
So it's codec level coding and reasoning. So general reasoning both in one model. So And computer And now we're Now we're the five four.
I I might be out of a job.
Oh my god. Oh. I know.
You just gave me an idea for a completely AI newsletter that five four could do. Yeah. I get it now.
This sort of thing is just one example of closing the loop. Right? Like Yeah.
The dashboard thing you mentioned, we have Codecs authoring the JSON for the Grafana dashboards and publishing them, and also responding to the pages, which means when it gets the page, it knows exactly which dashboards are defined and what alerts. What alert was triggered by which exact log in the code base because all of this stuff is collated together. It has to own everything.
Yes. Yeah. Yeah.
And it means that if we have an outage that did not result in a page, it has the existing set of dashboards available to it, it has the existing set of metrics and logs, and can figure out where the gaps in the dashboard are, or in the underlying metrics, and fix them in one go. In the same way, you would have a full stack engineer be able to drive a feature from the back end all the way to the front end.
working for a way that the model wants the software to be written. It's like less human legible for better code legibility, agent legibility. How do you think that affects broader teams?
So one at OpenAI, do you liaison like this is how software should be written? Like, can imagine, say you join a new team with this methodology, this mindset. There's ways that teams do code review, teams write code, like teams are structured, and a lot of it is for human legibility.
Should we all swap? Like, how does this play back one broader into OpenAI and then like broader into the software engineering? Is it like teams that pick this up will have it's pretty drastic.
Right? You have to make a pretty big switch.
Should they just full send? Yeah. The mindset is very much that I'm removed from the process.
Right? I can't really have deep code level opinions about things. It's as if I'm group tech leading a 500 person organization.
Yeah. Like, it's not appropriate for me to be in the weeds on every PR. This is why that post merge code review thing is like a good analog here.
Right? Like, I have some representative sample of the code as it is written. I have to use that to infer what the teams are struggling with, where they could use help, where they're already moving quickly, and I can pivot my focus elsewhere.
Yeah. So I don't really have too many opinions around the code as it is written. I do, however, have a command base class, which is used to have repeatable chunks of business logic that comes with tracing and metrics and observability for free.
And the thing to focus on is not how that business logic is structured, but that it uses this primitive because I know that's gonna give leverage by default. Yeah. Yeah.
Back to that sort of systems thinking. And you have part of that in your blog post, enforcing architecture and taste, how you set boundaries for what's used. There's also a section on redefining engineering and stuff.
But, yeah, it's just it's interesting to hear. And as the models have gotten better, they have gotten better at proposing these abstractions to unblock themselves, which again lets me move higher and higher up the stack to look deeper into the future on what ultimately block the team from shipping. Yeah.
You mentioned so you this is primarily a it's like a 1,000,000 line of code based electron app, but it manages its own services as well. So it's like a back end for front end type thing. We do have a back end in there, but that's hosted in the cloud.
This sort of structure is actually within the separate main and renderer processes within the Electron. That's just how Electron works. Yeah.
Of course.
MVC style decomposition with the same level of rigor, which has been very fun. I have a fun pun. This is like a tangent.
MVC is model view controller, and any sort of full stack web dev knows that. But my up AI native version of this is model view claw.
the harness. That's right. That's right.
I do think that there is an interesting space to explore here with codecs, the harness as part of building AI products. Right? There's a ton of momentum around getting the models to be good at coding.
We've seen big leaps in, like, the task complexity with each incremental model release where if you can figure out how to collapse a product that you're trying to build, a user journey that you're trying to solve into code, it's pretty natural to use the Codex harness to solve that problem for you.
just communicate in prompts to let the model cook. Yeah. It's been very fun.
And it's also a very engineering legible way of increasing It's fantastic. Right? Just give just give the model scripts.
The same scripts you would already build for yourself. Yeah. Yeah.
So for listeners, this is Ryan saying that software engineering or coding agents will eat knowledge work, like the non coding parts that you would normally think, oh, you have to build a separate agent for it. No. Start with coding agent and go out from there, which OpenCore has.
Right? It's Yes. Pie under the hood.
Yes. Basically define your task in code. Everything is a coding agent.
By way, since I brought it up, it's probably the only place we bring it up. Is there any OpenClaw usage from you? Any No.
No. Not for any. I don't have any spare Mac minis rattling around my house.
You can afford it. No. I just I'm curious if it's changed anything in OpenAI yet, but it's probably early days.
And then the the thing I wanna pull on here is, like, you mentioned ticketing systems and you mentioned PRs, and I'm wondering if both those things have to go away or be reinvented for this kind of coding. So the git itself and is, like, very hostile to multi agents. Yeah.
We make very heavy use of WorkTrees. But, like, even then, like, I just did a dropped a podcast yesterday with Cursor saying then they said they're getting rid of WorkTrees because it still has too many merge conflicts.
but go ahead. The models are really great at resolving merge conflicts. Yeah.
And to get to a state where I'm not synchronously in the loop in my terminal, I almost don't care that there are merge conflicts. Yeah. Disposable.
Yeah. We invoke a dollar land skill and that coaches codex to push the PR, wait for human and agent reviewers, wait for CI to be green, fix the flakes if there are any, merge upstream if the PR comes into conflict, wait for everything to pass, put it in the merge queue, deal with flakes until it's in main. And this is what it means to delegate fully.
Right? This is, in a very large model, probably a significant tax on humans to get PRs merged. But the agent is more than capable of doing this, and I really don't have to think about it other than keep my laptop open.
Yeah.
I used to be much more of a control freak, but now I'm like, yeah, actually, you could do a better job of this than me Yeah. With the right context. Yes.
Anything else in Harness Engine general? Just this piece.
I think one thing that I maybe didn't make super clear in the article that I heard on Twitter as an interesting That threw them onto them. What's the chatter and then what's your response? Ultimately, all the things that we have encoded in docs and tests and review agents and all these things are ways to put all the nonfunctional requirements of building high scale, high quality, reliable software into a space that prompt injects the agent.
We either write it down as docs, we add links where the error message is told how to do the right thing. So the whole meta of the thing is to basically tease out of the heads of all the engineers on my team what they think good looks like, what they would do by default, or what they would coach a new hire on the team to do to get things to merge. And that's why we pay attention to all the mistakes mistakes that the agent makes.
Right? This is code being written that is misaligned with some as yet not written down nonfunctional requirement.
Sorry. What did the online people misunderstand?
Or No. What do you Somebody just literally said that. Was like, oh, yeah.
Okay. This is the thing. This is what I was doing.
You agree with it. Yeah. I see.
Interesting.
and giving it to Pi or Codex and say, make my repo this. You've achieved all recursions. And it was wildly effective.
Really? It was wildly effective. Just actually is something I tried with five four yesterday.
I I didn't have that much time. I was like out speaking at something. And this is one of my things.
Was like, okay. I have this article. Can we just scaffold out what it would be like to run this?
And I I did it first as that. And then I was like, okay, let me take another little side repo and say, okay, if I was to fully automate this like this, because I haven't written a line of code. It's like a full set.
Right? The side thing I'm doing voice TTS. I'm just like slopping out whatever.
It's nothing production. I'm like, how would I make this like this? And it's actually, like, a really good way.
It's, like, a good way to learn what could be changed, what could be like it's just a good analyzing. Right? You give it all the codes.
You give it all the context. You give it the article, and it walks you through it very well. That's right.
That's right. I guess one more thing before we go to Symphony is I wanted to cover Brett Taylor's response. We had him on the show.
He is your chairman, which is wild. Yeah.
That he's reading your articles as well and, like, getting engaged in it. He says software dependencies are going away, basically. They can just be, like, vendored Yes.
Response.
A 100%. 100% agree. You still have PromQL.
You still pay Datadog. You still pay Temporal. Thank you.
Yep. The level of complexity of the dependencies that we can internalize is, I would say, low medium right now. Just based on model capability What is the what is medium?
I would say like a a couple thousand line dependency is a thing that we could in house no problem God. In an afternoon of time. One neat thing about it is like probably most of that code you don't even need.
Like, by in housing and abstraction, you can strip away all the generic parts of it and only focus on what you need to enable the specific thing Yes. You're building. I've been calling this the end of bullshit plugins.
Yeah. Because it's so much when I publish an open source thing, I wanna accept everything. Be liberal, I wanna accept.
This is Postel's Law. But that means there's so much bloat. There's so much overhead.
One other neat thing about this too is when we deploy Codex security on the repo, it is able to deeply review and change the internalized dependencies in a much lower friction way than it would be to, like, push patches upstream, wait for them to be released, pull them down, make sure that's compatible with all the transitives I have in my repo and things like that. So it's also much lower friction to internalize some of these things if code is free because the tokens are cheap sort of thing. I think, like, the only argument I have against this is basically scale testing, which obviously the larger pieces of software like Linux, MySQL, he calls up even the data logs and temporals.
And then maybe security testing where Yes. Classically, I think is it Linus Torvales who said the security open source is the best disinfectant? Many Is.
Many Iss. And if in line your dependencies and code them up, you're gonna have to relearn mistakes from other people that Yep. Yep.
And to internalize that dependency, you're back to zero, and you have to start reassembling all those bits and pieces to Yeah. Have high confidence in the code as it is written. Yeah.
by Codecs,
including internal tooling. Right? So internal tooling, like, when you're visualizing what's going on, it's writing it forward to us.
Yeah. I'm building internal tooling for AI now, and, like, I just show them off and they're like, how long did you spend? And I that is spending time.
I just prompted it. Very funny story here. Yeah.
Go ahead. We had deployed our app to the first dozen users internally.
I had some performance issues, so we asked them to export a trace for us. Get a tarball, gave it to our on call engineer, and he did a fantastic job of working with Codex to build this beautiful local DevTool Next. Js app that you drag and drop the tarball in, and it visualizes the entire trace.
Oh. It's fantastic. Took an afternoon.
But none of this was necessary because you could just spin up Codex and give it the tarball and ask the same thing and get the response immediately. So in a way, optimizing for human legibility of that debugging process was wrong. It kept him in the loop unnecessarily when instead he could have just let Codex cook for five minutes and gotten the same Yeah.
You're if I your instincts here, this is how we used to do it or this is how I would have used to solve it. Yeah. In this local observability stack, like, sure, you can deploy Jaeger to visualize the traces, but I wouldn't expect to be looking at the traces in the first place because I'm not gonna write the code to fix them.
Yeah. So basically, there needs to be like this kind of house stack and owning the whole loop. I think that is very well established and it sounds like you might be like sharing more about that in the future.
Right? Yeah. I I think we're excited to do we're gonna talk about Symphony in a little bit, but like the way we distribute it as a spec, which I think folks are calling ghost libraries on Twitter.
This is like a such a cool name. It does mean it becomes much cheaper to share software with the world. Right?
You define a spec, how you could build your own, specifying as much as is required for a coding agent to reassemble it locally. The flow here is very cool. Like, we have taken all the scaffolding that has existed in our proprietary repo, spun up a new one, ask Codex with our repo as a reference, write the spec.
We tell it spin up a TMux, spawn a disconnected Codex to implement the spec, wait for it to be done, spawn another codex and another TMux to review the speccom or review the implementation compared to upstream, and update the spec. So it diverges less.
with high fidelity able to reproduce the system as it is. It's fantastic. And you're basically you're not really adding any of your human bias in there.
Right? That's correct. A lot of times people write a spec and be like, okay, think it should be done this way and you'll riff on something and it's no.
They didn't could've just handled it. Like, you're still scaffolding in a sense. Right?
I want it done this way. It can determine that spec better. That's right.
That's right. Part of me I'm I'm been working a lot on evals recently and part of me is wondering if an agent can produce a spec that it cannot solve. Is it always capable of things that it can imagine or can imagine things that it is impossible to do?
or established or new. Right? And I think things that are hard and new is still something that the models need humans.
Yeah. Drive. Yeah.
But I think those other quadrants are largely solved, given the right scaffold and the right thing that's gonna drive the agent to completion. It's crazy that this solved. But it means that the humans, the ones with limited time and attention, get to work on the hardest stuff.
Like, the problems where it's pure white space out in front, or like the deepest refactorings where you don't know what the proper shape of the interfaces are. And this is where I wanna spend my time because it lets me set up for the next level of scale. Yeah.
Yeah. Amazing. Let's introduce Symphony.
I think we've been mentioning it every now and then. Elixir, interesting option. Yeah.
Yeah. I'm not Again, like, the Elixir manifestation here is just a derivative. Is it a model chosen?
Yeah. Yeah. Yeah.
And it chose that because the process supervision and the gen servers are super amenable to the type of process orchestration that we're doing here. You are essentially spinning up little daemons for every task that is in execution and driving it to completion, which means the model gets a ton of stuff for free by using Elixir and the Beam.
and I think most people are not operating at that scale of concurrency where you need that, but it is a good mental model for resumability and all those things, and these are things I care about. But tell me the story the origin story of Symphony, what do you use it for? Is this how did it form?
Maybe any abandoned paths that you didn't take?
we were at about three and a half PRs per engineer per day. So it was before five two came out. In the January, everyone gets back from holiday.
With 5.2 and no other work on the repository, we were up in the five to 10 PRs per day per engineer. And I don't know about y'all, but, like, it's very taxing to constantly be switching like that.
Like, I was pretty tapped out at the end of the day. Again, where are the humans spending their time? They're spending their time context switching between all these active TMUX pains to drive the agent forward.
Yeah. No way. Yeah.
So let's again build something to remove ourselves from the loop. And this is what a frantic sprinted after here to find a way to remove the need for the human to sit in front of their terminal. So a lot of experimentation with dev boxes and automatically spinning up agents.
Like, it seems like a fantastic end state here where my life is beach. I open Litter twice a day and say yes, no to these things. Yeah.
And this is again a super, super interesting framing for how the work is done because I become more latency insensitive. I have way less attachment to the code as it is written. Like, I've had close to zero investment in the actual authorship experience.
So if it's garbage, I can just throw it away and not care too much about it. In Symphony, there's this like rework state where once the PR is proposed and it's escalated to the human for review, it should be a cheap review. It is either mergeable or it is not.
And if it's not, you move it to rework, the Elixir service will completely trash the entire work tree and PR and start it again from scratch. And this is that opportunity again to say, why was it trash? Right?
What did the agent Yeah. Do that was fix Yeah.
That before moving the ticket to So people in progress again. Yeah. Why is this not in the Codex app?
I guess it's you guys are ahead of Codex app. Yeah.
the way the team has been working is basically to be as AI pilled as possible and spread ahead. And a lot of the things we have worked on have fallen out into a lot of the products that we have. Like, we were in deep consultation with the Codex team to have the Codex app be a thing that exists.
Right? To have skills be a thing that Codex is able to use. So we didn't have to roll our own to put automations into the product.
So all of our automatic refactoring agents didn't have to be these hand rolled control loops. It has been really fantastic to be, in a way, unanchored to the product development of Frontier and Codecs, and just very quickly try to figure out what works. And then later find the scalable thing that can be deployed widely.
It's been a very fun way to operate. It's certainly chaotic. I have lost track very often of what the actual state of the code looks like because I'm not in the loop.
There was one point where we had wired Playwright directly up to the Electron app with MCP. MCP is I'm pretty bearish on because the harness forcibly injects all those tokens in the context, and I don't really get a say over it. They mess with auto compaction.
The agent can forget how to use the tool. There's probably only, what, three calls in Playwright that I actually ever wanna use, so I pay the cost for a ton of things. Somebody vibed a local daemon that boots Playwright and exposes a tiny little shim CLI to drive it.
And I had zero idea that this had occurred. Because to me, I run codex and it's able to Yeah. Drive Like no knowledge of this at all.
So Uh-huh. We have had, like in human space, to spend a lot of time doing synchronous knowledge sharing.
fan out the understanding of the current state. Yeah. Was gonna say, this is good for a single human multi agent, but multi human multi agent is a whole like poly explosion of stuff.
Yeah.
like, 10,000 engineer level architecture in the app because we have to find ways to carve up the space so people are not trampling on each other. Sorry. I don't get the 10,000 thing.
Did I miss that? The structure of the repository is like 500 MPM packages. It's like architecture to the access for what you would consider I think normal for a seven person team.
But if every person is actually like 10 to 50, then the, like, numbers on being super super deep into decomposition and sharding and, like, proper interface boundaries make a lot more sense. Yeah. To me, that's why I talked about micro front ends and I annexes from that world.
But cool. And it's just coming back to to to this.
so much work going going through this. Is this enough? Is this, like, any moments?
It'll be interesting to see, like, where okay. So right now, you pick linear as your issue tracker. Right?
Or it's like a is it actually linear? This is actually linear. Linear?
Oh, that's linear. It's linear. Oh, I know I never looked at The demo video I had to download to run.
I because I'm a Slack Maxie, but yeah. Linear linear is also really good. Yes.
We do make a good use of Slack. We we fire off Codex to do all these Like, we should low tier Slackity fix ups, the things that, like, sync that knowledge into the repository. It's super cheap.
Yeah. Just do it in Codex. My biggest plug is OpenAI needs to build Slack.
You need to own Slack, build yours, to turn this into Slack. I did read don't know how to You did. Yeah.
that we want these agents to do economically valuable work, which is, like, this is the mission. Right? We want AI to be deployed widely to do economically valuable work, then we need to find ways for them to naturally collaborate with humans, which means collaboration tooling, I think, is an interesting space to explore.
Yeah. Totally. Yeah.
GitHub Slack, Linear. Yeah. That was kinda my thing.
Okay. Where do we see right now, Codex has started Codex model, then CLI. Now there's an app.
App can let me shoot off multiple Codexes in parallel, but there's no great team collaboration for Codex. And it seems like your team had some say into what comes out. Right?
So you talk to them. Codex kind of was a thing from there. If you guys are on the bound, what stuff that, like, you might not focus on, but what do you expect other people to be building?
Right? So people that are, like, five x, 50 x ing, should you build stuff that's, like, very niche for your workflow, for your team? Should it be more general so other people can adopt this or a niche there?
Because because part of it is just, okay, is everything just internal tooling? Do we have everything our own way? Like, the way our team operates has our own ways that we like to communicate, or is there a broader way to do it?
Is it something like a issue tracker? Just thoughts if you wanna riff on that. I think TBD.
We have not figured this out in a general way. I do think that there is leverage to be had in making the code and the processes as much the same as possible. If you think that code is context, code is prompts, it's better from the agent behavior perspective to be able to look in a package in directory x y z, and it not to have to page so deeply into directory ABC, because they have the same structure, use the same language, they have the same patterns internally.
And that same, like, leverage comes from aligning on a single set of skills that you're pouring every engineer's taste into to make sure that the agent is effective. So, like in our code base, we have, I think, six skills. That's it.
And if some part of the software development loop is not being covered, our first attempt is to encode it in one of the existing set of skills, which means that we can change the agent behavior more cheaply than changing the human driver behavior. Yeah.
Have you ever have you experimented with agents changing their own behavior? We do. Yeah.
A parent agent changing a sub agent's behavior or something like that.
bits for skill distillation. So, for example, there's one neat thing you can do with Codex, which is just point it at its own session logs to ask it to tell you how you can use the tool belt better? It's like Introspection.
You ask it to do things better. So Organize this session better. What skills should I have?
Yeah. I like the modification of you can do just do things to you can just ask agent to do things. Yeah.
You could just codex things. This is like a this like a silly emoji that we have. Right?
You can just codex things. You can just prompt things. It's glorious future where you live in.
But okay. You can do that one on one, but we're actually slurping these up for the entire team into Blob Storage and running agent loops over them every day to figure out where as a team can we do better, and how do we reflect that back into the repository Yeah. Though everybody benefits from everybody else's behavior for free.
Same for, like, PR comments. Right? These are all feedback that means the code as written deviated from what was good.
A PR comment, a failed build, these are all signals that mean at some point, the agent was missing context. We gotta figure out how to Yeah. Slurp it up and put it back in the reboot.
By way, I do this exactly. Right? I used to when I use Cloud Code for mortgage work.
Cloud Code Work is, a nice product. Right? Yes.
And and I I think you would agree. I always have it tell me what do I do better next time, and that's the metaprogramming reflection thing. So almost think, like, you have six reflection extraction levels in Symphony.
Almost like the zeroth layer so the six levels are policy, configuration, coordination, execution, integration, observability. We've talked to about a couple of these. But the zeroth layer is like the okay.
Are we working well? Can we improve how we work? Yes.
Can I modify my own workflow with RDMD or something? I don't know.
Of course. Yeah. Of course, you can.
Like, this thing is also able to cut its own tickets because we give it full access. Yeah. Make it a ticket to have it cut tickets, you can put in the ticket that you expected to file as on follow-up work.
Like Self modifying. Yeah. Yep.
Put don't put the agent in a box. Give the agent full accessibility over its domain. I had a mental reaction when you said don't put the agent in a box.
So I think you should put it in a box. Like, it's just that you're giving the box everything it needs. Yeah.
Contacts and tools. But we're, like, as developers, we're used to calling out to different systems, but here you use the open source things like the Prometheus, whatever, you run it locally so that you can have the full loop, I assume. Yep.
I think, like, in that You wanna minimize cloud cloud dependencies. You also wanna make sure that you think about what the agent has access to. What does it see?
Does it go back in the loop? Like, from the most basic sense of you let it see its own, like, calls traces, it can determine where it went wrong. But are you feeding that back in?
what is being outputted? Right? It can self improve a lot of these things.
It's all text. Right? My job is to figure out ways to funnel text from one agent to the other.
It's so strange. Like, way back at the start of this whole AI wave, Andre was like, English is the hottest new programming language. It's here.
It's here. Yeah. The feature is here.
A lot of okay. Like a lot of software, a lot of stuff, there's a GUI. It's made for the human.
We're seeing the evolution of CLIs for everything. Right? All tools have CLIs.
Your agents can use them well. Do we get good vision? Do we get good little sandboxes?
Like, right now, it's a really effective way. Right? Models love to use tools.
They love the best. They love to read through text. So slap a CLI, let it go loose.
That works for everything? That does. Yeah.
We've also been adapting nontextual things to that shape in order to improve model behavior in some ways. Right? We want the agent to be able to see the UI.
Agents do not perceive visually in the same way that we do. They don't see a red box. They see red box button.
Right? They see these things in latent space. So if we want Yeah.
Yeah. We have a have a thing that goes off every time we go to latent space. Ding.
Anyway, if we wanna actually make it see the layout, it's almost easier to rasterize that image to ASCII ARC and feed it in to the agent. And there's no reason you can't do both, right, to, like, further refine how the model perceives the object it's manipulating.
Cool. Could we you wanna talk about a couple more of these layers that might bear more introspection or that you have personal passion for?
the coordination layer here was a really tricky piece to get right. Let's do it. Yep.
I'm all about that, and this is temporal's core thing. This is where when we turn the spec into Elixir, where, like, the model takes a shortcut. Right?
It, like, is, oh, I have all these primitives that I can make use of in this lovely runtime that has native process supervision, which is, I think, a neat way to have taken the spec and made it more achievable by making choices that naturally map Yeah. The domain. Right?
In the same way that, like, you would prefer to have a TypeScript model repo if you are doing full stack web development. Right? Because the ability to share types across the front end and back end reduces a lot of complexity.
And because It's what GraphQL used to be. That's right. And I I don't know if it's still alive, but it's No humans in the loop here, so like my own personal ability to write or not write Elixir doesn't really have to bias us away from using the right tool for the job, which is just wild.
Love it. I love it. Yeah.
I wonder if any languages struggle more than others because of this. I feel like everyone has their own abstractions that would make sense, but maybe it might be slower, it might be more faulty where, like, you would have to just kick the server every now and then. I I don't know.
I think observability layer is really well understood. Integration layer, MCP is dead. I think all these are just like a really interesting hierarchy to travel up and down.
It's common language for people working on the system to understand. The policy stuff is really cool. Right?
Yeah.
build a bunch of code to make sure the system waits for CI to pass. It's your institutional knowledge. Yeah.
You just give it the GH CLI with some text that says CI has to pass. It makes the maintenance of these systems a lot easier. Do you think that CLI maintainers need to be do anything special for agents or just as is it's good?
Because, like, I don't think when people made the g GitHub CLI, they anticipated this happening. That's correct. The g h CLI is fantastic.
It's great. Super industry. Everyone go try g h repo create g h pull and then pull request number.
Right. G h p r like one fifty three, whatever. And then it like pulls.
Basically, my only interaction with the GitHub web UI at this point is g h p r view dash web Is that tight? Glance at the diff and be like, sure thing. Send it.
But the CLIs are nice because they're super token efficient, and they can be made more token efficient really easily. Like, I'm sure you all have seen, like, I go to BuildKite or Jenkins, and I could just get this massive wall of build output. And in order to unblock the humans, your developer productivity team is almost certainly gonna write some code that parses the actual exception out of the build logs and sticks it in a sticky note at the top of the page.
And you basically want CLIs to be structured in a similar way. Right? You're going to want a hash dash silent to Prettier because the agent doesn't care that every file was already formatted.
He just wants to know it's either formatted or not, so it can then go run a write command.
Similarly, like,
in our PMPM distributed script runner when we had one, when you do dash recursive, like, it produces a absolute mountain of text. But all of that is for passing test suites. So we ended up wrapping all of this in another script To suppress the which you can vibe The one to only output the failing parts of the test.
You make a pipe errors versus the standard send it out. I I don't know. Okay.
Alright. Whatever.
Too much thinking how to do that. The CLI I used to maintain a CLI for my company and yeah. This is, like, a course very core to my heart.
But you're vibing my job. That's right. Cool.
Any other things this is a long spec. I I appreciate that. It's got a lot of strong opinions in here.
Any other things that we should highlight? I think, obviously, you can spend the whole day going through some of these, but I do think that some of these have a lot of care or of this you might wanna tell people, hey, take this, but make it your own.
Fundamentally, software is made more flexible when it's able to adapt to the environment in which it is deployed, which means that things like Linear, or GitHub even, are specified within the spec, but not required pieces of it. There's like a more platonic ideal of the thing that you could swap in, like Jira or Bitbucket, for example. But being able to tightly specify things like the ID formats or how the RALF loop works for the individual agents, basically means you can get up and running with a fully specified system quickly that you then evolve later on.
I think we never intended for this to be a static spec that you can never change. It's more like a blueprint to get something working Starting point. Up and running Yeah.
For you then to vibe later till your heart's contented. You have, like, code and scripts in here where it's, oh. I think this is a really good prompt.
It's just a very long prompt. Fundamentally, the agents are good at following instructions, so give them instructions, and it will improve the reliability of the result. We much like the way we use Symphony, we don't want folks to have to monitor the agent as it is vibing the system into existence.
So being very opinionated, very strict around what these success criteria are means that our deployment success rate goes up. Yeah. Means we don't have to get tickets on this thing.
I think it all goes back to that, like, code of disposable. Right? Like, early on when you had CLI, it's where you'd kick off a Codex run, it would take two hours.
You would wanna monitor, okay, I'm in the workflow of just using one. I don't want to go down the wrong path. I'll cut it off and then just shoot off four.
Like, that was my favorite thing of the Codex app. Right? Just vorex it.
Like, it's okay. One of them will probably be right. One of them might be better.
Stop overthinking it. Like, my first example is probably like deep research. When you put out deep research and I'd ask it something like I asked it something about LLM, I thought it was legal or something and spent an hour, came back with a report completely all through it.
And I was like, okay. I gotta monitor this thing a bit. No.
Don't monitor it. Just you wanna build it so that it it goes the right way, you don't wanna you don't wanna sit there and babysit. Right?
You don't wanna babysit your agents.
query that you made, looking at the bad result, you probably figured out you needed to tweak your prompt Yeah. A bit. Right?
That's that guardrail that you fed back into the code base for the task, your prompt, to further align the agent's execution. Same sort of concepts apply there too. When you talk how are the customers feeling?
For Symphony, I think we have none. Right? This is a thing we have put out into the web.
Symphony's internal. Right? As long as you're happy, you're the customer.
That's right. Just what's the external view?
I'd say folks are very excited about this way of distributing software and ideas in cheap ways. For us, as users, it has again pushed the productivity five x, which means I think there's something here that's like a durable pattern around removing the human from the loop and figuring out ways to trust the output. The video that is shared here Yeah.
Is the same sort of video we would expect the coding agent to attach to the PR Yeah. That is created. Yeah.
That's part of building trust in the system. And that's to me, like, fundamentally what has been cool about building this is it more closely pushes that persona of the agent working with you to be like a teammate. I don't shoulder surf you, like, for the tickets that you work on during the week.
I would never think that I would want to do that. Yeah. I wouldn't want a screen recording of your entire session in Cursor or Claude code.
I would expect you to do what you think you need to do to convince me that the code is good and mergeable. Yep. And compress that full trajectory in a way that is legible to me, the reviewer.
Yep.
codex will absolutely sling some f f f f You can take around. It's great. Oh, if Vivint Pegg is the OG, like, god CLI.
Yeah. Swiss army chainsaw. I used to say there's a SaaS micro SaaS, let's call it, in every flag in FFmpeg.
Oh, for sure. You know what For sure. Just post it as a service, put a UI on it.
People who don't know FFmpeg will pay for it.
just popping up all over the place and getting captured and files appearing on my desktop. Like, very much felt like the future to have a thing controlling my computer for, like, actual productive use. Like, I'm just there keeping it, like, awake, jiggling the mouse every once in a while.
That's why there's some office workers do. So That they buy a mouse jiggler. That's right.
One thing I wanted to ask. Okay.
As stuff is so code is disposable, async, shoot off a bunch of agents. One question is, okay. Are you always like a extra high thinking guy?
And where do you see Spark? So five point three Spark, there's a lot of me wanting to make quick changes. I'm not gonna open up a ID.
I'm not gonna do anything, but I will say, okay. Fix this little thing. Change your line.
Change your color. Spark is great for that. But am I still the bottleneck?
Like, why don't I just let that go back and, like, just riff on that? Was there?
Spark is such a different model compared to the the extra high level reasoning that you get in these five Yeah. Three, five, four. It is a different model, different architecture, different like, it doesn't support it.
It's just It's incredibly fast. Smaller model I have not quite figured out how to use it yet, to be honest. I It's faster.
I was adapting it to the same sorts of tasks I would use x high reasoning for. Yeah. I know.
And it would blow through three compactions before writing a line of code. And that's another big thing with 5.4.
Right? Million coking contacts. Yes.
It's fantastic. Huge in AgenTix. Right?
Like, you can just run for longer before you have to compact. The more tokens you can spend on a task before compacting, like, the better you'll do. That's right.
That's right. I'm not sure how to deploy Spark. I think your intuition is right, though.
It's very great for spiking out prototypes, exploring ideas quickly, doing those documentation updates.
It is fantastic for us in taking that feedback and transforming it into a Lint where we already have good infrastructure for ES Lints in the codebase. These sorts of things, it's great at, and it allows us to unblock quickly doing those, like, antifragile healing tasks in the Yeah.
Makes sense. So you're pushed you guys are pushing models to the freaking limit. What can current models not do well yet?
They're definitely not there on being able to go from new product idea to prototype. Single one shot. This is where I find I spend a lot of time steering is translating end state of a mock for a net new thing.
Right? Thing no existing screens into product that is playable with. Similarly, while this has gotten better with each model release, like, the gnarliest refactorings are the ones that I spend my most time with.
Right? The ones where I am interrupting the most. The ones where I am now double clicking to build tooling to help decompose monoliths and things like that.
This is a thing I only expect to get better. Right? Over the course of a month, we went from the low complexity tasks to like low complexity and big tasks in both these directions.
So this is what it means to not bet against the model. Right? You should just expect that it is going to push itself out into these higher and higher complexity spaces.
Yeah. So the things we do are robust to that. It just basically means I'll be able to spend my time elsewhere and figure out what the next bottleneck is.
I do think it's also a bit of a different type of task. Right?
working with code bases, but companies like Lovable, Bolt, Replit, they solve a very different problem scaffold of zero to one. Right? Idea to product.
And it's there there are people working on that. Models are also pushing, like, step function changes there. It's just different than the software engineering agents today.
Right?
Like I said, the model is isomorphic to myself. The only thing that's different is figuring out how to get what's in here into context for the model. And for these white space sort of projects, I myself, I'm just not good at it.
Which means that often over the agent trajectory, I realized the bits that were missing, which is why I find I need to have the synchronous interaction. And I expect with the right harness, with the right scaffold, that's able to tease that out of me or refine the possible space, right, to be super opinionated around the frameworks that are deployed, or to put a template in place. Right?
These are ways to give the model all those nonfunctional requirements, that extra context to anchor on and avoid that wide dispersion of possible outcomes.
Thank you for that. I wanted to talk a little bit about Frontier Yeah. Sure.
Overall.
view it. Is there one product or is there many? I can't speak to the full product road map here, but what I can say is that Frontier is the platform by which we want to do AI transformation of every enterprise and from big to small.
And the way we wanna do that is by making it easy to deploy highly observable, safe, controlled, identifiable agents into the workplace. We want it to work with your company native I'm stack. We want it to plug into the security tooling that you have.
tools that you use. So you're just gonna be stripping specs.
Right? We expect that there will be some harness things there. Agents SDK is a core part of this to enable both startup builders as well as enterprise builders to have a works by default harness that is able to use all the best features of our models from the shell tool down to the codex harness with file attachments and containers and all these other things that we know go into building highly reliable, complex agents.
We wanna make that great, and we wanna make it easy to compose these things together in ways that are safe. For example, right, like the GPTOSS safeguard model, for example. One thing that's really cool about it is it ships the ability to interface with a safety spec.
Safety specs are things that are bespoke to enterprises. We owe it to these folks to figure out ways for them to instrument the agents in their enterprise to avoid exfiltration in the ways they specifically care about, to know about their internal company code names, these sorts of things.
mostly working by default for folks is the space we are trying to explore here. Yeah. And this is the snowflakes of the world just need this.
Right? Yeah. Brexit of the world, stripes.
Yeah. Makes sense. I was gonna go back to your I think the demo videos that you guys had was pretty illustrative.
It's like also to me an example of very large scale agent management. Yes.
you can die dig down to the individual instance and see what's going on. Yes. Of course.
But who's the user? Is it is it like the CEO, the CTO, CIO, something like that? At least was my personal opinion here.
The buyer that we're trying to build product for here is one, an employees who are making productive use of these agents. Right? That's gonna be whatever surfaces they appear in, the connectors they have access to, things like that.
Something like this dashboard is for IT, your GRC and governments folks, your AI innovation office, your security team. Right? The stakeholders in your company that are responsible for successfully deploying into the spaces where your employees work, as well as doing so in a safe way that is consistent with all the regulatory requirements that you have and customer attestations and things like that.
So it is a iceberg beneath the actual end It's great. Yeah.
I guess, layer in the UI is like going down the layer of extraction in terms of the agent. Right? Yep.
Yeah. Yeah. I think it's good.
Yeah.
not only for from like a security perspective, but also from like someone who is accountable for developing skills.
what's actually in the data warehouse. Yeah. Semantic layer Yes.
Type things. I was briefly part of that that world. Is this all set?
I don't know. It's actually really hard for humans to agree on what revenue is. Yes.
Yes. What is what is an active user? There's what?
Five data scientists in the company that have defined this golden They all get from different yeah. And no. And there's also internal politics.
Yes. As to attribution of I'm marketing, I'm responsible for this much, and sales is responsible for this much, and they all add up to more than a 100. And I'm like, you guys have different definitions.
Yeah. And if you're a startup, everything is ARR. So I think that's cool.
Oh, you guys blogged about this. Okay. I didn't see this.
Yeah. Is this the same thing? I I don't know.
This is what you're referring to? Yes. Okay.
We'll send people to read this. This is our data agent TSL. Well, I've gone really into this one.
Yeah. I I don't know if you're you have any highlights. I I don't know.
In general from the point of this, lots of good things to read. Yeah. Yeah.
Lot lots of homework for people. No. But, like, data as the feedback layer, you need to solve this first in order to have the product's feedback loop closed.
That's right. So for the agents to understand. And this is not something that humans have not solved this.
Like in This is how you build Oh, yeah. Artists that do more than coding. Right?
Yeah. Yeah. To actually understand how you operate the business Yeah.
what revenue is, what your customer segments are. Yeah. What your product lines are.
Like, one thing that's in looping back to the code base that we described here for harnessing, one thing that's in core beliefs md is who's on the team, what product we're building, who our end customers are, who our pilot customers are, what the full vision of what we want to achieve over the next twelve months is. These are all bits of context that inform how we would go about building the software. Oh my god.
So we have to give it to the agent too.
I'm guessing that stuff is like pretty dynamic and it changes over time too. Right? Like, part of it was it's not just a big spec.
You have it as one of the things and it will iterate.
One thing that I think is gonna break your mind even more is we have skills for how to properly generate deep fried memes and have riagi culture in Slack because with the Slack ChatGPT app that you're able to use in Codex, like, I can get the agent to shitpost on my behalf. Oh, I saying. It's just it's part of the theme.
Humor is part of AGI. Is it funny? It is pretty good.
Yeah. Okay. Yeah.
It's pretty good at making me proud. There's a lot of I think humor is like a really hard intelligence test. Right?
It's like you have to get a lot of context into like very few words. This is why Make reference to why five four is such a big uplift for our Right. The meme lore is it's the meaning.
Yeah. For sure.
Alright. Yeah. Yeah.
It's very cool. So five working two plus. That's all that's all the takeover.
Yeah. Maybe maybe when y'all are done here today, ask Codecs to go over your coding agent sessions and to roast you. Love it.
I'll give it a shot. I'll give it a shot. Just coming back to the the final point I wanted to make is Okay.
Yeah, I think that there are there are multiple other like, you guys are working on this, but this is a pattern that every other company out there should adopt Yes. Regardless of whether or they work with you. To me, this I I saw this.
I was like, fuck. Every company needs this. This is multiple business what it takes to get Yeah.
People to yes. Yeah. Actually realize the benefits Yes.
And distribute the energy out there. And it's it it I think it sounds boring to people like, oh, that's for safeguards and whatever, but I think you to handle agents at scale like you're envisioning here I don't know if it's like a real screenshot or like a demo, but this is what you need. This is original my original sort of view of what Temporal was supposed to be, that you've built this dashboard and you basically have every long running process in the company in one dashboard and that's it.
That's alright. Yeah. I think it's pretty customized towards every enterprise.
Right? Like, you care about different things. There's a lot of customization, There'll be multiple unicorns just doing this as a service.
I don't know. I'm, like, very frontier pilled, if you can tell. Amazing.
Love it. It it only clicked because, obviously, this came out first, then Harness Eng, then Symphony. And it only clicked for me that, like, this is actually the thing you ship to do that.
Yeah. Yeah.
and the building blocks themselves are part of the product. Right? The ability to steer, revoke authorization if a model becomes misaligned, like all of this is accessible through Frontier.
And there's gonna be a bunch of stakeholders in the company that have the things they need to see in the platform to get to yes.
do the widespread deployment. That's the fun part. Yeah.
I'm also calling back to there's this like levels of AGI. I don't know if OpenAI is still talking about this, but they used to talk about five levels of AGI. And one of it was like, oh, it's like an intern coding software engineer patient.
and this is it. That's right. Like, this this is level four or five.
I can't remember which which level, but it's somewhere along that path was this. You know how I mentioned that my team is having fun sprinting ahead here, and we do this thing where we're collecting all the agent trajectories from codex to slurp them up and distill them. This is what it means to build our team level knowledge base.
I happen to reflect it back into the code base, but it doesn't have to be that way. And it doesn't have to be bound to just codex. I want Chatuchi BT to also learn our meaning culture and also the product we are building and how, so that when I go ask it, it also has the full context of the way I do my work.
And I'm super excited for Frontier to enable this. Yeah. Amazing.
say when they see you do this? Like, you have a lot of feedback, obviously. You have a lot of usage.
You have a lot of trajectories.
I don't I don't imagine a lot of it's useful to them, but some of it is. When you have this too, you deploy a billion tokens of intelligence a day, and this was this was at the beginning of 2096. You're, you know, cooking.
Yeah. There's this fundamental tension, which I think you have talked about, between whether or not we invest deeper into the harness or we invest deeper into the training process to get the model to do more of this by default. Yeah.
And I think success for the way we are operating here means the model gets better taste because we can point the way there. And none of the things we have built actively degrade agent performance, because really all they're doing is running tests. And like running tests is a good part of what it means to write reliable software.
If we were building an entire separate Rust scaffold around codecs to restrict its output, that I think would be, like, additional harness that would be prone to being scrapped. But Yeah. Yeah.
If instead we can build all the guardrails in a way that's just native to the output that codecs is already producing, which is code, I think no friction with how the model continues to advance.
like, just good engineering, and that's the whole point. Yeah. And so I've had similar discussions with research scientists where the RL equivalent is on policy versus off policy.
Yeah. And you're basically saying that you should build an on policy harness, which is already within distribution and you modify it from there. But if you build it off policy, it's not that useful.
That's right. Super cool. Any important thoughts?
Any things that we haven't covered that we should get it get out there?
absolutely ship relentlessly. This is one of our core engineering values, ship relentlessly, and they the team there embodies it to an extreme degree. Yeah.
five three and then Spark and five four come out within what feels like a month is just a phenomenally fast. This is exactly a month ago. It five three and yesterday it was five four.
Yeah. I mean, is do we have every month now? Is five five nicely?
Can't say that. The poly markets would be very upset. I think it's interesting that it's also correlated with the growth.
They announced this 2,000,000 users, but, like, almost don't care about Codex anymore. This is it. This is the gay man.
It's like coding cool, soft, Like, knowledge work. That's right. This is the thing to chase after.
Yeah. And this is one of the things that my team is excited to support. Get the whole, like, self hosted harness thing working, which you have done and, like, the rest of us are trying to figure out how to catch up, but then do things.
You know what's right with it? Do things. That's right.
You can just do things. That's the line for the episode.
That's it. Any other call to actions? You're based in Seattle, your team, I'm guessing.
New Bellevue office? New Bellevue office. We just had the grand opening yesterday as of the recording date, which was fantastic.
Beautiful building. Super excited to be part of the Bellevue community building the future in Washington. And I would say that there is lots of work to be done in order to successfully serve enterprise customers here in Frontier.
We are certainly hiring. And if you haven't tried the Codex app yet, please give it a download. We just passed 2,000,000 weekly active users growing at a phenomenally fast rate, 25% week over week.
Peace. Come join us.
Yes. And I think that's an interesting my my final observation, OpenAI is a very San Francisco centric company. I I know people who have been who turned down the job or didn't get the job because they didn't wanna move to SF.
And now they just don't have a choice. You have to open to London. You have to open to Seattle.
And I wonder if that's gonna be a shift in the culture. Obviously, you can't say, but I was one of the first engineering hires out of our Seattle office. So Seattle's very natural.
Its success has been part of what I have been building toward, and it is it has grown quite well. Right?
durable products and lines of business that are built out of there, Ton of zero to one work happening as well, which is the core essence of the way we do applied AI work at the company to sprint after it new to figure out where we can actually successfully deploy the models. Yeah. Yes.
100%. We also have a New York office too that has a ton of engineering presence.
Yeah. Exact exactly. That's these are my road maps for AIE.
Wherever people hire engineers, I will go. That's right. As around So the cool office too in New York is the old RAI Building, I believe, the RAI office.
It's just no. You will never be as big. New York is you can't get the size of office that they need.
The New York Seattle has a very Office.
Mad Men vibe. It's beautiful. The Bellevue one is very green, gold fixtures, very Pacific Northwest.
It's very cool. This is a vibe. It'll be localized.
Yeah. A lot of people are, like, there for people like New York. They wanna be in New York.
Right? Yeah. Yeah.
We have a fantastic workplace team that has been building out these offices. It really is a privilege to work here. Yeah.
Excellent. Okay. Thank you for your time.
You've been very generous, and you're you've been cooking, so I'm gonna let you get back to cooking. It's been amazing chatting with you folks. Happy Friday.
Happy Friday.
Shared via Hopper