Specter - Supercharging App Development with AI

Ajouté : 2026-05-28

[00:00:00]Spectre is a way to supercharge application development using AI agents.

[00:00:05]It makes it easy for you and your agents to build highquality software at scale.

[00:00:09]I'm currently building Spectre while also using Spectre for two other projects and I've seen some amazing results. Spectre has two aspects, structured specifications and vertically sliced architecture. Let me explain these two in detail. The first thing Spectre provides is a TypeScript framework for writing specifications that compile, execute, and scaffold your application at runtime. These specifications are compiled and type checked so that it's impossible to write invalid specifications. They give you and your agents a clear structure to follow. These specifications also turn into executable tests that you can run against your app. So you are guaranteed that the specified behavior is always followed or the tests would fail.

[00:00:53]Finally, these specs also build up the scaffolding for our app. So when you or your agents finally get to implementation, you can focus on writing the business logic instead of the glue logic. So you can finally get rid of markdown docs as the specifications for your apps and use your favorite programming language instead that you are already familiar with to describe your specifications. The second aspect of Spectre that works really well with agents in particular is vertically sliced architecture. Apps built with Spectre or built in vertical slices, not in horizontal layers. Each slice has its own implementation, has strict contracts for incoming and outgoing data, has its own behavior tests and its own internal state. This basically means that each slice can be built, tested, and operated independently. since slices can never depend on each other for anything. So these two aspects combined make agents really good at working in complex large applications where all of your business logic can be split into small independent wellsp specified and well- tested pieces with all the glue and the infrastructure already laid out. Right now as I am building spectre, I am building two other projects using Spectre. So I'm getting to dog food this project every day as I build it. We start a Spectre app by defining events.

[00:02:14]These events are representations of our domain logic and state. We can also supply Zod schemas to give them structure and validation. Here for my very simple to-dos demo, I have a to-do added event, a completion change event, a removed event, and a cheer created event which is created every time you hit some sort of a milestone. And finally, there's an error event to record failures. After events, we have all the slices of our applications. For example, this add to-do slice which is a command. So commands can create events into our system. Here this add to-do command takes a title as an input and has certain scenarios. These scenarios specify how this slice should behave. So for example when we call this command with the title ship it, it should create a to-do addit event with the title ship it as well as a generated ID. When we call this command with some extra whites space, it should trim that extra whites space and do the same thing. And finally, if we give it a title that's empty or a title that's too long, it should create error events with the corresponding message. This is how we specify how this add to-do command slice should behave. Let's look at another command. For example, remove to-do. The remove to-do slice takes a to-do ID as input and its scenarios look like this.

[00:03:31]Given that we already have a to-do added event, which means we have created a to-do, the remove to-do event should create the to-do removed event when that to-do already exists. Or if there is already a to-do added event with the same ID. If we don't have a to-do added event already, the remove to-do command should create an error. Or if we have already removed the to-do that was previously created, it should return the same not found error. So these scenarios are how we specify how a slice should behave. Now the great thing about these scenarios is that once you define them here they automatically turn into executable tests that are run against the implementation to verify that our implementation passes all of these scenarios and if any of them fail the tests would fail as well and you can see exactly which scenario tests failed so that you or your agent can fix the implementation. So we have looked at how command slices can accept input and create events. Let's now look at a view slice. So a view slice or a projection slice is a way to look at some data through an interface. So we can see here that if we have no pre-existing events and we are looking at all to-dos, we should see an empty state. Our to-do list should be hidden. We should have the no to-dos yet on our screen. And we have and we should have zero to-do items on the screen. And down here, if we have added two events into our system and we are looking at all the to-dos, the empty state should be hidden. The to-do list should be visible. and we should have two to-do items on the screen. So the scenarios for views make assertions against what the user interface looks like given that we have certain events in our system. Once again, these scenarios are converted into executable tests which in this case are going to test the rendered output of our UI components. We can see another scenario down here where we have added a to-do, we have completed it and then added another to-do. And if we are looking at the active to-dos only, we should only see one item in our to-do list rather than two rather than the two to-dos that we have added because one of them has already been completed and doesn't show up as an active to-do. So we have command slices that create events and we have view slices that go over the existing events in our system and show some UI or show some data. Finally, we also have reaction slices. Reactions are a way to encode workflows or automations. We can see an example here.

[00:05:51]When we have five completed to-do events, we should see a create to-do cheer command from this reaction. So the reaction is basically observing the to-do completion events and as soon as we hit five completed to-dos, it's going to create this command of create to-do cheer with the with the payload of the milestone five. So the actions essentially observe events, run some logic and then create side effects or a new or more commands that need to be processed by the system. We can see another specification down here where once we have completed five to-do events, created the to-do cheer milestone, set one of the to-do completions to false or uncheck it essentially and then check it back, we should not see any cheer created milestones. So basically what this scenario is saying is if you have five to-dos and you got the cheer milestone, then you uncheck one of the to-dos and check it again, you shouldn't see another milestone because you've already received the cheer milestone for five completions. So the next completion should happen at 10 to completed and 15 and 20 and so on. So essentially, so Spectre allows us to build our application out of these three vertical slices, which are commands that create events, projections that show the data, and reactions that automate workflows.

