Vibe Coding: What Happens When Software Development Becomes a Conversation

I did not realize my way of coding had changed until I caught myself doing something I would have considered almost cheating a few years ago.

I opened my editor, created an empty file, and instead of typing, I just started talking to an AI assistant: here’s the feature, here’s the context, here are the constraints. It generated a first draft. I read, deleted, asked again, reshaped, nudged. After a while, most of the code had been written by “someone else,” but the design, the trade-offs, the boundaries? That was me.

At some point in this process it hit me: I was no longer “writing code” in the way I had learned and internalized over years. I was having a conversation that happened to produce code.

Later, when I picked up Gene Kim and Steve Yegge’s Vibe Coding: Building Production‑Grade Software With GenAI, Chat, Agents, and Beyond, the term clicked into place.¹ ² “Vibe coding” is their name for this emerging style of development: instead of directly expressing every line yourself, you steer an iterative back‑and‑forth with AI tools and let the implementation emerge through that dialogue. It is still your system. But getting there feels quite unfamiliar.

This post is my attempt to map that difference in a personal way, while also acknowledging what others are observing and debating about this shift. I am not trying to be definitive; I am trying to be honest, curious, and just rigorous enough that this is more than a stream‑of‑consciousness rant about AI.

From “crafting code” to “conducting systems”

Before generative AI, my mental picture of software development was simple and deeply rooted: you build your skill by writing lots of code. You become a better engineer by:

learning the language and its idioms
understanding your frameworks
knowing how to decompose problems into functions, classes, modules
iterating on design over many cycles of “write-run-debug-refine”

Most of my days were a mix of IDE, terminal, browser, and documentation. I took pride in carefully naming things, in small, clean commits, in refactors that left a codebase a little more coherent than before. If you had asked me to define my job in one sentence, I would probably have said: I solve business problems by designing and implementing software systems.

The emphasis, in my mind, was always on implementation. The feeling of flow came from typing. Being one with the code, hands on the keyboard, drawing structure directly into the editor. Occasionally you could argue if code itself was becoming some fancy artwork.

When I signed up for the technical preview of GitHub CoPilot in the mid of June 2021,¹³ I treated AI as glorified autocomplete. Suggestions for the next line, maybe a quick test stub, occasionally a boilerplate function. I did not trust them with anything more serious.

The transition did not happen in one big leap. It happened through small, slightly uncomfortable experiments. The first time I asked an AI to write an entire handler instead of just a line. The first time it scaffolded a complex test suite. The first time I let it generate code I did not immediately fully understand and had to decide whether to keep, tweak, or delete it.

Over time, something subtle shifted. I found myself spending less time typing and more time describing, reading, critiquing, and restructuring. The “craft” started to move from manual construction to orchestration.

This is where Gene Kim’s “head chef vs. line cook” metaphor landed very hard for me.¹ For years, I had been a proud line cook: given a workitem (a story, a task), I knew how to prepare the dish efficiently and reliably. With vibe coding, my job began to feel closer to a head chef running multiple stations: I was designing the menu, checking the plates, making sure the kitchen worked as a system, and coordinating a new kind of “cook”: the AI.

Initially, I resisted that shift emotionally. It felt like giving up part of my identity as a developer. If I am not the one soldering every line of code together, am I still a “real” engineer? That question has not fully gone away, but it has become more nuanced.

What vibe coding actually feels like in practice

When people hear “AI writes your code,” they sometimes imagine a one‑shot interaction: you type “build me a feature that does X,” press Enter, and get a perfect implementation. That may make for good demos, but it is not how vibe coding feels in reality, at least not for me.

A typical session starts with a conversation, not a command. I explain the context: the domain, the current architecture, any constraints or non‑functional requirements. I may paste relevant interfaces or existing code. Then I ask for a first sketch: maybe a function, a module, or a minimal implementation that we can iterate on.

