What do we do now?

Speaker 1

So final speaker, and he's a new VP of, uh, Marketing and Community at Laravel. You know him as the host of the Mostly Technical podcast. Uh, he's also the creator of Solo at solotern.com. It's very good. He's also the father of four kids, two sets of twins, so I think he's, like, the only one of the speakers who genuinely understands concurrency.

Please give it up for Aaron Francis.

Aaron Francis

Thank you. All right. I definitely understand concurrency and accidental complexity, so, um, yeah. Thank you for having me here. This is my first time in Denmark. Um, like Isak said, I'm the new VP of Marketing and Community at Laravel as of, like, three weeks ago.

Uh, so I'm very excited and excited to be here. Um, who am I? Like he said, I have two sets of twins, so we have, uh, now they're a little bit bigger. They're two and a half and five. Um, so I'm quite busy all the time. My wife was able to make it out to Laracon US, but she was not able to make it here because she is at home with all four of those kids.

Uh, and I couldn't be here if she wasn't there, and so I'm very grateful for all of her support, uh, in everything that I do. And I don't normally share pictures of my kids' faces on the internet, um, but it does look weird to have the whole four and two, and so that's a little clearer. Um, so that is, that is my wonderful family. The question is, where do we go from here?

Um, the world has changed a lot in the past year, and I think, um, if you're anything like me, you've kind of asked yourself, uh, "If the machine writes the code, do I still have value?" Right? So we all, we all woke up, uh, recently and realized that, uh, there are machines that can write code.

And while I derive a lot of value outside of work, I derive a lot of value from my work. I like to work. I like to write code. And I don't think, um, I'm on a podcast, so I can say this. I don't think the podcasters, the talking heads, the, the, the people who commentate, I don't think they have it quite right because they say, "You've been freed from the code.

You never have to worry about code anymore, thank goodness." And I look at this. I- I've loved the computer for thirty years. Like, I don't want to be free of the computer. I lost the goggles at some point, but I don't wanna be free of the computer. Like, I like writing code. And so when people say, "You never have to think about code anymore," that is not a relief for me.

That makes me sad. I like writing the code. And so when you wake up on Thanksgiving break and you realize, "Whoa, a big part of what I've spent thirty years doing maybe is going away." And so the more pointed question is, if the machine writes the code, what the hell am I supposed to do?

Right? I've had this superpower for so long, and now it's gone? And I don't think the answer-- I think you can go a couple of different ways. I don't think the answer to this question is, "The AI will never be as good a developer as me. The AI sucks. I can do it better." All of those things may be true.

I don't really know. They're getting better every single day. And so I don't think the answer is, "I'm gonna become a Luddite, and I'm never gonna look at AI because I'm a very smart boy." I think there has to be a different answer that still somehow retains, "I have value and my work matters, and there's a new hammer that I can use, and I should probably use the new hammer." So what am I supposed to do?

That's not right. There you go. You don't have to become a product manager. I don't think you do. That's the common talking point, right? "Developers, be free. Just think about products now." If you wanna do that, that's great. I derive a lot of joy out of thinking about products and experiences and that kind of thing, but I don't think this is good. I don't think this is good advice.

You don't have to become a product manager. I do think we're moving up a little bit, but that doesn't mean we're moving up into product. That can mean within the realm of caring deeply about the craft of code, we are moving up a little bit. And we're gonna look at this, uh, in three different sections. So we're gonna talk about the first draft and then building the box and then what leverage that gets us.

Okay? So for the, uh, narrative, we're gonna look through a product that I built completely using AI, okay? And we're gonna walk through the Git history and all of my mistakes, and the reason we're looking at this product is because it's written in languages that I don't know. It has users. People like it.

I think it's very good, but it's written in languages that I don't know, completely using AI, and I have learned a lot of stuff in that process, okay? And I think this is interesting because we're in this phase of the world, we're in this phase of the world where, at least in my own experience, the language matters less.

So this is written in Rust and TypeScript, and I'll show you all the, the gory details. But I didn't pick, uh, I didn't pick the framework, which is Tari, which makes desktop applications. I didn't pick the framework because I love Rust. I don't. I've never used it. Um, I picked the framework Tari because it is the most complete ecosystem.

