Room 107 Saturday Mar. 07 - SCaLE 23x

In this talk, Alex Garnett, a developer relations engineer at Blue Sky, presents an overview of the App Protocol, which underpins Blue Sky's decentralized social network. He discusses the importance of the App Protocol in enabling features that distinguish Blue Sky from other platforms, particularly its approach to user data ownership through Personal Data Servers (PDS). The speaker highlights recent updates to documentation for the protocol, describes the concept of a billion-edge social graph based on backlinks, and introduces tools like the fire hose for data access and the tap command-line tool for data management. He emphasizes the protocol's support for custom feeds and community-driven innovations, showcasing a collaborative development environment that prioritizes user control and engagement.

Sound check. Check. Check. Check. That's better. Still getting some feedback. >> Where do you think that's from? >> That's just me. >> That's okay. All right. >> All right. Very good. One, two, three. One, two, one, two, three, four. This is a normalish voice. I am speaking into a microphone. This is a microphone in my hand. And you all want to hear a knock joke. Knock knock.

Who's there? A microphone. Okay. >> I don't know what I'm doing. >> Microphone who? >> I'm just saying words so you can test the microphone. one, two. All right, we are at 15 passed. Whenever you think it's good to go, I'll let you be the judge. >> Check. Check. One, two, one, two, one, two, one, two. Check. Check. Hey. Hey. One, two, one, two. Check. Check. >>

Check. One. [laughter] This is a normal voice, I think. You just let us know when you're ready. >> Sound on the DI >> digital intermediate >> multimedia. >> No, I'm not. >> Okay. >> Yeah. >> I'm good. >> Hello. Hello. Hello everybody. Welcome to scale. Welcome to scale 20 26. Uh this is the developer track. Welcome back. Today uh we have uh a great set of talks

for you today. Um are your safety is really important to us here at scale. So if at any time you feel uncomfortable, please uh know that you can call the safety number that we have here posted all around the venue. Um our next talk we have is from Alex Garnett. uh he's a devril at Blue Sky and he's going to be giving a talk about at billion

edge social graph. >> Thank you Chloe. >> Take it away. Give a round of applause. >> Thanks everyone for being here. Uh I'm Alex. A fun fact about me is I live about two blocks away from this conference venue. So I love coming to scale. It's very convenient. I get to wake up in my own bed, have breakfast at home, walk over to the conference takes about

8 minutes. So that part feels nice. Uh, I'm Devril at Blue Sky like Chloe mentioned and I'm here to talk about the app protocol. Now, if you go to BKY.social, that is the company I work for. That is our homepage promoting Blue Sky, the social network. Blue Sky is big world social. It's a model you're probably familiar with from the last 15 years of micro blogging, and

you've probably got opinions about it already. Blue Sky is the company I work for, but is Blue Sky their main product? Arguably, no. If you take a look right up in the corner there where it says app protocol, that is the protocol that underlies blue sky, that is the novel part of doing big world social in 2026. And I'll get into why that is and why I

feel that app protocol is actually our primary product. So this is the brand new landing page for our approto docs site. It went live last month and I'm really excited about it. I joined the company about five months ago and the first thing I did was ship these brand new app protocol docs. The app protocol is what distinguishes Blue Sky from other social networks, big and small,

uh, and also from decentralized networks that exist along a different pattern. Over times, you're going to see more of our docs presence and our coms reflect the app protocol brand. We built Blue Sky first to have a product to ship the app protocol. Blue Sky is a social network. People still know us primarily as Blue Sky, but Approto is where a lot of our new docs live.

It's where a lot of my Devril effort is going towards and it's what we're building the most right now. I'm going to use this brand new doc site as a way to structure this talk about what we're doing. Our new docs, if you take a look at the sidebar here, they start out by showing you how to do basic readr operations. This is really core to whatever

you're doing. Obviously, it's also not something that was in the docs previously. That was only in the blue sky docs. And the blue sky docs primarily had higher level SDK abstractions, right? It's like okay I want to do something on this one existing network. Here we're taking a step back. We're talking about how to read and write at records. You know how do you just create records

in this network following any particular model. We will want to make it easier to understand our core primitives which will among other things improve LLM tooling for our docs and emphasize which aspects of app proto are meant to be generic and reusable. Again not just by blue sky. For those who are new to Approto, one of the most important concepts for users to self-host and own their

own data is our PDS or personal data server. PDS's are where the user data actually lives. Uh they actually live in individual SQLite repos laid out as Merkel search trees, which is super neat. If you want to see details of that, we can get into that later on. You can host a PDS on your own and you can migrate user data across PDS's at will. So you

might have one person hosting a PDS server that's got a bunch of different people's data on there. They can migrate across PDS's. If you just signed up with Blue Sky, chances are that you are on a Blue Sky maintain PDS by default because a lot of Blue Sky users don't care about where their data live necessarily. They just want to be able to interact with the network.

But by starting out that way, by starting out on a Blue Sky PDS, you can then go and take your data where you want to take it. You get a credible exit. You get the ability to own your data and a lot of the rest of our stack is actually designed to shift load away from the PDS to make it easier and less expensive to host that

user data. So most of the architecture of the at proto is essentially you have the PDS that's the thing that's easy to self-host that's what actually hosts your data. You can take that wherever you want. It's SQLite. the entire rest of our stack which I'll get into and which you can find here on this doc set you know relays application views are all different layers to index

that data and to make hosting your own data more achievable and more scalable PDS's proxy some app proto requests for example around login and we provide patterns for developers to help support user choice in this way you can self-host many other parts of our infra as well and this is covered in the new docs PDS are this part of the stack that Most people are going to

want to self-host in most cases. And for that, we provide Docker deployment scripts. So you can find link from our docs on GitHub. The way to self-host a PDS in a pretty lightweight VPS instance, whether it's, you know, OVH, Digital Ocean, you've got a lot of options. PDS by itself is pretty scalable. We've got a reference implementation. We also maintain a separate repo of contributed deployments. If

you want to host a PDS or a different part of our stack on non-standard infrastructure. Uh part of the reason I created this repo was in the first week that I was working for Blue Sky, I saw a lot of open issues on the reference PDS repo saying, you know, like I want to support Arch because we all love Arch Linux, don't we folks? >> Yeah. Okay.

Yeah. I have actually run Arch for many years myself. But I kept having to say like, hey, you know, Arch is not really the upstream default distribution. We're not necessarily trying to support Pac-Man out of the box on bare metal. So created this separate repo deploy recipe so that anybody who wants to contribute, for example, a way to run their PDS on a Synology NAS, which is

super cool, uh can do that and we can maintain that. We've got a really cool community of self-hosters, people who don't want to use that reference PDS. One thing that we don't currently provide in my opinion that I would like us to do better on that we're working on this year is a web admin interface for our reference PDS. Our PDS implements all the endpoints that we

expect it to. So that way you can interact with user data on a PDS. for example, using our Goat command line tool. But the PDS itself doesn't have a lot of a web backend that people might expect if they want to be able to go in for, you know, graphfanaometrics, for any kind of like self uh data checkup, anything like that. Uh I'm kind of picturing like

when I log into my Pi Hole on my own home network, we want to provide more of an interface like that behind a PDS on the web, like an admin dashboard. So that'll be coming soon. In the meantime, the reference PDS does implement all the expected XRPC routes back here. And we have Goat, our cool command line tool for interacting with the PDS in all the ways

that you might want. I can't believe, by the way, that goat wasn't taken. Such a good name for a command line tool. It's goat. Like that's just that wasn't even in brew. We have goat in homebrew now because nobody had taken that. That feels like really kismmet for us. All right. Now, I'm going to talk about some other exciting parts of the stack. Uh if you're familiar

with our work, some of these will be reviewed, but we have new work to share from all of them. So this is all brand new for 2026. We're going to start out with the fire hose. Fire hose is how you get data from the network. We talk about this pretty often, but it still bears repeating. All at protocol data on the fire hose is openly available. There

is currently no non-public data on the at protocol fire hose. It is all public. You don't even need to log in to access it. This is really cool. I worked for a Twitter data services startup in 2012 uh 14 years ago now and to get and rebroadcast Twitter data we had to write Hadoop queries and we had to store it all ourselves going back historical like it

was very very non-trivial to be able to get access to this data for research purposes right for universities who wanted to do social network analysis like figuring out how to actually get legacy data from a social network was really really really tough and everybody had to mirror it on their phone. The entire app protocol fire hose is on a websocket and one of our primary goals is

that if it's ever not possible to mirror the entire network by yourself, we have done something wrong. And that is a core goal for us. Uh right now, if you really wanted to mirror the entire network, that would be like 20 terabytes of hot storage. That's not something most people are going to want to do. But you can just connect to that websocket and you can get

data. For example, here's what that looks like. If I were to use a command line tool called websockat, which is pretty good for getting data from websockets. And if I were to say move my terminal window over here, and that's not how you full screen it by clicking on that because I am looking not where I'm supposed to be looking. What do we think? Is this going

to do it? I can't see that. Well, full screen. I could do like command option F, whatever. Web SOCAD. Here we go. It term that is the app protocol. That is all the data being printed out of a terminal. It's obviously pretty hard to keep up with. Um, we could like pipe it to less or something like that if we wanted to make it a little bit

more legible. But that's the data. Uh, you can do that right now. I don't have any kind of like O built in. There are rate limits of course to make it more feasible, but that data is accessible to anyone. We have a concept called backfilling. And backfilling is conceptually related to the fire hose, but it's also fairly unique to the app protocol. Like I mentioned, this is

not a trivial thing historically to be able to make all of your data back fillable wherever you want. Uh this is a core goal of ours. If you want any or all of the data on the network, you can get it. It's a bit non-trivial to do that. Obviously, like I mentioned, if you want to provision the entire network, you're looking at like 20 plus terabytes of

hot storage. But we want to make it easier to people for people to get a subset of that data. There's a lot of data on the app protocol network that is not just blue sky post for example and I'll talk about that in a second. But if you want to get any subset of our data technically challenging part apart from provisioning storage is actually cutting over from

backfilling legacy data to monitoring that websocket. Right? You need guarantees of at least once execution for being able to actually retrieve that data. You want that to work in a clean way where it cuts over from backfilling to monitoring new data coming in. We've got a brand new cool tool called tap that makes that very very easy. Tap is a command line tool. It has this guarantee

of at least once indexing of all the data. It can stream individual repositories at a time. Like I mentioned a second ago, uh the PDS is kind of the core component of the network. Most of the other parts of the approto stack are designed to just shift load away from the PDS. What this means as well is that a lot of the different parts of our stack

implement the same APIs and the same endpoints. And so if you're trying to use tap to back fill all the data from a relay from the relay of all the data on the network, you can make that same API call to an individual PDS or an individual user account. And so if you wanted to back up just your own data, for example, not only is that not

20 terabytes, it uses the exact same tools, same code path, same tooling, it's just way more scalable. That's also a nice principle. We call it mushrooms the whole way down because everything's implementing the same parts of the stack. Another cool use case for tap is creating custom feeds. Uh we like to talk about obviously algorithmic independence, being able to dictate what you want to see, being able

to not be reliant on uh large organizations pushing their content at you and not being able to dictate what's in your feed. You can make your own feed. What that entails basically is just listening to the fire hose with a tool like tap and then rebroadcasting posts from a specific endpoint after algorithmically sorting them the way that you want to. You can build a feed with our

sample feed generator patterns that make this pretty straightforward. We've got a feed generate tutorial featured on our new docs or you can use one of the many other products that are building on top of at proto like gray social whose entire product is a feed builder interface and feed hosting. So that way you don't have to do all that work of implementing the back filling and the

rebroadcasting and the algorithm on your own. They'll give you a visual tool for doing exactly that and for hosting it. Now, what if you don't want to have to backfill all the networks to all the records to be able to build on top of app proto? There's also a really cool solution for that. It is also community developed and it is written in Rust. Yeah, it's nice

to know your audience. Those are really easy applause lines. Uh this is the microcosm tooling. Microcosm is unbelievably cool uh built by a community member and this is a set of open APIs that index backlinks from the app protocol to let you perform very very fast queries on data that's already in the network without having to do all the work of building out those complex queries yourself.

There's a lot of questions you can answer with backlinks. So here's the landing page uh for constellation and this gives you the ability to find any record that's linking to another record. Well, this is really cool because a follow relationship is linking to another record by expressing a follow, right? That is one link to another. The semantics there, if you've ever done like semantic web stuff, it's

like okay, subject predicate object. That's a link. That's a backlink you can just get immediately. A like is a backlink. Any post responding to another post is a backlink. Any post that's embedded in a blog on app protocol is also a backlink. And so you can find lots of creative ways to query the existing data without having to do that big backfill. We have as of um

actually I made these slides about a month and a half ago probably more now but over 11 billion back links from the records already on the network. So that's where the title of this talk comes from billion edge social graph. There are so many ways of interrogating the data that we already have uh to answer complex questions just by looking at which records relate to other records

and we can do that in a really lightweight way because all the data is publicly indexed by relays. One of my favorite uses of backlinks is this data browser PDSLs. PDSLs also a community tool lets you open up any given app protocol record or account in a browser. So that way instead of looking at some JSON in a terminal, which is fun for some of us, but

not all of us, you can click through and see where all those different records are linking to one another, and you can navigate directly from a post to the person who posted it, to somebody they follow, to somebody they're replying to, or to the definitions embedded in those records themselves. Uh, PDSLs implements some direct PDS API calls. It also implements backlinks. And by doing that, it becomes

a very powerful way to navigate the network in primarily a front-end tool. Really robust big world social protocol tooling. It's all open. A lot of it is communitydriven. Makes me very happy. Now I'm going to talk about another key part of app proto lexicons. Lexicon is a schema system used by approto to define RPC methods and record types and provide interoperability. Approto apps like blue sky need

a way to declare their own behaviors and semantics. Lexicons solve this while making it possible for developers to introduce their own schemas. So there's nothing first class in the protocol that is built for blue sky. Blue sky is built on top of the protocol. Blue sky defines its own lexicons like a post for example and it implements that on top of app proto. That's why when you

talk about reads and writes, we're just talking about reading and writing different kinds of at proto records. Those are the generic. It's just a record. And Blue Sky uses a certain set of schemas to be able to define record types and then define API methods that you can use to create or read those record types. App.bsy.feed.post is a lexicon. It's quite a commonly used one, but it's

not the only one. And you can just push up your own. uh all the API methods are scoped and implemented using a particular set of lexicons. We've got an API system that we call XRPC short for lexicon RPC that is just HTTPS. Any app using that app bost record type would be expected to implement an endpoint again defined by a lexicon that also supports reading and writing

those records. Everything's lexicons the whole way down. That way you can build your own app very easily either by reusing the existing data from existing lexicons or by writing your own new lexicons. We've got some cool new CLI tooling for working with lexicons. Uh we just rebuilt our TypeScript SDK. Notice how I didn't pause for applause at TypeScript [laughter] unlike Arch or Rust. Again, know your audience.

Uh, but we just rewrote our TypeScript SDK and it's all built around this new tool on the command line called Lex. Lex is used for code generation from the lexicons hosted in our existing repositories or any repositories that you push up. You can run lex install to bootstrap a new project to install new definitions from existing lexicons and then just lex build to build types from those

lexicons to be able to just automatically import into a project. And again, we're trying to make this very, very generic. A lot of our existing SDKs, you know, had blue sky methods defined and there were non-blue sky methods. We're moving away from that. We're making everything codegeneration forward, lexicon forward, so that if you want to have first class support for your lexicon for your app, you can

do On the Go side of the shop, I mentioned Goat, which is useful for interacting with PDS's to give yourself kind of an interface to where you're hosting that data. Uh you can also use goat for authoring lexicons and for linting lexicons. So these are all expressed just in JSON. And when you do goat lex publish you're just pushing a lexicon definition up to your own repository

the same way that you would push up a post by interacting with the blue sky network. So, we've got Go, we've got Lex, uh, really cool new tooling, and we're also making the Go SDK, uh, code generation routes a bit cleaner, too. Those are coming soon. We've got a Lexicon style guide for those of you who are really interested in building applications on the app protocol. We

have a very, very long list of specs. If you scroll down this sidebar on appproto.com, you'll see lots of core specs. Uh, data modeling is really fun. I really like this part of the job because you spend so much time working with data models somebody else already put forward. And one of the cool parts of Approto is we do help. We have like a very batteries included

approach to data modeling where if you just define something in a lexicon then you already have some clues about how you want to push it into a database. Right? It's like your gets and your posts are exactly the same thing as what you're storing to begin with thanks to lexicons. But if you're authoring your own, take a look at our lexicon style guide. Another community tool lexicon

garden that is a web interface to the existing lexicons in the network. This way you can browse and search without needing command line tools to do it and you can also navigate throughout the existing lexicon so you can see exactly what's defined in there and what kind of data you're pulling down. This tool is also improving all the time. This is the example by the way of

the pub.leaflet.publication lexicon. Leaflet is an app protobased blogging platform. Wow, cool. We don't just do short form writing, we do long form writing internet. Uh, Leaflet's really neat because it has very very good first class support for embedding blue sky post and follow relationships because they're just kind of consuming different kinds of approto data. But I really like that we have this nice way of integrating, you

know, really short form writing with long form writing. Uh, I know everybody misses RSS terribly. I'm also in that group. And by building back the infrastructure this way on an open protocol, I think we're going to be able to get much closer to an RSS style serialization model as we've managed than we've managed to in like the 10 years since Google Reader kind of killed the whole

ecosystem. Like this is a really nice example of being able to interoperate with existing data sets. I'm very glad that love. >> Yeah, like it's really not that bad to just implement more roots once you have a network that works the way you want it to. It's just like, hey, request this data a different way. That wasn't so bad. It feels good. This is one of my

favorite community projects to showcase. I do a lot of my own uh Devril blogging on a leaflet right now. So, if you're ever curious what we're up to, you want to read about, you know, how I went to Fostam or how I'm here, uh, I like to get people excited about long form writing, and I really like that you can go directly back and forth from one

medium to another using app protocol In addition to apps like Leaflet, which are defining and building on brand new lexicons, you can also pick and mix the ones that are already in the network. For example, if you're making a new client to browse blue sky post to add additional features, you can combine long form and short form content or build like a new in between thing. There's

this client I really like called Anisota, which is kind of like a third party blue sky client, but it also defines a bunch of its own new lexicons on top of the blue sky lexicons that it interacts with to make kind of a game out of browsing your social media. like you'll actually like have a health bar and you'll take damage by reading too many posts, which

I think is a nice way to summarize how we all feel about this some of the time. And it's it's also a really fun experimental way to build on the network with the tools that already exist. Like you can get quite creative by just remixing the data we already have. And I would say if you look at the actual data models that Anod uses, it's like twothirds

blue sky lexicons, one-third its own. That's really cool. That works really well. If you take a look at all the lexicons currently associated with a given identity, here is my account in PDSLs. You can see how accessible this data is. Uh like I've interacted with Blue Sky a lot, but I also have the Anoda lexicons, Stream Place, which is a WebRTC implementation on the network. Uh Wisp,

which is personal sites, a lot of those leaflet lexicons, just really cool stuff. And we're really fond of saying you can just build things on the network as sort of like a an animating call to action. I think one of the AI companies I think stole that for a Super Bowl commercial. So we can't really say it like it was our idea anymore because nobody believes us.

It's like oh Open AI said it. But but you can just build things. And I think that's a really good principle to come back to. Like we want to give people the tools to be builders, to have fun with this network, to not be passive consumers of posts because I think that is responsible for a lot of people's negative feelings about social web and social interaction on

the internet. And by going builder first, I think we support a lot more self-determination and empowerment than the last decade and a half of social has in a lot of the time. Now I'm going to close by talking about social graphs. I've been talking about this to some extent for the last 25 minutes already reusing data building on the existing network network effects but there are some

community developers who are focused on this right now and I want to highlight that work. Uh we only maintain TypeScript and Go SDKs ourselves but there are a lot of great communitydeveloped SDKs in other languages. I actually just updated this on the site this week and I'm going to show it off real quick. This, by the way, is our extremely cool landing page for the doc site.

It has an animating globe that you can drag yourself and it's asy and it's really neat. And you can also scroll down and we have an embedded fire hose just like I showed off with websocket that just runs on here. Very cool stuff. Had a lot of fun doing this. If we go to our list of SDKs, I've mentioned that we maintain TypeScript and Go reference implementations.

There are also a lot of community libraries. We've got Python, Rust, community TypeScript library, Dart, Swift, C, Ruby, Zigg, Elixir, PHP for the real heads. And this is even an incomplete list. Uh there's a lot of community work on the network. So, for example, if you're more of a Python social network analysis person, there's lots of people who have been in that boat. I was doing it

in grad school for a while, like 15 years ago. Uh, you can do that if you want to do this good oldfashioned social network analysis. Again, we enable that backfilling. We enable all these back links. We can answer these questions and you can get good data out of the network. Right now, we don't gate keep it whatsoever. Um, followers as a a follow relationship. That's just a

blue sky lexicon. That is not like again a first class approto concept. There's nothing defining followers as a key concept of app proto that is implemented in blue sky. But that is a relationship that carries a lot of interesting data with it and it's something that a lot of people intuitively understand in a social graph. And so when I'm talking about picking and mixing lexicons to build

on your application, if somebody asked me, you know, like do you reuse the existing lexicons? How much should I make? what's a technically a new app before I have like a ship thesis thing going on here. You probably want to start with that follower relationship, right? Like that's really powerful. If you want to have a blogging app, use those follows. You know, build your blog app entirely