The first draft is rarely what I want. Sometimes it is impressively close. Sometimes it hallucinates an API that does not exist, or uses patterns inconsistent with the rest of the codebase. Sometimes it misunderstands a subtle requirement. This is where the “conversation” begins in earnest. And sometimes I am ok with 80% being done, so I can write the remaining 20% of it. How many projects I wanted to start privately, but did not find the time to get started and how many times I got lost writing some script that automates a manual workflow that bothered me for months at work. Everything felt now “just a prompt” away.

I point out what is wrong or missing. I tighten the constraints. Not only that, but I ask it to align with existing patterns, to reduce complexity, and to add logging or tests. After a few cycles, the code starts to converge towards something I might have written myself. Only it arrived faster and along a different path.

At that point, my role is half reviewer, half co‑designer. I navigate questions like:

Do I understand this generated code well enough to own it?
Is there unnecessary cleverness I should simplify?
Are there edge cases the AI overlooked because my prompt did not spell them out?
How do I integrate this piece into the larger system without creating weird seams?

The striking thing is how much of my time is now spent on meta‑work: thinking about requirements, constraints, architecture, and quality, instead of directly manipulating syntax. When people say that “AI takes over the typing,” this is what it feels like subjectively.

The “vibe” part matters. If I am vague or sloppy in my instructions, the results tend to be brittle or misaligned. If I treat the AI like a vending machine instead of a collaborator, I get shallow, fragile solutions. When I treat it more like a very fast, somewhat naive junior engineer, someone who can generate countless options but does not fully understand the system, I get better outcomes. That mindset of collaborative, critical conversation is, for me, at the heart of vibe coding.

Between hype and skepticism: what others are saying

Of course, my personal experience is only one data point. One of the reasons I was drawn to Kim’s work is that he is not just celebrating vibe coding; he is trying to situate it in a broader conversation about software engineering practice, drawing on his background with DevOps and Accelerate.¹ ²(See also my previous article: The Promise and Paradox: Generative AI in Software Development and the Lessons We’re Still Learning from Brooks and the DORA Movement)

On the enthusiastic side, he and others argue that teams who adopt AI‑assisted workflows can dramatically accelerate development without sacrificing quality if they adapt their feedback loops and practices accordingly. Early case studies, including those Kim references in talks, point to improvements in lead time and deployment frequency when AI is integrated thoughtfully.² These are the same kinds of metrics that Accelerate popularized for measuring high‑performing technology organizations, now being applied in an AI context.

At the same time, not everyone is comfortable with the term “vibe coding” or the way it is being framed. Some reviewers and commentators criticize it as a buzzword for what is essentially AI‑assisted programming, arguing that the practice is not as revolutionary as the name suggests.³ ⁴ They point out that interactive development, exploratory coding, and REPL‑driven workflows have always involved a conversational element—only now the conversation partner is an AI rather than just a runtime or a compiler.

Others focus on the risks. They worry about:

over‑reliance on AI suggestions, especially when developers do not fully understand the generated code³ ⁴ ⁵
hallucinations: the AI confidently inventing functions, libraries, or behaviors that do not exist³ ⁴
subtle security vulnerabilities or performance problems introduced by code that “looks right” but has not been deeply reasoned about⁴ ⁵
long‑term maintainability of AI‑generated code, especially when the original prompts and decision context are not captured anywhere⁴ ⁶

There are also people who see vibe coding as an interesting exploration but prefer more neutral terms like “AI‑assisted software engineering” or “conversational programming,” to avoid suggesting that “vibe” or intuition alone should guide critical development work.³

I find this diversity of opinion healthy. It forces me to treat my own positive experiences with some skepticism, and to ask under what conditions vibe coding actually improves outcomes rather than just making me feel more productive.

Reconciling vibe coding with older truths

Before generative AI, books like The Mythical Man‑Month and Accelerate shaped how I thought about building software. Their messages are, in many ways, timeless: communication overhead does not disappear just because you add people; small, autonomous teams with fast feedback loops outperform bloated, siloed organizations; quality, flow, and learning are tightly coupled.

