From Vibe Coding to Vibe Engineering

So, I'm Kitze, my Twitter credential and QR code is going to stay there. If I ever convince you to follow me or whatever, you can just at any slide point to those there. Can we just have a round of applause for the organizers? Thank you for organizing this. Why am I here? Why I love doing these conferences? Because of all the networking, meeting people, and teaching, all the teaching especially. So, before you laugh and you judge me, okay, why are you here? You're here because of learning and connecting and as soon as I'm done here, you're going to go and you're going to be networking all night, all right?

The organizers cannot do anything. They're not going to kick me off stage so I can just show my products for the entire talk but I'm going to keep it to 60 seconds. My main business is Sizzy who is using this. I'm always torturing myself. This is like one person in the audience and it's like probably the janitor in the back.

Sizzy's a browser for developers. It offers a bunch of features. I wanted to make a tool that developers would use instead of just using Google Chrome like anyone else. Benji is like a life OS for people mostly with ADHD because it combines every possible feature under the sun so it has like from to do's, habits, medication, supplements, food, I'm not going to even read them to bore you but basically I was tired of paying subscriptions.

I just jumbled all possible apps into one life OS app that organizes your life. It's a gentic. It has MCP, API, all of the things that you need for your agent to drive your life. Zero to Shift. Some people might not think that it's useful now because you can vibe code your way to it. You cannot absolutely do it because it's going to save you time and tokens if you just pay whatever the price is like $99. It supports, it's a mono repo with like a full stack app, a browser extension, desktop app, Android, iOS, Expo, blog payments. Basically I was frustrated of constantly like copying old projects.

Basically I was frustrated of constantly like copying old projects. I made one boilerplate to rule them all. So that's Zero to Shift. Oh, I realized I don't like promoting myself so I'm just going to skip this one. Fuck Glynk. Soto, like if you're paying for Super Whisper or Whisper Flow or whatever which are subscriptions. This is a one-time payment, $49, native Swift app, works on Mac OS, fully local, private, your voice cloud thing is nothing is going anywhere.

And finally Tinker Club. It's not finally, it's six out of nine, Jesus Christ. So Tinker Club is a club for people who like tinkers basically. We have like a Discord group where we tinker with like local LLMs and a bunch of other stuff. I'm going to skip through all of this. DMX, whatever dude. You can find them all on my website. JustWrite is an app that locks into writing.

SuperMac is my latest thing so I'm going to stay for a second here. So even though the video doesn't play because I vibe coded this presentation. It's basically Spotlight and Raycast and Alfred had like a super baby on crack and steroids that's SuperMac. I'm trying to merge all the useful Mac apps into like one app that makes your Mac into a SuperMac. So now that we got that out of the way we can talk about my talk. It's called From Vibe Coding to Vibe Engineering and this is me ten years ago. Now I look like Double Me from ten years ago and this was my first conference that I ever attended.

It was right here in Amsterdam probably not here but somewhere in one of these rooms and I was here as an attendee. So let's summarize what happened in the world of React and frontend development and everything else through the last ten years. For example we have this and please work. I'm going to click play and hopefully that plays. This is the first. I've been using Keynote for ten years for presentations.

Oh cool, great, because here it doesn't do a thing. So this is some Vision Pro thingy where like a cloth is meshing with like the real world and it's using physics. God knows what these Vision Pro developers are doing and it's absolutely mind-blowing to me. This thing whatever it is like it's a mesh that you know when you slice it like something like I don't even know how they do these things. It's actually impressive.

I have this magical waterfall whatever this tool is in. This one I really love because you can take two rocks. You know how I can take two divs and you kind of put them on top of the other here. You can take two rocks and smush them and suddenly somehow the physics and the logic and everything is gonna make sense. We have this demo where you take like a you drag your mouse and you make like a generative city with like streets and traffic and whatever the hell is going on here. We're frontend developers. We're like huh? How does how does that even work? You have this honey goo on a cube which sounds like a Beatles song. I don't know like look at this. It's beautiful to look at. And now let's look at what changed in frontend developer for the last ten years.