And for us in the room, I think one, one way that we're moving up is we are talking less and less about PHP. PHP was my first language at, like, eleven or twelve, and I love it. But these days, I'm finding myself thinking more about the framework layer, which leads us to the most complete framework in the world, Laravel.

And so I think as a, as a community, as, uh, an engineering, uh, group, we're starting to think more about what does the framework give me, not necessarily do I like the syntax of this language. And for people outside of this room, that's great news for Laravel because a lot of people don't like the syntax of PHP, right? But now we have a story to tell, which is, "Hey, we have the most complete framework in the world that happens to be written in PHP." We can all still love PHP,

but the selling point is the completeness, which is why I picked Tari. So you can see this is not a what's the prompt bro, right? There's no one-shot prompt. If somebody tells you, "Hey, why-- I could just one shot that," they're lying to you. Maybe accidentally, but they're lying to you. This is thirty-five hundred commits in, okay?

There is no-- There's no one shot, and I think that's a lot of where the conversation gets lost is, well, if they can just spit out code, well, then why do I need a developer? Because I'm thirty-five hundred commits in, okay? It's a huge code base, um, and I've never written any of that code, nor have I used any of those languages.

I don't like TypeScript that much. Um, I love Vue.js, but for this, the ecosystem was the most robust with a React front end. And again, I care about ecosystems because I want a complete, cohesive experience, not a box of parts that I could maybe put together or my agent could maybe put together.

I want something that is thoughtfully executed, okay? So the first draft is cheap, but everything happens after the first draft, right? Thirty-four hundred commits, fully one quarter of them contain fix. This is the job, right?

This is the job, and this is the thing that I don't think people really understand about the job, is it's easy to slop something out. That much is clear. It's easy to slop something out. It's hard to spend fully a quarter of your commits, probably like sixty percent of your time, figuring out what went wrong, making those fixes.

So if somebody is like, "Hey, listen, code is free now," of course, bad code is free. Bad code's always been free, honestly. It is, are you gonna do this? And inside of this twenty-five percent are decisions that only people that actually care can make, right? Only people with engineering judgment can make the decisions that lead to these commits.

It's stuff like, should we include this library at all? What is the architecture of this code base? What are-- The agents love to talk about seams, right? What is an appropriate seam? Do I want fat models, skinny controllers, fat controllers, skinny models? These are things that you as the engineer, this is where you have to guide those slop cannons and say, "No, no, no.

Back up." Like, "I'm, I'm in charge. I'm the captain now, and I am going to tell you the shape of the system." Because AI does not add stuff the right way. It adds stuff the easy way, right? It has been specifically trained to make you happy, right? It wants to fulfill your prompt.

And so more technically, the AI will propagate the shape of the existing system forward. So it takes your prompt, it takes whatever other context it wants, and then it looks at the shape of your existing system. And so if it comes into your system and finds, "Oh, we're cool with repeating functionality across these different layers.

Oh, we're cool with duplicating code everywhere," what it's gonna do is it's gonna say, "All right. Well, I guess I'll just propagate that existing shape forward." But if it comes into a code base that says, "Listen, we use strict types," going back to the previous talk. "We use strict types. All of our, uh, domain logic lives in, we'll say, Laravel actions or something.

Our controllers are thin. We have, uh, we have architectural testing." Then the AI has a much better chance at propagating a good shape forward instead of just, "I don't know. We'll, we'll see how I can make you happy the fastest." So we're gonna talk about building, uh, building boxes because ideally, we're putting the AI in tiny little boxes inside of your code base where it can reason about the entire shape of this specific universe,

right? Because if you can clearly define where the AI is supposed to operate, you have a much better chance of keeping that blast radius way down. Okay? So we're gonna talk about some technical specifics, but the point is, there's a reason all of these models talk about, uh, seams and handoffs and all these insane terms, right?

They want to reason about a specific part of the code. And if you say, like, "Go have fun," it's gonna litter stuff everywhere, which is what we've all seen. So a technical, very specific, extracted from reality example. The desktop app has an MCP server. It also has, um, the front end, which is the web view in Tari, right?

So when I started creating the MCP server, this was the structure that I was creating. Um, the Tari web view would post over the IPC bridge, and it would create to-dos on the back end. To-dos are just a model. And then I made the MCP, and I basically said, "All right, we need to, like, mirror the functionality. Let's create to-dos on the back end using the MCP." And we all know where this is going, which is this is not the last ingress point, right?

