Giving Old Projects New Life With Spec Driven Development

Hi everybody. I'm Leon. I'm a developer advocate at Zencoder, and I wanted to talk about spec-driven development. Now, I'm sure that a lot of you have heard about spec-driven development when it comes to building new features, when it comes to planning out campaigns, and it is a really powerful framework with agentic development to bring new projects back to life. The thing is, most of us haven't gotten to this point in a vacuum. If you're anything like me, then you got to this point by building weird, crappy, barely working stuff when you were first starting out because you had a vision or a dream or an ambition, something that you wanted to make real. That's how I got into the software, and for a lot of you, I bet that's how you did too. So the really cool thing about that janky, barely working project that probably isn't even live anymore, it's sunset on some old Heroku version that's living somewhere in a hard drive, maybe not even on Git, is that for better or worse, it might look terrible, but it does have all the makings of a great spec.

A little bit about me. Before I joined Zencoder, and even honestly before I joined Procore, I already was working on a couple weird ideas. I was working on a social app for highlighting and sharing those highlights through with different people. I was working on a push-a-button-and-do-anything website. Then about a year ago, I got to consult on some really cool projects for bringing some really complicated topics to schools and to senior officials, and that's major systems acquisitions. So when the government buys really, really big systems, how do they do that, and what does that approach look like? My idea to explain that to both college kids and senior officials in the government was this. Doesn't look like much, and that's because at the time it wasn't. It was a lot of stuff up here, tried to translate into something that you could play, that would be engaging across a lot of people and across a decent amount of time.

Now, it looked terrible. As you can see, there was a lot of layout, complicated to play, but the really fun part is the rules. So there were a lot of rules baked into what you see here spread out right there on that bed. Those rules lend themselves really well to spectrum development. So why do they lend themselves really well to spectrum development? Now, spectrum development can be broken down into four phases. You've got the specify phase, the plan phase, then the task phase, and then finally, implementation or execution. For the specify phase, now, when you're building a new feature, oftentimes what you'll do is you'll start with a sort of kernel of an idea, and you'll work with the agent to develop that into a full-fledged spec of what that user behavior is going to look like start to finish. When you already have a dusty old project that you can pull in from whatever storage solution or closet it's living in, then it likely contains a ton of that user behavior in whatever janky framework you originally wrote it in. The logic is there, even if the implementation and the execution is not. So that's a really, really strong foundation to build a strong spec without having to do too much back and forth with the agent because you already know what the vision is. This part is just now bringing it to life.

And here's where the agentic development combined with spectrum development framework brings new life to that project because now you can take that spec of desired behavior, and you can work with the agent for the planning phase. That planning phase lends itself to a whole lot of technologies that you may, A, either not be familiar with or B, just weren't even available at the time when you first had this vision, when you first tried to execute on this idea. So when I was trying to execute on this, this little game I like to call system overload, I barely knew a lick of React. Now I have an agent that can implement this game for me on the web in a React framework that makes sense with persistent storage for game states, with multiplayer functionality, with messaging, with notifications, stuff that I had no idea how to build when I wanted this vision to come to life in the first place. So at the planning phase, your agent takes that spec and brings the most appropriate technology recommendations to the table. And once you review that together, agents, especially in some of the newer models that are capable of long-running executions, are able to break all of those plan elements down into tasks. So breaking down system overload into those tasks is going to look like something like, first build the UI, then build user profiles, and then build user states and persistent memory, then build the game turn system and the role system, and so on and so on. Each piece that you've already thought about in your head and that might be implemented on paper, but now is being translated into subtasks of feature development. And finally you get the implementation layer. And the implementation layer looks something like this. So if you take a look at Zencoder running on the implementation phase, what it's actually running is task by task that we defined from that planning phase.

So you see how each level informs the next, where as this is running, you can see here that it's executing on a specific subsection of the big picture. And if there was one thing that I was limited on besides technical know-how to build this project when I first had this vision, it was the time to do it as well and as beautifully as I wanted to.

And the best part about this is now you can dedicate all the resources you need to each element of the game to make it a holistic experience. And so what does that do? When you have agentic runs that can basically split the workload off task by task into different runs, you get really good utilization of that context window, without having to overstuff the goose, without having to compact and summarize, because these tasks are being, they're completion states, lessons learned. They're being tracked in external state files, right? So the next agent can just pick up where the last one left off.

And so what you get when you spread that workload off, task by task, across different agent runs, is a finished project. And this is something that, frankly, I don't know if there is a future for this project. If somebody gets a use or a kick out of it, then that's great. But you can see how in a day I can take an old project that I thought was really important, that mattered to me, and that I just couldn't execute for this or that reason at the time. And now with this framework and with the technology that we have in our hands together, turn it into something magical all over again. So if the point of this talk is anything, it's rediscovering those projects that you were excited about that got you into this industry in the first place and taking them with you on this journey rather than leaving them in the past. So thank you. And if you have any projects like mine, or like, well, anything crazy, right, that didn't work at the time or that you had to move on to bigger and better things, give this a shot. Give it a new breath. I think you're going to be surprised by just how far you can take that kernel of an idea into a full-fledged vision when you combine agentic development with spec driven development. Thank you.