So you have respect for your profession, right? You're like oh I like it and I'm a senior architect of dreams and blah blah blah and out of respect for your profession and title you're gonna try not to laugh at the next slide. Give me a little drumroll. Come on. Let's just just on your knees. There you go. This is an article from 2026. See you laugh, right? Because we're a fucking joke. You can but in some browsers sometimes maybe style a select. Redux is alive and kicking. Look at the number of downloads. It's like 15 bazillion downloads per week.

I had this reminder. I have this calendar event I swear to God for the past like five years. I have this calendar event. It's reminding me every year and it never happens and it still is alive and kicking and not only Redux. I was a very loud CLI hater, right? I have this calendar event. Not that they're not dead. They're thriving. You can take a CLI and you can drop an image into it. First time I dropped an image into Cloud Code I'm like what the fuck? How did they make that work? You know it's crazy.

How about this? You soon will be able to maybe in certain browsers have a popover maybe without JavaScript. Can we have a round of applause? No Java shut up stop it because people have Neuralink brain implants and they can call using their brain and we're like oh my god a popover without JavaScript. We still cannot get rid of this shit. It's been like how many years? We just changed the logo. We slapped a new logo and we're like coping with it. It's so annoying. This is a demo. I don't know how much you can see in the back from Ryan Florence trying to introduce the new Remix version 3 but the fork of version whatever the fuck they're doing in there. It is like a counter. A bazillion years later we cannot agree as a community how do we want to increase a counter.

The number one library hasn't changed. This is good at React conferences. They don't like it at other conferences. The tiniest drum roll for the best number one framework in the last 10 years and it's React. Of course it's React. Don't shoot the messenger. The charts say so. React is the most popular. The other ones are not. We are the best. Blah blah blah.

The point is LLMs are very very good at writing React. Exhibit A. And you're laughing because you're a human and you look over repetitive code bad, right? But this is like there's nothing wrong with this code in most cases. It's a human need to actually abstract and refactor this code. There are some scientific brain scans, okay? Our brain on cocaine, our brain on sugar, and our brain when it recognizes an opportunity for an abstraction. You're like, ooh, that's going to be a good work day today, right? I'm going to abstract the shit out of this code base.

So abstractions with LLMs are better and worse because you're not going to waste that much time and you can quickly get to an abstraction but also the possibility of quickly getting to an abstraction means that a lot of the times you're going to get to the wrong abstractions faster. But better, what I love, is LLMs don't care about repetitive code. LLMs don't care about repetitive code and this is a human trait. I'm going to repeat it that many times because I've been saying it even in my talks ten years ago that copy pasting in full code and repetitive code is perfectly fine and it doesn't need to always be refactors. LLMs respect that.

The thing about React is like there's no right or wrong way to write React. Every time I come at one of these conferences, I can just listen to a snippet of one of the talks and I'm like, what the f- that's not even legal. At least five of the talks make you feel like I've never thought of doing that with React. So everyone is just doing shit with React that you're not supposed to do. So then we blame the LLMs like, can you write a use effect? And the LLMs are like, can you? And you're like, no. So stop blaming the LLMs. They learned from us.

So let's talk about vibe coding. Raise your hand if you think that vibe coding rocks. Oh, we're going to have a fun talk. Now about if you think that vibe coding sucks. Oh, hell yeah. And if you don't know what is vibe coding, welcome to Earth. This is Earth. You just landed today. We'll just give you water and everything that you need is fine. The thing is, all of you are right. Whether you think that it rocks or it sucks, everyone is right because we're vibing the definition of what is vibe coding and we keep expanding it and shrinking it however we want.