So if we think about these as ingress points, like I've got the Rust core on the back end, and then I've got the web view and MCP. Those are ingress points. You can think about that like you've got your HTTP controller, your CLI, your queued job, maybe a Filament admin panel, a web hook controller. All of those things are ingress points, and if you don't decide the shape early on, you'll end up with five different implementations.

And so what I did was I told the agent, "Hang on. I see what you just did. Like, you just propagated the existing shape forward. You said, 'HTTP runs some back-end stuff. We'll make MCP run some back-end stuff.'" And because I'm an engineer, which you are too, I said, "This is a bad idea. Like, this is stupid.

We need to centralize, um, an operations layer," right? So instead of saying my controller does, uh, model creation, my MCP does it, my command line does it, we're gonna create a box where every new business operation can live within. So then we started migrating. At that point, the, the AI, the agent thinks, "Oh, okay.

Well, I, I understand. We put everything in the ops layer, and then we have thin ingress points." And then we route both the Tari web view and the MCP through the canonical operations layer, which allows us to do this, right? All of my ingress points are thin adapters that do validation or verification at the edge and then come into this one shared module.

Right? So going back to Laravel, this is basically the actions pattern, right? You have an action that does your, like, core business logic data manipulation, and then you've got all of your ingress points that say when it's coming from HTTP, we, uh, authenticate or validate this way. When it's coming from Filament, we authenticate or validate this way.

But now I have given the AI, you go this far and no further, right? So if we wanna add a new business operation, we add it to the ops layer, and then the ingress is very small. You have to teach, you have to teach the models what a good system architecture looks like. This is still very fun for me.

This is still coding. This is not product. This is code. This is not typing, but this is caring deeply about what the shape of the system looks like. And so a big part of what I find myself doing is talking back and forth with the agent about the shape of the system. I honestly can't even validate if it writes good Rust because I don't know.

But I'll have rules for that, which we'll talk about in a second. But if I tell the agent, "Based on the shape of my system, this is how we do it," my odds go way up versus a Claude.md. Okay? So it's gonna find the pattern, and it's gonna propagate it. Then it's still gonna wanna do stupid stuff, right? How many of you have had a model do something very stupid?

Yeah. And the rest of you don't use AI. Okay, perfect. Yeah. It's coming for you. Um, the model will still do something stupid all the time. But the good news is most of the stupid stuff it does is deterministically checkable. We can check, did you do something stupid?

And my challenge to you is when the model does something stupid, you don't say, "Aha, I knew it. I'm a genius, and the business people don't get it. AI is very stupid," right? That is a response, and I think emotionally that is a valid response. I don't think professionally that is a valid response. So when the AI does something stupid, you turn on your engineer brain instead and say, "Hmm, how can I prevent this from ever happening again?" And the, the answer is not add a rule to

my agents.md. The answer is write deterministic linting and testing more than you could ever imagine, okay? So I'm talking pest architectural testing. So, like, when Filament upgraded from... It was either three to four or four to five, uh, the namespace changed, and the models weren't ready for that, right? And so the models kept writing the old namespace.

That was frustrating. What I did was I wrote a pest architectural test that said literally never are you allowed to use this namespace, and you should use this namespace instead. Okay? So deterministic tests. Here, the agent continually wanted to use navigator.platform to figure out if the user was on a Mac or a Windows machine.

Tari has affordances for that. That's not something that it should be doing. And so I said, "Hey, idiot. I want you to write, I want you to write an ESLint test that just fixes it for all of time." It doesn't matter if they forget to read the agents.md or their Claude.md. This is deterministic, and it fixes it forever.

And so now if an agent ever tries to do this, we'll catch it, and that keeps the slop out of my code base and routes it through the place that it's supposed to go with a nice message that says, "Don't use this. Use that instead." So there are, um, there are several of these. Look around. So, like, this one is, um, using certain Tailwind tokens and not using other Tailwind tokens.

Anytime it makes a repeatable pattern that you can deterministically check Tell your agent, I know this is insane, tell your agent, "You just made a mistake. I want you to write a test to fix that mistake moving forward." And like, you'll be able to see if it works or not. So we wanna use these chaotic, um, probabilistic neon gods that answer that same question a different way every time.

