From Vibe Coding to Vibe Engineering

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.

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.

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:

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.

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:

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.

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.

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:

1. Open the browser. Inspect the resulting interface and describe what changed.
2. Exercise the behavior. Say what is working, what is surprising, and where a bug appears.
3. Move into the code. Continue the same narration while reviewing the implementation.
4. 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.

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.

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.

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.

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.

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.

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.

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.

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 switches from the unnamed colleague 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.

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.