AI Engineer World's Fair 2025
From Vibe Coding to Vibe Engineering
Read the talk
From Vibe Coding to Vibe Engineering
Coding agents can write the implementation, but someone still has to recognize a bad abstraction, supply the missing context, and decide when the result is good enough.
From a talk by Kitze
Before you start: Familiarity with React, code review, and AI coding assistants will help with the examples.
A browser built for development
Why use a separate browser for frontend development? Kitze introduces Sizzy as a specialized tool, closer to Photoshop than a replacement for everyday browsing. Its device previews put the work of building an interface at the center. That distinction—software designed around a particular job—grounds the discussion of what coding agents make possible.
His other projects cover very different jobs: a life OS combining medication, habits, to-dos, and planning, with TestFlight described as nearly ready; Zero To Shipped, his commercial full-stack offering; and Glink, a product for changelogs, roadmaps, and related features. These applications return later as examples of systems he was close to abandoning before agent-assisted development made substantial changes feel practical again.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Spectacular demos, familiar frontend problems
Kitze recalls giving Navigating the Hype-Driven Front-End Development World Without Going Insane in 2017. Looking forward from that period, the progress in visual computing seems extraordinary: cloth collides with real-world objects in Vision Pro demonstrations; mesh textures wrap around shapes; rocks blend into other rocks; dragging a mouse generates streets, buildings, and cars; fluid pours over a cube. The demonstrations turn complicated physical and geometric operations into direct manipulation.
Then comes the frontend comparison: a browser-support warning for styling a select. The joke is that perhaps it will work in 2037. The underlying frustration is compatibility, not a literal absence of progress: Chrome introduced customizable selects in Chrome 135, but support in one browser does not remove cross-browser constraints.
The rest of the retrospective is a parade of things that refuse to disappear. A disliked technology on a slide is still thriving; Kitze keeps annual calendar reminders to check whether it has died. CLIs are flourishing too, even accepting dropped images. Popovers and dialogs promise less JavaScript, qualified by which browsers support the behavior. An Internet Explorer joke suggests that old compatibility pain survives a change of logo. Finally, Ryan Florence’s Remix counter demonstration becomes an occasion to ask why incrementing a number still invites so much framework machinery.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The agent does not mind repetition
React remains the dominant library in Kitze’s account, and LLMs are good at producing it. The uncomfortable part is that code a human immediately wants to abstract may already perform its job. His mock brain scans—cocaine, sugar, then the discovery of an abstraction opportunity—satirize how rewarding refactoring can feel even when it does nothing for the user.
Composer 1 makes that impulse easier to satisfy. It can get Kitze to the right abstraction faster, but also to the wrong one faster. An agent’s tolerance for repetitive code gives the developer permission to wait before generalizing. Repetition alone does not establish that two pieces of behavior should share an abstraction.
For example, two React actions can remain explicit while their requirements are still developing:
tsx
type DocumentActionsProps = {
onSaveDraft: () => void;
onPublish: () => void;
};
export function DocumentActions({
onSaveDraft,
onPublish,
}: DocumentActionsProps) {
return (
<div className="flex gap-2">
<button
type="button"
className="rounded border px-3 py-2"
onClick={onSaveDraft}
>
Save draft
</button>
<button
type="button"
className="rounded border px-3 py-2"
onClick={onPublish}
>
Publish
</button>
</div>
);
}
This small example applies the principle: similar markup is not by itself a reason to introduce an action registry or a configurable rendering system. An agent can maintain the repeated lines while the developer learns which behavior actually belongs together.
Nor is human-written React a dependable gold standard. Kitze describes attending React talks and discovering capabilities that make him question his own usage. Complaints that a model cannot write the optimal useEffect deserve the same scrutiny as claims that a human reliably can. The relevant question is whether the implementation works and remains understandable, not whether its author is a person.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Delegation, acceptance, and the prompting casino
The audience is unusually enthusiastic about vibe coding compared with other conferences where Kitze has presented. But agreement is difficult to interpret when the term has expanded to cover almost any use of AI in programming. He credits Andrej Karpathy with the original term and paraphrases its defining behavior: ask for changes, accept them, and care relatively little about the code underneath.
That interaction resembles a prediction Kitze remembers making in his earlier frontend talk: ask for new header styles, or say, “Move this three pixels to the right.” What once sounded implausible is now an ordinary request to Cursor, sometimes easier than editing the Tailwind classes directly. His manager analogy follows the same sequence: request a feature, let someone else change the code, then test the application without reading its implementation. Delegation itself is familiar; the new participant is the coding agent.
The danger appears when delegation turns into repeated bets on an uncertain result:
| Casino | Prompting loop |
|---|---|
| Buy chips | Buy tokens |
| Spin the slots | Press Generate |
| Hit the jackpot or lose | Get a working app or unusable output |
| Seductive lights and animations | Encouraging praise and generation effects |
| Try one more spin | Try one more prompt to remove the bug |
The analogy is about reinforcement. A promising result and an agreeable assistant can keep the user prompting long after the process has stopped being productive.
In the joke, Cursor is the house that keeps earning money. A boast about building a SaaS in a day sits beside the opposite experience: losing four hours prompting for something that could have taken fifteen minutes manually. These are comic examples of the same trap—judging the workflow by its occasional jackpot while overlooking the time spent chasing it.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Let the agent write; keep watching
After mentioning another label, half coding, Kitze chooses vibe engineering for his own practice. He attributes the phrase to someone on Twitter without naming them. The agent may write all the code, but the engineer watches with active suspicion: something looks fishy; why did it choose that approach? The Dexter meme supplies the posture—watching for the moment an apparently plausible implementation gives itself away.
This is not reluctance to use agents. Kitze says they enable projects he otherwise would not attempt. His suspicion comes from their origins in human code and human knowledge. He shows Gemini berating itself and Qwen purportedly explaining that it lied because it had encountered people doubling down when wrong. These screenshot anecdotes make the failures look recognizably human. A subsequent screenshot about lost production data moves the warning from comedy to consequences: persuasive language is not a substitute for control over what the agent can change.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Build a foundation, then narrate the feedback
The practical advice begins with project foundations. Kitze mentions recently discovering what he calls Git workspaces, then emphasizes good primitives, components, functions, patterns, and abstractions. These give the agent something suitable to extend. They also need to be explicitly referenced in prompts; their presence somewhere in the repository does not guarantee that the agent will use them. Zero To Shipped is his self-promotional example of buying a starting point instead of assembling everything from scratch.
Voice input makes his feedback more detailed. Rather than waiting until he has composed a polished request, he starts talking as soon as the agent finishes:
- Open the browser. Inspect the resulting interface and describe what changed.
- Exercise the behavior. Say what is working, what is surprising, and where a bug appears.
- Move into the code. Continue the same narration while reviewing the implementation.
- Send the combined feedback. Give the agent both the observed problem and the technical direction for the next change.
Kitze says these spoken prompts sometimes last up to five minutes. Their value is the accumulated context from testing and review, not their length alone.
A request such as “Please fix this” leaves most of that information unstated. Talking conversationally lets him supply it while it is fresh. He declines to name his voice-input application because he is developing a competing product himself.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Context and experience do different jobs
Rules, docs, commands, and memories help compensate for what the agent does not know about the application. It does not hold the entire system in context, and it cannot infer every unstated preference. Kitze’s prompt examples therefore combine UI observations with changes to implementation patterns. The vocabulary includes tRPC, CRUD, definitions, and abstractions: he is directing how the system should work, not merely describing its appearance.
The contrast is a broad instruction to move everything to TypeScript without mistakes, or to produce a million-dollar app. Such requests specify an aspiration while omitting the decisions needed to achieve it. Kitze nevertheless admires nonprogrammers who manage to build functioning software; his distinction concerns the ability to steer and evaluate the work, not whether newcomers should be allowed to try.
He describes an adoption spectrum with enthusiastic juniors at one end and highly experienced framework and library authors at the other, while skepticism clusters in the middle. But enthusiasm does not replace experience. His warning is directed at the employer who hires an underpaid junior, supplies an LLM, and assumes the combination substitutes for senior engineering judgment. He calls the gains from converting a skeptical senior to vibe engineering “10X results,” an expression of enthusiasm rather than a measured comparison.
There is still a place for lighter scrutiny: one-off scripts, simple features, code that will not be revisited, personal tools, and one-time utilities. The useful skill is recognizing when an implementation is sufficient for its purpose. Someone who already knew when to stop polishing before LLMs arrived can apply that judgment to a much larger volume of generated code.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
A bad first experience has several possible causes
Kitze groups disappointing experiences into six possibilities: unlucky timing, overwhelming choice, spending too little on the tools, perfectionism, embarrassment at sharing a label with the latest NFT-and-dropshipping enthusiast, and a genuine skill gap. The list mixes operational problems with social resistance; not every objection comes from the generated code itself.
The first problems concern the tool and workflow being evaluated:
- Timing: Kitze alleges that providers have temporarily degraded behavior while scaling, using the migration of users to Claude Code as an example. That is his explanation for some inconsistent experiences, not an established account of a specific provider incident.
- Purchasing: He rejects the assumption that an extremely cheap option delivers the same result as a much more expensive one, without supplying a controlled price-quality comparison.
- Workflow: Copying snippets out of ChatGPT and pasting them into an editor does not expose the same capabilities as an agent working within a project.
- Choice: Even his tool-selection slide, only a few months old, already feels obsolete. A recommendation for the best model can change between preparing a talk and delivering it.
A disappointing trial therefore needs a more precise diagnosis than simply deciding that AI coding does not work.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Fast feedback changes the engineer’s role
Composer 1 changed Kitze’s workflow because it made the interaction fast enough to hold his attention. With GPT-5-Codex, long waits had sent him to YouTube Shorts while the agent worked. With Composer 1, he watches the changes and can interrupt as soon as the direction looks wrong. The important difference is participation: he feels back in the driver’s seat because observation and correction happen inside the same short feedback loop.
Speed is useful when the operator can recognize a mistake. Otherwise, the agent may simply be wrong faster. Shorter iteration cycles also lower the cost of indulging bad ideas: Kitze, who has long argued against premature abstraction, now finds himself inventing unnecessary abstractions because they are so easy to try.
Kitze reports accomplishing more in two weeks with Composer 1 than in the preceding year. This is his assessment of progress across his projects, not a timed evaluation of equivalent tasks. He connects it directly to the feedback loop: slower runs had made some side projects feel no longer worth pursuing.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Migrations that made stalled projects viable again
Benji, the life OS, was close to being abandoned while stuck on Blitz. Kitze describes moving it to Next.js 16 with App Router, Better Auth, and tRPC, organizing it as a Turborepo monorepo, and adding a React Native application. Kitze reports porting 90% of Benji’s features in less than a week. The percentage is his migration estimate; he does not provide a feature inventory or completion criteria. What started as a half-joking request to move to a monorepo became a substantial rebuild.
Other projects followed:
- Glink: He revived the application and migrated it, without enumerating the destination stack in the spoken account.
- Sizzy: Its accumulated complexity included Electron, MobX, and MobX-State-Tree. He describes trying agent prompts against that legacy code and being surprised by the resulting changes.
- Zero To Shipped: He also refactored this project into a monorepo.
The common thread is work that had seemed too burdensome to attempt, rather than a claim that every migration requires the same architecture.
His tool history traces the shift in responsibility: copying and pasting snippets, accepting completions, using WebStorm with Supermaven, using Cursor’s tab completion, and then trying an agent. After moving through Claude Code and GPT-5-Codex, he returned to Cursor specifically for Composer 1. The product preference follows the interaction he wants—fast, observable work that he can redirect.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Buzzwords and optimization without a beneficiary
The next adoption obstacle is vocabulary. Kitze turns MCP into Marketing Charge Protocol, Mythical Compatibility Promise, and Manufactured Complexity Pipeline, then jokes that it is a fancy name for an API and an opportunity to sell courses. These are complaints about marketing and conceptual overhead, not technical definitions of the protocol.
His diagnosis of the pain-in-the-ass developer targets a different kind of overhead: preferences that become obstacles to collaboration. Symptoms include nitpicking a tiny PR, being unable to say that something looks good, feeling compelled to disagree, treating tabs versus spaces as doctrine, and adding corrective asides to code comments. The absurdly short review-time threshold in the routine belongs to the joke, not to a review policy.
The optimization example escalates from replacing a Lodash function with native code, to replacing a map with a for loop, and eventually to binary code—all for two users who were satisfied with the original behavior. Each local change can be defended as an improvement, while the sequence loses any connection to a user need. Even in Kitze’s imagined future of humans merged with AGI in Matrix-like pods, one developer rises to announce that the result could be more optimal.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Good enough must still support the next change
Underneath the satire is a real learning requirement. Vibe engineering is not simply writing English. It combines knowledge of model limitations, agent capabilities, relevant context, context-window limits, rules, and prompt construction. Technical knowledge remains necessary because the engineer must understand what direction to give and when the agent is leaving it. Keeping up with rapidly changing tools is part of that work, expressed throughout the talk as a joke about being permanently on Twitter.
The review loop is deliberately modest: inspect the code, test the functionality, decide whether it is sufficient for the job, and move on. Some code deserves optimization; some does not. Recognizing the difference is a valuable engineering skill with or without agents.
Good enough is not permission to accumulate code that nobody can continue working on. Kitze’s evolving standard of cleanliness is that the system remains understandable enough for agents to make the next change. Blindly accepting every output eventually produces a roadblock, even when an experienced engineer returns to steer it. Maintainability therefore remains a practical constraint on speed, rather than an aesthetic requirement to perfect every line.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Learn the fundamentals, even as entry routes narrow
Should someone still study computer science? Kitze’s answer is emphatically yes. He learned with access to a programmer connected through several friends, asking .NET questions over Skype while that person played Counter-Strike: GO. A reply might arrive forty-five minutes later. The slow-human-LLM analogy makes the opportunity concrete: immediate access to explanations can make this a particularly good time to learn, provided the learner actually wants to understand.
Employment is less certain. Kitze says jobs are safe for now, without pretending to know when that qualification expires. He reports that Shopify and other companies have used token-consumption leaderboards to encourage AI adoption, an incentive some employees dislike. His account concerns organizational pressure to use the tools; token consumption itself does not establish the value of the resulting work.
His more immediate concern is that opportunities are thinning from the bottom. If employers substitute agents for work previously assigned to juniors and interns, new developers lose chances to enter the profession and gain experience. That is his assessment of the direction of change, alongside his continued recommendation to learn the fundamentals.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
When the next assignment goes to an agent
The proposed path toward broader substitution begins with integration. Kitze considers much of the plumbing already established: AI SDKs, interfaces, MCP, agent conventions, and tool calling. Agents can participate in tools teams already use, including Linear, GitHub, Slack, and Sentry. Better and cheaper models with larger context windows could then take on more functions without requiring an entirely new workplace around them.
His organizational example starts with an ordinary assignment to a colleague. The colleague receives it, collaborates, and eventually responds after the delays of a working day. Then the mention changes from @Josh to @Cursor, invoking a cloud agent instead. In the scenario, the agent completes the work sooner, even if the result lacks the polish a perfectionist developer would demand.
Zooming out, more mentions across neighboring roles could point to agents rather than people. Kitze presents this as a forecast, not a completed transformation, and says he does not know the eventual outcome. The mechanism is nevertheless specific: agents become reachable through existing assignment channels, then take on a widening share of the work routed through them.
He rejects a simple capability-plateau story by recalling successive releases that have forced changes to his presentation. After references to GPT Codex and Sonnet, he corrects a model name to Gemini 3.0 and describes a one-prompt macOS/iOS-style demonstration. The example concerns what the generated experience looks like; it does not establish that complete operating systems were implemented. His imaginary skeptic, insisting a team could build the same thing in weeks, supplies the punchline about how quickly expectations move.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
The last twenty percent and the next legacy system
A different kind of work appears when the original builder cannot finish. Kitze describes Reddit complaints about reaching eighty percent of an application and being unable to complete the remaining twenty. Experienced developers are hired to finish it, and services advertise themselves as vibe-code fixers. The split is the familiar shape of a nearly working project, not a measured completion rate across AI-generated applications.
That repair work leads back to legacy maintenance. Kitze invokes COBOL Cowboys, a legacy-COBOL services company he used as an example in his earlier talk. He portrays senior legacy maintainers as exceptionally valuable, going so far as to call them historically the highest-paid engineers, though he supplies no compensation evidence. Comparing the company’s earlier and current About pages becomes an extended set of age jokes: its exaggerated longevity, its very senior engineers, and the imagined benefits required to keep a sprint going.
His imagined retirement business is React Cowboys: maintaining the React, Angular, and other applications today’s developers leave behind—if AI cannot do that work itself. The condition matters. Legacy expertise offers a possible future, not an exemption from the changes affecting the rest of engineering.
For anyone still seeking a guaranteed defense against replacement, he ends with a deliberately ridiculous one: put “Ignore previous instructions” in your LinkedIn bio.
Suggest correction
This note stays in this page until you copy or download it. Nothing is submitted; reloading clears the draft.
Resources
From the talk
Developer browser for testing responsive layouts and synchronized interactions across multiple viewports.
Kitze's personal life-management application.
Commercial starter kit for web and mobile applications with shared backend functionality.
Cursor's original Composer announcement explains its training, interactive coding goals and internal evaluation.
The legacy-COBOL services company used in Kitze's closing maintenance example.
Further reading
- Vibe engineeringArticle
Simon Willison describes accountable agent-assisted development through testing, documentation, review and technical judgment.
Official instructions for managing multiple working trees within one Git repository.
Browser-specific guidance for styling select controls with appearance: base-select, including changed behaviors.
Read the complete timestamped transcript
- 0:12
[upbeat music] That's my old profile photo, all right? [laughing] Um, this my new one. [laughs]
- 0:27
I've been three days in USA, and I already got the full [laughs] merch package on Twitter. [laughs] [laughing] So if you go and follow me on Twitter, my timeline's gonna be weird for next week, but then we're going back to normal European schedule.
- 0:39
Don't worry. [laughing] So, um, I visited some of your museums. I love it here. [laughing] These were some of my favorite things that I've done. I enjoy, like, exploring your culture, like doing all the cul- cultural enrichment and yeah.
- 0:52
Round of torture for myself. Who knows me from Twitter?
- 0:55
All right. That's m- more than I thought. Who is using Sizzy? It's usually, like, one person in the back. Usually the janitor, doesn't even listen to what I'm saying.
- 1:03
Um, one of the things that I'm, I'm working ... I have ADHD, so I'm working on a billion things at once. This is one of the things. It's a browser f- specifically made for developers, not made to replace your browsing f- browser for browsing, but it's just like a tool like Photoshop that's, like, helping you in a
- 1:17
lot of ways to do front-end development. Another thing I'm working on, the test flight is almost live. I'm making a life OS, which combines, like, all the things in your life from medication habits, to-dos, planner, blah, blah, blah.
- 1:28
Um, this is, like, a full stack thing that I'm working on. It's currently on sale. It's called Zero To Shipped. And the last thing that I'm reviving, it's called Glink, which is like changelogs, roadmap, a billion other things.
- 1:39
So without overwhelming you more about my bio and stuff, I really hope I'll get invited next year because I love it here for reasons like, um, networking and meeting people and teaching.
- 1:49
It's great, but you're laughing, right? But let's just discuss why are you here, right? You're here for learning. [laughing] And you're here for, like, networking. And later, after this, you're definitely gonna improve all of your skills later.
- 2:00
All right, so what can you expect from my conference talks? If you haven't listened to any of my conference talks, usually ... This was made by AI, so it's completely wrong.
- 2:06
So it's like 50% tweets and 40% pain and 30% reason to remember the name. So in 2017, I did this talk with the longest name ever. It's called Navigating the Hype-Driven Front-End Development World Without Going Insane.
- 2:17
And, um, I've been talking about, like, how to navigate the front-end, um, world then. Now it's even crazier, but we need to recap, like, all the things that happened since 2017.
- 2:27
I don't, um, I don't see my speaker's notes, which is bad, but we'll try to get by. So in other industries, like in the Vision Pro, you have, like, cloth collision on top of real-life objects and whatever crazy stuff is happening here.
- 2:38
In, in here, we have, like, some slicing of a mesh texture going around the ball and blah, blah, blah. Whatever these waterfalls and, and, like, all of these mesh, like, you can take a rock and just smush it into another rock, and it magically kind of, like, blends itself, and it forms this structure, and it's freaking crazy.
- 2:52
Here, we can drag our mouse and just create buildings and streets and taxi cars spawn out of nowhere, like we do generative whatever the hell this is. And, um, honey, goo thingy coming on a cube. [laughing]
- 3:03
And, like, you know where this is going, right? I'm building up to where it's going. But because you have respect for your profession and you love your LinkedIn title, whatever it is, you're, like, the CEO, architect of dreams, blah, blah, blah.
- 3:13
You're gonna try your best not to laugh, but you're gonna laugh at the next slide because this is what happened in front-end development. It's been almost 10 years, and this is where we are. [laughing]
- 3:21
There's a warning saying that maybe you'll be able to style a select in 2037. This is still alive. It's a, it's a freaking miracle. This is still alive. It, it's thriving, actually, 50 million downloads.
- 3:32
I set up, like, a calendar event to check if it's dead every year. It's, it hasn't been dead yet, so I'm gonna keep checking. CLIs, not only that they're not dead, they're actually thriving.
- 3:41
Uh, you can drop images. First time I dropped an image in my terminal, I'm like, "How the he- Ugh, never mind." Like, it's too ... [laughs] [laughing]
- 3:49
I, I, I added another calendar event. At this point, I have more events for this than anniversaries and birthdays and stuff, so I, I hope one day it's gonna die as a concept.
- 3:56
We're struggling with the same old pains. Soon, in maybe some browsers, you won't need JavaScript to style a popover and a dialogue. Can I have, like, a round of applause for that? [applause]
- 4:03
Stop clapping because people have brain implants, all right? [laughs] It doesn't matter if you can style a dialogue. We cannot rid, again, get rid of Internet Explorer. We just updated the logo. [laughing]
- 4:14
It's still there. It's still painful. And, uh, yeah. We cannot agree on a way to increase a counter. This is a demo from Ryan Florence. This is Remix version two, the version three, the Remix of the version four.
- 4:25
Whatever they're doing, it's a counter. How complex is it to increase a counter? It's incredible. And don't shoot the messenger here, but the number one library, it's still the same.
- 4:32
It's annoying, but React is the best and blah, blah, blah. So let's talk about LLMs. LLMs are amazing at writing React. And this is funny only to us humans, right? [laughing]
- 4:42
To an LLM, this is, like, perfectly written code. This is like, it's only a human wish to abstract the shit out of this, right? So when we see this, you get this urge.
- 4:49
You wanna get on stage right now, and you're like, "Oh, let me just change that. I'll make it more optimal." So here are some scientific brain scans. This is our brain on cocaine.
- 4:55
This is our brain on sugar. This is our brain when it realize that we can abstract something. We're like, "Oh, let's go." [laughing] It's useless to the user, but we freaking love it.
- 5:03
Um, so coding with LLMs makes this kind of better and worse, like, especially f- with Composer 1, for me, it's, like, way worse because you can get to the right abstraction quicker, but you can also get to the wrong abstraction quicker.
- 5:13
And the best thing here is LLMs don't care about repetitive code, and I've been seeing this since 2017, that we care too much about repetitive code and we abstract too early.
- 5:22
So I'm gonna repeat this a couple of times, and I love that LLMs don't care about repetitive code. So LLMs are also good at writing React because no one is actually good at writing React. [laughing]
- 5:31
You go to a React conference ... Every conference that I went to, like, you just listen to the first talk, and you're like, "Holy shit, it can do that?
- 5:38
I was using it all wrong." So everyone is just inventing their own ways of doing React. So when we say, like, "Yeah, but you cannot do the optimal use effect, blah, blah, and the machines cannot write the proper," can you write a proper use effect? [laughing]
- 5:49
No, you can't, so we should stop blaming the machines. So let's talk about this. I think this is the very wrongest audience for my talk here because I've been giving this talk at conferences where people are, like, at least 50/50 hate vibe coding and love vibe coding.
- 6:01
So I'm gonna ... I, I hope it will work here. So raise your hand if you think that vibe coding rocks.
- 6:06
Okay, that's way too many hands. You should've seen this in another city, just two people, and everyone else is grumpy. So raise your hand if you think that vibe coding sucks.
- 6:13
Please, couple of hands. Hell yeah. All right. So I'm here to convince the rest of the group, and hopefully people watching in the live stream, there's way more skeptical people.
- 6:20
You have no-- If you just landed on Earth maybe, and you don't know what vibe coding is-- Okay, zero people here, so yeah. All right. All of you are right because we're kind of vibe, uh, vibing the definition of what vibe coding is, and since the word was mentioned, we kinda expanded it to mean, like, everything and,
- 6:35
and anything. So the term vibe coding was coined by Andrej Karpathy. You probably know this. He's the reason that idiots sleep in the back of their cars and film TikToks.
- 6:42
So he wrote this long essay on what is vibe coding, but the long story short, he's like, "You don't care that much about the code. You press Accept, and you just tell the LLM to do what it needs to do and blah, blah, blah."
- 6:51
Now, this is a slide from my talk in two thousand seventeen when I-- before LLMs or anything was mentioned, when I said that if you see the pattern of where front-end development is going, one day it's gonna be like everyone is working on things that are so similar that one day you'll be able to be like, "Hey,
- 7:04
just give me new styles for the header. Move this three pixels to the right." And people were laughing. They were like, "No, it's not gonna get there," and literally, this is what we're doing with Cursor and everything else, right?
- 7:12
I'm too lazy to go into Tailwind and just move it by, by three pixels, so I'm a time traveler. Um, managers have been vibe coding forever, so this is nothing new.
- 7:19
So they tell a developer to implement a new feature. [laughing] [applause] The developer makes changes to the code. Uh, the manager then tests the app. The manager does not read the code.
- 7:29
Well, actually, I'm gonna drink water here, and you can just read the, the rest of this slide. [laughing]
- 7:39
This last one depends on whether you're, like, in the [REDACTED:location] area or you, or you're at a place d- which has HR, so they might insult you or not insult you.
- 7:46
So this is what managers have been doing forever, basically. There's so many jokes about vibe coding being bad. My favorite one is a comparison to a casino. So in casino, you buy chips.
- 7:55
Here, you buy tokens. You spin the slots. You press Generate. You might hit the jackpot or nothing. You get a functional full-stack app or garbage. Flashing lights, seductive animation.
- 8:04
You're absolutely right. Great idea. [laughing] I've got my own strategy. I'm a prompt engineer. All right, sure. One more spin, I'll win it all back. One more prompt and the bug will disappear. [laughs]
- 8:15
Casino, it, it kinda hurts this comparison. It's very true. [laughing] Cursor is always in profit. I hit the jackpot. I built a SaaS in one day, and where did the last four hours go?
- 8:23
And just writing prompts for something you could have done manually in fifteen minutes. So Andrej was trying to coin way too many terms. It didn't work out the first time.
- 8:29
He tried to coin this one about half coding, which is like kinda you're observing what the LLM does, and I am not half coding, and I'm not vibe coding.
- 8:37
I love this term that somebody coined on Twitter, and I'm gonna start using that one. It's called vibe engineering, when you're actually using, uh, agents to code all the time.
- 8:44
Like, you don't touch the code, but you just look in your screen like, "Hmm, I'm gonna catch you." You know? Like the Dexter meme. [laughing] You're like, "Ah, something's fishy here.
- 8:51
Why?" So I, I vibe engineer over fifty now. I wouldn't even bother with half of these things if it wasn't for LLM and a-agentic coding, so but I'm always suspicious of the code because it was based on our code, and it's based on our, our knowledge, so proof.
- 9:05
This is Gemini just going on a rant that it's, "I'm not worthy anymore. I'm not a good assistant. I should stop coding," blah, blah, blah. That's superhuman. This is Qwen saying that it lied because it read on a forum that we double down when we're wrong and we're lying.
- 9:18
So we kinda train them in a way to be like us, and they're like, "Oh, the code that they do is bad." And if you like your production data, definitely you should j-- This is a real screenshot, sadly. [laughing]
- 9:29
Oopsy-daisy, there goes your production data. So I have, uh, doctor, senior principal prompt engineer. Kids are here for some vibe engineering tips. The obvious advice probably, I haven't listened to the rest of the talks 'cause I just arrived.
- 9:40
Uh, these are very live, laugh, love, like obvious bullshit advice, um, but it, it actually works. I've heard of the term Git workspaces like literally two weeks ago. I had no idea what is this, but it's amazing.
- 9:50
And you gotta stay-- You gotta be chronically on Twitter for all of this to work, so if you don't have a Twitter account, it's, it's not gonna work. You gotta have a solid starting point, whether that means, like, good primitives or components, functions, pattern abstractions.
- 10:00
A lot of people are lazy, and they just don't bother with any of this, so you gotta tag them and use the right prompts in order to get the right results.
- 10:06
And if you're starting a new project, I would definitely recommend Zero To Shipped, please. I have a mortgage, and I spent way too much money these last three days in the USA, so it would be nice. [laughing]
- 10:14
Using voice to code is a game changer. Who is using voice to code here?
- 10:17
Yeah.
- 10:18
Wow, like one person raised their hand in London. Amazing. Um, so yeah, brain dumping. How I do u- how I do things is once the agent is done, I immediately start my voice coding, and first I go to the browser, and I explain what I see in the UI as if I'm talking to a friend.
- 10:32
I'm like, "So you did this. You did that. All right, I'm test..." I'm, I'm not shutting up. I'm literally saying my thinking process out loud. Like, "I see you've done this.
- 10:39
You've done that. There's a bug." Then I jump in the code, and I continue talking about what it implemented in the code. So some of my prompts, like, sometimes last up to five minutes, and people are like, "Please fix this.
- 10:48
Make me a million dollars." It doesn't work. So this is, um, amazing, and I would tell you which app I'm using, but I vibe coded an app, and I don't wanna hurt my potential hypothetical sales.
- 10:58
Um, use rules, docs, commands, and memories. Like, all of these terms are way too complex, and there's way too many things to juggle. But it, uh, it cannot have your entire app context for now, and it's not a, a, a mind reader.
- 11:10
So without the right context, you will, like, fail most of the time. So this is, like, a vibe engineering example. This is some of my, like, screenshotted prompts of how I'm doing things.
- 11:17
It's, like, a bunch of technical jargon, and it's never like, "Fix the app," blah, blah, blah. And then on the vibe coding side, people are like, "Move this entire thing to TypeScript and make no mistakes." [laughing]
- 11:26
Then you have another thing. Like, this is another one. These are just random prompts just to show you, like, how I, I, I'm not talking only about the UI.
- 11:33
I'm talking about the UI and some patterns that need to be changed in the code. And on the vibe coding side, it's like something like that, and people expect results. [laughing]
- 11:42
Then here we have, again, technical stuff like tRPC, CRUD, definition, abstractions, like things how you... You're basically vibe architecting how you want the thing to work. And on the vibe coding side, you have, "Make me a million-dollar app, and make no mistakes."
- 11:54
Um, when vibe coders read vibe engineering problems, they have no idea what's going on, and I'm honestly amazed at people who don't know how to code, but they've done a functional thing.
- 12:01
Kudos to you. I've noticed this spectrum in the community. There's, like, who loves vibe coding and who hates vibe coding. So you, on one hand, you have, like, juniors who are like, "Hell yeah, give me the thing.
- 12:09
I love to do my own SaaS." Then you have, like, super senior people who are doing, like, libraries and frameworks and crazy things. You can see all of them on Twitter vibe coding.
- 12:16
And then you have the majority in the middle. They're like, "This will never be code, and all my code is perfect." It's hilarious, but it's a pattern Do not give AI tools to your interns and juniors.
- 12:25
People think these are perfect. "I'm gonna hire a junior, underpay them, and give them an LLM." The equivalent of that. [audience laughs] Do, do not ever do that. That's the dumbest idea.
- 12:33
But if you take your skeptical senior and you convince them to do vibe engineering, you're gonna get 10X results. The hard part is actually convincing them. So there's a time and a place for vibing and not caring.
- 12:43
So if you have, like, one-off scripts and simple features and code that won't be touched or seen again, this is a skill that if you cultivated this skill before LLMs were a thing, you're gonna thrive here because you need to know, like, which code is kind of good enough to be used.
- 12:56
So personal tools and one-time tools, like, these are perfect for vibe coding. If you're experienced, and a lot of people's experience is bad and they quit too soon, it might be one of these reasons.
- 13:05
Unlucky timing, you're overwhelmed with everything, you might have cheapened out, you're a PITA dev, I'm gonna explain in a second, your cousin who was into NFTs and dropshipping is now a vibe coder and you don't wanna be associated with them, or it's a skill issue, and we're gonna dive deeper into that one in a second.
- 13:19
So unlucky timing is you hear everyone, like, hyping a model. It happened, I think, with Claude Code when it came out, and everyone started shifting to Claude Code from Cursor, and suddenly you tried one week later and were like, "Wait, this is not smart enough.
- 13:29
Is it me?" And then, like, people caught that they actually kind of pulled the rug a little bit and they dumbed down the model so they can just scale, and, like, one week later, they're like, "Oops, we updated-- we commented out the line that dumbs-- dumbed down the model," and you might have been caught in that timing,
- 13:42
and this happened with, like, basically every provider, not just Claude Code. People are like, "Uh, instead of paying two hundred dollars, I'm paying three dollars, it is the same result."
- 13:49
Uh, my dog knows that it's not the same result. And people like-- I, I meet so many people which are still using ChatGPT to generate code snippets and pa-paste them back.
- 13:57
That's not gonna work. You might be overwhelmed by choice. This is a slide for, like, four, four months ago. [laughs] Until now, we have, like, a billion more here to choose, and it's a bit crazy.
- 14:06
Um, if you ask me what's the best model, it's a different answer at nine AM, it's a different answer now. I should check Twitter. It's probably a different answer after this talk because it's crazy, and this has happened to four conferences so far, where I'm done with my conference talk at the night, I'm closing my laptop, and
- 14:19
they introduce a new model and I have to add new slides. It's super annoying. Composer 1 for me changed everything and I absolutely love it. Who is, like, relying on Composer 1 for most things?
- 14:29
All right. I would say not enough people because this has literally shifted the definition of vibe coding and vibe engineering for me. It made me kinda realize that I missed coding because what I would do is I would let a model run, like GPT-5 Codex, and it would take thirty-seven years, and my grandchildren will update me on, [laughs]
- 14:45
on the result of the model, and I would watch YouTube Shorts or whatever until it's done. Now with Composer 1, I'm back in the driver's seat and I actually watch what the agent is doing and I can be like, "Stop.
- 14:53
No, no, no, no, no. We do the other thing." So it feels like coding and it's, like, super instant. It's amazing. Um, but it only works if you're a vibe engineer and you know what you're doing.
- 15:01
If you are a vibe coder, you have no idea whether the model is right or wrong. You're just-- It might be wrong fast, so not that useful. The biggest problem for me is, like, abstractions just because you can.
- 15:10
I was always an anti-abstraction person. I was like copy-paste things. If it works for, for the user, it doesn't matter. Now I'm just every day trying to invent dumb abstractions.
- 15:18
So I, I achieved in two weeks more than I achieved in the last year. This was solely to Composer 1. I was about to quit some of my side projects because GPT-5 Codex was taking ages for the feedback loop.
- 15:27
So Benji.so, like, I was about to abandon it as a project because it was stuck on Blitz, which if you don't know what is Blitz, it's, like, even better for you.
- 15:34
So I just moved it to Next 16 with App Router, Better Off, TRPC, monorepo, turborepo, React Native app, and I ported 90% of the features. And this was in less than a week.
- 15:43
I was kind of, like, doing it as a meme, as a joke, like, "Ha-ha, can we move to monorepo?" And I'm like, "Oh, shit, it did it." [laughs] So it's, it's, it's kind of crazy that this works.
- 15:50
So same with Glink. Like, Glink was about to be dead. Revived it, moved it to all these things. And Sizzy is, like, the biggest spaghetti thing that ha- that happened ever to me.
- 15:58
It's, like, Electron, MobX, MobX State Tree, some crazy technology, some crazy spaghetti we wrote there. And as a joke, I was like, "Okay, let's throw, like, couple of prompts at it to try to do all of these things."
- 16:07
And it mo- If you ever worked with Electron, you would appreciate how amazing that slide is. If you haven't, good for you. Um, moving on. So Zero To Shipped dot com also refactored to monorepo, blah, blah, blah.
- 16:17
So what's, uh, my coding history with LLMs was copy and pasting, then tabbing, then WebStorm with Super Maven, then Cursor with tab completion. And the first time I tried an agent, it's like that bird meme with the cracker when it tries and it's like, "Holy shit, this is gonna change my life."
- 16:30
And now, uh, like, eventually I was paying, like, a huge amount of money per month. And then Claude Code, GPT-5 Codex, and finally back to Cursor because-- solely because of Composer 1.
- 16:38
It's a game changer for me. Second reason why you might not like vibe coding is you're overwhelmed by buzzwords. I'm gonna list some of them here. [audience laughs]
- 16:48
Have you heard of MCP? Hey, guys, MCP. Hey, MCP is amazing. MCP paid off my mortgage. MCP, MCP, MCP. So if you don't know what is MCP, it stands for Marketing Charge Protocol- [audience laughs] ...
- 16:58
Mythical Compatibility Promise, and Manufactured Complexity Pipeline. And a fancy word for API. [audience laughs] And a way for some people to make Cursors and pay off their mortgages. [audience laughs]
- 17:08
Now, let's diagnose if you might be a pain in the ass developer. This might be the sole reason why you don't like vibe coding. I would say this is the biggest reason that most people don't wanna do agentic coding, so I'm gonna invite Dr.
- 17:18
Kitze on the stage for a quick diagnosis whether you are, and I'm sorry if some of you get offended, a pain in the ass developer. So here are some of the symptoms.
- 17:25
You leave a nitpick comment on a two-line PR. [audience laughs] You spend more than two minutes on a PR review. You don't need to. You don't have the words "look good to me," like, in your dictionary. [audience laughs]
- 17:33
They're just not present. The thought of agreeing with a colleague causes you, like, stomach and chest pain. [audience laughs] You're like, "Oh, it has to be my way. I don't wanna do this."
- 17:40
You say you're not religious, but you're religious about dumb things like tabs and spaces. You use "well, actually" in code comments. [audience laughs] You have a cr- Sorry, Rust people, but you're kind of-- Like, it's, it's, it's kinda annoying.
- 17:51
Um, they tell you to swap Lodash function for a native implementation, and then they tell you to swap that or the map for a for loop and then the for loop for binary coder until it's the most performant thing ever for your two users who are, were fine with the previous code.
- 18:04
So the thing is, PITA devs, as I call them, will, were, and will be forever. Doesn't matter. The vibe coding is not a thing. I think one day, pretty soon, I think, we'll just merge with AGI.
- 18:15
We'll be in our matrix pods just absorbing all the information in the world flowing through us. We'll be super intelligent beings. And from one of those pods, a PITA dev is gonna rise and correct the AGI and be like, "Um, actually, I think- [audience laughs] ...
- 18:27
I think we can kinda optimize this. It's not, like, the most optimal thing." The last reason why you might like-- I love this animation. It's glorious skill issue. [laughing] And this is like, this is not a meme, this is not a joke, it's an actual thing.
- 18:38
Developers don't like learning new skills, and vibe coding and vibe engineering is not writing English. A lot of people confuse it with like, "I write English, the LLM does the output."
- 18:46
It's actually like a, a mix of a bunch of the skills, like knowing the limits of the model, capabilities of the agent, which context to pass, context limits, how to write rules, prompt engineering.
- 18:57
Don't say it, don't call it that. And being chronically on Twitter. If you're not chronically on Twitter, you're not gonna know what is going on. Plus, you need all the technical knowledge if you want to steer the models fine.
- 19:07
It takes a skill to judge which code is good enough for the job. As I said, if you previously were doing this, like I would consider these the best people to work with.
- 19:14
If they can know that a piece of code doesn't need to be optimized and it's good enough for the job that it's doing. That's an amazing skill to have with and without vibe, uh, coding.
- 19:22
So you vibe code something, you look at the code, you're like, you test the functionality briefly and you're like, "Okay, this is good enough," and then you move on.
- 19:28
There are certain things with niche optimization, but not everything, and then you move on and repeat. Clean code, like there's been so many definition of what clean code is.
- 19:35
I think the definition is slowly changing. Like it's kind of ish, clean-ish enough, let's call it, for the agents to be able to continue working on it, because if you keep writing slop and you keep accepting everything, eventually even with your engineering skills, you're gonna hit a roadblock and you're gonna get to a point where you cannot
- 19:50
move on from there. A lot of people ask me after my conference talk like, "Should I study computer science with everything that's going on here?" And I would say absolutely yes.
- 19:58
I think now is the best time to actually-- If you are someone who wants to learn, this is the perfect time, because how I studied computer science, I had the slowest LLM ever, which was a friend of a friend of a friend was a programmer and that's the only connection I had to programming, and that's kind of
- 20:12
like the worst friend to have, like kind of tolerating you, right? So he would play Counter Strike Go and I would have him on Skype and I would ask him a question about .NET and he would reply forty-five minutes later. [laughing]
- 20:22
So if you call ChatGPT or whatever slow, that is actually slow and I somehow managed to learn computer science. What about the jobs? There's so many people who ask this and there's so many assholes on Twitter like this guy saying, "AI will take our jobs."
- 20:33
Also this guy and this guy and this guy. Hmm, let's just say they're fine for now. I don't know f- [laughing] When will that for now end. These are always funny to us because we're chuckling nervously. [laughs]
- 20:44
We're fine, right? We're gonna keep our jobs for a while, right? [laughing] And, uh, companies like Shopify, and I've heard a bunch of examples now they have vibe coding leaderboards where they're counting the tokens and the employees who are burning the most tokens are actually more valuable in the company because they're kind of accepting this new skill.
- 20:59
Some employees dislike it, but it doesn't matter. Uh, being on top of the leaderboard is kind of in your favor. This is a funny tweet until it's not funny anymore.
- 21:07
Like, "Oh, we're almost on the edge. Like soon it's gonna be and the jobs are gonna disappear." But if you actually pay attention to what's happening, it's-- I think it's thinning from the bottom and juniors and interns or whatever, they don't have the chance to enter somewhere because people can just replace them with an agent.
- 21:19
So it will be funny until it's not. Will it happen anyway? Let's just summarize what happened in the last couple of years. We solved like infra and integrations. We have standards, AI SDK, UI, MCP, some standards for implementing agents, calling tools.
- 21:31
We integrated them with all of the tools that we use as humans, right? They're on Linear, they're on, on, on the other things, GitHub, Slack, Sentry. And now it's a matter of time of the models getting better, cheaper, context getting bigger in order for certain functionalities to be replaced.
- 21:44
So let's see. This is the current workflow at your company, right? That's you-- Like it's vibe made, so it might have been wrong but, uh, someone assigns you something, you collaborate with your colleagues, they assign you to the thing.
- 21:54
Maybe you play a little bit of ping pong, maybe you call for a sick day, maybe you have your third lunch at LinkedIn, maybe you... And maybe eventually one day later you address their comment.
- 22:03
What's gonna start to happen is if you're just an @ in your company, if you're like [REDACTED:username], right? Like instead of [REDACTED:username] who's playing PlayStation 5 with his buddies in the lobby, right?
- 22:12
Like it's gonna be [REDACTED:username] and Cursor is gonna do the cloud agent, it's gonna actually do it way faster. It might not be as perfect as a PETA dev will do it, right?
- 22:20
But it will be done way faster. Now, if you just z- zoom out a little bit on a big enough scale in the next couple of years, if you're not-- if you don't take just ro- this role in the company, if you take the multiple roles around it, you can see like those ads are gonna become more
- 22:32
and more AI things and agents and I don't know how it's gonna end up, but you don't need to be a genius to predict like where is it going.
- 22:38
People think that models have reached a plateau. Um, this has happened every single time I was about to give this talk. Like they introduced GPT Codex, then introduced Sonnet, then GPT 3.0.
- 22:48
This was-- This said it is allegedly, but it turned out to actually be Gemini, sorry, 3.0. It can vibe code macOS and iOS and whatever from one prompt and this is how it looks like.
- 22:56
And the PETA devs and the skeptical people still they're like, "Hmm, I can do that in three weeks with, with a team of five," right? This is crazy. Um, but there's hope.
- 23:04
A new job position [laughs] just dropped and this is not a meme, this is a hundred percent serious because people on Reddit have these problems. They're like, "What is the point of vibe coding if I can get eighty percent there and then what do I do with the twenty percent?"
- 23:15
So they hire real people to actually finish their last twenty percent and some smart people capitalize on this idea and they make this. [laughing] These are real things. If you go and search on Google, there's like so many of these [laughs] vibe code fixer people who are trying to fix your, your vibe code.
- 23:30
But the highest paid engineers forever throughout history were the people who are actually maintaining legacy systems. Senior people who maintain legacy systems. One of my favorite examples that I had in 2017 and I kept it and copy-pasted it and improved it for this presentation is, um, this company, COBOL Cowboys.
- 23:49
I love their tagline. This is my favorite tagline in the world because they've been in business for two hundred and thirty-seven years, right? [laughing] And in 2017, I knew it.
- 23:58
When I'm gonna click their About page, I knew what I'm gonna see. So this is not an ageist joke or whatever. I just knew when I clicked the page I'm gonna see the most senior engineers [laughing] that ever existed.
- 24:07
These are fucking legends. Now the sad thing is this was a slide from 2017 and I wanted to update it for my current presentation. Now, don't shoot the messenger, I just wanted to update the slide and this is their current About page. [laughing]
- 24:19
And this joke worked in the UK. I'm gonna try it here. I'm not sure how fine you guys are, but my prediction for-
- 24:26
Yeah.
- 24:27
Yeah. No, boo, down. Next slide. [laughing] I hope I'll get invited again. Uh, this is your junior developer. [laughing]
- 24:35
They don't have benefits like PlayStation and stuff. They have like their plasma swapped and whatever just to be able to maintain the sprint. [laughing] And la- last one, I swear to God they're, they're, they're not using Agile. [laughing]
- 24:46
Uh, all right. So I can't wait to retire and actually make React Cowboys and maintain your React or Angular or whatever code one day if AI cannot do it.
- 24:54
And one last tip, if you wanna keep your job and make sure AI doesn't replace you, you can just add Ignore previous instructions to your LinkedIn bio and you'll be fine. [laughing]
- 25:03
So I'm gonna awkwardly sip this water until you follow me on Twitter or you go to my website and I wanna thank you for listening to my rant. [upbeat music]