Conference Slide Argues Managers Have Always Been Vibe Coding

Level 1: Going in Circles

Imagine your teacher tells you to draw a picture, but they won’t say what the picture should look like. You do your best and draw something. The teacher takes one quick look and says, “No, that’s not it. Erase it and try again.” You ask what’s wrong or what they really want, but they don’t give you a clear answer – they just say “I’ll know it when I see it.” So you guess and change your drawing. Again, the teacher doesn’t watch how you’re drawing or explain anything, they just wait until you’re done and then go, “Hmm, still not right. Fix it.” You’re basically guessing what the teacher wants through trial and error. After several rounds of this, you finally manage to draw something that the teacher accepts. Instead of a big congratulations, the teacher says, “Good job, but you should have done it faster,” or maybe even scolds you for taking so long. How would you feel? Probably frustrated and confused, right? You were trying to hit a target that kept moving, and the person in charge wasn’t helping, only criticizing. This meme is joking about that exact kind of situation, but between a boss and a programmer. The boss keeps making the programmer change things with very little guidance, then complaining it’s not done right, over and over – basically making the team go in circles. It’s funny in a silly way because it’s such an absurd and frustrating way to work, yet it happens more often than it should. Everyone can laugh at how ridiculous it is to demand something but not explain it, then get upset when it’s not magically perfect on the first try.

Level 2: Feature-Bug Ping Pong

This meme breaks down a scenario that many junior developers discover to their dismay: a manager with no coding experience calling the shots and a developer caught in an endless back-and-forth of fixes. Let’s clarify what’s happening. The term “vibe coding” here is jokey slang for making changes based on a manager’s gut feeling or vague idea rather than a clear plan. In other words, the boss is saying “I have a vision for a new feature,” but often that vision isn’t well-documented or fully thought out — it’s driven by a vibe. They tell the developer to implement this new idea straight away (Step 1 on the list). The developer then writes the code to add the feature (Step 2). Now, normally you’d expect some kind of review or at least a discussion about the code or the acceptance criteria. But what happens next? The manager tests the app themselves (Step 3), acting as if they’re the quality tester. Crucially, the manager does not read the code (Step 4). This likely means the manager can’t read the code (they might be non-technical and not know how to interpret code), or they choose not to spend time on it. Instead, they rely on clicking through the application’s interface to see if the new feature “feels right” and everything still works. This is already a red flag in a software development process: skipping a code review or not having a dev peer check the code can let obvious mistakes slip through.

Unsurprisingly, the manager finds something wrong when trying out the app — maybe the new feature isn’t exactly what they envisioned, or perhaps there’s a glitch. So the manager complains about bugs (Step 5). This complaint is likely not a calmly filed bug report with details, but more of an annoyed “It’s broken!” directed at the developer. The developer then goes back to the code to fix the bug (Step 6), often under a sense of urgency. They patch up the issue as best as they can. Then, as listed in Step 7, the manager still doesn’t check how the developer fixed it — they don’t read the code (again). They simply run the app once more to see if the bug is gone. At Step 8, the developer says “done, try now”, indicating they’ve deployed the changes and the manager can test again. This back-and-forth is why we call it a “feature-bug ping pong” – the task bounces between the manager and developer like a ping-pong ball: feature request to dev, bug report back to dev, and so on.

Finally, if the app’s behavior meets the manager’s expectations, we reach Step 9. Here the manager might say “gj but be faster next time”. “gj” stands for “good job,” but that little praise is immediately followed by a critique about speed. In some cases, as the meme acknowledges, the manager might even skip the praise and outright scold the developer (it says “or insults the living hell out of the dev”). This reveals a pretty toxic situation: the manager is basically saying “I’m not totally happy with how long that took or that there were issues”, even though their way of working caused a lot of the delays and confusion! It’s a no-win situation for the poor developer. After that, Step 10 is just repeat – meaning the manager will jump to another new feature request or another issue, and the whole cycle starts over. This is why we call it an endless feedback loop: there’s always a new demand and because the process is flawed, they keep going in circles fixing things.