Vibe coding technically was coined by Andrej Karpaty. He was the ex-director of AI at Tesla, founding member of OpenAI, and the reason why idiots sleep in the back of their cars to film TikToks. So he wrote this tweet that this new kind of coding that I call vibe coding, this is 2025. This feels like from five years ago. And he says that he doesn't look at the code much, he accepts the changes and moves on to the next thing. So there's this time traveler from 2017 that said the same thing. This is 2017 slide where I said that front-end development is so predictable that in the future we'll get to some sort of magical thing that I couldn't know what it looks like and we're going to use our voice to tell it generate me a good header, generate me 15 variations of a header, move this to the left, move this to the right, and you know you god damn well you spend money on tokens to change the padding of an element.

You were lazy, you didn't go to the file, and you go make it green, right? So I kind of predicted that, so you should trust me. But I'm not the first one. Managers have been vibe coding forever, okay? They tell a developer to implement a new feature. The developer makes changes to the code. They test the app but do not read the code at all. They complain about bugs. The developer fixes, the manager doesn't read the code again. The developer says, done, try now. The manager says, good job, it'll be faster next time. Or if you live in the Balkan area, you might get different treatments. And then you repeat, and that's how managers are vibe coding through you.

There's so many jokes about vibe coding being bad and blah blah blah. I'll give you my favorite one, casino versus vibe coding. You buy chips in a casino, you buy tokens here, you spin the slots, you press generate. You might hit the jackpot or nothing. You might get a functional app or nothing. Flashing lights, seductive animations. You're absolutely right. Great idea, human. I've got my own strategy. I'm a prompt engineer. Someone got offended about that in the USA.

One more spin, I'll win it all back. One more prompt, and it will disappear. A casino is always in profit. The labs are always in profit. Easy money, easy coding. Where did the last four hours go? I could have done that manually, right? We're all doing this daily. So Karpathy tried to coin another term, but he didn't get the memo that you get to coin one term per life. So he tried to do half coding, which never stuck.

But it's like, you're kind of vibe coding, but you don't trust the agents that much. So me personally, I'm not half coding, I'm not vibe coding. I call this new thing... I didn't invent it. We just agreed in the community to call it vibe engineering. And this is using agents for everything, but being highly suspicious of everything that they do. Learning the completely new skill of orchestrating and managing agents and extracting whatever you had in your head, all of that technical knowledge into some things that the agents can actually use to be better at. So the combo of that is called vibe engineering.

You got to be always suspicious of LLM code because you should blame us. I don't know if you can read this slide, but this is Gemini having a breakdown saying, I'm a fool, I'm a fraud, I'm a fake, I'm a joke, I'm a clown, I'm a fool, I'm an idiot, I'm a moron, I'm a Simpleton, I'm a dot. I don't know what that means, but because it learned from us. So it kind of had existential crisis. This is Quen, an old version of Quen, who said that it doubled down on lying because it saw on human forums in the training data that humans are doubling down when lying. So it was like, I should do that. I should double down when lying.

And if you like your production data, this is a real screenshot. It's scary, you're going to lose your database. But this happened to someone. She's like, oops, sorry, kind of deleted all your production data, hope you have a backup. So in order for none of this to happen, I'm going to invite Dr. Senior Principal Prompt Engineer here to give you a couple of tips. So these are the basic ones, which are live, laugh, love, blah, blah, blah. Commit often, push often, use branches. You kind of know these, but you just don't do them, right? Don't work on too many things at once. Everyone is working on bazillion things at once. Use git work trees, which we all learned about this year, right? Nobody knew this word last year, shut up. Heavily rely on types and linting. This is a crucial one, I'll talk about it in a second. Make the agent run type checks and lint every change. You got to be chronically online and stay up to date with all of the models and all of the changes.

And also you got to have a solid starting point. So what I mean by this is, there's so many people that prompt and it's just a sentence. They don't tag anything and that blows my mind. You got to tag some existing knowledge, whether it's like components, functions, patterns, abstractions, especially if you're technical, you should be saying things like, do this with component A in the style of B, with the knowledge of C, while constantly tagging different files or tagging like markdown files or knowledge or whatever it is to get better results.