new. It doesn't have to be at all identified with Blue Sky. We don't want everything to feel like an extension of Blue Sky. But that follower graph, that's pretty cool. And so if you are building your own video app on top of our existing network, for example, bootstrap it with those follows. that helps you get past the I'm doing this brand new thing and now I have

to get users mindset and that's no fun. Uh I've talked a lot about how the way the PDS works. Again, they're just SQLite repositories that contain all of your records that have endpoints that let you access them and rebroadcast them, but deep down they are just your files. And so you can host your own PDS. You know, it's not just on someone else's computer. It's not just

in the cloud. It's all of our stack helps to rebroadcast those PDS records. really easily and in a lightweight way. And somebody made a fuse plugin, a file system plugin for the PDS, so you can just mount all of your posts on a local file system, which is awesome, right? Because when you're just storing all your records in a SQLite database, in a PDS, you can do

that. And so rather than having to like download all of your posts as a social graph export because you want to quit Twitter and you want them to email you a zip file that's like 200 megs that you're never going to look at, which I think many of us have done, you can just mount mount your PDS mount your PDS like a file system. That gives you

a lot of power to do whatever you want with your own data from any number of apps. Again, not just Blue Sky. Um, for the activity pub heads in the audience, and I'm sure there are several, uh, bridged is a really cool tool that provides compatibility between approto and activity pub. So that way you can syndicate your data across both social networks. There are a lot of

tools that are using bridged. When I look at our internal metrics, a really cool thing I've seen is that all like the professional social media marketer dashboards that I don't really interact with because I'm not like a professional social media marketer are built on bridged. And so you can see that the critical mass between activity pub and approto has really been useful for professionals and for companies

that want a broader reach to get on open social. It's nice to be able to go further together when you help get to critical mass with the community. Um, I have some data that also speaks to that. If you're interested in digital sovereignty and you follow our ecosystem, you've probably heard about Black Sky, North Sky, Euros Sky. These are all different hosts that are implementing parts of

our stack on their own. So that way you don't have to interact with Blue Sky infrastructure at all if you want to be able to interact with the network. That way, if you don't want to have to go through American servers or if you want to be able to keep your data in a particular jurisdiction or set your own expectations around moderation, you can do that with

your own infrastructure. That is non-trivial. You know, hosting a PDS is pretty straightforward. From there, it gets harder, but it's possible. And we're doing everything we can this year to make that easier. And we're seeing a big big big growth in scale from other providers this year. This is going to be a really big year for self-hosters. If we look at the blue sky records, these are

records in the blue sky lexicon, people who are posting coming from nonblue sky hosts. You'll see the majority of those are coming from bridge posts from activity pub. That is the blue chunk. So all of those are activity pub compatible bridgeifed uh extensions. You'll also see in green, those are self-hosted PDS's, people who are hosting their own not on Blue Skies PDS's. If we look at the

label from this graph, that's like 20,000 total in a given day. And this is only as of January. I think it's actually gone up since that. If you compare that to this slide uh which is all weekly posting users which is like one and a half million people in a given week unique users posting 20K relative to one and a half million that's a little more than

1% of people who are currently creating records who are self-hosting in some way who are not on blue sky. Little more than 1% that's like desktop Linux numbers that feels good. that's sustainable, you know, like that's enough. That's an ecosystem. That's enough to kind of take those headwinds and go build that critical mass together. And so I see that as stable, solid, increasing, and really exciting. And

I want to see this graph have way more granularity to it this year. I want to be able to see all those users who are on their own servers implementing all their own tools for interacting with the Approto network. All right. So why build on that proto? You don't need to architect your own data models. Our SDK code generation provides first class support for all lexicons, not

just ours. You can build on top of the existing social graph. You can get those follow relationships. All records are basically just gets or posts in practice. Got a very engaged dev community. You can self-host as much or as little of the stack as you want. Uh you can take a low code, no code, or lots of code. uh my term approach to solve for your use

case. So if you're building a feed for example, you can use an existing SAS implementation on top of app proto like grace and we have protocol interoperability with big world scale. I know a lot of open social is very skeptical of this big world scale point. Like we're one of the only ones arguably who are still trying to do this big world scale piece in a way

that we believe can be open and provide a credible exit from uh corporateowned social media and we're committed to this that that credible exit with the big world scale handinand is something that's very unique to Approto right now and it's something that I really believe So that is the end of my slides. Thank you. And I would love to take some questions. [applause] >> Hi. Um, how

does the protocol handle uh PDS's which are uh not great on uptime say? >> Yeah, that is a great question. Our relays are responsible for indexing content across PDS's. And the relays currently do a lot of different internal futzing with rate limiting and all this stuff to help make sure that we're able to avoid any one PDS from causing traffic problems for the network, but still make

sure that we're hitting the PDS again. So if we miss it a few times and the record broadcast doesn't work and if it comes back up, it can keep syndicating records. A lot of the issues I get opened on the internal PDS repo were like, "Hey, I seem to have detached from the relay. Like, how do we work on that?" I can show you actually. Um, I

had a browser window open here, didn't I? Yes, I did. PDS, PDS, PDS, PDS. So, if we take a look down here at the very bottom of this readme, one thing that I was just able to add was um fixing a relay desync is something that comes up from time to time for whatever reasons. Like if the cursor desyncs for some reason, we want to give people

the tools to fix that on their own. Like we're in the middle of improving our relays and giving people again more insight. That's why I want to have this PDS web admin interface. People can see whether or not they're actually coming up and being indexed where they expect to be. But we want to give more tools there too. Thanks for asking. >> Um, for like the coming

year, what do you see as like major roadblocks and how the team can work around them for appro? >> Oh man, that's a great question. Uh, we really want to make self-hosting easier. And so, like I said, the PDS is pretty easy to self-host. Relays have recently gotten much easier to self-host as well because we released a new protocol improvement sync 1.1 that makes it so relays

no longer need to maintain legacy copies of all the data on the network. So a relay can now just rebroadcast. It doesn't actually have to maintain like a full mirror of all the data. So you can run your own relay now and many more relays have come online which is super cool. Hosting your own application infrastructure. Um, so for example, Black Sky Social is building their own

app. So that way you can interact with Blue Sky users without having to ever even touch Blue Sky the app. That's hard because that actually requires you to do all the things you need to do to serve an entire app, right? You have to build your own indexes, your own caching layer, your own CDNs and all that. And so we want to be able to feature and

make it much easier to document what goes into actually building that application level infrastructure. That is a big big piece because that part is still challenging because shipping application infrastructure is inherently challenging. Something else um I just wrote the new docs like I said really pumped about the new docs. New docs have six or seven standalone tutorials on them. Half of those are ooth related and that

is for a reason but I don't love Approto is really good as an identity provider and so we talk about you know like build your own lexicons integrate with our social graph even if you aren't all in on the social graph like being able to log in with your own app proto identity is really cool right you own your own identity you're not using Google or Apple

as an o source you're using app proto your own pds as an o source that's really neat that's powerful people want to do that but oath is not fun is so not fun like if you look at all the use cases we talk up on our website. It's like build your own algorithm, cool. Build your own agent, cool. Write ooth. No. And so we're really trying to

make the the O primitives uh equal in uh implementation uh fun to their utility. And so that's something we're working on. I could go on, but that's just a couple things. uh, can you hear me? >> Okay. So, uh, how do you guys plan on dealing with age verification? Because I know there always been a lot of talk about that recently. >> Oh, yeah. Uh, so we

were, I believe, the first or very very like one of the first to comply proactively with an age verification requirement recently in Australia. And that caught people off guard because they're like, "Why is Blue Sky making me prove my age?" You know, like this is weird. And it's because a lot of the other providers, you know, like Twitter, other companies, they're large enough they expect to be

given a grace period by governments in a way that we don't take for granted because we're very small. And when a regulation comes in, we comply with the regulation. Discord recently ran a foul of this in a pretty serious way because they were the first I think uh social network to try to sell this to Americans which didn't go great. It's like a lot of people have

been losing that battle in the UK over the last couple years and you've seen a lot more UK apps have to implement age verification because the government's been pretty straightforward just saying you have to do this. You know, I was in the UK on the way to Fostam 2 months ago and I had to do age verification to access my blue sky DMs, which is confusing to

me. It's one of these things that we're not used to and I think we're hoping that the regulatory environment in this country is able to slow that down a little bit potentially. I know uh AOC gave a pretty effective speech in Congress just this week about why you might not trust neutral parties to be able to collect uh ID from users. Uh, right. It's one of those

things where it's like, hey, you know, we see why this is maybe worth doing, but then who do you use for your third party ID implementer? There's lots of potential areas for leakage there. We comply with regulations. The reason that people saw in Australia that Blue Sky was asking us to, you know, verify IDs is because we had to be proactive. We don't take for granted that

we're going to be able to skirt regulations. Uh, but we would really like to be able to use trusted providers and like neutral parties to do that where possible. And we're paying pretty close attention to that conversation. >> So are you are you >> are you actually collecting ID information in Australia or you are you pushing that off to a third party? >> We push it off

to a third party in markets who are required to. >> Have you seen a response from their citizenship? Are they okay with that third party or are they kind of revoling the same way we are and people in the UK and other places have? I think the UK for the most part has kind of accepted it in a way that Americans have yet to accept it. >>

What about in Australia? Have they are they is there like is their provider already been caught a foul of like not I guess keeping their promise of because all of them say that oh we're going to get rid of the data after x amount of >> Yeah. Not not to my knowledge but I agree with you. probably a matter of of when, not if, right? And and

it's not great. And I would like to see the uh public infrastructure for providers keep up with public requirements to collect this ID in the first place. I would like to see that shift towards a more neutral organization than currently exists for it, if we have to do it at all. >> Thank you. Uh on that same topic, how does age verification interact with self-hosting PDS's? So

far, it does not. Um we've actually had a someone opened an issue from Euros Sky just a week ago to propose that we should put the age verification in the PDS and we push back on that for now saying that belongs to the application layer. We will see where that goes. But this is all very new. >> Well, my question is really like it >> if I

host my own PDS. >> And then bridge to the main network or join the main network like is the main network eventually going to require that I somehow prove my identity or prove that I am following the regulations or something like that. >> I would say in the worst case scenario it would probably just be like one database flag that gets stored that is like has user

passed verification in jurisdiction? Yes. And there's not going to be any more associated with your account there. But again, I think we're currently thinking this doesn't belong in the PDS and it belongs in the app >> Okay, >> we'll see where that goes. >> Uh, what do you think about hosting things that aren't really social or very much content on the PDS? Like, uh, one weird project

that I've been thinking about is hosting DNS records in a PDS. >> Yeah. Uh, ignore the bootstrap problem of if your PDS goes down, you no longer have access to your PDS. Don't think >> Uh, we've had a lot of people talk like have similar ideas, right? The PDS is a pretty attractive model for just where you put your data. Like it's not quite a blob store.

It's not quite a bucket, but we are doing work this year on permissioned data. So you can actually have ACL's in your PDS for data that you do not want to be rebroadcast everywhere. Right? The fact that the entire network is public right now obviously imposes some limits in the kinds of things people want to put in PDS's. But as our permission data model matures and you

can read my colleague Daniel Homegrren's blog series about that. It's super cool. I think there is going to be more desire to just use these as generic data stores. And please do join that conversation because it's currently very open-ended. >> A followup to that, what's what would the impact be on the data infrastructure that you guys have to pay for? >> Yeah. Uh people eventually ask that

question, right? They're like, "Hey, isn't this all fairly expensive?" And the application Streamplays, I think I mentioned, that's implementing like a WebRTC type solution on top of Approtos. They're trying to have like it's like Twitch for like a streaming solution for example. And I've talked to the maintainer of Stream Place right now. One of their ideas for how to collect revenue from paying users is to gatekeep

the highquality video transcoding, right? And that makes sense because if you're paying for bandwidth, you're paying for bandwidth on a PDS. You know, right now everybody who posts a video to Blue Sky, it goes through 3 megabit uh H.264 transcoding. That kind of sucks. I've done a lot of video work. 3 megabit H.264 is not very good, right? Everyone complains like, "Hey, your video quality sucks." And

I'm like, "Yeah, but for a reason." Yeah. Uh but again, if you wanted to have a service and you wanted to charge, you know, for like 20 megabit 4K H.265, like that's a pretty effective thing to try to gatekeep in your revenue model. You're not actually gatekeeping access to any data or features. You're just having someone pay you for storage. So, I think there's something there. And

as people try to figure out, you know, like what a business model looks like building on top of all this open data, there's a lot of granularity. Is it too early to um have case studies uh to talk about like relationships that you had with governments um um like outside of the US where uh sovereignty is important to these governments? >> I would say it is not

too early but a lot of those conversations are already happening in public. So, a lot of people are trying to get the EU excited about AP proto right now for good reason because it provides a lot of hooks into an audience that they want their message to reach and helps avoid a lot of the nastiness around the US government. Like those conversations are all happening in public

and so I would just get involved and you know it's it's nice right when it's all just there but there's there's less happening behind the scenes than you think. It's all pretty much you know it's just there for you. Yeah. uh is it possible to host self-host any uh I guess private infrastructure using the AT protocol where you don't want to publish to in public or so

a lot of the components do they share openly by default or are they able to be run I mean if you run them like offline in dedicated network is that possible or could they by natively be peer-to-peer within a private infrastructure There is no permissioned or private data on protocol yet. That is something that there will be shipping this year. We're currently in the design phase for

that because a lot of people have asked for it. The way that DMs work in Blue Sky right now or the way that user preferences work. Uh those are just at the application level right now. Those are not on protocol so to speak because we implement a lot of the same APIs at different parts of the stack which helps us again shift traffic load off the PDS

for example. We can use very similar you know API structures and just put the data in the app rather than in the PDS. This is not a great model long term and we don't want to do that wherever possible which is why we're shifting towards putting permission data on Thank you for all the wonderful questions by the way. I really appreciate the engagement >> for for permission

data model. Um would it be poss like I assume that's both for reading but also is it for writing and how you can interact with records? >> Yep, sure is. Uh we we have a few different use cases. So, we talk about, you know, like syndicating a a post that you want someone to have to be able to subscribe to or like a private group or all

these different things. And, you know, some of them are harder than others. So, we're trying to solve for a way that will address all of them. So, you can have, you know, your private subreddit on approto, you can have your subscriber substack on app proto, you can have your group DMs and things like >> Uh, part of my thinking is, for example, like um letting people write

records into into your PDS. kind of >> not quite arbitrarily but >> that is also being actively discussed right now. That's a big big can of worms. >> Uh how would that work with different app views? Because the app view obviously needs to be able to access this private this private data. How did would different app views have different access to private data? >> Well, sorry. How

would this work with app views? You basically have to give your app view access to everything you have access to. >> So that's a good question and this is a long conversation. I would encourage you to read my colleagues blogs as he gets well into it. But what I can say is one of our earliest models for private data that we moved away from was having uh

the app views like proxy all requests around permissions, right? Where it's like you're only granting access to a private bucket to a particular app and everybody who wants to be able to access that same permission data has to do th do so through apps that have been granted permissions to it. We discarded that because we thought it got too appentric and away from the PDS as a

model to a point and so we're working in a way to be able to do permission data that is not that appentric but yeah there's way more where that came from >> is there any uh talk about large files support or uh yeah >> yes we only use git lfs everyone's favorite tool uh so blobs are something that are allowed right now in the protocol and so

when you have like an image attached to a blue sky record that's just a reference to a blob that's stored in the CDN and we have a lot of different ways for proxying and handling blobs defined in our docs uh so we have a pretty graceful way of saying this blob is associated with this record you can run like a sidecar service for video transcoding, which is

what we do, and just have different endpoints that interact with the existing record Records themselves are just JSON. >> Uh uh the project you mentioned that was using a file system mount, right? >> Yeah, that's Yeah. >> Does or do you know the constraints on what that supports currently? And uh communicatable, right? Not just for personal use. >> Yeah. Not off the top of my head. >>

So can the things that are uploaded there, they're shared, right? They're they're publishable. >> So basically what you would do they it's all public data but the way the file system fuse plugin works to the best of my knowledge is it just implements like the PDS read write endpoints for your PDS that you can then go into. >> All right. I think that concludes our talk for

today with uh we had this great one with Alex here. Um we are going to be having another uh uh talk later in about 15 20 minutes from now. But let's give it a round of applause for Alex. Thank you for this great talk. >> Thank you all and I hope you are back here at whatever time it says on the schedule. at 12:30. Testing. Testing. >>

Words. More words. Good words. Hi everybody. Thumbs up in the back. Sweet. >> PHP. Don't hate me. Oh my god. Look >> I should have said bash. Why didn't I say bash? >> PHP is a funny joke. [laughter] >> I I already got my first screw up out of the way, guys. Okay, we're good now. >> Awesome. All right, I'm going to turn this off. Okay. Is

the AV team happy? >> Sweet. >> I I don't have words in my mouth. Okay. This is a This is a talking voice. This is a different voice. >> we got five minutes and we're gonna get started soon. This is going to be a really great talk. I'm super excited. >> I appreciate the vote of confidence. >> because Yeah, [laughter] because you're gonna be great. It's gonna

be I'm really excited. We could also get started early if you >> Sure. >> Hello. Hello. Hello. Hello everybody. We are welcome back. We are here with scale 2026. This is our second talk in the developer uh track. Here we have uh Gina. Oh gosh. Gina Verstro. Um, she's gonna be giving a talk on there it is. Oh, well, that's embarrassing of me. Did we not >>

a button? Did I touch a button? >> No, it's This is a different This is not your help from >> That was >> It worked a minute ago, guys. I swear this was up there. >> It worked on my machine. I swear. >> No, no, it's good. It was >> I was so >> Michael, do you want to see what button you think there is? There you

go. >> Which one is it? I don't know. I'm just gonna call you manager. >> All right. So, she's so let me try that again with a more fitting intro. This is Gina Verostro. She's going to be giving a talk on called Give Them Shell, Joyful Automation for the Busy Programmer. She's a DevOps engineer at Soshi. And everybody give a round of applause for Thank you very

much. Um, so yes, this is a talk on Bash automation. And so if this isn't what you thought it was going to be and anyone's looking to beat a hasty retreat right now, I invite you to stay anyway because we're going to have some fun. My name is Gina Verstro and I am the girl with the shell script tattoo. Uh, this is just a little pseudo code

for remove all negativity. By way of a proper introduction though, I want to share with you my origin story, if you will. I am a career transitioner. For most of my life, I thought that I wanted to be an English professor and then I realized academia is not for me. So, I bounced around to some different things and eventually made my way to Learn Academy, which is

a web development boot camp that was in person in San Diego. And I actually got that tattoo as a graduation gift to myself. My first job in tech was a tech support engineer at Sohi and I started in November of 2019. Fun fact, my interview took place on Halloween and I of course wanted to present professionally but still be ready to add a dash of whimsy in

case they were to ask about my Halloween plans. So I wore a plain black shirt and a cardigan. And then at the end of the interview when they asked what I was going to be for Halloween, I just pushed up my sleeve, held my arm in front of me, and said, "I'm a terminal window." And they hired me anyway. At that time, we were a scrappy startup.

And those of us who were new to the industry and our field had regular one-on- ones with our amazing CTO, Alo Sarv, and he would do little kind of career coaching sessions with us and ask us things like, do we like frontend or backend more? Or what tools and technologies are we really excited about? What do we want to learn? And round about the third or fourth

time that we had our one-on-one, I realized I probably needed a better answer than everything, all of it. Because while then and now I want to learn absolutely everything there is to know, I can't learn it all at the same time. So I thought it would probably behoove me to have a focus, at least to start. So I went down the internet rabbit hole trying to figure

out what it is that I might like to focus on in the beginning. And that led me to this. You don't have to squint and try to read all of that. I will summarize. There was a build engineer who left his company and they discovered all of these scripts on his laptop. Things like if he's logged in to the server beyond a certain time of night, then

it will choose a list. It will choose from a list of excuses and text his wife that he's working late. or if he gets an email from a certain client with the words like sorry or mistake, it will automatically roll back that database to the last backup and send an email with like that's okay, man. Just be careful next time. So, I took this to my next

one-on-one and when Alo asked what I want to be when I grow up, I said this guy. I want to be him. And Al said, you have a bright future in DevOps. So that is why I stand before you today a DevOps engineer at SOI. I want to talk next about why we write automation scripts because I think a lot of people including those of us who

do it jump first to laziness, right? Work smarter not harder. But there are some other reasons that we should also such as brain space. We have certain limitations as human beings learning everything all at the same time. time we may want to do it but there are only so many hours in the day. So when we write automation it gives us the freedom to then focus on

all of the other many things that we want to learn all the other tools that we want to play around Another reason to quote the incredible Alosarv, we came into this space because we love solving complex problems and I just think that it is so special that we get to do something that we love so much that's genuinely fun. Some of us are out there getting paid

for it and that is super special. I never want to take it for granted that we have this superpower. It's something that honestly I feel like it's maybe the closest I'll ever get to magic. Pressing a button and just seeing all this output suddenly light up my terminal. We're all just wizards at a keyboard. And that's fun. It's also a life hack because if you love writing

automation scripts, then suddenly anytime you get a task that's tedious or boring or that you just don't really want to do for whatever reason becomes an opportunity to play to do something that you actually enjoy. I'll give you an example of this. It was Thanksgiving and we had a lot of new retail customers. So that's their biggest shopping weekend of the year. And so our boss didn't

want to just rely on our monitoring and observation that weekend. He wanted actual human eyeballs on our database cluster resource usage metrics every six hours. And before you grown, he's in the room. So everybody just be cool. It was absolutely the right call. And I I definitely appreciate that. But nonetheless, I didn't think it would be the ideal use of holiday time to have to click through