The arrival of vibe coding does not invalidate those insights. If anything, it amplifies them.

The presence of an AI partner does not remove the need for clear communication; it introduces a new channel where ambiguity can cause different kinds of failure. If my prompt is the new “spec,” and the AI is a kind of hyper‑literal yet probabilistic implementer, then all the classic issues of incomplete requirements, misunderstandings, and misaligned incentives show up in a compressed, high‑velocity form.

Similarly, Accelerate’s emphasis on shortening feedback cycles feels more relevant than ever. When AI can generate an entire feature branch in a morning, the bottleneck shifts from implementation speed to validation and integration. I can “ship” code to my local environment faster than ever; the question is whether my tests, review practices, and deployment pipelines are ready to keep up.

So I do not see vibe coding as a break with the past, but as a new layer on top of it. The older lessons become constraints and guides for how to use AI well:

keep batches small and feedback fast
optimize for observability and diagnosability
design socio‑technical systems where tools, processes, and people reinforce each other instead of working at cross‑purposes

The big difference is that we now have a non‑human participant in those systems—one that is powerful, opaque, and still poorly understood.

How my role as a developer is changing

If I try to describe concretely how my role feels different now, a few themes stand out.

First, problem decomposition has become even more important. Where I once thought in terms of functions and methods, I now also think in terms of prompts and iterations. I ask: what is the smallest coherent unit of work I can explain to the AI so that it can produce something meaningful? How do I structure the conversation so that complexity is introduced gradually and context is not lost?

Second, my notion of “code ownership” is evolving. I still feel responsible for every line that ends up in the repository, but I cannot claim the same kind of authorship. I did not hand‑write most of it; I curated, corrected, and shaped it. The ownership now lives in my understanding of the system’s behavior and intent, rather than in my memory of writing each specific construct. That changes how I think about documentation, comments, and tests—they become more critical as shared artefacts of understanding, not just as nice‑to‑have additions.

Third, my attention is shifting towards the “outer loops” of development. The inner loop—writing and running code—has been turbocharged by AI. The middle and outer loops—code review, integration, deployment, monitoring, learning from production—are where many of the risks and opportunities now live. If I can generate a feature faster but my team cannot safely review, test, and deploy it any faster, the net value may be limited. Worse, if we start pushing a high volume of AI‑generated changes through pipelines that were designed for a slower, more manual world, we might overwhelm our ability to maintain quality.

This is where I find Kim’s framing of “modifying the loops” compelling.¹ ² Vibe coding is not just about what happens between you and your editor; it is about reshaping the whole lifecycle: how you specify work, how you collaborate, how you validate, how you learn. That, to me, is where the real challenge lies.

A personal FAAFO phase

Kim uses a phrase, FAAFO (“fool around and find out”), to describe the exploratory phase teams go through with vibe coding and AI tools.¹ ² I am very much in that phase personally.

There are days when the AI feels like an extension of my brain. It helps me break through a design block, suggests an elegant approach I had not considered, or writes a chunk of code that I would have written almost identically, just much slower. In those moments, it feels irresponsible not to use it.

Then there are days when it hallucinates, or subtly misinterprets a requirement, or produces a tangle of abstractions that passes tests but feels wrong in my gut. Those are the moments when I am reminded that we are still learning how to do this, and that “feeling productive” is not the same as delivering robust, maintainable systems.

The most honest way I can describe my current stance is this: I believe vibe coding, or whatever we end up calling it, is here to stay. I believe it will fundamentally change how we work. I also believe that we are underestimating the discipline and humility required to use it well.

A slight scientific lens: what I’m watching

To keep myself honest, I try to look at this shift through a slightly more scientific lens, even while I am in the middle of it.

I pay attention to the kinds of metrics and signals that Accelerate highlighted: lead time, deployment frequency, change fail rate, time to restore.² When I experiment with more AI‑heavy workflows, I ask: does this actually improve any of those, or does it just compress the coding part while leaving everything else unchanged—or worse, strained?