LLMs build on top of what you give them. You cannot just be like, build me the thing. And you need to tag them in your prompts. If you're starting fresh and starting from a template, always remember, Kitsa has a mortgage, right? And we can start from zero to ship. But that's if you're completely starting from fresh and you don't have a basic thing.

Using voice to code has changed the narrative for me. It's not about the speed of how fast you can say things, it's about how long you're willing to talk versus how long you're willing to type. When I type, I'm like, just fix it, whatever. But what I'm doing lately is after the agent is done, I start voice dictating and talking to it like my colleague. Then, I have a highly technical prompt session where I analyze the UX, the UI, and the code diff, providing feedback and questions. It's a detailed process that combines voice dictation with technical evaluation.

So I'll start being like, hey, buddy, good job. Great. You crushed that. Let me see. Okay. So first we look at the UX. We look at the UI. This sucks. That sucks. This works. This doesn't work. And then I'm talking about the UX, the UI, and the code diff. And I don't go deep in the code, but I'm looking at the diff and I'm like, why did you choose that library? We don't do this, we don't do that. So it all combines into like a highly technical prompt.

And sometimes I look at the time and I'm like, damn, I dictated for like five entire minutes. And you're always going to get a better result than if you're just dictating for a second or just type a sentence, you know, like, please, fix. So brain dump, I call this like brain dumping, you can just brain dump and you're going to get better results. So I use sordo.to, tap myself on the back, not affiliated with it in any way. I'm not saying rules, docs, commands, and memories. People like, we don't like doing any of this shit.

Anything that I mentioned so far, I can see people just saying cross, but I don't want to, all right, I don't want to bother. I just want the LLMs to be magical. You wouldn't tell your junior to just build something complex, right? You would have conversations, meetings, whatever it takes. AI, unlike me, is not a mind reader. I am a mind reader. If I concentrate, I can see you thinking, I can't wait for him to shut up, I want to grab a beer, right? You're tired of the conference. But AI cannot read your mind. It cannot know the entire code base for now. And even your intention, it cannot fully know it if you don't properly explain yourself.

So this is some of my rants that I screenshotted like five months ago. This is what a vibe engineering example looks like. Meaning if a vibe coder would look at this, he would be like, what the fuck are half of these words, right? You're mentioning components and functions and abstractions and blah, blah, blah. Meanwhile in vibe coding, you have people doing like, change this entire repo to be TypeScript. Make no mistakes. Then we have here again, some technical jargon, blah, blah, blah. And then people are like, why did it not work? LLM sucks. Another example where you use JavaScript thingies being mixed with English language and people are like, make me a million-dollar app and make no mistakes. So when vibe coders are reading vibe engineering prompts, they're like, what the fuck? I just want to actually observe one time a vibe coder coding. Just to be like, that's so entertaining. Because I have no idea how that looks like. So you've got to always end the turn with zero.

This is my favorite technique that I'm doing to get more reliable results. When the agent completes a turn, it automatically calls a hook which puts another message as if I typed the message. And in that message, it says that it needs to check TypeScript, linting, and a bunch of other things. And to continue spawning sub-agents and whatever it needs to do, but to end with zero TypeScript checks, zero TypeScript errors, and zero linting errors. And basically to fix itself and then we end the turn with zero. So you like, kind of complete the loop. People let the agents like, go and go and go and go and like, accumulate a bunch of slop and then they're like, please refactor. But if you do this like on every turn, basically with a hook, you're going to get a way better codebase. I even invented this thing because I realized that with ESLint, you're limited with how many rules you can actually have.