all of those different databases in performance insights and go hunting at different tables, different graphs, etc. So, I wrote a script and it was a lot of fun and it would output the different metrics, both the average and the maximum or minimum depending on what you're concerned about over the last 6 hours and one hour. And that way I had this sort of 30,000 foot view and

I could see trends and spikes and then if any one cluster looked sort of out of whack, I could go and focus on that one in particular. that became part of a larger script that I'm going to share with you today. So the first script that I want to share with all of you is called daily digest and there's some problems that it's addressing. Number one, I'm

not a morning person. Takes me a little while to get going even with a lot of caffeine. And I have colleagues in many different time zones. So some of them are starting at like 3 or 4 in the morning my time. By the time I log on at 7:30 a.m., I need to be ready to hit the ground running. And I also need to be able to

orient myself in my day, know what's going on in different places without feeling overwhelmed. So my solution was to build a script that would give me that highle overview of my day and also help me get into the right headsp space. So I'll share that with you now. And this is the code. Might be a little hard to see due to the lighting, but I'll walk you

through how it works. The production version, of course, will have credentials in there, but this is the presentation safe version. No free credentials for you. Okay. Get G Suite is going to pull in my meeting schedule for the day along with the emails that I actually have to care about. So, it's looking specifically for emails from either of my bosses or with certain subject line. Get tickets

is going to be my Jira tickets that are in progress. So, I know right away what I'm diving into in the morning. Next is data dog signals. So, this is getting specifically the medium level security signals and that is because any critical or high alerts is going to hit my phone. alarms are blaring. I already know about those. But when it comes to security, we don't have

a lot of those, thank goodness. But I maybe because I'm still new to infosc, but I sort of view security signals like parents view young children playing in another room. If it's loud, if you're hearing them screaming and laughing and running around, it's all good. But as soon as it gets quiet, you're about to have a mural on your wall you did not commission. So that is

why I like to still have the medium level signals coming to me just so that I have my finger on the pulse no matter what. Then of course we have those database statuses just so I can be aware of what all of our different databases are doing resource-wise. And then we have good news. And if you can believe it, this is the piece of the script that

gave me the most trouble because finding pieces of good news is a little bit challenging these days. So I found that when I just entered search terms like good or happy, I was getting this is not good and I used to be happy that's a bummer. That's not what we want to start our day with. So instead, I found that joyful and uplifting were better search terms.

And I chose uh science, technology, and sports as my topics to focus on. I felt like that was kind of safer territory. Uh just a few things to think about if you're planning on hunting for good news in your day as well. And finally, gratitude. Very simple. It just pulls from a predefined list of strings something to be grateful for each day. big things like my health

or little things like the existence of coffee. Maybe that's a big thing. Um, but that is what that script does. And I have a pre-recorded demo that I'm going to run now hopefully. So, it starts with meetings, then gets into emails, lots of SSL certificate updates, tickets. Here are our data dog signals. The database data takes a little bit of time to pull, but I just want

to assure everyone that none of those security signals were anything dangerous. The first one was me, the second one was our IT team, and the third one is our director of engineering. So all good there. We do have more database clusters than this, but for the purpose of this, just in case anyone thought I was being really lazy and pathetic over Thanksgiving, finally, our good news articles

pop up with just headline and little intro. And there you have it. this next script that I'm going to share with you addresses the problem of context switching. When you're in the weeds, you're trying to solve a really hard problem. You're trying to read through a lot of code that's pretty obscure and then your stomach does that really loud growl and you realize that you need the

fuel or you're never going to get through this. But at the same time, now suddenly your brain has to switch from what you're focused on to what you want to eat. How long is it going to take to make that thing? How difficult is it? Do I even have the ingredients? So this script basically just outsources all of the thinking, all of the mental energy. So again,

I'll just walk through the code and then I will attempt a live demo, but I also have a recording in case things go south. Okay, once again, no credentials for you, but in production, you'll want Starts by choosing an appropriate category of mail for the time of day. And oh, I should point out there's a little bit of setup needed with this one. So, this is what

the setup looks like. essentially just Google Sheets with the name of the meal, the ingredients, and then tags as far as whether it's quick, gives you energy, and if it's hot or cold, uh, and light or filling. And those are just sort of the things that when I'm trying to decide that I land on, but of course, you could do things like sweet or salty or spicy

or things like that. And there's also a groceries section. And the script assumes that if it's on your grocery list, you're out of it and therefore can't make the meal. So that's kind of a limitation. Of course, you know, maybe people want to put something on their grocery list before they're all the way out of it. Or yeah, you could still make a salad without tomatoes, but

for the purposes of this script, that's what it's doing. And based on the time of day, it's pulling the appropriate meal, breakfast, lunch, dinner, Um, of course, these times can be adjusted as well. If you want to take this and make this your own, maybe you hate breakfast in every breakfast foods, then it can be lunch all day. That is up to you. First, it's going to

pull in the sheet for the meal category as well as your groceries. And then it's going to filter for only available meals. Then we have a find delivery option. So if you're feeling lazy and you just want delivery instead, it's going to help you out with that. And then you also have this decision flow because if you don't enter an argument, it will walk you through choosing

what you want to eat from the meals that you have available to you. And finally, usage. This is something that one of my mentors, Brian, taught me to always do just in case you forget or if someone else is running the script for the first time, so they don't have to look through the code, they can just use the usage argument and it will tell them the

different arguments that are available to enter. attempt the demo and I'm going to see what happens if I bigger. So, I've entered it with no input. So, it's asking, do I need energy? Let's say, yeah, I want something energetic. Do you prefer something hot or cold? Let's say I'm feeling something cold and just light. All right. So, it's telling me like pre-made salad. Perfect. Now, if I

just want something quick, I can say something I can have right now. Okay. Or if I want to say if I'm feeling lazy. So you'll see here it says this script is using my IP address to determine my geographical location. However, because I'm on the VPN, it's putting me in LA when we're actually in Pasadena. So, we can say no, that's actually not correct. And tell it

that we're in Pasadena. And there are a lot of options here. So, sorry. If you scroll up to the top, it'll tell you if you don't have time to decide on a restaurant, then this is the one that you should order from. If you do have the brain space for more options, it gives you more options and you can choose what you want to eat. Um, and

it's pulling specifically, um, essentially the search that it's doing is using Google places to find restaurants within a certain geographic radius that do delivery for the type of food, breakfast, lunch, dinner, etc., and that are open at the time that you're running the script according to the information of course on Google Places. Oh, not share. There we go. Okay, so that is my presentation. If you want

to find me, I do have some characteristics that make me pretty easy to locate while still here at this conference. And if you want to look me up later with questions, comments, concerns, feedback, then uh you can find me on LinkedIn or on Instagram. Thank you very much for coming to my first conference talk ever. >> I'll take questions, but please be nice. >> So yeah, raise

your hand. really high up if you have a question so I can run over to you with the microphone. >> Sorry, >> that was fantastic. I really liked it. >> Um, are these scripts available on GitHub or anything like that? >> Yes, they are on my GitHub which uh I have it listed on my LinkedIn but it's also GitHub. My username is bashkit case like basket case

>> which is great by the way. I love it. basket case. >> Great. Thank you. Thank you very much. >> I have a question. >> Okay. Uh, so I have an issue with remembering to eat when I'm programming. So, how did you go about this? Like that script was awesome. How did you go about like like what gave you the idea to let's automate this? [laughter] >>

Um, you know, it would be anytime that I'd be working on something and really just trying to intensely focus. Uh, my husband who also works from home, um, I really really appreciate this, but he'll come in and say, "Hey, you haven't eaten. It's getting really late. Can I make you something?" And then I'd have to go, "Oh my god, okay, what can he make me that's not

annoying to make? What do we have? let me think. Uh, and then I just realized, you know, it would be a lot quicker if I could just hit a button and have it tell me and then say this thing. And you could also, if you forget, um, and don't have a partner at home or someone who will come remind you, you could probably run it on a

cron job. So, it'll pop up for you and say, "Hey, knock knock. Eat something." >> Right. So, even the lonely programmers can do this. >> Absolutely. >> You hear that, everyone? We can do this. other questions? All right, one more round of applause. All right, so we have we finished a little early for this talk. We are going to be returning here in I forgot what time

it should be in your uh brochure uh or on the schedule on the website. Um and uh we will be back in here after that and we'll have one more talk. All right. Thank you very much. >> That was really good. test. Good. Oh, I see. It works. >> Cool. Cool. >> Okay. Okay. >> That's fine. Yeah. more comfortable for you. >> Okay. Yeah, I think we're

good. Hi everyone. Uh let's wait for two more minutes and we can start. Okay, cool. Cool. I think we can start. Hi everyone again. My name is Mushek Yoran and u today we are going to talk hopefully um very interesting topic which is VIP coding or uh I more prefer to say AI coding. Uh so for me the difference is w coding and when you don't really

understand what's what it really generates and AI coding when you are an engineer and AI is basically generating the code for you but you still understand what it does right and um obviously um it's not a secret that with current tools that are available in the market like cloud code cursor windsurf codex from openai They make us engineers like 10 times more productive. You basically ask what

you want. AI creates the code. It works. It feels like a magic. But what if it's not only you that are using the AI to generate the code, but your whole team is using it. So this is when a lot of problems are arising and basically this is um my speech is about how to solve this problem but what let's start from the problem first what's the

problem so imagine there are like multiple engineers in the team and everyone is using AI obviously they are using some kind of in isolation uh there's engineer and AI and they're chatting together and it might be possible that one engineer might create a table another one might create another table which duplicates some data uh the third engineer might create some service while one of the existing services

might work. So basically each of these chains separately makes sense but together that actually can create a mess right engineers make mistakes developers I mean we can make mistakes we can we can write bad code that's normal and that's why we had code reviews right so when you write some code you send it for review and your peers review your code give you feedback and this is

how we have been preventing ing let's say bad code or we we have been preventing messy code when different engineers creating the same stuff in a different way but now in this new world when AI generates in a single PR sometimes 500,000 or 2,000 lines of code obviously like the old way of doing code review doesn't work anymore like as a human you can't really review the

AI generated code I mean you can but probably you will miss a lot of things there you will be you will not you will not be able to review all the code and also I think when you review AI generated code to be honest in my opinion it's already too late because based on my experience especially when I'm reviewing junior or mid developers AI generated code what

usually my feedback is like hey can you just rewrite this all please because it doesn't make sense at all because this is what AI it's true not the engineer So and also if if you if you catch these issues, I think it's already too late because now uh the engineer should go and start everything from scratch. So basically the old style of doing code reviews doesn't work

anymore in this new world. And now let's multiply this this problems over five engineers across multiple screens. And let's say you don't have a proper solution for this uh what you'll end up with is uh with codebase that is not maintainable and I was in this situation to be honest I was managing a team five engineers were ship like it was a startup and obviously we're shipping

very fast like very very fast but after few weeks we realized that code is unmaintainable we are getting bugs and fixing the bugs becoming like kind of refactoring take taking sometimes days sometimes weeks of rework. So we noticed that we are getting duplicate tables in our database schema. We were not using any patterns. So basically code was garbage. Maybe for startups it's okay in the beginning because

eventually yeah if you gain customers then you will be able somehow to u refactor or sometimes even start from scratch but in general I think it's very dangerous right you don't want to base your business on a codebase that is messy it's it's not maintainable and you don't know what might happen in the so that's why basically why I came up with the idea of specind it's

an open source project uh and I credit it first for us and we have been using it um so far. Then the idea of spec is very basic nothing complicated to be honest. So the it's it's a three-step process. So first is analyze analyze your codebase then design a feature then implement a feature. We'll actually review each of these steps today and I will also try to

do real demo with real AI coding and hopefully it will go good. Um but yeah let's let's review each step separately. So first step is analyze. So let's say you want to you want to start doing AI coding on an existing project not a new project and this is usually what happens in big companies or big teams or not new startups right you already have some codebase

that's there and you have a team and now you want to accelerate your development with AI. So if you start using specind the first thing you would need to do is to run the analyze command and by the way this um um specind works in all existing uh coding assistance. So you don't need really to switch or you know you don't need to change your processes. You

can still keep using cloud code cursor codeex windsurf git copilot whatever. So it lives inside of this assistance. We'll review it later in more details. But in a higher level, what you need to do first you need to run analyze command. So what analyze command will do it will basically analyze all your current existing codebase. It will parse it with three and whoever um doesn't know the

tree is basically understand your code structure and not just text. uh and and then Specmind also understands your service layers, your patterns, your databases, your dependencies, frameworks, ORMs you use. And eventually based on all of this, it creates a comprehensive documentation. It's called system.sm which basically tells what's your project is about and how it's implemented and covering all of Uh this is the first step and let's

try run analyze command on one of um projects I actually vcoded by myself. Uh yeah so first thing you need to do basically you need to install um specind into your environment and as you can see different um coding assistants. I'm going to use cloud code for this demo purposes and I'm going to run spec setup command on my project and hopefully you can see it. Uh

if not I will try to kind of uh go through the generated code. So I run this and what what this uh yeah first I set up the code. What it does basically it copies the commands which are basically the prompts into your codebase and also it installs a CLI that can be later be used. So now if you go to our clot folder here we'll notice

we got three commands analyze design and implement review. Let's review analyze for now. So what analyze basically is it's a prompt for cloud code which says you know what whenever developer runs this command first go and run this MP specind analyze CLI which will generate for you you know what let's run it and see what it does. So I'm going to run analyze Yeah because I just

installed I guess I need to restart my cloud code. Let's try Yeah, here we go. Now it's available. So I'm going to run analyze command. And here hopefully you can see that first thing it will do, it will run the CLI, the analyze. So now this CLI will go over your codebase and will start JSON files. What you see it automatically detected services in my codebase. I

didn't tell anything right but it went to my codebase and actually yes I have like a couple of services like I have admin service agent crawler. By the way this project is another AI agent uh for car buyers. Whenever you want to buy or lease a car, you you chat with this AI agent and it's connected to different dealers and it automatically makes suggestions for you and

um schedules appointments. That's what AI agent does. But it doesn't matter in this context. So it automatically detected these services for example admin agent crawler DB is like module more not a service and web and then under each um under each uh service it also detected the layers. So it always tries to find any API layer any data layer external layer and service layer and under each

layer it will generate chunk files. So this is basically uh kind of this is the high level explanation of your service. What methods does it have? What classes you know like everything whatever it could uh uh kind of get from your and then the coding assistant which is in this case cloud code as you see it's it's running five different agents in the background. So now they

are reading these chunk files. So instead of going and reading the all the uh all your codebase which sometimes might be so big that it will not fit in the context of AI right even now we have like 1 million uh tokens context but still it will not be able to fit in one in one uh kind of context. So that's why first what we do we

just like because we don't care about like implementation details yet we we um now more care about the architecture. So basically with the this chunk files we get a high level architecture of our project and then we give this to AI and say hey this is our project please create a comprehensive documentation. So I think now it's working on the documentation uh itself. Let's go back to

presentation and we'll come here uh again. So again let's summarize what analyze does right. So first it analyze your codebase. It generates descriptive JSON chunks that will fit in your AI context. By the way, even if your codebase is very big, this will still work. Um then it's basically runs a prompts against your chunk files and generate the system SM file. And what you will have in

this system SM file? Basically you will have this highle system architecture for your project. Then you will have per service architecture if you have multiple services. By the way, now we are talking about monorreo project, right? Imagining that you have multiple services in one repo. Also, it will automatically generate sequence diagrams showing the cross service flow between your services. And event and last but not least, it

will generate the entity relationship diagram. Basically, your database schema or your database schemas if you have multiple ones. And now this system SM file will uh kind of play and be a source of truth for us. Whenever we want to understand what our project is, we need to uh check the system SM file and also the AI by itself can go and read this SM file when

it needs. Yeah, let's see if if it's done. It's still working. Sometimes you know like it it takes like few minutes. Sometimes it might take more but uh you know what let's continue presentation and we'll be back I guess in a minute or so. I see like it already generated 16,000 tokens. So probably it's almost done. It might take a little bit more. Let's go back to

presentation. We will come here. So the next command let's say we have system SM file right it means okay we have the base now we are ready to start implementing new features. So if you remember in the presentation I mentioned like before AI how we how we were handling the implementation right we're writing a and then we are sending the code by itself for a review what

I propose I propose that wait starting implementing the code let's design the feature but and here by saying design I mean design in terms of architecture and technical details let's create a specific ification file for our feature and only then we'll start implementing it. So basically to do it you just run /design command you tell your um your future description feature description it can be as short

as like I don't know like real-time notifications or it can be very comprehensive description about the feature and then it will start generating the um specification just for your feature. I want to show you this. So, okay cool. I think we got the uh systems SM file. Let's review it. Cool, cool, cool. Yes. So, now uh so as you see it generates specimen folder in your project

which obviously you need to commit and push to g. And here you will have the system folder which is basically the JSON representation of your codebase. You basically don't need to come here. It's it's just like for first analyze step. And then we got this system SM file. And by the way uh as part of spec I also built an u extension for VS code for vincer

for cursor for every IDE. Uh so you can preview this file because basically for AI obviously this is enough it's it's markdown but for human if you want to read and understand what it generated you can basically preview it. And this is what what AI basically generated. So as you can see there's a high level overview what our project is about. Then there is high level architecture

of our system. Sometimes this is more complicated. In our case it's pretty simple. So here what we see we see that okay here we have um couple of services. Then we have our data stores which is posgress and radius. Then it automatically detected all the external services we use in our project. For example we use openAI for LLM. We use Oz for authentication. lags for tracing our

agent to understand what it generates. Uh this link is basically for uh iMessage communication, Google maps API and ME zero for agent memory. Yeah. So it automatically detected what uh kind of services we use. Then yeah here's also some um explanation right what's uh which uh about each service like admin service, agent service and so on. the data stores, external integrations, some communication patterns and then oh

sorry okay and then uh it generated the sequence diagrams. So basically by sequence diagrams it shows each flow in my application and here we mean like flow from user perspective. For example, this one is crawl job flow. In in my agent, I have a crawl job when when I click and it automatically goes and crawls and scraps the data from dealers, right? And here I hope you

can see that it basically with a sequence diagram describes that. Okay, this is how the flow works. So, first it it insert a job in posgress, then it cues a job with radius and then it it uh triggers the crawl service. basically just explaining how our um agent is implemented. So basically if you onboard a new developer you know what you can even give them this system

SM file and say hey go read this system SM file you will learn everything about our project you don't need to read even the code so there are more uh sequence diagrams obviously I hope it also generated the entity relationship diagram here we go so it automatically found our um entities and it automatically detects multiple uh OMS so it automatically detected our entity ities the types the

relations and everything and it it just like wrote down and then it generated some more diagrams per each service and some let's say summary right so we have our system SM file and now as you remember we uh wanted to generate a new future now I'm going to ask AI to generate uh for example I want to add a new feature so the the car buyers can

add for example I don't know favorite cars like and I'm going to call it like buyer favorite cars. I mean again I can provide very long description about my feature. Let's say I can even provide a PRD or my I can copy from my Jura ticket or whatever we have our task but for demo purpose I think this is enough. So what design uh command will do

now? It will go and read your system SM file every time to understand okay what what's our what's our current state right and then if needed it will also go and review your codebase this is this is basically depends on your system SM file and your uh codebase uh by itself and then it will take your um description and it will start generate specification file just for

that feature. Okay. And basically this specification file is um this specification file. Let's go back to our presentation. So now like instead of like sending your um code for this feature you you will send this specification file to your peers and now instead of like reviewing few thousand code that AI generated they are going to review just specification file to make sure that whatever is written there

makes sense right for example yes we need a new field or yes we might need a new service for this feature or yes we might need to add some new relationship in our database and so on and and now human uh can read the specification and and just approve which means like okay now we are ready to implement this feature so that's that's the new process and

everything still happens in your same code review process so you don't need to like change the code review process in general if you are using for example GitHub for your code reviews and you are using uh PRs pull requests you can still use them, right? I can generate the spec file. I can open a PR. I can send my to my team to review and then when

when uh I got approval, I can start implementing it. So, let's go back to our um code and see where we are. Okay, I see that it's actively now generating the feature specification. Okay, now I have everything. I let me create the feature spec specification. Okay, uh let's go back to presentation and we will come back here. So let's say we send the specification well which by

the way which is very similar to the S system SM it just um it just u only about the the feature specification not the whole project and by the way I forgot to mention one thing to be honest I'm very sorry uh if you have any questions during the presentation I should mention this in the beginning you can scan this QR code uh and submit your questions

we'll oh Sorry, we will review at the end or if you want to ask at the end. Yeah, you can do that as well. By the way, I vcoded my presentation as well. Yeah, I even I I even vive coded something more and I forgot to do that. a speaker notes and also I someone from my colleagues asked to record this and I forgot to start recording

but I even implemented recorder. So I'm going to turn it on now. At least we'll have some part of the presentation. Cool. And it will record and automatically put to cloud. Yeah. Uh I forgot to do that in the beginning, but that's okay. Okay. Now, let's go back where we were. Yeah. Implement. So, um hopefully our uh feature specification is ready. Yeah, it is. It's just writing

now to the disk. And now for each feature you'll have first you'll have this features folder here and under each you'll have your like feature slack which automatically obviously generated by AI and then you'll have your each feature specification here in the another SM file and we can preview it as well. I'm not going into much details but I what I want to highlight it's first it

generated requirements right okay so what are the requirement functional and technical requirements for my feature so it just like just thinks in this way what what I need to do in order to build this feature and what is very important it highlights the services it's going to touch it says you know what I need to change the agent service and I need to change the database and

that's right because it doesn't need to change crawler or the web I didn't ask any UI change or I didn't ask any admin change. So that's why it automatically highlighted that I'm going to change this service and me as a reviewer I'm going to review this and say yeah that makes sense that's cool and if if I want to get more details okay what are you going