We wanna use those to write deterministic tests that literally cannot change. Instead of saying, "Please remember to do this," you're gonna say, "No, I'm gonna put you in a box, and you can't get out of it." Another one here, um, a terminal, uh, the terminal is a big part of Solo, and it keeps wanting to do these weird things that makes it hard to test later, and so we just write more deterministic tests.

So I'm talking PHPStan, when you realize that like, oh, my agent wants to use, uh, PHP's native string replace instead of Laravel's facade helpers, right? Write a PHPStan, write a Pest architectural test, write a Pest test, lock it in, make sure that it cannot get out. You've built this box that it should live in, and now you have to guard it with your life because it's gonna wanna try to escape, and you can continue to write more and more tests.

You don't even just have to test the code. You can test the system. So the one at the top is audit production bundle. I one time released the application, um, and the production bundle, but not the development bundle, the production bundle was missing, uh, like a, like a P list, like an info file.

And so I thought, one, I'm never gonna remember this. Like, there's no chance I remember... I mean, we're at like a million lines of code. I don't stand a chance. I've got four kids. I can't remember anything. So we turn it into a deterministic check, right? I say, "Hey, we need to make sure that this never happens again. We need to set up a registry of files that should be checked in the production bundle, and then write a script that makes sure that those are always there." Now they're always gonna be there.

So you can see all sorts of like the affordance surface manifest drift. Like, these are insane. I would never have written this by hand because then if I had written it by hand, a lot of that checking would've remained in my head, right? You know you have this institutional tribal knowledge of, ooh, we don't do that here, and that would either get caught when the senior is writing it or when the senior is reviewing it later.

So what we're doing now is we're taking all of that, like I'm the expert, I have institutional knowledge, and we're baking it into code that can never fail, right? It can never change. It can never be forgotten. So now if we have, uh, if I release something new in the canonical operations layer, I have a script to make sure that it's exposed at every ingress point, and I have a script to make sure that the, uh, arguments exposed at the canonical operations layer are represented in the ingress points.

So if I change like maybe toDo.title becomes toDo.name, that script at the top is gonna validate that every ingress point has updated accordingly, and so I don't get this drift. So I'm spending a lot of time like boxing this thing in and then confirming it. Last one's, um, linting. All kinds of stuff.

So there are several JavaScript code quality things, PHP ones as well. I lint the JavaScript licenses to make sure that my agent doesn't acc- accidentally pull something in that is non-MIT that I can't release or that would potentially poison my code base moving forward 'cause Solo is closed source. I make sure that the rest dependencies, there's no like CVEs or anything like that.

Um, all of the shell commands that I'm using for like GitHub Actions runners, these literal scripts here, those are all linted as well to make sure that none of my shell scripts go out with any sort of like syntactical errors. So any time, here's my challenge, any time something goes wrong, whether, uh, it makes it through CI and it shouldn't have, you s- you test in production, you realize something's missing, um, any time it does something stupid, I would encourage you, is there a deterministic

check we can bake in? And you end up, uh, with a lot of... You end up with a lot of tests, right? There's more test code than there is production code. I don't care. That actually makes me super happy. I didn't write any of that, but every time something failed, I had it write a new test. I had it go red first and green.

So we're doing red, green refactor, TDD, whatever it is, I end up with, uh, 13... 15,000 test cases, 14,000 te- test cases, something like that, including a custom end-to-end harness, right? So Tari on the Mac doesn't actually have a cust- uh, doesn't have a built-in end-to-end harness because Safari's weird or, or something.

And so instead of saying, "Well, we'll just, you know, we'll just hope," no. The code is free. So I tell the agent, "Hey, we're gonna write a custom end-to-end harness. You're gonna spawn a little thing inside the web view. You're gonna spawn a server over here. They're gonna talk to each other. It can drive the web view." And then my check production bundle script makes sure that the end-to-end harness gets compiled out, so I can never accidentally forget to compile out this end-to-end harness, right?

So you see how we're like we're moving up out of, um, what is, what is the perfect like function name and what are the perfect arguments, and we're moving up into how can I design a robust system that these very smart and very stupid models can work within that gives me a lot of confidence moving forward that I can put my name on this thing, right?

And you know what sucks? Is building GitHub CI workflows. You don't have to do it anymore. Just tell the agent, "Build it." And so you'll see here, um- We've got-- If you look down at the bottom, that's eleven jobs completed. You move up to six jobs completed. You move up to the top, fourteen jobs completed.