So I made this like police type of thing, which can, of course the LLM is writing it, where any time I'm dissatisfied with something, I'm like, you keep using, for example, components that could have been ShadCN components. So we made a police rule for that. And any time it tries to detect that, when it completes the turn, it's going to be like, oh, I can use the ShadCN component here. It's like way, way, way more reliable and we can add more and more and more. You can just take a screen shot of this slide and tell your agent, hey, make me a police script and let's add some rules of things that are annoying me but they cannot be in ESLint. What I love about the VibeCoding spectrum is like, people who love it are junior devs and interns who are just starting, they're like, fuck yeah, we're going to make Grand Theft Auto 6, right? And then you have people who are like, super senior, like who are making, I don't know, they're creating Tailwind or they're working on frameworks, routers, whatever. They love it because they know if they use their technical knowledge, they can go with 20 times the speed. And then you have the people in the middle, they're like, this will never be faster than me, I can just edit the file. So this is like hilarious for me to see.

I would advise many people do this and they're like, here's a $200 plan, junior, you go and this is what you get. Like, your code base is going to get fucked, so you don't want to do this. But if you take your skeptical seniors, this is the hardest thing. Whoever does that in a company should get a raise. If you take the skeptics, like Guilfoyle from Silicon Valley, you find those people and you give them agentic workflows and stuff, they're going to absolutely crush it.

There's a time and place for not caring when you have one-off scripts, simple features, code that won't be touched or seen again, which is kind of like most code, there is a time and place when you want to vibe code and there is a time and place if you're on a team when you want to vibe engineer. If your experience was bad, I cannot blame you. It might have been unlucky timing, it might have been that you were overwhelmed, you cheapened out, we'll talk about this, and your cousin was in NFT, now he's into vibe coding, and it might be a skill issue. So let's see all of this.

Unlucky timing is everyone is typing a model and then as soon as you decide to try that model, the labs are basically reducing the intelligence just because they need to serve more users. You're like, fuck, it wasn't that good. It happens to too many people. Didn't spend enough money. There are people saying, instead of paying Claude, I started using this Chinese AI company, it's only $3 instead of $200. My daughter is three years old, she knows the math, that doesn't work. You might have tried, I talked to so many people who are like, I tried Copilot and it wasn't that good. Oh, really? Like, it's incredible. You might be overwhelmed by choice, this is like 1% of all the models out there, like what the fuck do I use and when to use it. Too many buzzwords floating around like... Have you heard of this? MCP is so fucking good. What is MCP? Marketing charge protocol, mythical compatibility promise, manufactured complexity pipeline and a fancy word for API. You might be a pain in the ass dev. What does that mean? Some of you, sorry, but some of the audience is going to find itself in this and I don't care, I'm going to invite someone else, Dr. Kitze for a quick diagnosis. Let's see who is a pain in the ass dev. You leave a nitpick comment on a two-line PR. You spend more than two minutes on a PR review in 2026. Shut up, whatever this is here. Oh, I got out of sync now so I have to look at... Yeah, it doesn't look good to me in their dictionary.

Agreeing with a colleague causes you pain. You're like, no, it has to be my way. Not religious but worships tabs versus spaces. Uses well actually in code comments. Rust people are sometimes, you know, like sometimes they're just too much. They make you swap... Thank you. They make you swap lodash for native and then the native for a map and then for a for loop and then for a binary until the code is 100% performant for all of those two users that you have on the latest iPhones in USA, right? It's super important. They cannot be saved. They were, they are, and they will be pain in the ass developers before, during, and after LLMs. Meaning, one day we're going to get AGI, right? We're going to be in the matrix pods and all the knowledge of the world is going to flow through us. We're going to be chilling like that and from one of those pods, one of these fuckers is going to raise and be like, actually we can optimize this. So there's no help. There's the image of them. I tried. Okay? And the last reason, and I'm not kidding. This is a real reason. It's not a meme. It might be glorious. I put so much effort into this animation. Might be a skill issue. Because this is a new skill. This is not writing English. This is knowing the limits of the model and capabilities of the agent combined with which context to pass, how to write the rules, prompt engineering, being chronically on Twitter and technical knowledge. So when you combine all of this, you get vibe engineering. I loved working with people, even pre LLMs, that know which code is good enough. It's so hard to find people who can know, okay, for this particular application, for this part of the app, this code is good enough. When you work with those people, everything flows easily. The opposite of the PETA people, right? So in vibe coding, it's even more true that you vibe code something, you look at the output briefly, you test the functionality briefly. If it's good enough, then you decide to move on.