to modify I can read for example it's saying you know what I'm going to create a new um in M value and I'm going to create a new tool which is correct I'm going to create a new manage fits tool for LLM I'm going to create a new server service for API endpoint and I'm going oh look and it says no new source existing buyer vehicles interest

table used with new source value so it turned out that I have some table and I think that oh you know what instead of like creating new one I can reuse it and probably it's also highlight in the ER datab diagram yeah here it's saying you know what I'm going just to change this table and I'm going to add this new field and me as a reviewer

I'm looking if if I for example notice that it's creating a completely new table I might say hey wait but why you are doing that right let's say it's a new engineer join our team why you are creating a new table actually we had a we have a table that you can use so in this way I can review the specification and just give my kind of

uh approval and then we can say okay me as engineer who who wanted to implement this feature I'm ready to implement it and that's the last step which is implement now I'm just going and telling AI hey this feature specification is okay by the way uh if I want to change anything here, I can do it manually. I mean it's not only AI. I can go and

change here or even even I can chat to AI and say you know what uh no I want to create a new table for example let's say for some reason which is in this context is not correct but it's not that we are fully kind of uh automating the process it's I mean or delegating to AI we still can inter we can change whatever uh AI thinks

but in general the idea is that I'm working on my spec file, not code. I'm talking to AI. I'm changing a lot of stuff, but I'm not changing the code yet. I'm changing the feature specification. That's it. And then when I'm ready, I'm uh running implement. And yeah, what implement does basically it detects your feature specification file. It just basically starts implementing based on it, right? Automatic

and then automatically updates the system SM file. So your architecture is always up to date which is very important right because sometimes we create documents but we as human are lazy or engineers are late and we never go and uh update them and and if you are moving like super fast with AI I mean probably you will not be able to keep it up to date. So

now Specman will do it for you and also it creates a change log a separate file when it just like writes every change you did. So if you want to understand how you ended up with this you can read the change log. Now what is very important when you have a feature specification file and as you know with AI the cost of implementation now is low right

basically you just ask AI to do it and they do it that's it now you can give the your feature specification to five different AI assistants you can ask cloud code to implement it then you can ask codeex to implement it and you can like look and choose any version that's the good thing about uh specification and by the way this specification thing is not something I

came out with it's called like specdriven development. It's it's pretty new thing which means like let's first work on our spec and then think about specification and even if I implement it and I don't like my implementation I can just trash it because it's AI generated. I didn't spec spend hours on it, right? I can just like delete it completely and and start again because I have

all my um engineering zones in my specification file. And that's why we engineers are being paid, right? We are not being paid just for coding. We are being paid for engineering things, designing things, thinking and you know like designing a proper solution that can work. So with with uh future specification, you can just like give it to multiple assistants which sometimes I do. And they take the

version you like most. Uh and finally let's just okay it's asking to change uh changes to my specification file. I will say no. You know what? Because I know that my request was not a good one. I will just now ask implement implement buyer favorite car. And I mean I can do typos here. it will it will probably detect uh which feature I'm referring to and it

will start okay look what it's saying let me read the feature spec and understand what needs to be implemented and this will take more than other steps so let's yeah so u basically with specime we create this loop right so first we analyze which is one time operation we don't need to analyze our codebase every time then we design a feature, we send it to team team

review, we implement it, the documentation is up to date and then we go to design, review, implement the update. That's the loop actually. Yeah, I mean test is is part of implementation. Yeah, I I I I missed that. That's a good call out. Probably I need to add. Yeah, but basically um uh everything which is related to um testing, deploying and you know like running your unit

test, running your integration test uh all of that part in this context is part of implementation. yeah so as I mentioned in the beginning so spec is in already integrated with cloud code windsurf cursor uh I'm working on codex um soon um because I'm using three uh basically adding a new language is not very very hard thing but it still requires some time so if you are

interested to collaborate this is a good area you can collaborate it uh basically I only have Typescript, JavaScript, Python and C# um uh integration. So yeah, let's kind of understand what we get with Spec Mind. So before Specmind, the problem was that each developer was working isolated with with with their AI and which basically creates architecture drifts and usually you catch problems very late and which is

costly which I faced. Um but with with spec basically you have this uh the AI has the full context. Uh you basically design before coding and uh architecture stays kind of in sync and consistent and docs are automatically up to date. So you kind of keep the speed but you don't um end up with chaos. So obviously as I mentioned it's an open source project. If you

are interested um please scan this QR code. Uh if you like it please give me a star or fork it or whatever or you can even if uh you can try if you see issues you can open issues or or even open PRs as I said there are areas for contribution and yeah now let's go to questions but before that so let's see what it's doing here.

Yeah. So basically now it's implementing uh the feature based on our specification. Let me close this. Okay. So now AI has a clear picture what it needs to do. Cool. It started implementing it. So we can review this at very very end. Uh but if you don't mind I would like to do a selfie with you guys if you don't mind. Uh I'm so excited that so

many people joined my presentation. So I want to fix this moment. Thank you. And now let's go to questions if you have any. Oh, we have questions here. Cool. I was not expecting this. So let's read Uh how does this compare to open spec? yeah to be honest uh I think it's one just um um I think it's just another implementation of specdriven development. Uh and there's

another cool project by the way from GitHub. I think it's called SpecKit. So you can check that as well. I'm thinking to maybe integrate also to to uh to this um kind of projects. Uh but uh I probably don't have deep understanding of the openspec. So maybe I can't give you a good answer. after spec generation does it become part of the system or does it live

separately? Could you explain the long-term integration? after specking the generation sorry does it become part of the system file oh okay so yeah basically when you generate the system SM file it's now in your codebase so basically you commit as you do any other file right and you have also g history on top of it generates and I think at the end I will show what's the

change log but also you can commit it same about the features so features are in your codebase and they stay there and you commit them and obviously uh why you need to do this because whenever uh new developer joins or even during the work like when developers fetch and pull from repo obviously all of them need to have all of these feature specification files and system file

right uh and sometimes you might even get merge conflicts on systems SM files as as with any other file obviously um is this thing on okay if it's about spec mind yes during analyze it creates a bunch of chunk files to form the system SM file I understand that we need system SM for any feature development but can we discard it actually that's a very good question

uh yes now these chunks are used once so basically you can discard them I was thinking that maybe I need to you know like periodically or again after each implementation update this chunk file as well because you know what sometimes happens sometimes AI might hallucinate and I don't know forget to update the system SM file it it's happening very rarely but let's say if it happens I

always want to have the source of truth which is my chunk files which is generated deterministically right which means like it's it's true there is no hallucination I want still keep it up to date as well bless you uh I was thinking about that but for now at this moment yeah you can basically discard it because you just used once. curious YSM extension over MD. Um, yeah.

So, obviously YSM because it's spec mine. Why not use MD? uh because actually what I did in my extension as you noticed I'm using mermaid diagrams and um I think uh the diagrams were not automatically being rendered in VS code but I think they are rendered in GitHub so I just wanted to render them and I couldn't it with MD file and I didn't want to change

the uh kind of the previewer for MD file so I just came up with new extension which is SM. That's it. I don't know maybe I overthink uh but uh that's that's uh why I did SM just to have this extension so I can have full control over it to be honest which is also open source which is also in the project. Can the system SM file

get so large to be problematic to break into the context or is there some logic? Um yeah I I think I have a issue in my GitHub project. So it's not happening but I think in theory it can happen. Uh it it depends uh on your project size but because spec now works only for monoros. So if you have very very big projects most probably you are

you are not on monorreo you have multiple ripples. So this is how I control the size of system smile. But I was thinking that to have some um chunking logic for system SM file as well or some you know like u split into separate uh logical uh parts you know instead of having just one file. Will PHP be added to your road map anytime soon? Um so

yeah again to be honest uh so far I was doing this totally alone and I was getting only feedback from teams I was working on. If I start getting feedback hey we need PHP yeah probably I will do it. Um and if you want you can even try to add that uh by yourself because you can use AI to add this integration to be honest right. So

uh but yeah I mean uh if I start getting some feedback I will start adding more languages and uh PHP might be one of them. What do you think about having the test creation as part of the plan step rather than implementation step this will hurt against? Yes that's a very good question. So I have some more ideas. Uh to be honest I want to now um

split implement step into more steps and one of them is test. Another one is a plan you know like I want to take a feature I then I want to create a test plan. uh and and then I also want to create a implementation plan you know like just get more understanding how AI is going to do and give less let's say judgment to AI how this

should be implemented you know like I want to make sure that the specification file is so well documented that whatever AI does it just like just kind of different style of coding but it will not make bad or wrong decisions. So, but I think creating a test plan separately is a very good call out. And by the way, uh now whenever I'm vibe coding or AI coding

any anything uh I usually try to start from test so obviously unit test integration test but what uh I do more now with AI is simulation test. So whatever AI I'm creating I create simulation test for them. basically creating scenarios so I can give to to my agent get the output and assert on the output to see like okay how it will behave I don't know like

is this part of integration or what but usually I do simulation test and um yeah and and I think probably this will be good another good step to add to generate you know this simulation but simulation tests are only for AI agents when you are building non-deterministic system if you're building deterministic one basically Unit test and integration test will cover your scope. Language agnostic. What amount of

token credit usage was used for your example? Uh, good call out. Let me let me check. Um, yeah, I I think it will be hard to >> Sorry. But it's still doing that's the problem. I think it's still implementing. But let's see what it will give because I think the most of the tokens will go on the implementation by itself. Uh to be honest, I'm now using

cloud code max and I just stopped thinking about tokens because uh before that I was using windsurf um that that was coming from my team and yes I was always checking my tokens. I was always buying extra tokens. Um, I'm not promoting any of them, but my personal preference is now cloud code. Uh, because basically I just don't care about tokens anymore. I there's a limit which

I never reach and I and I AI code a lot nowadays. So yeah, but uh um so basically if you generate the code without specind most probably you will spend the same tokens as it will spend when implementing. So you are spending extra tokens on uh specification generation but in this way you prevent the future ray implementations. So in the long term probably you just uh save

tokens. So um but I don't have numbers to prove this do we have more questions? Language agnostic uh with question mark I mean it's not language agnostic in terms of that I need to support each language separately. So I support if that's the question to be honest I support these languages Typescript, JavaScript, Python and C#. Why? Because this is the languages I use. Uh but yeah, pro

probably like Go I know is pretty popular. Rust, Java, I mean C++ I don't know just popular language I wanted to have on my slides to be cool. the workflow of creating a >> um what is the workflow of uh implementing the new language support. So basically what I do um so first uh I just explain what I want to do right with with u I use

spec mine for my project as well now uh and then what I do usually I go and vibe got another project with that language some you know like mock project for example to do usually I do like task management system implemented by Java for example right uh and then I just run the spec mind on that project to to do human test and see what it what

it generates but I don't have to be honest um good designed automated testing yet I think yeah I I have I have I have unit tests for of course uh but during this time I was just asking my friends to use spec and give me feedback that's how to be honest I was improving it yeah but that that's the process basically and again I'm using three seaters

so uh to understanding the a abstract syntax uh three um that part is delegated to three seater. So the only part specbind um handles is understanding the patterns, the layers, some um let's say dependencies, OMS to because it it's not looking to your database, it's looking to your entities to build your entity relationship diagram. So you need to understand the syntaxes. So are if you're using drizzle

or entity framework or whatever, it automatically understand oh these are your entities. Oh, then these are the relationship. So it pulls from your uh entities not the database. Um >> and we have a couple questions from the >> Yes, please. >> So uh I notice one back here first. >> Great presentation. Um, could you just go over the basics of like uh say you're a beginner vibe

coder, how you work with git and get github so that you when you've created something you don't lose it because sometimes I just go in circles for half a day and nothing's accomplished. yeah, let me rephrase your question. I don't think I understood it like how how I handled not to lose the context or can you repeat the question? Sorry. Well, I'm a beginner vibe coder and

I tend to vibe code, but I don't really have a good workflow with GitHub yet. So that when I do work, >> okay, >> like going back to it, I could spend all day and then lose what I did. >> Oh, I see. Okay. Uh Okay. So, yeah, if you're vibe coding, uh so are you an engineer or I guess not, right? Okay. Yeah. So, if you're

vibe coding, um the good thing that u you can even ask AI to do the GitHub stuff for you. That's what I do now the analysis I I stop manually running g add or g status or g commit or whatever. So what you do so first thing you need to create a project in GitHub right so that's that's the part that you need to do it manually

I guess and just copy the URL from the GitHub give it to AI and say hey this is my git project please pull it or do whatever so I need to have my code there and whenever you are creating a feature any feature and you see that it works just tell AI that hey please push this to GitHub that's it and it will push that chunk of

code to the GitHub automatically what it does under the hood commits it creates a commit and it push to main or you can say I mean if if if you work in a team this is not something you need to do you need to open PRs but if you are alone and if you're vive coding just say push to uh GitHub after every meaningful iteration okay and

then you will have everything in your GitHub yeah any more questions yes please >> hold on Hey, so um I'm wondering though because my codebase is split across a an absolute boatload of services in completely different repos, but they all speak the same language and they all of course depend on uh you know libraries and similar to talk to each other. What's the recommended way in spec

to handle a lot of repos given you only talked about the monor repo use case? Yeah. So I have like just for information I have that in my uh list to support uh multiple repos let's say multi-repo solutions. But for now what you can do basically you can um open uh you you can have like per repo kind of assistant right with it spec setup. And then

you can have another agent which you open in your root folder where all your repos are and you just ask and you just dis explain them hey I have this repos and there are feature specification files here here there and then if you want to come up with any let's say I don't know like integration or whatever you can ask the agent but to be honest the

uh ultimate solution will be just uh adding that support to spec in my opinion uh or any specdriven development uh tool so that's I have in my list. But that's the probably the best advice I can give you. Yeah. >> Cool. Uh could we could you talk a little bit more about the disposable chunk JSON files, right? I believe those are created from trees sitter, right? Um

but could you explain why they're disposable or one-time use or did I get something confused there? >> Yeah, sure. So, um basically why what are these JSON files and why I need them? So what I do so basically to in order to generate the system SM file the AI need needs to understand your codebase right basically so uh the one way of doing this will be asking

AI hey go and check my codebase and generate uh documentation I tried it it I tried that it it it's not always working well because it's using different search algorithms and most probably it will pull some of the files and when it feels that oh I high level understanding it will just start generating documentation on top of it. What I'm doing I'm generating JSON files from my

codebase basically uh to ignore the implementation of my method. Let's say if you go if our unit is one method right I just ignore the implementation of the method by itself but I want to understand all my relationship between methods classes and services uh which is less information which can be included in the context. So that's why I run the CLI to generate these JSONs which basically

are kind of some kind of a graph on top of my code. And if for example if you look to this uh API layer I have this JSON files and I have a summary which um explaining my chunks and then each each chunk it's it's kind of it has some representation in terms of for example uh this one is because this is a API layer it has

all the APIs for example it says call caller name post I don't know arguments receiver you know for example if I go to my data I will have another representation probably about yeah uh about modules and entities and everything. So then these chunks now are small enough to just inject into the context. That's the reason only and because it's used only once for generating the system SM

file because I hope that uh moving forward you will always use spec mind to generate these feature files. So you'll have commulative updates in terms of feature specs. So you don't need this anymore. So that's why you can basically delete them. It's >> just around bootstrapping the project. >> Yes. Exactly. Yeah. >> History of project. So we have like a set of versions of system files and

the log files that changes from one to the other. That's >> Uh that's a good question. I think implementation is done. So I can show you. So >> because the chunk files you just throw you discard. So they're just like temporary. >> Yeah. Yeah. Yeah. So basically you just >> repeat the question for the uh >> sorry repeat the question. >> Yeah. For the audience. >> Yeah.

So the question basically u let's say you you implemented multiple features. Uh what's the kind of version history what what you have right? So I have only one system file. I'm not it's only one. It just being updated after each implementation. But I have a change log and as you can see it generated one change log. Right? If I want to understand how this uh system SM

file evaluated, I can always come to this u change log and here it tells what it did and why it did with notes and also I get this u feature specification file. So basically you'll have bunch of features specification files here. You'll have just one system file and you have all your changes in this change log. That's >> Okay. Thank you. Um yeah, so this is very

interesting. I I actually use a uh Amazon Skiro uh coding agent which has a similar spec feature but it's not as comprehensive as this is basically start with green field create requirements design and then tasks. Uh so this kind of ends on top of that by uh examining existing code bases which is great but uh uh how do you handle uh having codes get out of sync

with the spec right? It seems like if somebody makes just changes to the code directly, that's going to pretty much break the whole thing and it's going to be hard to get >> Yes, that's a very good question. So the question is what if someone just u change directly in the code? So now the the system SM and and code out of sync. uh that's why I

was thinking to uh implement this feature so I can regenerate the SM file you know iteratively and that's why I was thinking that I still need to keep these chunk files which I don't do now so the use case you mentioned yes it's a problem so if if I start using spec mine and at one point I just stopped uh so my system SM file will be

kind of uh out of date but uh let's say if if at one point I want to um resume. I mean I don't recommend this but uh let's say if there's you want to do in some way you can just ask AI to go and kind of try to update the system MSM file but it will not work well. So basically that's a missing feature probably that

uh which I have I think I even have in my GitHub issues. I I addit issues for myself just to remember. I think I have one of them to be able to you know like if you just temporarily stop using it and you want to resume be able to regenerate the system SM file not generate from scratch but just like you know like add whatever was added

after last point the good news that I have a change log so I know when last time you edited it or even I can look to the g history but yeah I think uh I think that's a missing point in spec now if you if you use it you need to keep using it uh always let's Any more question? >> Question. >> Okay, looks like that's it.

Let's give our speaker some love. Thank you. Thank you for coming out. Uh there by the way sorry there was a question where is the presentation. Uh I'm going to submit this to uh scale and I think there should be way of getting all the presentations. So uh it'll be on YouTube. uh or what you can do you can connect me on LinkedIn and I can uh

you can DM me and I can send it to you as well. >> So this is my LinkedIn URL and my QR for my LinkedIn. >> There's a live stream right now on YouTube and the videos should be edited out uh very very soon. Can't say. >> Oh cool. >> Thank you everybody for coming >> for coming. have a great rest of your day at scale. >>

Good talk like the demo basically demonstrate what I had like hypothesized and even heard like a few years back than I've heard over the years is that now like now you need just at a high level. You don't need the level code anymore. It's kind of like >> you're abracting out level detail, Test test test. Okay. And you can say >> hello. Hello. Hello. >> You could

also say this is a normal talking voice. This is a loud voice. >> That's what I I'm silly and dus. >> Okay, thanks. >> That sounds really good. You're good. [clears throat] >> You're closer to that speaker too. >> Acidating all channels of binaural hearing. >> I don't know. audio. >> You know what? Actually, we are not. I'm sorry. I missp >> that sounds appropriate. I think

like live captions or Yeah. And also because you know voice to text can be done for free as opposed to interpreter would be cool. That'd be fantastic. You know what I on this on YouTube you just you just get that so once it's recorded >> testing >> what's that it's too loud >> other people outside for Yeah, they have to like give you the caption file and

you add it yourself as It's dramatically a step backward. >> Starts soon. >> Soon. >> Yeah. So, how do you feel about everything so far? >> So far so good. get my slides. >> Um, how would you like me to introduce you? well, so you my name is a little bit hard to pronounce, but it's Kazam Zad. If you do divide and conquer. Oh, I I do

know that. Kazam Zad. Okay, I can do that. >> And Abe like the American president, not like the Japanese president. cool. You are Do you want me to give like a title role like? >> Yeah. Professor >> Professor at University of St. Thomas. >> Yep. >> Okay. And you got like 50 minutes or we going to have time for questions at I have these Q cards and

I think for a lot of people it's convenient if I cue them like when like until we out of time but some people prefer me to cue them when like we are like 10 minutes, five minutes or one minute into now time for >> But you choose like how do you want and which do you have a preference? >> No, I think either is fine. >> Do

you like questions all throughout and stuff? >> Yeah, the questions all throughout are fine. Well, then yeah, then I got you right there. Don't worry. >> I'll set a timer or two. >> I I've got you backing you up in case yours fails. No, don't worry. I'm here, >> So, we got this together. if somebody asks a question, YouTube cannot hear them unless they're miked. So, I

go run and put the mic in their >> Or you can repeat what they say if I'm too slow. >> I'm try to be fast. And if people have questions, I'm gonna make them talk their hand go high because I can't see them. Think we're >> Good to go. You're still in the mic. All right. Hello. Hello everybody. Welcome back to Scale Developers Track Scale 2026. Um

here we have our next talk from Abe Kame Zade uh who is an assistant professor at St. Thomas University. Um he's going to be giving a talk on OM's um forward and reverse engineering database erds versus Django's RM and migration tools. Give a round of applause for Abe. >> Well, thank you. Um, thanks for coming to the presentation. I'm going to be talking about object relational mappers

and entity relationship diagrams and uh the kind of parallels between the two. So, um, I want this to be accessible to kind of beginners. So, I'll try to go through all the acronyms in just a second, but um, just so I can kind of read the room. Um, how many people have used SQL in the last year or so? Okay, so I probably don't need to explain

too much. And how many people have used Django? Okay. And um, within Django, the OM I guess a little bit. Okay, good. So I'll uh try to skip over some of the like basic details but um otherwise I'll try to go through everything carefully. So um because I teach databases so I try to teach to people who don't um know anything about databases and um so I

teach in St. Paul, Minnesota, but I've been coming to scale since I was a student and um I like to use open source tools, but I use Oracle at work and um so I wanted to try out open source tools, in particular DBver. They're a supporter of scale and I saw parallels between forward and reverse engineering features in entity relationship diagrams erds and Django's object relational mapper