And so it's just like, brother, test it all. I don't care. Test it all. Test literally everything. This is the only way that I can release the desktop application. I'm not gonna put myself at risk of having a release script on my machine. One, 'cause I might be tempted to use it and be like, "Ooh, I'll do a hotfix." No, bad idea.

Two, the agent might be tempted to use it. "Oh, I'll do a hotfix." No, bad idea. So push everything through this deterministic gate that is not on your machine, right? 'Cause your machine may get lost, stolen, corrupted, whatever. Push it through here and exercise the hell out of it. Just be like, "What else can we test?" Two hundred percent coverage, great.

I'm happy. Here's something that, um, that often gets lost in this discussion, right? Um, people will be like, "Code is free. Prototypes are free. You can one-shot anything, bro. Work faster. Give me more output." This is the part where you have to use your very powerful engineering brain and say, "Hang on.

We messed up here." Or even more probably accurately, we learned something new, and we have to rebuild, right? So the best example I have of this is from the Solo code base is rewriting the terminal. So I started, uh, with libghosty-web 'cause it was cool. Didn't work very well.

I moved to xterm, xterm again, a Rust, and finally, I'm at a custom-owned, a custom-owned Rust and WebGL terminal. Each one of these steps required, uh, required systematic engineering judgment. I had to decide at every point, is this the right move?

Am I willing to drop xterm, which has been battle-tested in VS Code for a dozen years? Am I willing to drop xterm, which the agent thinks is a bad idea, right? 'Cause it's like, "Hey, this is a good library. It's been used in VS Code forever. Are you sure you wanna take this on?" And it's gonna try to talk you out of it, but I had to decide, yeah, unfortunately, I do.

I do wanna take this on. This is better for my code base. I think it's better for the product, but the thing I cared about is this is better for my code base to get xterm out 'cause then we can keep the terminal in Rust where it's super fast and then just have a thin little renderer on the front end. No agent is gonna be like, "Hey, this library that's a huge amount of work that's owned by Microsoft, I think you should rip it out and go, go for it yourself." But as, as the engineer in the room, I

get to decide, right? I get to tell it, "We're gonna rebuild this," and that is my judgment, not the agent's judgment. Unfortunately, um, having controller over everything does not guarantee stability, but it does guarantee control, right? And so this is the part, uh, this is the part where you, again, have to decide, what do I want?

So after I rolled into my-- using my own terminal, it was a disaster. It was a nightmare. Um, but what it got me was the shape of the system that I wanted. I now own the ability, when my users complain, I now own the ability to fix the thing like I want. And in some regards, having control is exactly what we're now able to do.

There's literally zero chance I would have ripped out xterm if I had to write the terminal by hand. But now that we can bring this control in-house, you can decide what is best for my system, what is best for my users, what is best for the thing that I know is coming in six months but I haven't even talked to the agent about. I know that it's coming, right?

And so I need to set myself up for success in the future, and I don't wanna explain all that to the agent of like, "Hey, in a year, the big-- the suits want us to do this, and so we need to think about the architecture this way." No, I just tell it, "We're doing this." Right? So it gives you that, it gives you that control. But again, twenty-five percent of the fi-- twenty-five percent of the commits are fixes, and so this is the price that we still have to pay.

Nothing has changed, right? Nothing has changed at all. What I do think has changed is, um, what this gets us, right? So if we say, if we say that, that code is cheap, the first draft is cheap, um, we can prompt a lot of stuff into existence, right?

We can, we can just, we can clank it out, and it's done. And I'm telling you that you don't have to become a product manager if you don't want. Where does that leave us as professional developers, right? Because I'm saying move up, and then I'm saying don't go into product if you don't wanna be in product.

Where does that leave us, the developers? My stipulation is that, that leaves us with a lot more leverage, right? So you come into a meeting with stakeholders, users, product managers, CEOs, whatever, and you get to say, "Hey, code is cheap.

Therefore, I built three versions of this thing that we're talking about. I just slopped them out," right? In our minds, we thought we knew what we wanted, but after I slopped out these three prototypes, I realized this workflow is terrible. This one actually feels pretty good, and this one exposed this edge case that I don't think anyone was thinking about.