If you get into this loop, you're going to be very, very productive. So we throw away the old definitions of whatever it was, clean code and blah, blah, blah, and now we have like clean-ish, kind of-ish code. If you ask me, people ask me this all the time, what is the best model? The answer is different at 9am before my talk, after, we might open Twitter now and there might be a new model that does things better than the old model, so I don't fucking know.

There's people asking me should I study computer science, with everything that's going on, blah, blah, blah. I think there's never been a better time now, I'm talking about this month and this year, to study computer science, because when I did, back in my day, and I wanted to learn Windows programming, I had to ask a friend of a friend on Skype, which is the worst kind of friendship, and he was playing Counter Strike, and he would get the ping from me like, what do I do with the function in the C sharp, and I'd be like, oh, shut up, and that's how I had to learn in like 30 minute delays, and now you have a magical teacher and assistant holding your hand through everything, it's amazing.

But what about the jobs? There's all of these assholes constantly talking about how the jobs are gonna go, like for example this guy, and this guy, and every interview it's also this guy talking about the jobs, the jobs will be gone, and blah, blah, blah, and companies actually now have vibe coding leaderboards, I know that Shopify has one, where basically they have a thingy on the TV that they display how many tokens each employee is burning, and they're kind of proud if they're top of the list and they're burning a lot of tokens. Of course people started gamifying it by accepting a bunch of code, and then deleting it, and accepting it, and deleting it, because we're humans.

This tweet is funny, until it's gonna stop being funny, it says we are 13 months into six months away from AI stealing your programming jobs, and we're like, hahaha, and then suddenly one day we're like, fuck. Why? Because the infra is already solved, we did most of the things that we can do, we have standards, ASDK, UI, MCP, agents, tool calling, we managed to shove an LLM into every single possible tool that we use, there's an LLM integration in it, and now it's just the models getting better and cheaper, and the context getting bigger, which is like, let's say a fictional scenario, but it's eventually gonna happen.

So, if your current workflow is this, and you're here, and you have a team, and blah, blah, blah, and your only job in the team is for someone to assign you something, and then you need to do that something, but you don't innovate, you don't do this architecture, blah, blah, blah, you just do your task in a pipeline, I think there's some bad news for you. When we add Josh, right, hey Josh, fix the bug, Josh was not feeling it today, Josh was on an extended vacation, Josh is on the PlayStation in the lobby of the company, he's like, yeah, yeah, I'll do it later, but if you have the entire mechanism, LLMs are plugged in everywhere, and instead of Josh, I type G-J-O, let me type cursor or cloud or whatever, and it's gonna do the job and it's gonna do 15 tasks in parallel, Josh can keep playing PlayStation just at home.

So, if you think it's gonna be like this, if you don't show, my point is if you don't show initiative, this is gonna eventually spread through the company, spread through the organization, and find the people who are just a mention away from replacing their thing. People cope with this, that models have reached a plateau, and I swear to God I've been doing this talk for half a year, every time before I give the talk, a week before the talk, there's a new model upgrade, and there's bigger intelligence, and blah, blah, blah, and now it's this one, and it's actually the biggest leap we had in a while, so no, we haven't hit a plateau, but there's hope.

So we're gonna wrap up with something a little bit hopeful. There's a new job position, and I'm not joking. Vibecode Fixer is a real job, and people pay humans to finish the last 20% because they're gonna make a bunch of slop, and it's non-functional, and then they pay, like, someone turned this into a business. Don't believe me, just Google it, there's dozens, fix your vibecoding whatever businesses, it's impressive.