or OM. So I'll define these terms but it seems like most people have heard of these at least. So entity relationship diagrams or erds are diagrams that visualize a database's structure. The nodes represent tables aka entities. And so this is an example that we'll go through. So we have a presenter table and it's um we also have a presentation table. So this is kind of like a

model of scale talks. So not every presentation has multiple speakers but if you wanted to have multiple speakers potentially and I think there are some uh you would have to have a many to many mapping between presentations and presenters and to do that you have this many to many mapping table that has multiple different names like a join table bridge table intersection table association table etc. And

so uh this is modeling that many to many mapping. um basically um entity relationship diagrams are kind of more on the database side and object relational mappers are a little bit more on the programming side. Um, so if you're more on the programming side, tables in databases roughly correspond to classes in programming languages and the rows correspond to instances. And then the edges represent relationships between the

tables. So these edges here uh mean that the way that we would read this is the presenter has uh one row in the presenter table has many rows in this presentation presenter table and I don't know if you can see that on the the screen but it's a kind of looks like a it's called a crow's foot. It looks like a crow's foot. That means that uh

one row here corresponds to potentially many rows here. So a presenter can be registered for many and uh every row here though would correspond to just one presenter and one And so this is a foreign key. These two columns here are foreign keys that refer to the other two tables. And the edges, arrow head and tail shapes represent the cardality patterns. Uh so one to one, one

to many and many to many. And here you don't see any direct many to many mapping because in debaver you can't directly represent a many to many mapping. And so if you're trying out DBver for the first time, you might get kind of um stumped by looking for the particular edge shape that is for many to many mapping because it isn't there. And I'll go over why

that is. Uh but basically the different ER er diagramming tools show different levels of abstraction and DBver is closer to the actual database rather than a kind of abstract data definition or data and ER diagrams are more than just visualization tools and that's kind of the point of this talk. So there's two main operations forward engineering and reverse engineering where you can generate SQL code from an

ER diagram or you can create an ER diagram from SQL code or the actual database. Okay, so here's just a kind of schematic. Forward engineering goes from an ER diagram to the database schema and reverse engineering like the name suggests goes reverse. now to get on to object relational mappers. Um so an OM is a software library that helps to store and retrieve aka map programming language

objects to and from relational database. And OMS often hide the details of SQL from programmers and that can be kind of good but um it does help to know the details of SQL to see the bigger picture. So in a programming language objects can have all sorts of data in them but relational databases like to have data that in tables that is dedicated to just one specific

type of information and this is what's called normalization. And so there's this difference in behavior between the programming language and the database. And this is called object relational impedance mismatch. Just a kind of fancy name that uh they're not a kind of onetoone mapping from the programming language to the database. So I'll be using Django as an example for the object relational mapper. And object relational mapper

also has a two-way transformation process. So it can take programming language code class definitions and generate SQL table definitions from that. And this is called migration. And there's a couple commands actually that we'll go through. And then the so that corresponds to forward engineering. And then what corresponds to reverse engineering is where you take database code and generate Python class definitions from that. And this is a

um command line argument called inspect DB. Okay, so here is the schema for uh migrate and inspect DB. So you can see it's pretty similar to the forward and reverse engineering. I'll go over these more, but um these are just some examples that you may have heard of. It sounds like most people have heard of Django, but there's other OMS and there's other erds. If you were

in the talk before here, before this one, um there's other tools like mermaid that can also generate entity relationship diagrams. So these entity relationship diagrams and object relational mapper features have different names. So one of the things that I wanted to do is to present them together because I think it's kind of Just uh in case you didn't register it before, this is the similarity of both

processes. The only thing that's different is we're to going to and from an ER diagram uh with the forward and reverse engineering and we're going to and from a models py file in the case of So I kind of wish that I had realized this earlier. So hopefully it'll help others and it also helps to understand other tools like UML unified markup language or modeling language and

pi reverse. So pi reverse is a pretty useful tool that if we have time I will uh present that. So I want to describe and compare and contrast forward and reverse engineering in DBver to Django's migration and inspect DB commands and compare and contrast ER diagramming tools and give a tutorial example with DBver and Django and show parallel techniques from this uh PI reverse tool and uh

two-way communication is ideal. So um please ask questions or if you want to share anything please feel comfortable. So while I'm on the slide, does anyone have any questions? Keep going. Okay, so first forward and reverse engineering. I think I'll go over this uh quickly. So I think everyone knows SQL. Uh we can divide SQL into different parts. The two parts that are salient here are data

definition language and data manipulation language. And the data definition language is where we create table structure. And that's going to be primarily where both of these tools work at. Um, but Django's object relational mapper also does migration of data, not just the database design. Okay. Um, so there's different levels of abstraction in ER diagrams. And if you want to compare the different tools, you kind of need

to have reference to these different levels of abstraction. So at the most abstract level, you just have entities and relationships. And this is just something that I made. It isn't any one particular tool. But here you can see a many to many mapping directly between uh this example is institute and students. So maybe this is like a college or school name and then this is the student.

So the way that we would read this is one student has can have many institutes that they're affiliated with but they need to have at least one. And so that's kind of like there's no free range students. And then the institute can have many students but an institute may have zero students. So maybe the institute is just a research institute and there's no students. Okay. Okay, so

that's the most abstract level. Then we can go a little bit more detail and add the columns and then go into a little bit more detail and add these join tables. So there's a lot of different names for these like join, bridge, um, junction tables, associative entities. Um so this is still a many to many mapping between student and institute but it has this third table implementing

the many to and so some tools will require you to make this third table and other tools will do it for you automatically. And um debaver is in the latter case where we'll have to make this manually. But in Django we'll see that this third table will be created automatically. [snorts] Okay. And I went through the forward already. And um so you can think of forward engineering

as exporting the ER diagram to a database schema and reverse engineering as importing the database schema into an ER diagram. Question >> okay. >> Yep. I'll repeat the question. Thanks. Uh yep. So uh the question was how do userdefined functions fit in here? So some tools will not only generate the create table statements but also things like surrogate keys and um triggers and they may also um

create userdefined functions too. But I'm not 100% sure about those. But I know triggers are something that these will sometimes generate for you. So that uh saves a lot of work. Um I don't see that in debaver. So that one it seems like you have to do that manually. >> kind of exp. >> Yeah in the visualization sometimes there's uh different symbols. Um so these are kind

of the standard symbols but uh for example one that I've seen in Oracle data modeler is uh no transferability. So you can kind of think of these relationship as a a um a child and a parent relationship. And so no transferability means that you can't basically adopt a child or kind of transfer their parents. And so there is another symbol for that and that's implemented as like

a trigger that will uh run before you update the foreign key of the child table. And so that is pretty handy that that you can do that so you don't have to worry about the logic of the triggers. >> Yeah. No, it would be uh represented in the symbols. >> Yep. And I don't have an example of that but um yeah that it would be a different

symbol. And so actually these are kind of the standard symbols and there are some other symbols too like for cascading deletes sometimes they'll have a different symbol for that. Good questions. Any other questions? So that um is one of the things that's nice about some of the tools that it does have um these other kind of uh constraints. Okay, so this is a kind of historical um

ER diagram that it um ER diagrams have been around since the 70s, so before I was born. And uh they don't look like this anymore. Um so this was before they had the crows foot style diagram and this is a um case where you have the many to many mapping directly um displayed. So this is PG modeler and uh here's the one that we saw again and

so here are some of the um synonyms for this third table bridge table junction table join table. It's kind of a pain that there's all these terms. Does anyone have a favorite term for this? >> Lookup table. Okay, I didn't put that pivot table. So, it's a pain teaching to uh new students, but I like to tell the students that um whenever you have this phenomena where

there's a lot of words for the same thing, it's kind of a a display of the importance of the thing. So, a lot of people have took it upon themselves to name it. Okay. So, DBver is the one that I'm going to be showing and that um is a supporter of scale. It supports a lot of different databases. Um it's kind of like a premium model or

that the there's a paid version that includes forward engineering, but the community one does and um it's more databasecentric as opposed to modeling centric. So it doesn't include these many to many mappings. Um my SQL workbench I believe it's uh I'm not expert at this but I believe it's similar to debaver that you'll have to make these uh lookup tables, pivot tables, intersection tables. Um PG modeler

is more modeling centric. Um, another thing that you can kind of tell what is modeling centric and what is kind of more databasecentric is whether the ER diagram software is bundled with the same IDE for writing SQL. And so PG Modeler and Oracle data modeler are standalone tools for ER diagrams. They don't allow you to run SQL code in those tools. And these are kind of like

a mirror images. So this one is open source, but it's not free. And this one is free but not open source. And um this one you can if you can compile it, it's free. And um if you kind of vibe compile it, it might take an hour or so. and then schema spy is just reverse engineering. Irwin, I'm not too familiar with that, but it's not free

or open source. And then there's DB schema, which is um a software as a service. And then the presentation before this uh mentioned uh mermaid and so that's a kind of more general markup language that you can use to generate all um diagrams. So some pros and cons. The ER diagrams are visual. They have a guey. You can manage different levels of detail ideally. Um sometimes they're

kind of a specific level of abstraction. It's easier for beginners. Um, it may or may not be integrated with the database IDE and it keeps relational database theory as opposed to object-oriented design. And the cons are that the tools are often specific to databases and there's not always the both forward and reverse features, forward and reverse engineering features. Sometimes they're only available in enterprise editions and they're

not designed to be integrated into applications. They're not like libraries. They're just tools. And I put this as both a pro and a con because sometimes it's nice to have everything in one tool, but sometimes it's also nice to just have um one tool for each purpose. Okay. So now moving on to Django. Django is a Python server side web framework. uh usually the kind of focus

is the web server of course but the OM is very powerful and we'll be considering that part not really looking at the web part uh the component deals with mapping objects that are defined in Python to the relational database here's some other object relational mappers um does anyone have any um hot takes on comparisons between these I've had um I've had a lot more uh flex um

flex flexibility uh or sorry expressivity using Django's RM than just straight up SQ Alchemy. >> Yeah. I I found I found I found just it just it's more expressive because it's more declarative in that way. >> Yep. Yeah. Go ahead. >> Uh, my hot take is that I honestly decided not to use them. >> Okay. So, just straight SQL. >> Yeah. Admittedly, this was because I decided

to do a project to I decided to not use it for my main project in order to learn SQL. >> And I also just like SQL. >> Okay. But do you have something to do the sanitization of the user inputs? Yeah, the Python the Python default library can sanitize. >> Okay, good. Um over there. I've used quite a bit of the entity framework and the like um

having the ability to do like select where all that kind of stuff in code um is really really nice. It's very easy to show people how it's going to >> Is that that L link or LQ? >> L I NQ. Yeah, link. >> thanks. Just getting started on started with both of them. I um started using Tortoise which is uh being sold as hey it does deals

well with uh async Python async.io Well, uh the training materials were unusable and so I decided, okay, I'll try and fall back to SQL Alchemy. Uh it at least has a lot of training materials. [snorts] It's not all great, but at least it's there. >> Okay, good. Thanks. >> I didn't consider that, but uh good to know and put that on the list for the future. Another

question. Yeah, I hate to bring PHP into the mix, but Laravel has a really good and like a really good query builder and OM and it makes PHP tolerable. >> Okay. [laughter] Okay. Good. Good to know. So, Laravel is also another option. Okay. And so like I said, the migrations are roughly equivalent to forward engineering, but they have version information and they also move data. And then

the inspect DV is when we want to have an existing database and uh we're managing ourself not uh managing it with Django. And um this is roughly equivalent to Okay. So, Django has really good cross database support. Uh, in the demo, I'm going to kind of go um between Postgress and um SQL light and it's used as a library. There's command line scripting support and you can

do more than just forward and reverse engineering. Like I said, you can store the migrations both in the database and in version control. And uh it's not as beginner friendly as er diagrams. There's no guey. It's not integrated in the sh that there's um not IDE support. Um there may be some but uh it's not like kind of um Django IDE. And also it prioritizes object-oriented design

over strict relational database design. And this is what's called a leaky abstraction. It's kind of what leaks through this um uh Okay. So now I'll go over a demo of how um well first I'm going to go over forward engineering. So we're going to go to DBver and convert the entity relationship diagram to Postgress. Then we're going to go to Django and show the corresponding kind of

forward engineering equivalent where we're going to write some Python code and generate create table statements. Yep. >> Yes. Yeah. Yeah. So, it wouldn't be how somebody would design the database schema if they were just using SQL. I'll try to point that out later. Okay. Um, and then the third part we're going to do reverse engineering. So, we're going to go back to um Oh, wait. We're going

to look at the tables that were created by Django and then we will um see them in debaver and then we'll the tables that were created by debaver and show the automatically generated Python code from that. And so this is kind of the general flow that we're going to do. We're going to create an er diagram then do forward engineering to Postgress. Then we'll create this models.py

file. Do migration which is kind of aka forward engineering to SQL light which is the default database for Django when you are just doing development. Then we'll do reverse engineering. We'll see that Django has a lot more tables that are created by default and it also has um this uh intersection table join table that's created automatically. Then finally we'll go from the the code that was the

SQL code that was generated from debaver and then we will generate Python classes that can be imported into Django. Okay. So first we will convert the ER diagram to SQL create table statements. And so this is kind of the flow that I'm going to do. And I'll switch over to debaver. So debaver has this uh so I already have the diagram kind of pulled up. Let me

close that. So you'll kind of get the taste of um creating a diagram from scratch. So you go to the connection that you want to create a diagram for. So the diagram doesn't live independently from the connection. And that's kind of why I called this database centric rather than Um sorry well you won't have to read that. Um so um what you do is you go to

the connection. This will allows you to browse the connections and um I have this empty public schema and I think in pretty much anywhere if you click here and go to I guess you have to go uh one step down. Actually, if you go to like public or postgress here and then go to Oh, no. I guess you have to go to the public and then go

to view diagram. So, it's a little bit tricky to kind of figure out where to create the diagram. Uh, at first, that's the kind of benefit of having a dedicated tool that you open it up and you're in a diagram. But, uh, here you have to poke around a little bit. So, we'll go to view diagram and it'll be empty, of course, because there's nothing here. And

what we'll do is we'll just rightclick and then go to create new table. And we'll call one table presenter. Oops. Presenter. And then in here, so I made the font bigger so you could see, but now it's kind of a little bit um [snorts] uh the [snorts] font is now or the columns are overlapping um so what you do is oh start in the columns. So uh

even though we'll create the index first um you can create the index in the heading uh so we'll go create new column and the first column we'll say is ID and so this is a little bit small this is uh data type serial not like the kind you eat for breakfast but um like a incremental ID and um we'll say that it's not null and we'll will

uh set it to be unique um it's going to be a primary key. So that already creates the primary key. So other tools may automatically create the primary key for you. Um this one is a little bit like I said more closer to the underlying SQL. So you have to create the ids manually. And then I'll create a column called name, like the presenter's name. And I'll

make this uh text. I'll say that it's not null. I'll say okay. And then I'll do the same for email. I'll make this uh text data type and not null. Okay. So now we have this uh entity the columns defined and um we'll go to save and that will generate the SQL for us. So this is pretty nice that it will generate the SQL for us. Uh

if you're learning databases this can kind of help you to learn the create table statements by seeing kind of the picture getting converted to SQL. So we'll say execute and then now if we go to diagram here we'll see this in the diagram. this is one of the kind of wonky things that if you try to create a table here it will give you a different it

like the look is a little bit different than the um dialogue earlier. So it just goes directly into the columns. So, I'm going to close this and go back to this public uh schema and go to refresh. So, now I'll see the table that I just created. And then in this public schemas er diagram, I will create another table. And here you can see that it looks

the same. The dialogue is the same. So, I'm not really sure why there's this difference there, but uh so we'll call this presentation. And like we did before, we'll create a column for the ID type serial. Go back into this and make it not null. And Okay. So, I didn't check the index uh button when I was setting that up. And so, I think if I go

to this new index from selection, it will make that into an index. And then we'll add another column for the title of the presentation. And we'll make that text. And just to kind of in the I'll make that not null. Um for the sake of time, I'm going to skip the room number or the room and I'll just go add a um starts at for the time

that the talk starts at. And we'll make this a time time zone or time stamp with time zone. Okay. And I would probably also want to have an NZ at um too, but I'm just trying to make the demo not go over time. And I'll also check that to make um not null required. Okay. So then I'll save this and um you can see that it was

a little bit different. the index now is uh created as a alter statement. It wasn't in the um the create table statement. So I'll execute that and again I'm going to close this window and go to refresh from this window. And now I need to make the intersection table aka join table aka lookup table aka what did you say was the other name? >> Pivot table. Yeah.

Okay. So, I'll go and we'll call this presentation_presenter. And we will um go directly to foreign keys here. And so we'll add a new foreign key. And the first one will be pointing to the so this is a little bit uh hopefully you can see when you you want to specify the presentation. Oh no unique keys in table presentation. >> What's that? Um well the presenter and

presentation we created and it has there's nothing in it but there should be the primary key >> um maybe it wasn't let me go back in here. And unique. >> this one. >> This one. >> Primary. Yeah, for some reason it's not letting me click on this. That seems like it would be the right way to do it. let's see. I'm just going to Sometimes the best

thing is just to delete and start over. Let me Let me try one more time and see if this So, there's the index. It's Not letting me check the Sure. Let me um I think it's probably easier if I So, I'll go back here to the tables and uh I'm just going to and say yes and then try again. So, sorry about that. So I'm going to

create a column and make sure that this ID column is serial I'm going to make sure that it's a unique primary key. And uh just to save time, I'm going to not put the other columns uh so we don't run out of time. And then I will do save and execute. Going to close this. Close. Oh, actually let me >> yeah, I was in the pro in

the um process Okay, I think this was the new table I'll just uh remove that and start from fresh. So, uh presenter. So you can kind of see that um there is some things that are um if you're familiar with SQL, it might be easier just to kind of create the tables with SQL because you're kind of fighting um the interface presentation presenter. And so we'll go

to the foreign keys, create a new foreign key. In the presenter, we'll go to this column and uh select that we want to create a new column. And we need to go to column options and change the name to presentation ID. similarly I'll say okay we'll do the same thing for the column. Hation. >> I did it for presentation. >> Let me just go cancel. So there's

unless I named this wrong. Let's see. Create foreign key presentation. Let's go through this one more time and see new. Okay. And we'll call that presenter and say okay and okay and now we'll go to save this. Oh also uh we want to put an index so that uh those two columns together are unique. And so this is one of the things that I'm not [snorts] sure

if Django does this but it it will do it in a different way that it'll create its own kind of surrogate key. So increasing index. Um, so here we'll create a new index here and I'll I'll make this a unique index and select both of these for the unique index. I should be able to save this and you can see the well that'll be small but it's

a create table statement for this third table. And so now we'll go to and we'll close this. And if we refresh this now we should be able to join table aka linking table aka pivot table. Okay. So that is the kind of first step that I want to do. Now let's go back here. So now I want to do the Django example. So we'll do the same

example in Django. How am I doing for time? 15 minutes. this is this part here. And so this is the general thing. We'll install Django into a virtual environment. Create a project called scale and then an app called talks. So the way that Django organizes this is you have a project and then you have different apps inside the project. And so you could imagine scale has a

lot of different apps. One of them is talks. Maybe another one would be uh the expo hall and maybe another one for sponsors. Okay. And then uh we have to register this new app and then we can make the migrations. Okay. So first step is to make a virtual So I'll use UV VN I'll do VN And then I will activate it. Then I'll do pip install.

Oh, UV. PIP install. I'm new to UV, but it's pretty great. Um, UV pip install Django. And so now we have Django. And we'll use the tool Django admin. Oops. Dingo-ashadmin to start a project called scale 23. So then we'll cd into scale 23. And if we view the directories here, we'll see that we have this manage. py file that's kind of like doing the same thing

as the admin Django admin but it has the settings. So these are the settings of the project. So now I'll create an app with the manage.py script. So start app and this is talks. And so now we have this talks directory. You can see that there's a migrations directory that's empty right now before we have any migrations. And we also have this models py file. That's where

we're going to put in our models. So I'm going to open the models. py oops talks. So each app will have this models. py And so right now it's empty. what we'll do is we'll add these two models dot. So it's inheriting from this models.mmodel class. And uh we'll create we don't need to create an ID because Django will do that for us. Um, we'll say uh

name is equal to models dot I'm just going to copy and paste this in because I want to make sure that I don't go over time here. So, I'm gonna What? How are we doing for time? >> Good. Okay. Um, so we have the name and then also the email. So this is kind of doing the same thing that I was doing in debaver but uh I'm

doing it now in a python class and then I will do class present oops capital. So we have to kind of keep Django or Python's convention. So we'll use the kind of camel case for classes and that will also inherit from models.mmodel. And to speed things along I'm going to just copy and paste these Okay. So we don't have to create this third table, the intersection aka

join uh linking aka um pivot table because we have this and this will actually create objects that have a kind of list valued attribute in the Python code but it will create this third table when we do the migration. There's another option here that we can put uh related_name and this would be this would put the a list in the presenters oops. >> Yes. Yeah. So we're

actually having to do a lot less work here. And this is kind of typical of what you would See, if you had a modeling specific ER diagram tool, you wouldn't have to really worry about those. Okay, so now I have this saved. I will go in and edit the the settings file. So that's in scale 23 and this is where you see the different apps that come

with Django. So it's called the batteries framework because it has all the user authentication and content types and um authentication built in. And so we're just adding to the already existing functionality. So we'll save that. And so now let me just do the tree command first. So we see that uh we're still where we were before. But when we do make migrations, generate two files. So we're