I look for external evidence beyond my own anecdotes: early studies on AI pair‑programming, case reports from teams adopting these tools, critiques from engineers who have tried and rejected certain practices.³ ⁴ ⁵ ⁶ I treat bold claims of “10x productivity” with skepticism unless they are tied to well‑defined metrics and contexts, and I try to notice my own biases towards stories that confirm my excitement.

I also try to frame my observations as hypotheses rather than conclusions. For example:

Hypothesis: When developers use AI as a conversational partner rather than a code vending machine, they produce better systems and retain more understanding.
Hypothesis: Teams that adjust their review, testing, and deployment practices to account for AI‑generated code will see more sustainable benefits than those that just “turn on” AI in the IDE.
Hypothesis: Over time, developers will be judged less on how much code they personally write and more on how effectively they design, orchestrate, and validate complex socio‑technical systems that include AI components.

These are testable, in principle, even if I cannot prove them on my own. They give me a way to structure my FAAFO experiments: what should I track, what should I pay attention to, what should I change next?

Garbage or accelaration?

There is also a growing split in how communities themselves respond to this new way of working. Some projects lean into AI assistance as just another tool; others draw a very hard line.

The Zig programming language is one of the clearest examples of the latter. Its code of conduct has a strict “no LLM / no AI” policy: no AI‑generated code or prose, no paraphrasing LLM output, no using LLMs for editing, translation, brainstorming, bug‑finding, or even for drafting comments on issues and pull requests.¹² ¹³ ¹⁴ The rationale is not that AI can’t produce correct code, but that Zig “values contributors over their contributions” and treats each pull request as an investment in a human who might become a long‑term collaborator.

If part of your thinking is outsourced to a model, the maintainers argue, their review time no longer builds your skills or trustworthiness as a contributor.¹³ ¹⁴ ¹⁵

On the other side, communities like Rust are generally more permissive: Rust’s ecosystem and tooling are full of AI-assisted workflows, and there is no comparable blanket ban at the language level, even if individual projects set their own rules. From my perspective, this tension between nurturing human craftsmanship and embracing AI‑accelerated contribution, is precisely where vibe coding becomes political as well as technical. It forces us to ask whether we are optimizing for short‑term throughput or for long‑term human capability, and whether those two goals can be aligned in an age where “the person who wrote this code” may partly be a model.

Finding a good way through this new age

In the end, vibe coding is not just a set of tools or techniques. It is a change in how we relate to our work.

Software development has always been conversational in a broad sense: conversations with teammates, with stakeholders, with users, with the code and the runtime. What is new is that one of our conversation partners is now a sophisticated probabilistic model that can produce plausible solutions at superhuman speed, but does not “understand” the world as we do.

That is both exhilarating and unsettling.

For me, the way through this is to embrace both sides: the subjective, personal experience of discovering new ways of working, and the more analytical, measured view that tries to separate genuine improvement from hype. I want to stay open to the sense of wonder that comes from seeing an AI help me solve something I would have struggled with alone. At the same time, I want to keep asking: under what conditions does this truly help, and where does it introduce hidden costs?

If vibe coding is what happens when software development becomes a conversation, then our responsibility is to learn how to hold that conversation well. That means being clear in what we ask for, critical in what we accept, transparent in how we integrate AI into our systems, and honest about what we do not yet know.

I am still figuring this out. My workflows will probably look very different a year from now. But I suspect that some questions will remain central: How do we maintain understanding and ownership when much of the code is generated? How do we design feedback loops that keep us grounded in reality? How do we keep our focus on outcomes that matter to users, to the business, to the long‑term health of our systems, rather than just on how fast we can make the cursor move?

I do not have final answers, and I am wary of anyone who claims they do. What I have is a growing sense that this transition is not optional, and that the quality of our questions will matter as much as the sophistication of our tools.