[00:07:11]Now, once you have these scenarios laid out, your agent can go ahead and work on the implementation, and you are guaranteed that the implementation is going to pass all of these scenarios because these scenarios turn into executable tests. If you want more test coverage, you can simply add more scenarios that encapsulate the kind of business logic and policies that your applications need to follow. The actual implementation of these slices is not the most important part. And the implementation details can be different depending on your app and your stack.

[00:07:42]But these scenarios and these tests should be able to work with whatever implementation you decide with your application. So let's try to understand how a Spectre app works at runtime. So these are the essential components of a Spectre app. We have our projection, command and reaction slices and we have our event log. Each slice is split into two parts. The first part is some state that the slice owns and the second part is the actual handler that's going to query its state. The command handler can create events which are appended to our global event log. This is the only piece of state that is shared throughout our application. Outside of the event log, every slice has its own internal state that it's going to query to decide what needs to happen. For example, the command handler is going to query its internal state to validate an incoming command and to decide what which events should be created. The projection is going to query its internal state to display data in the UI. And the reaction is going to query its internal state to decide which side effects need to execute. The first part of each slice applies the events that it cares about from the global event log into its internal state. Let's look at some code to make this concrete. Here we're looking at the code for the add to-do command. We have already seen the schema that defines the input for the command and the scenarios. This decide method is the actual handler for this command. It receives the command input which in this case has the title as string same as our schema. And down here we have the implementation. We're going to trim the title. If it's an empty string, we're going to create an error. And if its length is more than our max title length, we're going to create an error.

[00:09:25]And if everything works well, we're going to create a to-do added event with the title. So this is an implementation of a very simple command handler.

[00:09:34]However, this command doesn't actually have any state. So let's look at another command, the remove to-do slice. Once again, we have our schema and and our scenarios. But we can also see that we have a apply object here. And this apply object determines how the slices state gets updated with events. So each individual event gets applied through this function. So whenever there's a to-do addit event, we're going to insert a row into our table here with this value. That's the to-do ID. Let's quickly look at what this table looks like. So here we essentially have a table with two fields, the to-do ID and the removed. So this table tracks all the to-dos that have been created in our system as well as which of these to-dos have already been removed. We don't need to track any other state because this is all the state that this slice needs to make its decisions. So only two events are applied to this state. We have our to-do added event that inserts a new row and we have the to-do removed event that sets the removed field to true for that to-do ID. Down here we have our decide function which along with the command input also also receives our database transaction so that it can query the state for that individual to-do that we received in our command and it can check if that to-do exists or has already been removed and then create an error and if that to-do already exists and has not been already removed this command is going to create a to-do removed event.

[00:11:02]Now once this event is created, the state for this slice is automatically going to update here and it's going to set the removed field to true. So that if you try to remove the to-do again, it's going to create an error. So the command handler creates an event and those events get applied to the state for all the different slices. We can also see how the to-dos view is implemented. So once again, we have the schema for the input that the view receives. We have our scenarios and we have our apply functions. The view here has another table that keeps track of every field of our to-do. The title, completed, and the removed. Down here, we can see that it's applying the to-do added event, completion changed event, as well as the removed event so that it can update all of the fields of its internal state. And then down here, the projection imports a UI component. This is the component that gets rendered in the UI and the component that gets tested by these scenarios. The component internally will query the exact same table that we are updating in this apply functions so that it can show the up-to-date state of all the to-dos. The reaction slice similarly has its own SQLite table to keep track of whether a to-do has been completed or whether it has been removed. It also has a second SQLite table that that keeps track of how many cheer milestones have we already created. Now down here we can see that it's applying the to-do addit event to keep track of all the added to-dos. Then it's also keeping track of its completed field as well as the removed field. Once we have created a cheer milestone, it's going to add it in its second SQLite table to keep track of it. And finally, it has a react handler which queries its state and performs the actual side effect. So in this case we are counting all the to-dos that have been completed and we all we always want to create a cheer milestone for five to-dos or for five completed to-dos or 10 or 15 and so on. So if our completed count is zero or if it's not divisible by five we don't do anything f then we check if we already have an existing milestone for the specific completed count. So for example, if we have created five to-dos and we have already created a cheer milestone for those five to-dos, we are not going to do anything.

[00:13:20]If everything else works, then we are going to call the create to-do cheer command. This command is going to get handled by a separate command slice.

[00:13:28]Here we have our create to-do cheer command which has its own scenarios again to specify how this command behaves and its own apply events as well as its own decide handler. So, Spectre is a way to build applications with structured specifications that compile, execute, and scaffold your app in vertical slices that are independently buildable, testable, and runnable at the same time because all the slices have their own internal state and they only depend on the global event log as your real application state. Let me know if you think this is a good idea to give agents.