generating this talks migrations initial and then we're also creating this empty database that we will populate in a Uh so the next one is optional but this I don't have that here this command called SQL migrate that will allow you to see the SQL. So if you don't do this command you'll be fine you will just kind of kind of blissfully be unaware of the SQL. So

this is SQL migrate and then we have to specify the app talks and 0001. So this generates the two tables talks_presenter. So there's this convention where you'll prepend the app name as a prefix to the table name. So talks_presenter talks_presentation and then we create this third table presentation. So that corresponds to the third table that we created manually. Okay. So that um allows us to visualize that.

But like I said, we don't even need to do that. Uh we could just skip ahead to this migrate command. And that's going to actually create all these tables and the talks app is just one of them. Uh let me just show also if we want to see the migrations file 01 initial. So this is actually kind of cool because it's the Python representation of the create

table So these create table statements are represented as a class migration which is a list of operations. Okay. So that is now you just kind of have to trust me for a second that the tables are actually there. But um I'm going to go to this next step of reverse engineering where we will go from the we'll see them as an ER diagram. So to do that

what we need to do is go to and then create a new Um, so here we will go select. I swear this like seems like it's a different order every time. Oh, here it's right here. SQL light. And then we'll find the SQL file that we just created right here. Now go open and finish. this connection and we can do view diagram and so now we have

a lot of other tables besides what we created. What we created is right here. So we see that this intersection table, join table, linking table, uh pivot table was created automatically for us. Uh we also see there's another example of this here. So we have groups and users and a user can be part of many groups and then a um group can have many users. Okay. So

almost done here. Um so the ne last step is to view Django generated tables in debaver. Oops. To uh sorry to view the DB generated tables in uh Django um with this inspect DB. So I'm going to also copy and paste here so that it's a little bit quicker. Um, so what we need to do is go into the settings file again. So, Emacs scale 23 settings.

py. And we're going to edit our connection to the database so that instead of being connected to we will be connected to So, I'm never sure how specific Python is about the indentation, but probably better safe than sorry. So, now if we do manage.py py inspect db we need to install uv pip install psycho pgg2 so we don't have the postgress driver in um in python yet

but now we do so now if we do manage py inspect db we'll see that we generated the presentation table, the presentation presenter. Oh, sorry. These are classes that were generated from the tables and they convert the names. So, it understands the naming convention. It'll convert the to the camel case convention of the class rather than the snake case. And you can see that this uh presentation

here we I think that's where I kind of skipped putting the attributes here. So this is just to kind of refresh this is going this original table here to Python classes. So it's kind of nifty and that's what I wanted to show for this Um there's also uh this pi reverse. So this kind of idea of forward and reverse is kind of uh shows up in different

areas and um I don't have time to run this but if you want to try it these are the commands. So this will basically generate a class diagram so we can see the classes oop that got created. I'm gonna go switch here. So none of the PDF viewers is kind of ideal. Here we go. So here we have the presentation and pre presentation and presenter tables or

sorry classes. Those inherit from model and um you can see kind of these container relationships. So the presentation has a many to many field and a char field and a text field. So to wrap up, I we compared these two different tools and kind of showed their parallel and I showed PI reverse very briefly. Um it's kind of hard to avoid AI. Um so I left a

part about AI at the end. So visualization is kind of a way to better understand AI generated code. And so you could use this technique as a way to visualize and we saw that actually in the last talk um in this room that there was like generating um interaction diagrams with mermaid. Um and also the code generation part is also a little bit like AI. So these

tools came from the 70s and 80s and back then generating SQL code from a diagram was kind of like their AI back then, the expert system era. So that's all. Um I guess we're running out of time, but I guess maybe one or two questions. So um using Django and uh you know the reverse engineering stuff would you say that's kind of uh what you would prefer

to do bootstrapping a new database uh bootstrapping a a uh new SQL database or Postgress database from from like an existing one like say you're you're you're migrating across SQL versions or or a new version of Postgress that's that's the ideal place to be using it or >> I think so So yeah, being able to change the connection and still generate the class files >> um allows

you to kind of be at this ideal level of abstraction so you're not worrying too much about the database. I'm sure that there is like that I mentioned the leaky abstraction that there could be some issues that you'll have to deal with potentially but um I believe Django takes care of that um pretty well for you. All right. Thank you very much. Give a round of applause

for a cousin >> and thank you all for the also thanks for the uh volunteers too. >> Oh no, you did great. Thank you so much. All right, so I will help you get set up uh in a moment uh at uh five o'clock. We have one more. We have two more talks here in this track today. Okay, we have the next one at 5:00 and uh

I look forward to seeing you all Well, I can speak a bit about my last startup. So, I had a failed startup for nine months. Uh, so it had been February of 2025. Uh, we raised the seed round and one of the questions we got from our VCs at the time was this is we were like, "How much money are you raising?" We're like $8 million. It

was going to be a multicloud startup for cloud portability and they're like, "Oh, this is great." Um, you won't have to hire hardly any engineers because AI will write all the code now. And I thought that was the most ridiculous question. I I I flipped the dummy bit on that VC that asked that question of us or made that statement. I'm like, that is so ridiculous. There's

of course you need a lot of engineers to write this code. And what I found is our CTO was really cynical about that as well about AI because they had tried AI like maybe six months before that and now a year later he was right like now he wasn't right 12 months ago but I couldn't have foreseen at that time um and that whole startup is essentially

um you know I left the startup because I don't think it's but the I think a lot of what we were doing um is automatable now because you can go to an AWS cloud um point your AI model at it and say I want the equivalent infrastructure on GCP or Azure and the models can do that now and it wasn't like that before. So I think that's

like a an example of how fast this stuff is changing. >> So that venture capitalist had the crystal ball. We need to go talk to So I I see a lot of questions in open source land about AIS like where where is it learning to code? uh what what license is the code licensed under when it spits it out? Um I'm getting a bunch of slot pull

requests. What do I do with them? Um should I should my project allow people to to use AI or not? Um how do new contributors get started in in an age where if you ask them to solve an easy bug and they can just generate code in three seconds and submit whatever comes out and they don't have the skills to review it themselves. Um, so I think

there's a lot of questions in open source world about how does this fit in. >> Cool. Um, so I think I think the followup for me is just there's a lot of engineers in this room. I'm assuming a lot of folks kind of between CIS admin to DevOps to engineering. I guess how should we be thinking about it today? Like what how should we be approaching it?

What do you like? Give me the hard opinions, you know, whatever they are. Should we be completely using it? Should we be not coding anymore? I know 90% of the room raised their hand when we ask that question. Should like what should we be doing? >> I I don't have the answer to that, but uh I think a lot of people here are here because they like

coding. So, we have to keep that in mind as we figure out what the new jobs of the world are. But I think one thing is interesting is just the terminology that you kind of hit on as you were asking that question. like they were engineers and then they were developers and now they're coders and like the the terminology even changes as our world changes which is

interesting >> man. Uh I'm retired so I have less skin in the game. I had just be honest with myself. My views on this are very different than my daughter's views who's 18 trying to enter the industry for the first time. So I just have to make sure that I'm being reasonable with myself. I can afford not to care about this. I can afford not to fall

into the hype. Throughout this conference, the last couple of days, I've seen a few people walk up to me and their eyes are just lit up. Agents, agents, agent, what are you doing with agents? Our agents will talk to your agents. Your agent will call my agent. And then I'm like, but why? Because we have stuff to do. My agent knows what needs to be done and

your agent knows what needs to be done and they're going to work it out. And I'm like, so then what are you here for? and they're just like stunned like what do you mean? I'm here to tell my agent what to do and and I'm trying to listen. I'm trying to like be patient. And the weird thing about this when I see another human being, the thing

that makes me excited about that human is I am going to climb this mountain. I am going to learn to cook. I'm going to go somewhere with my child. I am going to grow. I'm learning how to play guitar. And one day I'll be on the stage. I'm going to write a song about love because I had this experience and I want to share that experience with

the world. And never once have I asked them, well, how fast will you write that song? Productivity wasn't part of the equation. There's nine billion of us individuals having experience. We make happy accidents. And when you think about life in general, and maybe some people argue that life may not be necessary in those regards, in those terms, but we created the data set. I always try to

remind people, you created the data set. You created all those YAML files. You created all that source code. You created all those bugs and the fixes. You created the questions on Stack Overflow and you've answered them. And we've taken all of that and we shoved it into a machine that is trying to approximate either. Sometimes it repeats it back to us. I know because I got the

class action lawsuit from Enthropic. Kelsey, we've taken your book. We've used it in our model. We're gonna give the lawyers 80% of it and you can split the other 20% with the rest of the authors that we've taken the information from. So these are the actual facts. Like these are like real things. So how should you think about it? Well, if they took your book, you might

have a little gripe knowing that your intellectual property was used in a machine like this and it's being rented back to other people for roughly 20 bucks a month. Right? That's one way to look at it. The other part is like you're still important, right? maybe some of the work that we're having agents do was useless work to begin with. My daughter gave her first talk yesterday.

>> And they asked her after you went through this whole learning Kubernetes and Docker and all of this thing, how should you how should it work? And I watched her because I know my daughter, she gave the answer she thought she was supposed to give, which is I'm willing to learn it if that's what's necessary. Good answer for interview, good answer for LinkedIn. And it feels like

that's the pressure the industry has put on all of us. this is how you better think about it because if you don't think about it this way then you're going to get left behind. We're not sure by who but left behind you will. And after the talk I sat down with her and I said listen you said the right answer probably for there but that probably isn't

the right answer. I think the right answer is no one would build this thing again this way. This is this is a this is a tragedy. Like we have 50,000 configuration formats. We have a thousand programming languages that are all incompatible. We have a thousand ways of doing things. And I remember in her talk that was so dope, and this is what I'm going to wrap. She

started learning all this stuff because she learned how to write code. And she wrote this really nice burnout timer, right? For someone who loves studying, has all this pressure as an 18-year-old that's about to graduate college. She built this timer to just tell her like, "You're studying too long. Take a break." And it was a cool exercise, something that she can actually use. She learned Docker. She

learned how YAML files. She learned a little AWS, gave up on AWS, went to Digital Ocean. And she did all of that and she showed us that her app was deployed. And she said, "I went through all of that to have the exact same thing that I had before. Why are you all doing all these intermediate steps?" And there's no way in the world that we're like,

"This is the best we could come up with. This is just what we have." And that's the way I think about Loom. LM are a product of what we built. That's what's in the train set. These things didn't fall out of the sky and just bestow knowledge on us. This thing has been trained by the best of us and the worst of us. And that thing in

the middle, I think that's the decision that you got to figure out that we still have to make. That's how I hope people are thinking about this. You're important. The models are great, but don't forget you have one up here, too. And that one needs to be trained because I don't think we can checkpoint society >> I do want to add another chapter to the story that

I told. So I had a failed startup with with people that didn't want to use AI. They weren't using the AI models and our engineering was relatively slow for what we wanted to accomplish. And here I work now with Ron at Flocks and we're about 25 people and the we have several engineers that are really trying to learn the new tools using a lot of cloud. We

have people using Gemini. We have people using codecs. And I found that the people that are really curious and good at sharing and evangelizing what they learned in a daily basis, they kind of like this one engineer, he keeps a diary of what he's learned that week from AI. And it's an experience diary. It's not like these are all the great parts of AI. It's like this

is the really frustrating part. I had to try to rewrite these tests and it didn't work and it [clears throat] failed and it sucked at it. But he's sharing his experiences with the team throughout week after week after week. And I saw the other engineers on the team then start sharing their experiences. So I think that that learning mindset and having someone that's curious and sharing is

helping the rest of our team like navigate this because it it is dizzying, right? I feel like right now if I turn away from like two weeks and come back that like the bleeding edge is like some new gas town or uh superpowers or there's all these like you know catchy names of the new framework that people are using but our engineers are learning from each other

and that gives them I think the confidence to to keep >> So so I think you mentioned engineers [clears throat] learning from each other like where where else are you guys learning what's latest? Are you actually trying things out? Are you just reading? Like trusting someone that you read from or how how do you keep up? >> I'd say I hear about new things from reading. Um,

and then I try them out. And I actually learn a lot from AI chatbots. I'm like, you can ask all those stupid questions that you would never ask maybe people in the room. And you can say, you know, someone mentioned this and I didn't understand it. Can you explain it? And then you can say, how does it relate to that? And it I think it's a really

good learning tool just in and of itself. AI are llm. >> I'm starting to feel like the last Jedi And when I go to the grocery store, I do try to find the organic things like because like the selling point is like this is just this fruit and nothing else. Like that's the selling point. Like it's just food and nothing else. Like yeah, you got to pay

extra though. The organic thing costs extra. this thing uh you know it's half price right we made some trade-offs for it when it comes to like learning things luckily for me the sources of information are I do a lot of VC work so due diligence before we cut that check and we're about to spend our LP's money hey why did you give this company $1 million what

did the founder say what are they promising to do and then I get to do due diligence so anytime I meet a founder's like we're going to use AI for this thing I say just do me the privilege of treat me like a smart person just for Just for this one call, don't say AI. Don't personify it. Don't say work in a box. Don't say digital workforce.

Any buzzword that works well on LinkedIn. Please spare me. Just talk about what it does. That's it. That's all I want to say. Don't say AI. Don't say rag. Don't mention any of the models. Just show me what you do. The worst founders, they don't know what to say. All right, Kelsey man. We import spreadsheets and we put them in another database. All right, just be honest.

That's fine. Some say, "Hey, I used to do this work for a very long time. I've watched my colleagues struggle putting information between three and four systems, literally calling gas stations to get an inventory check on the inventory in the gas station. It may or may not be accurate. They get that information and they put it in two or three systems and a team gets in a

circle and they have to decide, do we do buy one get one free at the local grocery store or not?" Right? Do we have enough inventory and enough profit margin to do that? Today, Kelsey, the way that works is lots of paper, a lot of inaccuracies and a lot of lost product and a lot of lost revenue. So, we built the system to try to streamline that.

And we do that by allowing people to take what they have. Sometimes it's handwritten notes, sometimes it's actual receipts from a big vendor. And we allow them just to put it in one place. And we do leverage some of these newer technologies because they can't say AI to read those notes and turn them into bits and bites that we can consume in a certain format. So we

normalize on the front end and then we just try to mimic the workflow that they were using before. We show it to them. It's like that's exactly right and we're getting the results we want. This is amazing because only three or four of us at this company could do it and they didn't want to do it. So that's what our product does. Our product takes a thing

that needs to be done that no one wants to do. And we think we have a few new primitives to finally get us over the hump. You could have done a lot of this with bash if you knew what you were doing. But there are a lot of things that were just so hard to rig up because you would have infinite if statements to parse all these

docs and libraries just weren't there. And I've been working on this for 15 years. And after these new things came about, I finally got much more predictable results. I've been able to kind of see my vision come to life. That's why I'm excited about adding these two pieces to the 30 we already have. And so when I see a founder do those things, then I start dragging

into the technical details. All right, show me what pieces of the stack you're actually using. And I'm like, oh, those are the winners. Those are the ones that are allowing people to build real products and solve real problems. And then when I'm hearing someone's like, hey, I haven't wrote code in eight months. Hell, I don't even look at the code, right? I see those posts on LinkedIn.

Hey, I'm a professional engineer. I just let this thing do its thing. and I look at it and be like, you know what? Does it matter? It's probably right. If not, we'll find out later. That to me seems highly irresponsible. That sounds insane. But then I check myself because I know what we tend to do as developers. Import big ass library from written by who knows who,

call function that you need, and then we deploy it straight to production. >> And so, are we even any better? So, now I'm just trying to be a little bit more pragmatic. Show me what you're doing. and I work backwards from there. So, that's the way I'm getting my information, but I'm trying to dig into the details that way. >> I love that. And and I think

you you touched on the subject now, right? You said um there are parts of the life cycle that we do certain ways and there are parts that we're doing differently. what is actually changing? >> Oh, oh, I love this. [laughter] >> So, there have been people that's like, I've been doing this for like two years. I was like, all right, I'm going to believe you and I'm

going to believe that the technology is really, really good now. at least better than what it was before. So, I don't want to have that debate. Show me the results, please. They're like, well, we sell insurance. Like, great. I'm going to go to the website. Hey, this looks the same as before. So, what are you doing with all this 10x productivity? And then people like phrase is

like, uh, we're getting through way more issues. Like, great. Show me the byproduct of doing all of this productivity. Are you getting paid more? Like, oh no, we're they didn't give out raises with all this productivity. Okay. Um, did anything get better that I can actually touch? And I think those examples are far in between. I haven't seen a lot of things just get dramatically better or

noticeably better. So, right now, I don't know how much is changing because when I was writing software, figuring out what to do was hard. And even if you did it, you could have made a mistake. Like Microsoft moved the start menu. You guys remember like what was it? Longhorn or one of these? They're like, "Oh, we're going to idea. We're going to do this metro theme." And

who needs the start menu? And if they did that really really fast and they put it out, people like, "Hey, put it back. Lower left is where it belongs." So even if you want to go 10x faster, you're not moving that start menu. And so now the question I have for people now is like, even if this all changed, where are the results? I need to see

the results before I'm all in on like this is real. Do insurance companies go into 10,000 verticals now because they can just write all the software they want or do they just stay in their own lane and we just end up with the same site managed by fewer people? That's the conversation I would like to progress to assuming that these things would just infinitely get better. >>

I mean I I I maybe have a follow-up question James product guy. Um I think one of the things that we've been talking about in the last few weeks right has always been like from the product sense and the engineering sense has been focus right like figure out what's the main customer problem that you have and build towards that ICP and all but then >> what is

ICP >> sorry ideal customer profile right like focus on who you're trying to sell it to their problem walk backwards from that but and there's always been the notion of like don't listen to the noise, don't follow all the shiny things. Um but now with I don't know agent AI like should we be taking our central product and oh that person wants a little bit of a

different variation. So just run it through the agent machine and make it compatible to that unique use case that no one else is going to use but now it's just such a low lift >> until it's not [laughter] >> expand. What do you mean by that? I mean, maybe one day the agents will also support it super easily for you, but you're going to end up with

a hundred a thousand one-offs and anyone who's had to support software, including yourself, probably wins this. >> Yeah. I mean, things can change really fast and I think if you want to know, go ask Stack Overflow. It's essentially out of business. I'm serious because like it was all good until it wasn't and now no one's using Stack Overflow. I mean maybe not no one almost no one.

>> So it changes really really fast. One of the things and I know Ron you don't already know this but we started thinking about um defensibility uh for you know we're a software company. If software is free well maybe they don't need our products. So there are some things that I think are defensible and so we started like writing those things down. So I'll give you an

example. Uh network effects are pretty defensible. So LinkedIn is really popular, right? Employers go there and say I want to hire employees. Employees go there to look for jobs and they share their stuff. That is a network effect. And because they're there, there's a flywheel going. I can ask claude to build me a business social network and it'll do it really fast but if no one's there

it's not valuable right so there are some things that are defensible and that we are trying to think about those kinds of things systems of record like workday or salesforce and these kinds of things those are valuable too and just because claude can do some of that stuff doesn't mean people aren't going to do those things so I think those are the kinds of things we're trying

to think about in terms of what new things that we can build now Should we build all those things and which which things make sense? We definitely think about the things that we are building that are going to have sustaining value and which things maybe aren't as differentiated as they used to >> I don't think we know yet what those things are. Like I think some of

them will really surprise us. So I read a stat today that said that readers um visits to like tech journals and tech online sites is down like 40 something%. Um, and I think all small creators, except maybe video makers at the moment, are suffering from this because now I go type my search in and if I have Gemini turned on, it gives me the answer. It re

it references the website, but often I never need to go click on that website to learn what I wanted to learn. So, I think we don't yet know what what's going to sur be. >> So, so someone someone actually told me something fascinating today. Um, and it seems so obvious, but I was like, "Wow." Um, someone told me like, "Most of the websites right now are really

wrong." And I what do you mean by that? I say most websites today assume that the person coming to your website wants to learn about your product. Okay. Okay. What's wrong about that? Right? Because like that's why we have a website. It's kind of like our billboard, right? There's like the use cases all like she told me no. She said by now most of the time that

a person actually gets to your friend page it means that there's a high likelihood that some model or some answer agent engine already gave it all the information they needed and now they're in a I want to either try it or dig deeper right so I I think there is a lot of paradigms that are that are pretty aggressively shifting right you know right now um and

I love the fact that someone actually raised a hand uh over there. No, no, it's okay. I'll repeat it. Don't worry about it. I'll repeat it. Don't need >> So my question for you is Thank you. So my question is hearing both of you talk about how, you know, the decline in media being generated and media being consumed that's being written and you talk about the decline

of Stack Overflow that it's basically a graveyard, but the models trained on that content and that's how they got good at it. So what's the next generation of models going to look like if people aren't generating human content? So, um I don't know if everybody heard the question, but you know, it's the it's like kind of like the AI inbreeding question, right? Uh what happens when we

run out of human uh like actual human content? Um right, Stack Overflow is dead. We're not necessarily contributing to it as we used to. Um what what are models going to be trained on in 2027? >> I don't have a great answer for that. I think it is absolutely a risk because and I I worry about this for open source right there one of the the hot

takes I've seen out there is like oh uh if let's say like some of these libraries that are JavaScript or you import like you know some 200k size node library to change some color on a font or rendering or something like that and you could just have the the AI model instead just gives you a 10-line snippet instead and then all of a sudden what used to

be a really popular, well-maintained JavaScript library doesn't have as many people using it anymore. And what's going to happen to that library, right? So, I I don't think we we actually know whether that's, you know, content that's going up, whether that's a well-maintained open source library. I don't know. I I do know that there's going to be big changes. Uh I just don't know how bad they're