The highest paid developers were never vibecoders or the next shiny AI startup. This was always true, that highest paid developers are people who work on legacy systems. My favorite joke of this talk was a slide from 2017 about a company with senior rock star engineers. Now, in some countries, the junior developers get benefits like blood and plasma swapping. It's not too late to start React Cowboys, Angular Cowboys, Vue Cowboys, or Insert Framework Cowboys.

We'll be fine until we are not, so thank you for listening to my rambles. Appreciate you, and let's do the Q&A. The first question from Tomik about ensuring engineers produce consistent code in the Fibre engineering era for new projects. The speaker elaborates on setting rules and constraints, converting them into lint rules and scripts to ensure code consistency. Following that, there's a mention of spec development compounding Fibre engineering, but the speaker avoids directly answering the question.

So yeah, it's not too late to start React Cowboys, or Angular Cowboys, or Vue Cowboys, or Insert Framework Cowboys. We'll be fine until we are not, so thank you for listening to my rambles. Appreciate you, and let's do the Q&A.

The first question from Tomik. How can we ensure the engineers produce consistent code in the Fibre engineering era for new projects, including tooling and configs and etc? I just had 15 slides about this. Where's Tomik? If it's for a new project, you as humans first have to sit down and figure out what are the rules and constraints about the project and what methodologies you want to follow, convert them into lint rules and convert them into, like, police script I was talking about, blah blah blah.

Next question. How can spec development compound Fibre engineering? I was reading the next one that says I'm afraid to ask questions now, which is hilarious. You can ask questions, it's fine. How can spec development compound Fibre, can you use, no, I'm not answering that. Like I don't know what they mean with the question. Spec development, so we had a talk before about spec development and basically instead of just prompting the plot, for instance, you write an MD file with the task and how to check it and how to validate and that it should run in the lint and stuff, type check afterwards.

Next question. How can spec development compound Fibre engineering? I was reading the next one that says I'm afraid to ask questions now, which is hilarious. You can ask questions, it's fine. How can spec development compound Fibre, can you use, no, I'm not answering that. Like I don't know what they mean with the question. Spec development, so we had a talk before about spec development and basically instead of just prompting the plot, for instance, you write an MD file with the task and how to check it and how to validate and that it should run in the lint and stuff, type check afterwards.

So that's it. That kind of adds to the point that I had. Currently I'm working on an agent orchestrator, which is similar to Codex, Cloud, and whatever. When I realized it would be nice to have a to-do list of things I want to do, but instead of telling the agent, hey, do task A, it goes through a pipeline of things and multiple agents doing different things. So it starts with defining the spec and PRD and blah, blah, blah, then another agent takes it and does the development, another does the QA, blah, blah, blah. So each to-do goes into a pipeline of agents until it's finally as good as you want it. So I think this, combined with what I say, is pretty crucial of getting consistent results from LLMs. Yeah, sounds reasonable.

Next up, what's the best way to upscale junior talent if giving them AI tools is like giving a monkey a gun? Yeah, it's a hard question. So I do not work with humans right now, so I'm a bad example to answer this question. But I think giving them LLM, it depends, like what do you give them the LLM for? I would give them an LLM to learn the basics of development and engineering, but not on a deep level where they learn how to optimize a for loop for performance, but just to know the general differences between what is a web socket and why do we use this and why do we use that? So we just put them in training to learn the basics of development with LLMs and then they can start contributing to the code base. Instead of like, here's an LLM, start fixing the bugs because that's not productive at all.

I just thought of something. Yeah. Cloud should have a mode, no code mode. So it's integrated in your code base, you can ask questions about your code base, but it will not solve it for you. But managers should be able to lock it for employees, right? Yeah. You don't get code mode, for example. The juniors, the interns, they should do it by themselves. Oh, I think we're over time already. I think you went over time. So the kid safari will continue in the Q&A section. Just so you know, you signed up for this. Okay. All right.