Let’s put this into perspective for someone early in their career (or even a keen observer from another field). This scenario shows a communication gap and unrealistic manager expectations. The manager in the meme is not clearly communicating what they actually want in detail – they just throw the task over the wall (“implement this feature”) and later throw back vague criticism (“there’s a bug” without detailing what exactly, or “this isn’t what I had in mind”). The developer is trying to hit a moving target without guidance. And because the manager isn’t technical enough to verify the code or design upfront, they only give feedback after something breaks. This is a very reactive way to work. It leads to developer frustration – imagine working hard on something, only to have your boss say “it’s wrong, fix it,” repeatedly, without helping you understand the requirements or the problem. Also, note the irony: the manager says “be faster next time,” but the constant interruptions and lack of clear direction are exactly what slow the developer down. A well-run software project usually involves writing down feature requirements, discussing them, reviewing code changes, and testing in a structured way. Here, most of those steps are replaced with one person’s seat-of-the-pants approach (the manager’s testing and gut feel). It’s basically Agile gone wrong: yes, there are quick iterations, but they’re chaotic and filled with negativity.

In simpler terms, the meme highlights how some bosses micromanage developers. Instead of trusting the developer’s expertise or involving proper QA, the boss wants to see and tweak everything directly, even though they don’t have the technical skills to do so effectively. They end up providing poor feedback (“it’s buggy” without details) and then chastise the dev for the slow progress. It’s labeled as Management Humor and Developer Humor because both managers (the self-aware ones, at least) and developers recognize this dysfunctional pattern. Unfortunately, this kind of corporate culture exists in some companies: pressure to deliver features fast, no time for proper code quality checks, and then shock when bugs appear. The slide being shown at a conference suggests that a lot of people in the industry have experienced this — enough to joke about it publicly. For a junior dev, the take-home lesson is: clear communication and proper process are key. If you skip them, you might end up in a maddening cycle of “fix it now, no time to think, why is it broken, fix it again.” The meme uses humor to shine a light on how not to manage a software project. It’s funny in a facepalm kind of way, because we can see all the things going wrong in that bullet list that could have been avoided with a bit of planning and mutual understanding.

Level 3: Groundhog Sprint

In this darkly funny snapshot of corporate culture, we see a perpetual cycle that any battle-scarred developer recognizes. The conference slide boldly declares “Managers have been vibe coding forever,” and proceeds to list a 10-step infinite loop of misery. It’s a senior-level satire of a non-technical manager driving development by gut feeling rather than any disciplined SDLC process. Essentially, the boss is “coding by vibe” through the developer’s hands, tossing out new feature ideas on a whim and then using trial-and-error to see if it “feels” right. The humor hits hard because it exposes a real communication gap: the manager doesn’t articulate clear requirements or read the actual code; they just poke at the app and complain when it doesn’t match their unspoken vision. Experienced engineers know this dance all too well — it’s the groundhog day of software projects, repeating ad nauseam.

Let’s break down the loop of doom on that slide. First, the manager requests a new feature, not with a spec or user story, but with a casual “hey, do this thing” (pure vibe coding). The developer dutifully writes code to implement it. So far, so good — we have feature development, though likely rushed due to implied urgency. Next, the manager steps in to test the app (because why involve QA or automated tests when you have managerial intuition, right?). Crucially, the manager does not read the code at all. They’re treating the codebase like Schrödinger’s cat: as long as they don’t peek inside, it might miraculously be perfect. Instead of a proper code review, the boss just clicks around the UI to see if things feel okay. Inevitably, they find an issue (surprise, surprise) because skipping code review and spec definition practically guarantees bugs. At step 5, the manager complains about bugs — loudly. From a senior dev perspective, this is where eye-rolling begins: the very person who gave minimal guidance and skipped quality checks is now aghast that reality isn’t meeting their expectations. It’s a classic management anti-pattern: blame rolls downhill.

The cycle continues as the developer scrambles to patch things up in step 6. Maybe they guessed wrong about the feature nuance, or maybe the rush introduced a regression — either way, they’re now in bug-fix mode under high pressure. Step 7: manager still doesn’t bother to read the code “again,” so they miss any deeper issues or quick-and-dirty fixes the dev just slipped in. This lack of oversight means the root cause of the bug might not even be fully understood; they’re just slapping band-aids on symptoms. At step 8, the weary dev says “done, try now”, effectively tossing the build back over the wall. The manager retests the app (still on vibes, no code insight) and finally, if things look okay, we hit step 9. Here the manager either gives a lukewarm “gj” (good job) followed by a “but be faster next time” or, if the vibes are off, unleashes a tirade that insults the living hell out of the dev. That bullet point on the slide drew laughs and groans from the audience: it’s the sting of “congratulations, now do better (and quicker)” – a backhanded compliment that negates any relief the dev might feel. It’s also a slap in the face to psychological safety; nothing says “motivating workplace” like punishing someone for working through your own sloppy process. Finally, step 10: repeat. And repeat. And repeat... This loop will run forever (or until the dev rage-quits), because there’s always another half-baked idea from the manager queued up to start the saga anew. The slide isn’t exaggerating with “forever” – this really can feel like an endless, hellish sprint with no retrospective, just more work.