going to be. Like one of my the theories is that like the really proven low-level libraries that have hardened um like compatibility matrices like that's really important stuff. You probably can't vibe that [clears throat] and just expect it to work. But if it's just like a simple font thing on a on a library renderer that's probably going to get replaced with, you know, 10 lines of, you

know, model generated code. So I I keep trying to look at history and I'm I'm not a historian at all. Um and usually I look at like the internet or cell phones or something in technology to understand technology, but in terms of content, I think it will just shift. I think humans are creators and we're going to continue to create at the edge of what technology allows

us to create. So I'm sure like we're we're missing some beautiful things in the past like some of the woodworking, some of the the quilt work, some of the knitting. Like there used to be beautiful things created that we don't create very often anymore. Like it's a hobby now. But we create some amazing things that weren't possible like a hundred years ago. So I hope that we

just shift up and we create things in technology whether it's solutions or art that we can't even imagine right now. >> Yeah. I know we have a few questions and and I I don't think I can just repeat them as well. I don't want to make you guys run. I think while you're asking that one, I think there's part of me that says, "Man, I loved all

the skills we obtained and grew. I love the curiosity that that brought about. I love being able to ask those questions and get the answers." But there's also a part of me that's realizing that maybe the UX that we put out there wasn't good to begin with. A lot of these REST interfaces weren't system designs weren't good to begin with. And the demand for backwards compatibility means

we got stuck with a lot of these systems for way longer than we should have. We've indust we've industrialized this stuff where we're training people on those things and giving them certifications and we're kind of slowing the industry down. And so as someone who is like bit of an AI skeptic, the one thing that I think is correct is that there is a challenge that should these

have ever been the >> and if you can ask a thing, forget the implementation detail, but if you can ask a thing and we get the other thing, that's a really good API. That's an intentbased API. We spent our entire industries or at least my career building these little Lego bricks of REST APIs that don't really go together and then I watch us write documentation with just

hints. I don't know why we do this. You build a standard library and you put hints on how to use it. This function creates an SSL certificate. Feel like I'm learning how to use it. And you're like, but but you wrote the library like you know everything right now. You know everything. Could you just give me an example of how to use it? Maybe give me an

example of how not to use it. Like no. No. Go ask on Stack Overflow. And we did this for decades. We come up with new technology, no manual. and the community jumps in and we all like, hey, even though there's no docs, here's how I think you should use it. And then I've extended it and here's how you should use it. And then we go on this

discovery mission every time. It was never good. It was never good. So now we have this machine that's like there are no docs for this, but I've seen the corpus of usage and I can spit out an example for the first time. Even if that example isn't good, it's still better than nothing. And so this is where I kind of give this technology grace. Search engines suck

right now. Ads, ads, ads, ads. Maybe right or wrong blog post or outdated. Just give me the example of what I'm looking for. So this intentbased system that we're developing, maybe that is the way we should have been doing it. RPC versus REST is a dead discussion. I don't want any of those. I just want an intentbased thing. Give me a VM with some storage. I don't

want to call 7,000 endpoints to coales what a VM looks like through Terraform. Is that really a good design? No. And so I'm actually looking forward to people maybe rethinking the way we build systems to be more intentbased than a collection of components that you glue together if you know how. >> Hey. Um, so you know, 150 years ago, master weaver wo fabric, made a cloth, make

garment out of it. Great. Obviously, industrial revolution gets cheaper faster. Um, fast forward now, fast fashion. If you wear a hole in your sock, none of you are probably going to darn it, right? You're going to throw it away because it's now industrialized. It's disposable. If what people are talking about the last couple months in particular, if that sort of progression is true, then in the future,

we'll have a future of software being disposable. Not all software. There's going to still be artisans creating crafted software that does the thing, but there's going to be a lot of cheap good enough to use until it you get a hole in it and then you throw it away. Um, so I guess my question is, um, if you could talk about if that's true that we, if

we were in that future where software is now disposable, um, some much of the software, maybe not everything, but some of it, um, what does that look like? >> I think I think my tolerance for holes in my socks is much higher than holes in my banking software. But >> so so I I think u I have some thoughts on that. I think I approach it from

here's here's an opinion that will probably completely be blown out of the water in the next uh cloud version, right? Because who knows? Um my latest opinion on this is that we're going to have a instance for I don't know how long where we're going to have I'm coming from the NYX ecosystem so I use pure and impure, right? We're going to have software that needs to

be pure because of what it does and what it's reliant on and how critical it is in whatever we're trying to do. And there we're going to have a lot less tolerance for any holes, right? And and and then there's going to be software that's going to be impure. We saw that a decade ago. Who knows what Wix is or or website, you know? It's like I

I don't know. I want to put on a website for my gender reveal. Like, do I care that it has 50 holes in it? I don't care. Whatever. Um, so I think I think the pure and impure pieces of software in the modern society are just going to be different. And the impure ones, it's going to be okay to build it and then rebuild it again if

you ever need to and throw it away. Um, but I think this touches on a very open-sourcy point to me that James was starting to allude to. um where I think we're still going to be human physics inside of software where we're going to try and I hope we're going to try to figure out recycling uh or reuse which is I think one of the baselines of

open source right it's like hey we all need this library let's put it out there work on it together now we don't have to redundantly recreate it across millions of machines every time that it's needed so I think we're going to start finding that there's going to be core pieces of our infrastruct that hopefully we can again package and maybe put it somewhere out there that other

people can use. Maybe we'll give it a name. Uh maybe we'll call it, you know, open something. But I I do hope that we're going to actually lean there. So there's going to be pieces of our software architecture that maybe in the future agents will contribute back to open source with those pieces. Um but that's just some thoughts. I know. I mean, I love this question, by

the way, because I'm sitting here thinking what would happen. Like, we have a huge spoken language library. Like, not a lot of new words come up all the time. Dictionaries are pretty thick across multiple languages. Alphabet has been pretty stagnant. Like, I don't know what it would take to add another letter at this point. >> Yeah, you Yeah, you would kill the song. And so you have

all of this vocabulary and I'm pretty sure the people who are imagine there's probably a group of people like making words all the time. Orange. Oh man, you got another one. And I could imagine that if that's not what people are doing, creating alphabets and new words, then they're creating movies and books, right? They're they're finally doing something with the words, right? That's where the work is.

And if so software maybe shouldn't have been this hard for this long. Like it's still surprising to me. Like I hear people devops, s platform engineering and I started my career in 1999. I'm like we were still trying to copy an application to our server and run it. All of this energy going into running software. It's insane. So what happens if we don't need to do that

anymore? It doesn't mean that it means maybe software and all the things we did to make software are no longer important. And if we could do that, would you allow it? I think I would. Now, it's unfortunate for all the people who've made a living doing that. And I have empathy for those people. It's probably where my mind sits most of the time. But if I put

that to the side, should software be this hard? If it wasn't this hard, then I I went to the dentist recently and they gave me this clipboard with a form on it and they gave me a pen and they asked me to fill out all of these. talking about it's 2026. You're still asking people to fill out paper on a clipboard. Then I give it to the

person and I know my handwriting is terrible. So you probably think I have every one of these diseases that I said no to. And then they type them back into the computer. Maybe if it was really easy, they would all just have kiosk that rival the same kiosk that the big vendors can use with hundreds of developers. So, I think it's a good psychological question is if

we got software to the point where fabric is, you can have fast fashion. You can have someone that wants to make that $5,000 suit. You can have all of those things. It wouldn't be the hard part about creating the material. And maybe we've just getting to that point where software should never be this hard to get. Just an ingredient for the thing that actually matters because I

think we spend too much time on the pen and paper versus the movies that people watch. And maybe it's just time for that to go. And I think a lot of us are holding on because that was our profession. That was our hobby. That was our passion. But if we zoom out a little bit, maybe it's time. We don't need to do this for another hundred years.

2024, are we still doing DevOps? Hope not. >> I did want to build on one point around this idea of like let's say there's it's a lot easier to create and it's really cheap. Do software engineers have jobs anymore? Well, there's a couple points that I found really interesting the last couple of weeks. I think it was within one or two weeks ago, like Aaron Levy, who's

the CEO of Box on his LinkedIn, he put out a post and he showed a curve upwards for hiring software engineers for for job listings. And that's like completely counter to the narrative of, you know, everyone being scared that they're going to eliminate all these jobs in software engineering. And some of the analysis that came out about that was this Jevans paradox, right? Where something gets cheaper

and then that there's more consumption of it. And they're going to need people um that have an engineering mindset to understand how to drive these models and to make sure that it's with high quality so the model's not doing something crazy. and we're just moving up an abstraction level. And then another data point on this was um you know I saw people like really trolling Anthropic because

they had a software engineer listing for something like $500,000 for their I don't know if anyone you saw this but they were like if we don't need software engineers because Daario from their CEO is saying we don't you know this this job field's going away why are you hiring them still you know which is another interesting point. I I don't know how it's going to go, but

I do feel like raising the level of of abstraction, the skills that we've been building up will still be valuable, but we'll have to adapt. >> What's the question? I'll I'll repeat So something mostly were well represented sites and so I it's very hard to create that makes software Bolite thinks. >> So, so just to repeat the question if I correct me if I if I get

it wrong. I think um you're mentioning hyperard as a almost like a conceptual model of creating bespoke software and I guess you're alluding to the fact that you don't see that yet created in today's modern ecosystem where I can just hack my own bespoke software together in a very basic way and why that's not there >> right since we were already starting to >> I you know

that's I think that I think this thing where um I don't know why the industry gave them permission to, but every enterprise was like, you know what, we're all going to do custom everything. That's our emote. That's our IP. That's our secret sauce. We're going to figure out how to put things on servers better than the next company. And that will be our strategic advantage. And if

y'all don't believe that, that's how most vendors sell their software, right? You know, you buy the software that we sell to you, but we also sell to everyone else. And if you use it better than them, you will get to production faster or something something return on value. And I think that whole customization was just a lack of discipline in our industry, right? Like imagine someone's building

you a house like, "Hey, we're going to use a new material today." Not bricks, no drywall, wood is out of the question. We call this antimatter. Hey, have you used it anywhere else before? No, but we're going to build your house with it. So, we have no history, no metrics about whether this is safe or not. Well, look, we don't have to live in it, but it'd

be really cool if we did it for you. We're going to write a blog post about it and everything, [laughter] right? And so, our industry has allowed This is some of this stuff literally irresponsible. You work with the person like, "Hey, we should just rewrite all this in Rust." And you're like, "Dude, what the hell are you talking about? This is a static website. It [laughter] it

doesn't need to be in Rust. No, we're going to make our static rush generator, right? And it's like, oh, okay. But a lot of the things that we do in our industry is completely unnecessary. Like I was a big Kubernetes person. I was like, Kubernetes is great. And then someone's like, hey man, I work at this university and we got three servers and it's really productive. It

serves all the students with three servers, but I really want to get into this Kubernetes thing. I say, "Hey, stand stand to the side for a second. Listen to me very clearly. You see this book, you see the author is you have to trust me. Stay away from this. You don't have this problem. This is good for you. He's like, I don't get it. I was like,

okay, there's some breakthrough like cancer treatments. Cancer is bad. It kills people. You don't have cancer. He's like, no, I don't. You don't need the treatment. He's like, ah, I get it. [laughter] And I think a lot of the technology we see in some of these companies is some people just haven't stopped and said I don't I don't think we need that. And so I think a

lot of this complexity that we have the reason why we haven't cryst or or settled on a set of technologies and let's be clear there have some people that have I've seen some people like man I just run my business on Heroku man I wrote this thing 10 years ago it's been running on Heroku ever since man I'm doing about a million a year I go to

all these conferences and I see this stuff but I'm like should I rewrite this and I'm like but it just works. So there are some people that have found the constraints, conformed to them, and they're getting a lot of value right now. There's a lot of people that are winning on that regard. But I think a big part of our industry still sees this excitement around making

something custom, even if the cost means 10,000 people dealing with that complexity going forward. And maybe it was necessary for the last 20 years, but I think what we're seeing now is like, you know what, how many Uber clones can you have? And I think that's just where >> So this is a great question to all this and it seems [clears throat] like there's a one-dimensional problem.

Go put the promps in get the result and it's so mundane but what is QA? I mean it doesn't write perfect code sometimes maybe it does on small scale but you have you know a giant set of trading operations trading different instruments there's a commonality and so on and so forth but how do you go about dealing with that kind of complexity and expecting not to ever

because I'm not hearing anyone saying oh I'm going to go after I've, you know, comped and gotten and, you know, reviewed the code or something, I can probably be sure that I can put it out there and, you know, test and it'll all be good or it'll just go right to production. >> there is there ances Is it only one person going to be distributed effort? >>

Yeah. So, so just to repeat the question, I think um I guess what what is changing in the SDLC, right? Everyone's talking about co-creation and ideally putting that co-creation into production. Where's the testing? Where's the QA? Where's reproducibility? Um, you you just flagged I don't know >> Yeah. Like a few NYX people probably glowed blue when you said some of that. so so I think I think

you're you're you're spot on, right? Like I I've seen folks say AI developer life cycle or a Gent developer life cycle. I I kind of call there's no such thing. There's a software development life cycle. I um we just ran a conference here called Planet Nicks. It's about Nicks. It's really cool. Check it out. There's for some reason they're still in the hallway even though we don't

we finished with the conference. Um and and one of the things that I did in preparation was I started reading some of the original kind of like uh software engineering thesis from from like mid 90s, early 90s just to see kind of where things were when when we were starting to build things out there. And one of [clears throat] the things that really resonated with me was

was someone um defining software engineering as all we're trying to do is tell a rock a set of constant inputs and have the same provide me the same output. >> Yes. And it's a rock. But I just want it to do a thing for me. And and I think I was I was kind of equating it to a light switch, right? When I come into a room

and I see a light switch, I hope that when I flick it on, meaning give it an an input, u ideally it's going to turn on lights in the room and not turn on and blow up some microwave in, you know, the messaul. Um, so I think we just have a new SDLC with parts of it. And you're right, I think a lot of folks are talking

about the most exciting thing, which is the code generation, how fast it is. And I think that's also influenced, Kelsey was mentioning VC and due diligence. is also influencing where the money is going right now. Every model is trying to out compete the other model on being faster and better and faster and better at what at code creation. But I think I'm seeing a lot so if

you dig a bit deeper, you're seeing a lot of different companies and paradigms work on the rest of the SDLC. It's still there. It's 100% still there. I think right now it's still kind of open season to define what that SDLC is going to end up looking like, right? And I'm a biased Nyx person. So like nicks and flocks and I was just gave a talk about

how reproducibility and determinism should be part of that SDLC at the bottom because that's really important for when we have uh u those agents kind of running in the middle and sometimes doing things that are not exactly deterministic. Um but I think there's definitely work being done >> Is that done by hand? >> So so I I don't think it's being done by hand. I think it's

for instance I'll give you a flow that I've seen recently. Um again plug for NYX. seen it done on nyx where they actually have asked the models to pre-generate the tests that are going to validate the output that they expect right so so they actually started it's almost like if you remember TDDM right test driven development uh from from a little while ago it kind of came

back now it's like no start with the test make sure that I'm getting what I'm trying to get now go do whatever you want to do in the middle and then at least my output would be somewhat consistent but um I don't know if you guys have more thoughts >> well yeah I mean one of the things you you know's law which is basically ally like we

can speed up the creation of software, but if I have to then go get it certified, the security team has to bless it, I got to get it through the production team. So all the software's coming into the top of the funnel really fast, but it's getting stuck in the thinner parts of the funnel that that take just as long as they took before. Now there's just

a big backlog. We're going to have to figure out how to do those other things at at scale. Otherwise, the other stuff's just going to wait to deploy because it's behind. What's that going to look like? >> I I think if it looks anything like this in 10 years, this whole thing was a failure. >> Just think through this. We didn't built apparently this super technology to

do the same thing we were doing before. That's a failure mode, right? When I go buy new tires, this person doesn't sit there and QA each tire. Why? Because they're dealing with known entities, right? Like this tire has the right tread. You can put a tread gauge in it. They fill it to a particular pressure with the standard stem. They put it on the car and they

balance it and I drive >> Where are we in that time? >> Not in there. Oh, in the timeline. I think right now for 10 years, the business model that we've chosen to accept, you're going to be stuck in this timeline for another decade. Kubernetes, we're still doing the same things as before. We're deploying apps on VMs with a bunch of YAML files. Some of it people,

oh, this is a new way of doing it. I'm like, I was there in the beginning. It's the same thing we were doing before. And right now people are very frustrated with Kubernetes. Like dude, I'm doing the same thing as before and I have a lot more YAML files and I created a whole another industry on top of Kubernetes. >> But I think it's the same thing.

So if you're going to keep generating software we're unsure of, yeah, you're going to keep testing it. Whether you ask the AI to do it or you do it, at the end of the day, your company's going to put their name on it and then your company's going to figure out what's required to wear my badge. If you think you can just let the AIS do everything,

remember, and it's better now. What was that? Canadian Airlines, they unleashed the bot early and the bot created a refund policy and people were like, "Yo, look at this thing. You just get free money from it." And then they put their name on it. And so at that point, your name's on it. So whether the agents are good or bad, your name's on it now. So at

some point, you're going to ask, "What will it take to put your name on it?" That's the QA process. Whether like if I use a very mature framework, you don't test all your open source libraries. Most people do not test their compilers. Guarantee it. You don't test your CPU architecture. You don't even look at the assembly it generates. >> That's your belief, but you're probably right. It's

that stable tire. Now, right now, the software we're generating is reflecting the type of crazy, untested, unreliable, probably not even correct software we're used to. For some reason, we've accepted that as the checkpoint. So this thing is like I can do what you've been doing way faster. So of course to me this is just a fast way to do the same thing. So this is why I'm

not as excited. Oh, it's going to take over everything. No, it just means you're going to be doing the same thing forever for $20 a month, maybe 2,000 depending on how many tokens you need. That would be a failure. So here's what I hope happens. I hope someone gets wise and says, "Why are we generating the same snippets of code over and over again? This is insane.

This is silly. irresponsible. There was a musician, I believe, before AI. He just generated every melody and went to court. The ones that were spoken for, those are copyrights. The rest of them are public domain now. We're done with this debate. Every melody is generated once. So, feel free musicians to make the music. You won't be sued anymore for the majority of this, and it's only a

matter of time before the other copyrights expire. And no more melody lawsuits. At some point, when do the models start contributing back? Hey, there's a million people using this tool. All of you for some reason are trying to do SAML integration. When do you just create the perfect library that just does that correct? And then it's well tested. It's bulletproof. You can test it again if you

want. You're going to get the same results. So, I think we hopefully end up there. And if we don't, then we all got taken for a ride to start paying a toll fee to write software versus being able to do it for free. So, I know we have a little bit of time, so I'm gonna do a lightning round for folks that had their hands up. You

go first. >> I won't repeat that part. He's very excited. Go ahead. I'm worried >> I'll repeat that really quickly just for a sec. Um he was mentioning if folks are not familiar Mitchell Hashimoto was built a system called vouch. Um he most recently was building Ghosty and and you know he was getting AI slop uh well AI generated uh poll requests and um and slop and

and he wanted to do some verification of who's doing it who's not and and that you know and what was said here is that we've had a model especially in the open source domain has been working right humans coming together getting together to work on a common goal on a common piece of software that we all want to make better and it's just worked because of the

human aspect of it. What if we just what if that AI model just comes in and breaks out something that's been working for 30 years or or longer? >> So my first comment to that was always these these LLMs learned from something. So we've had a lot of bad behavior out there that they've also learned in addition to the good behavior. Um, but a plug, I did

a talk yesterday about this. I tried to make it super interactive like this one with everyone contributing what was working in their projects and what wasn't working. Um, so there were a lot of great ideas that that came out of that. Um, but I think it's it's a it's the other my my second point is always that that agent, we talk about the agents and in the

news it's like the agent did this and the agent did that, but somebody created that agent and somebody paid for those tokens. Um, so that agent, maybe it went rogue, but somebody was responsible for it and that person didn't fess up for quite a while. Um, so I think I think we have a a human problem, a process problem, and something we all need to work out

>> Yeah. Um, I'm going to I'm just lightning questions. Okay, I go there. statement first would not I always go and check because it's the other thing you go to a doctor say okay I have fever of my son it's 106 he goes home maybe go to hospital your son that makes no sense so there's always a reason in my office senior given me these are the

solutions you know this is copy paste from child >> human where you have to tell it's up to you. Stop. I don't want to and it is up to you. Oh, I don't want to use it at this place because it's important for you because your son is sick. You don't want to go to that doctor who gives you >> I mean I think to summarize and

I know we're out of time here like reputation is a human thing. Accountability is a human thing. And if you cause harm to another human, whether it's issuing a bunch of pull requests causing me more work and pain, then I'm going to hold you accountable and just close them all. And I think we tend to work things out by saying you can't tell me the agent did

it to me. That's unacceptable. We won't take that as justice. Humans will tend to govern ourselves in the way where there will be accountability. So, right now, maybe we're all excited and we're taking shortcuts right now. And maybe to your point around LLM's contributing code, here's the thing. If you're doing it right, I don't care if it's an LLM. When you issue a pull request, read the

contribution guide, put your name at the top, follow the commit message, understand and have empathy for the reviewer, and then put the code in there. Whether you use an LLM or not, why would I know? It's the fact that I know that the LLM did it is where I have a problem. You didn't even take the time to look at this. >> This is a Golang project.

Why are you issuing PRs in Rust? That's just laziness. >> Yeah. So, I'm gonna I'm going to just kind of wrap up. We're some of us I'm not going to speak for everyone. We'll have some time. Do we have a talk after this? Is there a talk? >> Yeah. So, we we'll be outside to not bother the talk. Um but I think just to wrap up, a