How are we gonna handle this? Right? And so you as the developer, as the engineer, come into the room with the ability to have a lot more leverage and say, "Not only do I have opinions," we're famous for having opinions, aren't we? But now I have artifacts, right? Now I can say, "Hey, just pull it up on this, you know, vanity.laravelcloud domain." Laravel Cloud, it's very good.

So we can just look at three different prototypes, right? And now the people that maybe are making decisions about what you'll work on the next sprint or cycle can look at this stuff that you've done, and your opinion gets more valuable 'cause you're not just saying, "Trust me. I'm in-- I'm, I'm the wizard in the cave, and you can't approach me, and I promise you that if you do it your way, you're an idiot." You can say, "Here's what I've done.

This was easy. This was free." And we can go back and fix that and bake it into actual product. So you get a lot more leverage if you're willing to come to the table with more than just opinions. Now you can come with artifacts that maybe took an hour for the machine to write while you were watching YouTube videos or something, okay? Um, this hasn't changed at all.

This has been my experience for twenty-five years since I started writing code. As you're building, AI or not, as you're building, uh, you're discovering not only what the product wants to be. Forget the product, right? You're discovering what the code wants to be, which is an insane thing to say, but I know that you all know exactly what I'm talking about, right?

You start writing it, and you're like, "I'm a genius." And then you get a half step further, and you're like, "Well, I'm not very smart." And that's because you're discovering-- when you put pen to paper, you're discovering, oh, this system wasn't actually fully fleshed in my head, right? This thing that I thought was a good abstraction actually doesn't take care of these cases.

So let me pull back and then redo it. That is the exact same thing you're doing with AI. You're discovering along the way, why is the model having such a hard time grasping this? Like, this should be very clear. It's very clear in my mind. And you start talking to it, and it's like, "Well, it's confusing because we have these operations crossing these boundaries." And you're like, "Huh, that actually is a good idea.

We should centralize the place that this works. We should give it one enter point and one exit point." And so as you're moving faster, you actually have to exercise more care and more judgment more often, right? It used to be such that we would do this over the course of weeks, right?

We would discover abstractions, we'd tear them down, we'd build them up. Now it's done in minutes. And so while I don't think your job is gone today, I think it's definitely not gone in the future. I think it's more important moving forward as things go faster that we have people with good systems minds, we have people with engineering experience making these decisions because they're coming a lot faster.

And so as you're building, you need to be pulling back and saying, "What am I learning from this? What does the shape of the system want to be? I'm gonna draw it, and I'm gonna take that screenshot and hand it to Codex and say, 'This is what I want the shape of the system to be. Where are we at now?'" And it's gonna be like, "Not there." I'm like, "Great. I feel like we should move that direction." And you talk back and forth with it.

But your judgment becomes a lot more important. People like to talk about taste, like taste is the only thing that matters. And you're like, "What do you mean?" And they're like, "I don't know. Taste." And so from my perspective, engineering judgment is not the only thing that matters, but it's one of the top few. The judgment to say, "We're gonna vendor this library. We're gonna build this system out.

We're not gonna do that even though that's in the training data. We're gonna change this, uh, interface. We're gonna change the way this subsystem works," that's your job moving forward. You get to build systems. You don't necessarily have to do the underlying implementation if you don't want. But my goodness, if you've ever seen something that's slopped out by a non-engineer, it's very clear, right?

You've got-- You click on a thing over here, and the thing over here changes. It's loading and errored at the same time. And you're like, "Ah, I guess they don't know about state machines." Of course, they don't. We do. We should tell the agent, "Hey, we shouldn't be able to represent impossible states." And it's like, "Oh, that's a very good point, sir. Let me change that to a state machine." And you're like, "Why didn't you do that in the first place?" Right?

But that's our job now is to say, "State machines exist, my friend. Ring buffers exist, my friend. FIFO queues exists. Schedulers exist. Enums, structs, all of these things exist. Let's obviate, uh, not even fix. Let's make them impossible, these bugs," right?

If you're-- If you have a state machine that can only represent loading, loaded, or errored, you're not gonna get loading and errored at the same time. And that is our job, is to build these systems with this knowledge that we've spent decades building up. So I think the answer to the question at hand, where do we go from here?

I think personally, I think you let go of the keystrokes. I really think that you do. But I don't think you let go of the caring. I think that's something that makes the people in this room very special, is that we care deeply about the art and craft of code. You do not have to go into product. You have to keep caring about the code. I don't think you have to write it all by hand.

Thank you.