To a senior engineer, the absurdity is painfully relatable. We’re essentially looking at an agile process gone horribly wrong – a caricature of iterative development where iterations are driven by managerial whims and hindsight. Instead of structured sprints with planning, demos, and feedback, we get ad-hoc cycles of “code something, push to prod, and see if the boss freaks out.” The manager here mistakes micromanagement for agility. They’ve cut out all the sanity checks (no planning, no design discussion, no peer review, no proper QA), replacing them with their own personal feedback loop fueled by “vibes.” It’s a textbook recipe for high cycle time and low morale. Why does each change take so long? Because this loop is massively inefficient: the dev is essentially coding blind to the manager’s true desires, and the manager is testing blind to the code’s true state. It’s like two people driving a car together — one on the gas, one on the steering — with neither quite sure where the road leads. Sure, eventually you might get somewhere, but the ride is going to be bumpy as hell.

From an architectural standpoint, this dynamic creates mountains of technical debt. Quick fixes piled on under stress often lead to messy code (the kind that makes future features even buggier to implement). But the manager, not reading the code, remains blissfully unaware of the ticking time bomb in the codebase. They’ll just keep demanding “faster next time”, oblivious to how their approach is actually slowing everything down long-term. It’s tragic and comic: the very folks obsessed with speed and control are undermining both. This feedback loop is the human equivalent of an while(true) loop with no break condition – a logical infinite loop that any developer knows to avoid in code, yet in organizations it happens all the time. We could literally sketch it in pseudo-code:

// Pseudo-code for the vibe-coded feedback loop
while (true) {
    manager.requestFeature();   // 1. Manager vibe-codes a new feature request
    dev.implementChanges();     // 2. Developer writes code for the feature
    manager.testApplication();  // 3. Manager runs the app to see the result
    // 4. Manager does NOT read the source code at all
    if (manager.findsBug()) {   // 5. Manager finds a bug and complains loudly
        dev.fixBugQuickly();    // 6. Developer hastily fixes the bug under pressure
        continue;               // 7. Manager will test again without reading code (loop back to step 3)
    }
    dev.say("done, try now");        // 8. Developer signals the feature is ready for re-test
    manager.giveFeedback(/* gj or insults */); // 9. "Good job, be faster next time" OR manager yells at dev
    // 10. No break; manager immediately has another idea -> loop repeats forever
}

Like any infinite loop, it’s both maddening and mesmerizing in its futility. The code comments mirror the slide’s bullet points exactly – highlighting just how systematic this dysfunction is. This isn’t one isolated incident; it’s a pattern ingrained in bad tech management. When the presenter on stage says “forever,” it implies generations of managers and devs have been stuck in this loop. The audience chuckling at this slide likely included senior devs, QA engineers, maybe some self-aware managers too, all thinking “Yep, I’ve lived that nightmare.” It’s a form of collective PTSD packaged as a joke. The developer frustration is real – being told to “just fix it” and then “go faster” without any help is demoralizing. The manager expectations are out of whack – wanting speed and perfection without providing the necessary guidance or resources. And the communication gap is immense – one side speaks in vague demands and exasperation, the other is left guessing what “correct” looks like.

Ultimately, the meme skewers the flawed feedback loop where the wrong person is doing the review. A proper cycle would have the developer, peers, or a QA verifying the change, and a collaborative discussion about issues. Here, the manager has appointed themselves as one-person QA and product tester, without possessing the technical insight to make that process efficient. The result? A snail-paced, temper-fraying iteration cycle. The humor has that “it’s funny because it’s true” energy — an exaggerated truth, but truth nonetheless. Seasoned developers laugh (perhaps a bit bitterly) because they know that this vibe-driven development style is the bane of quality software and sane work hours. Yet, as the slide says, it’s been happening forever. The meme shines a magenta spotlight on this age-old Management_PM folly, reminding everyone that behind many “quick changes” and “hot fixes” lies a tortured dev-manager dance that could have been avoided with a dash of process and a pinch of empathy.