lot is happening. A lot is changing. Um, I think folks here in this panel have had their job titles changed probably 101 15 times. And I know those that are kind of at the later stage of their career are less concerned or not envious of those at the beginning of their careers. Uh, but wherever you are, I think I think we're going to figure it out. I'm

I'm a naive optimist on where things are going. I'm hopeful that we're going to figure out reuse. I'm hopeful that these models are going to help us contribute more to the open domain. Um, but I can totally see and I can totally resonate where these things are kind of scary or spooky. The only things that I can like the thing that I would emphasize leaving this is

go test it out. Experiment with things at your own pace, but don't stand on the side because I think right now the way that I view it is a lot of folks had had got a NASCAR uh vehicle delivered to their, you know, uh, front yard and no one knows how to drive one, right? But it's better to try it out a little bit. So if ever

you need that or ever we get to a point where we need to know how to use that you know machine you at least have some experience. So again I want to say huge thank you to our balance for for coming down today and I want to thank thank you to scale uh and thank you all for joining us and making this a very live energetic discussion.

So thank you guys. [applause] Thank you all of you. Say one more big round of applause for Ron, James, Kelsey, and Stormy. Thank you. Thank you. We have one more talk here in this room later today. That's We're going to take a 15-minute break and we'll come right back here. Thank you very much. Have a great rest of the day. Check one. Oh, that is a that

is that is what I my voice there. Okay. Uh, one, >> Check. One, two, one, two. >> No. All right. All right. Hello everybody. Welcome back. This is our last talk of the day in the developer track. Uh here at scale 23 2026 we have our last talk of the day by the uh by Amy Iris Parker a grad student at University of Irvine California. She is

giving her talk on architectures don't matter. Please give a round of applause for Amy. Uh thank you everyone. Thank you for that wonderful introduction. Uh my name is Amy Ars Parker. I'm a graduate student at the University of California, Irvine. And today I'm here to talk to you about how with the power of tools like Kimu, architectures don't matter Uh before we get started, a little bit

about me. As I said, I'm a PhD student My research focuses are in distributed and embedded systems, computer architecture, networking, and social impacts of computing. Uh I'm part of the DUT research group where I'm currently working on proactive compaction. I was previously at Cal State Fullerton um just down the road from here. Uh I was doing research on IR pipelines. That is what led to this presentation.

I also did research on censorship evasion which if you had a chance to see my talk yesterday at 5:00 pm uh I uh presented some of that as well. I'm also the secretary of Orange County DSA. Uh as part of my role, I do a lot of uh management of our tech stack, including things for voting, transparency, member identification, and member contacting. I've been working on various

uh open source signal intelligence work in that as well. And I've been using uh Linux and other Nyx platforms for uh over a decade now. I run Nyx OS on my main computers. Uh I have lots of automation at home and I run a Proxmox home lab. Uh also previous uh the uh information from this was previously presented at ICCT uh 2025 in Paris, France. Um go

if you're interested in a lot more of how uh IR pipelines work, which we will get to later in this presentation, please read the paper associated with that presentation. And uh credit to the DBN wiki editors as large portions of this presentation derive from that Debian Wiki article. So, uh, what we're going to be going over today, first, what is Kimu and what is Kimu user mode?

Um, I a lot of you probably know what Kimu is. Not all of you necessarily know what Kimu user mode is. Second, we're going to go over how to run cross architecture user binaries and applications on Linux. We're going to go over how to automate that with bin format, um, uh, expanding your multi-lib setup and using LD preload. We're going to go over uh a very cool

application of uh uh chemo with bin format which is running applications in shroots including through uh crusty bootstrap for Debian users. Uh we're going to go over how this works for uh running legacy enterprise software and how to add modern architectures to this. And lastly, we're going to be going over how to distribute universal binaries that run on any Linux architecture. Uh this is not a workshop.

However, uh I wish I had the time for you all to get out your computers and do this along with me, but we do not have the time for that today. Um you are encouraged when you get home to continue uh to try the things that you learn uh try out the things that you learned today. Uh we are all hackers here. When you go home, please

hack. Um uh a lot of the stuff in here will may peique your interest. If so, please please try it out. And if you have any questions, please feel free to contact me um after the presentation. So, first up, what is Kimu and what is user mode? Kimu is the quick emulator. It is the current uh most uh popular emulator on Linux and several other platforms. It

provides both system level emulation, which is what you're familiar with for virtual machines, and user level emulation, which directly runs processes, as we'll get to. uh most VMs um on uh most VMs that are integrated into other applications on Linux. So for instance, if you use Nyx's uh boot VM for testing configurations or if you use buildroot uh automatically launch their VMs with Kimu. Uh Kimu currently

supports 30 different uh CPU architectures uh and has thousands of different hardware modules, CPU configurations, UEFI and BIOS versions, etc. and is extensible. It is pretty easy to drop in support for any additional hardware you need. Now what is user mode? So uh the traditional system mode of Kimu runs a full virtual machine down to you know the very first initializations very first posts. User mode is

something different. It takes binaries for Linux that are compiled for another architecture and allows you to run them as if they were native binaries for your system. Uh this creates essentially a tra a transparent way to run uh Linux binaries from other architectures. Um any uh any binary that is either statically linked or that you have the libraries installed for will just run with Kimu. Um and

this can be through the most absurd configurations. If you want to run an alpha binary that launches risk 5 binaries on a Power PC system, you can do that with Kimu just as easily as you would run normal applications for your system. Uh here here's a quick example here of uh testing out running some uh risk 5 binaries on an x86 system. This laptop here I know

this is a framework. This is not the risk 5 framework. Uh that is a native uh [snorts] risk 5 binary running on the system. uh as for how user mode works, uh every time SIS calls are made um for a given architecture, uh SIS call tables on Linux for different architectures are different. Kimu handles it. It automatically translates all of the different SIS calls that you could

ever possibly call. um the actual memory state of how it should look on the target architecture is maintained while also running the code directly in a separate mapped memory environment uh which allows us to maximize performance. So how to actually run applications with KU? Uh if you would if you have a binary and you have Kimu user mode installed, you run kimu- whatever architecture the binary. That's

it. That's all that's all it takes. Um that's all you need in order to run uh uh applications from any CPU architecture on your system. Um uh if you want if you don't know what architecture or binary is you can always use commands like file to get that information and to explore more um you can also uh pass other arguments to Kimu um to configure individual small

behaviors if you're trying to exactly match a given system um and you can of course also pass command line arguments and all that but essentially as once you've wrapped it with that Kimu execution it runs as if it was a native binary ary on your system. Uh now if you if that uh binary is statically linked then awesome it will run perfectly. You don't have to worry

about doing anything else. But we don't live in a world where static linking is very common. Uh most binaries rely on shared libraries even if that's just lib C. And that's fine. GIU can still handle this as long as you have a proper lib C for the original binaries platform. uh you can pull that off of any system, download it from the internet. Doesn't need to align

exactly with what you're running. You just need to have some lib C from the original platform. Um it doesn't need to be specific to Kimu usage. You can run the original native lib binaries or any other library. And as I said, Kimu executes essentially transparently. Once you have launched an application, it looks to the operating system and to you as if you were just running that application

natively, um it looks completely normal, but from the application's perspective, it is also transparent in that it believes it is running in the correct architecture context. Um if you do sis calls that are architecture dependent, they will still [snorts] work. Kimu has translations for all of those SIS calls. Um, and so you get the it's the best of both worlds. The application continues to run normally and

you get to run it as if it was compiled natively. Uh, moving on to bin format and other tools. So there's a slight problem. Every time you want to run something on another architecture, you have to type in kimu- architecture. That gets tiring after a while. Wouldn't it be nice to be able to just run the binary as if it was normal? Just type, you know, dot

slash whatever binary or install it into your path and have it automatically run. Well, we can Uh the Linux kernel exposes an interface called bin format. This allows um different tools on the system to uh uh receive applications when the colonel can't determine what is supposed to run them. Normally the colonel says, "Oh, okay. We're running uh say we're on x86. We're running an x86 program. We're

going to hand this off to the x86 linking interpreter." Well, uh with bin format, you can say, "Oh, we don't know who it's going to be run. Hey, Kimu, uh do you want to handle this?" Kimu says, "Sure." And it picks up the binary. It does that automatically as soon as you've installed bin format for all 30 different architectures that Kimu supports. Um uh this makes it

even more directly transparent. You can have an x86 program call an ARM program or a risk 5 program and it will act completely normally as far as the kernel is concerned. They are all the same architecture. you can also install libraries to your system from multiple architectures. Uh if you are running many different applications um multiple different operating systems have ways of doing this. Uh you can

do it on Fedora and Red Hat based distributions. You can do it on Nexos. But uh the oldest group that has been doing it is uh the Debian developers who actually have it natively integrated uh with first class support in Dackage. All you have to do is prefix uh or sorry suffix the architecture of the library you want to install and you have that installed. Uh anyone

who's had to do 32bit installations on Debian will be very familiar with this. You just add i386. Well instead of just doing 32-bit now we can also install ARM uh libraries. We can install risk 5. We can install alpha. We can install power PC. Anything that is available, you can install alongside your native libraries and you can run the and you can run commands uh compiled for

other architectures again as if they were fully native. Uh if you're developing for other architectures, you can also play around with adding your own libraries in or using LD preload. Um uh for those who aren't familiar, LD preload allows you to override a given library. You can do that just as well with Kimu as you can with anything else. So if you want to test potential security

vulnerabilities, test new versions of libraries, um insert patches into libraries, you can do that just as you would with any native application but with that full spectrum of architectures available. So now for shroots [snorts] uh for those who are not familiar with shroots shroos allow you to change the uh what the system sees as the root directory um and if you shroot into an existing system context

the system will act as if you are actually in that system instead of in your main system. Uh however you will still be using your original kernel and in it. This is very useful for many things like debugging and rescuing systems uh for building new systems. Whole whole whole there's a whole bunch of different use cases for and anyone who's ever used them has seen how effective

they are and that you can run applications that are contained within a shroot as if they were you know native applications on your system. But again traditionally they've had to be of the same CPU architecture. if you have chemo with bin format installed, this is no longer an issue. When the kernel reads applications from the shrew, it will still query bin format if it can't figure out

what it's supposed to run. This uh means that you can essentially take the drive of any system, no matter what architecture it runs, as long as you have chemo installed, plug it in, shroo it, and you are now operating as that system. uh you have access to all of the tools available on that system as they would be running on that system. Um if you and because

KU is so configurable, if you need to exactly match something, for instance, if you need to deal with the discrepancies between, you know, say a Raspberry Pi 5 and a Raspberry Pi 4, you can do that very painlessly just by slightly changing your bin format configuration. This has been used by the Debian project since 2006 for uh flashing Debian systems um for embedded environments. Uh debootstrap which

creates minimal Debian environments and is the basis for installing and building new Deviian by default without having to change anything works with Kimu bin format. And the official way of um bootstrapping systems for another architecture in Debian is to use Kimu with bin format. They don't have to do anything else. All the only change in the instructions when you're looking at the debootstrap instructions is if you're

running for a different architecture, install key user mode, install key bin format and you're done. It automatically works. Uh now on the enterprise side, how how do we justify this uh to our employers? Well, there's lots of old enterprise applications that are closed source and that we can't recompile. Um I'm sure you all have had that time where you have to deal with some old application that

you have a binary for from many, many years ago. Uh you can't get the source code for, you can't port it, you can't recompile it, and you just have to figure out what to run. Maybe you've even had to pull out old systems in order to run those binaries. Not anymore. You can bring these to life without having to set up a VM uh with still being

able to run them in your native context with Kimu. Uh Kimu user mode can as long as it was uh built for the operating system you're running on. No matter what architecture it's for, no matter how old it is, Kimu will run it. Um I I've had to deal with some UART software that was really really old um that we couldn't uh that in my lab at

Cal State Fullerton we couldn't get running on almost anything. Uh we decided to try and put it through chemo user mode and it worked and we were able to get that software running. Um uh if you're a developer who's who needs to develop for multiple different architectures, you can also use Kimu user mode uh to make your development process a lot faster. Um uh has anyone here

ever been trying to develop for a Raspberry Pi or something else and had to go through the process of constantly pushing your code to the Pi? Anyone here had to deal with that? Yeah, it that's really annoying, right? It takes a lot of time. Wouldn't it be so much nicer if you could just run your code on your system like you do for native testing? With GIU,

you can you uh you just run uh the binary and if you have bin format installed, it just Now if you're implementing for a newer uh say I don't know we come up with uh risk 7 as a hypothetical example uh that's obviously not currently supported by Linux or KU or anything else but you're say you're in the process of doing that and you want to be

able to run your x86 binaries on your new Kimu7 system or you want to test what the code you wrote for Kimu7 on your x86 system. Well, all you have to do to get it running in Kimu user mode is uh build a plugin for TCG's front end. Uh Kimu uh translates all instructions to uh its own intermediate representation. So all you have to do is provide

a front-end plugin uh that converts from uh your new architecture to Kimu IR. Um, and then a back-end plugin that converts from Kimu IR to uh your new architecture and you now have the full same level of support for running applications as if they were native like all the other architectures in Kimu do. Now uh I do want to give a little bit of a heads up

to anyone trying this. Kimu user mode works very well. It's transparent. It works for most applications. But if you are running something performance dependent right now, uh you will be in for some pain. Uh Kimu user mode is not the fastest thing in the world. Um uh what should have been a five minute uh Ubuntu server installation in a shroot ended up taking me two hours last

time I tried it. But things are looking up. Um uh recent research has shown that uh Kimu's uh TCG platform can be signific can be significantly optimized. Um what should take what took uh 246 milliseconds to run on Kimu previously could take only seven um if these changes were implemented. They're not in Kimu yet. But hopefully they are coming and once that happens you will have very

little performance drop off from native executables to Kimu user mode. Now the last thing is universal binaries. Uh does anyone in here have a uh Apple silicon MacBook or other Mac? Couple of you. Okay. You've probably heard at least a little bit about Apple's universal binaries that combine uh x86 and ARM code into one binary. Well, that's very repetitive. Um we're not going to do that. Instead

uh if we have just two tools uh Kimu user static which is Kimu user mode compiled statically um and um which that alone is very useful because you can as long as you have write permissions in a directory and can set the executable bit you can run chemo on any system without having to install it. Uh, and if you have the ability to write an executable wrapper,

which every major operating system has at least some version of this, then using a tool called FATLF, you can bundle Kimu for all of the architectures you could ever think to run a program on. Uh, and have those all point at your program. uh depending on how many architectures you add each is a few megabytes to your program size. So if you want to include all 30

um you can do that. You can 100% do uh be like maybe 100 megabytes if you picked only the ones that people actually are still using in any real server or desktop system today. you know, 10, 20 megabytes, your application can now run everywhere on any Linux system, no matter what. With that, thank you all so much for coming to this talk. I know it was a

little bit on the shorter side. If you ask. I'm here to talk for as long as you all would like. >> [applause] >> You said alpha. I still have an alpha >> Uh then you should >> So you suggesting that I could possibly emulate the alpha or actually run other code on the alpha. >> Yes, you can. Uh I have I have tested with alpha executables. It

works. If you want to go if you want to go um pull here here's an example I gave earlier. Um granted I was working with uh emulating x86 on x86 but uh here I am using uh I'm using kimu to emulate kimu which is emulating uh core utils. If you wanted to pull any binaries off your alpha system and emulate them on uh any other system you

have you can do that or the other way around. If there's something that you have that's only built for some other architecture and you want to try and run it on your alpha system, I don't know how old that system is, so I don't know how the performance is going to be, but it will run. >> I have an SGI too. >> Is it is it running

Linux? >> Uh the alpha runs Berkeley mostly and the SGI runs SGI. >> So that's a bit of a challenge. >> Okay. If you in if you install an alpha compatible Linux distribution on it, it will work. Power PC is very thoroughly supported including uh both 32-bit and 64-bit as well as both big Indian and little Indian. Um I haven't tried you know specifically like AI extra

targets. I don't work with power often but I've heard from others that that works pretty >> So this is more of a a comment rather than a question. So another use case for this sort of thing is um uh this may sound absurd on the surface but actually is x86 on x86. So um there are cases edge cases where uh certain um uh places where uh for

instance VM providers or or hosting providers may have certain things misconfigured and you may need to deploy something really quickly in a place. They may not have certain like SSE4 instructions enabled and you just don't have time to get your stuff like recompile, rebuilt for whatever weird thing. And you can use this to get your stuff working in like really quickly and then fix your real problems

later. Yes. Uh that is absolutely true. Um Kimu does have support for uh extensions on x86 that a lot of our CPUs do not have like AVX 512. So it is entirely possible that you can run something on Kimu for x86 that will work in Kimu x86 that does not work on your normal system. Thank you. Um, so two questions. Um, first, um, you have you noticed

speedwise any issues with end like big Indian when you're running those binaries on x86. >> Uh, I have not noticed any Indianness issues. No. Um, to my knowledge, at least on x86, Indianness flipping for anything up to 64 bits is a single instruction. Yeah. >> So it doesn't really add that much. >> Okay. And then so the second one is is somewhat related. Um as far as

speed goes like you know if you're if you're on you know a big Indian system S390X and you're emulating x86 binaries like do you have any experience like with where that is on the speed you know is that still really slow or >> uh I don't have experience with S390X in particular. Um I can say that if you want to get an idea of the the basics

of the performance change um K chemcg converts for most architectures one instruction of the beast architecture. If it's um CISK to about eight instructions for risk architectures it's a little different like if you're converting uh two x86 then it gets a little faster. Um, so you do have to execute more instructions than you normally would, albeit the the actual translation process once any given instruction has been

translated, it is cached and it does not have to be re-ransated again. So I would expect S390X running x86 um, depends on how depends on what x86 instructions you're running. Um, if you're running a mix of like SSC 4 and AVX 512, you're probably going to be in a worse situation than if you're just running, you know, stuff that can run on anything with SSC2 and below.

>> Um, but it it's it's definitely workable and performance improvements are coming, at least in theory. >> I'm gonna go break some computers. >> I was not expecting this one to go so >> I have a question. So, can you do forwards compatibility on like some really old hardware? Could I run the latest bash for whatever reason? B, the latest bash executable on my OOLPC, which is

an i386 architecture using this. it depends on one primary thing and that is uh whether you can get a Linux kernel version that is new enough installed. Um this is not tracked on most architectures executables but for x86 specifically when you run the file command it will tell you what the minimum kernel support version is. Um so as long as you can run that kernel or newer

you should be fine. um especially helps if you can use statically compiled binaries and you're not having to port over lib um because static lib does wonders here. Um I will say that while trying to get a new kernel version sounds daunting I I haven't seen any requirements on almost any regular like common binary higher than Linux 3.3 and most things only require about 2.6.38. So if

as long as you can get around that era of kernel installed, you should be >> Thank you. Do we have other questions from anybody? >> Okay, I have another question. >> All good. >> So I saw a little blurb at the beginning that you also do Proxmox home lab stuff. So I think you might know where I'm going with this. Proxmox does not support ARM on its

own if I understand correctly. Debian does >> and Proxmox is derived from >> Debian. >> I've seen this like weird like uh not so document very opaque like cross compiling of the Proxmox like DRO to ARM >> and it's kind of I'm sketched out by it a little you Google you'll find it. I had to get this from this one weird forum. It was weird. >> So,

I didn't want to install it on my Oracle 24 by 4 >> free tier >> V VM, >> but I wanted to do something stupid and I wanted to try to, you know, break things. And so I thought, what could I use this to like run ARM or run Proxmox on an ARM VM because I want to torture myself? But does that actually do it? >> [laughter]

>> I mean, if if you were to install the original Prox binaries, I would say most of them could mostly run. Um, there's a lot of things in Proxmox that are specifically focused on looking at processor attributes that are x86 specific. if you can work your way around those, you know, patch patch those features out or patch them to work with ARM, um it could be a

good starting spot, but given that Proxbox, at least for the community version, is open source, uh you will have a much better time just changing the architecture flag to ARM uh and recompiling and then patching as you go. Um if Procox was closed source, then sure, you could definitely try it. Um I don't have much experience dealing with LXC on um I Lexe on ARM but I

know it does work and of course VMs will also work because Proxmbox uses Kimu for VMs. Um so you could certain you could certainly try it. I just think you should pro probably focus on improving um existing works to port it to ARM. >> You want to make a universal binary. >> You talked about you can just pick an architecture and make your binary for that but

then have have it and be intended to run via um Kimu and uh the multilib. >> Uhhuh. Right. Uh bin for bin format. >> Uhuh. >> So how do you decide which architecture will be your your the one you build for and which ones are going to be the ones that are going to emulate that architecture? Like how do you decide is it based on like the

CISK or risk uh like like because there are performance tradeoffs when you're going one way or another, right? >> Yeah. Um I would say it depends on what your intended user audience is. If you had an equal distribution of every different architecture, I would say pick the riskiest thing you can find. So probably I would say armor risk 5. Um uh I believe currently ARM is the

most the most developed for um TCG in terms of translation performance um for risk architectures. Um, but given you know, given the continued ubiquity of x86 systems, I would probably say for practicality, put x86 as the native one and then Kimu for everything else. >> That's so cool. Thank you so much. Are there anybody else who have questions? Thank you very much. Let's give another >> Thank

you all so much. >> All right. Thank you everybody for attending scale conference this today on this session this year scale 23 2026 this is Saturday evening we are done with all the talks in this room today there is going to be a game night somewhere in I think in the expo hall so >> go do that if you want to or whatever have a great evening

y'all but good All