Output has never been cheaper and AI-native execution is abundant, shifting advantage from doing to deciding. The best builders and GTM leaders maximize learnings per minute the way great comedians maximize laughs per minute: they read the room, sequence value, and make judgment calls under ambiguity.
At the Lovable buildathon, the real bottleneck wasn't tooling. It was clarity, especially for non-technical builders unburdened by inherited limits and willing to approach building with "positive delusion" until reality proves otherwise.
The playbook is simple but disciplined: do research before monetizing (now easier than ever with AI-assisted feedback aggregation), define automation as X→Y and let AI suggest the missing middle, and optimize for CCC (context, cadence, computing power) by working one task at a time and preserving context instead of tool-hopping.
"Good enough" won't cut it. Taste and time to value win, first success beats feature depth, and selling increasingly looks like showing a prototype instead of a deck. As AI commoditizes, the moat isn't "we have AI." It's access, customization, speed to value, and the distribution and trust to get someone to try you.
Why AI still can't read the room
AI can replace math problems. It can replace deterministic work. But it can't replace comedians.
That line, shared by Lazar Jovanovic, Lovable's insanely talented Vibe Coding Engineer at a Miami buildathon, landed with unusual clarity because I'd already heard its twin a few weeks earlier in a very different room. In the MKT1 community, Emily Kramer relayed that takeaway from the Gen Marketer Summit conversation with OpenAI's Head of B2B Marketing, Dane Vahey.
Great content, they said, works like great stand-up comedy. It's not about how many jokes you tell. It's about laughs per minute. For marketers, that translates to learnings per minute. How much value are you actually delivering in the time you're asking for?
Two different rooms. Two different communities. Same signal.
Comedians read the room. They track energy, adjust pacing, and make eye contact. They know when to push, when to pause, and when to abandon a joke entirely because the moment has shifted.
Lazar framed the same idea from a builder's perspective. AI can replace deterministic, transactional work. But it can't replace judgment, sense context, or tell when the next step should be smaller, slower, or different altogether. That distinction matters more than most people want to admit.
If your role is purely transactional — you're solving the same known problem the same way every time, and/or you're acting as a deterministic middleman between input and output — then AI is likely already better than you. Faster. Cheaper. Increasingly good enough. But that's not the work that actually compounds.
In our brave, new AI-native world, output is cheaper and execution is abundant. The advantage now shifts to people who understand humans well enough to make good decisions under ambiguity. People who know how to frame problems, sequence value, and deliver insight in short, intentional moments.
A good gut-check: is this a math problem, or a judgment problem? AI eats the first category. Humans still win the second.
That's the shared lesson from both rooms. When AI makes doing easy, the edge moves to deciding what's worth doing at all.
This post breaks down what that looks like in practice, especially for builders coming from sales, marketing, or non-technical backgrounds who are starting to build with AI and realizing that speed is no longer the constraint. Clarity is.
Artificial limits and positive delusion
Lazar, a top 1% vibe coder in the world, said something recently that's been rattling around my head:
Not having a technical background is actually an advantage when you're getting into this space. — Lazar Jovanovic
At first, that sounds backwards. But the more I sit with it, the more it clicks. What I didn't realize at first is that this mindset, not tooling, is the real unlock for AI-first builders.
If you didn't grow up inside engineering culture, you don't inherit its fixed assumptions. You don't know what's 'not supposed to be possible.' You're not constrained by how things have always been built.
You just… try. I know this first-hand after competing in the SheBuilds on Lovable buildathon with only two websites built with Lovable under my belt as a non-technical marketer and the 'positive delusion' that I could build an end-to-end B2B SaaS software platform, much less win.
That line of thinking snapped into focus for me through a few moments that, in hindsight, feel connected.
I first heard of Lazar Jovanovic last December on Lenny's Podcast, alongside Elena Verna. Even then, what stood out wasn't just speed or tooling, but how much emphasis Lazar placed on clarity, constraints, and judgment over raw technical depth.
Then last month, I had the chance to meet Lazar in person at a Lovable buildathon in Miami. Being in the room made something click that's hard to capture in a soundbite. The people shipping the fastest weren't the most technical. They were the most unburdened by invisible guardrails. They treated the tool not as a system with rigid rules, but as a collaborator to be explored.
Now, as I'm listening to Lazar again — this time solo, back on Lenny's Podcast to discuss "Getting paid to vibe code: Inside the new AI-era job" — that same thread is unmistakable. There's a consistent belief running underneath everything he says:
Assume possibility first. Let reality prove you wrong, not the other way around.
That belief immediately reminded me of a classic idea from economist Stephen Dubner's early-aughts book Freakonomics about artificial limits, a concept that stuck with me after reading the book and hearing him keynote a Tapad conference in my past life.
Dubner talks about how people appear to hit 'natural' ceilings — like how many push-ups someone can do, or how many hot dogs competitive eaters could consume — until someone breaks the frame.
Before Takeru Kobayashi, competitive eating records barely moved for decades. Then one person questioned the assumptions, changed the technique, and suddenly the 'human limit' doubled. The stomach didn't evolve overnight. The mental model did.
That's what this moment in AI building feels like.
Every day, people are building things on Lovable that others insist shouldn't be possible. Not because the tools are magical, but because the builders are coming in unbiased. They're not asking, "Is this the right way to do it?"
They're operating with what Lazar calls 'positive delusion': the belief that everything is possible until proven otherwise.
That mindset showed up repeatedly at the buildathon, in half-finished demos, last-minute breakthroughs, and conversations with people who arrived thinking they 'weren't technical' and left with something real. I watched ideas take shape in real time, and felt a kind of collective permission that's rare: permission to try without first asking for approval.
Most limits in new spaces aren't technical. They're inherited. And vibe coders, by definition, didn't inherit them.
That same refusal to inherit limits is what makes clarity such a critical skill in AI-first building. When execution becomes cheap, the bottleneck moves upstream. The work shifts from doing to deciding. From typing prompts to shaping intent. From building faster to building the right thing at all.
Where this showed up in the real world
In Miami, I attended Connecting Giants and Unicorn's Vibe to Value Sales & Marketing Buildathon at Northeastern University, featuring Lazar and Unnat Bak from Revscale AI.
What stood out wasn't how fast people built. It was how often they stalled before they ever touched the tool. The friction showed up upstream. People hesitated. They second-guessed. They circled the idea instead of committing to it.
The bottleneck wasn't AI. It was clarity. That observation became the lens for everything that followed.
What surprised me just as much was how much faster clarity arrived in person. Sitting side by side, hacking together, asking half-formed questions out loud, and watching other people get unstuck in real time collapsed weeks of second-guessing into minutes.
I made new friends in that room. We traded ideas, LinkedIn profiles, half-built demos, feedback, and context you simply don't get in Slack threads or solo prompting sessions. There's something about building shoulder to shoulder that lowers the stakes, sharpens judgment, and reminds you that AI might accelerate the work — but people still accelerate each other.

The comedian convergence
In the MKT1 community, the takeaway from a Gen Marketer Summit conversation with OpenAI's Dane Vahey: great content is like great stand-up comedy. It's all about jokes per minute.
For marketers, that becomes learnings per minute. How much value are you actually delivering in the time you're asking for?
At CGU, Lazar framed the same idea from a builder's perspective.
Translators will die. Comedians will not.
Comedians read the room. They adapt. They connect emotionally. If you can translate that ability into how you build, market, and sell, you're safer than you think.
Different lenses. Same signal.
When AI makes execution cheap, the edge shifts to:
- Value density: how much someone learns, fast
- Human signal: how well you understand what someone actually needs next
Everything that follows ladders back to that. In fact, designer and cofounder of Lovable Felix Haas recently declared that websites will soon become obsolete because the best ones don't explain what they do, but show it. Don't try to sell your clients a solution, but show them one. Let them interact with it and make them fall in love. And fast, because you can't hold their attention long enough to convert them otherwise.
Why this buildathon worked when many don't
Most AI events fall into one of two traps:
- High-level futurism with nothing you can apply
- Tool demos that assume you already know what you're building
- Too salesy with not enough learnings or actionable takeaways
CGU avoided both. The structure helped:
- Focused fireside to establish mental models
- Long build window to actually create
- Real-time support to unblock people
- Mixed room of founders, operators, sales, marketing, and product/engineering minds of all ages, backgrounds, and Lovable experience levels
- Credits provided so we could build on a Lovable pro plan for one month gratis
- Nice lunch spread and caffeine/seltzer bar to fuel us didn't hurt, either
That mix surfaced the real challenge of AI adoption.
It's not access to tools. It's translating customer understanding into something usable.
That theme showed up repeatedly in Unnat's examples and in Lazar's live build.
Lesson 1: Monetizing before research builds the wrong thing faster
The most common mistake in the room was also the most understandable one. Even Elena Verna, Head of Growth at Lovable, advised me to first get 30 users using my SheBuilds on Lovable winning build, SiteAlign, for 30 days. Only after gathering that feedback, validating that I'd built the right thing (without feature creep), and confirming that users would genuinely be sad if it went away, should I even start thinking about pricing.
People want to monetize before they've done the research.
The good news: research is cheaper than it's ever been. You can use AI to continuously aggregate and summarize feedback from calls, tickets, and even public channels (Reddit, reviews, forums), so "we didn't have time to research" stops being a real excuse.
Not research as a slide. Research as discipline:
- Who is this actually for?
- Who buys it vs. who uses it?
- What problem are we solving in their words?
- What makes this urgent now?
AI lowers the cost of building. It doesn't lower the cost of being wrong.
Practical takeaway: the buyer map
Before you build anything new, answer these plainly:
- User: who uses this day to day?
- Buyer: who pays, and what do they fear?
- Champion: who pushes it internally?
- Blocker: who resists and why?
- Trigger: what event makes this urgent?
- Proof: what convinces them it works?
- Time to value: what can they accomplish in 10 minutes?
If this feels fuzzy, don't automate yet. Learn more first.
Lesson 2: Innovation is often just a better path to value
Another calibrating point from Unnat: Your product doesn't have to be new to be innovative.
If something already exists, but you:
- Reduce friction
- Improve access
- Shorten time to value
- Make it easier to understand
- Build infrastructure around how customers get value
That is innovation, especially for SMBs and non-technical buyers.
Sales and marketing leaders often underestimate their builder advantage. You already understand customers. AI lets you translate that understanding into tools without waiting on a full engineering team.
Practical takeaway: better-path positioning
Ask yourself: What outcome does my customer want, and how can I get them there with fewer steps and more confidence? Build that.
Lesson 3: Automation is just "X turns into Y"
Automation sounds abstract until you strip it down.
It's simply: How do I reliably turn X into Y?
Examples:
- lead → qualified meeting
- feedback → product insight
- trial signup → first success
- support ticket → roadmap signal
If you can't clearly name X, you can't automate Y.
Once you name X and Y, AI can often suggest the missing middle — and sometimes reveal the next best Y you didn't think to ask for.
Practical takeaway: the X → Y list
Write 10 X → Y statements for your business.
Pick one. Build the smallest possible thing that improves it.
This is where AI compounds.
Lesson 4: Clarity beats cleverness
Lazar came back to this repeatedly. It's not about prompting tricks. It's about clarity.
As Brené Brown says, "Clear is kind," and during a build, being clear on what the outcome isn't can be just as important as defining what it is.
You need to be clear on what you know and what you're doing. You're still steering the ship. The best way to learn is by building and treating these tools as technical founders and reading the agent output.
One useful frame I heard was CCC: context, cadence, and computing power. Better outcomes come less from "better prompts" and more from (1) the context you provide, (2) the cadence you work in (one task at a time, fewer tab-hops), and (3) the limits of the model's attention window.
Models have finite context windows. Attention is finite. Time is finite. Your job is to give the system the right constraints and quality bar.
If you don't know what you're building, no tool will save you.
In fact, a member of the audience asked why they couldn't use Claude Code then move to Lovable. The answer? They could, but Lovable uses Claude Opus 4.6 as of this writing anyway.
A subtle lesson: early on, staying inside one environment can beat 'the best tool for each task,' because preserved context often matters more than marginal model differences. And it's easier than ever with 'Plan' mode and message queuing.
This saves time, credits, and frustration.
Practical takeaway: let the AI clarify you
Before building, ask: "Ask me the questions you need answered to reduce ambiguity. Then propose two approaches and recommend one."
Lesson 5: 'Good enough' is no longer good enough
Baseline quality is becoming table stakes. What differentiates is taste.
Some products work. Others feel intentional.
That usually comes down to:
- Understanding the user
- Reducing thinking and clicking
- Speaking their language
- Delivering value fast
Practical takeaway: the taste check
Before shipping, ask:
- Is it obvious who this is for?
- Is the next step clear?
- Are we selling outcomes or features?
- Does this feel intentional or generic?
Even inside Lovable, there's a simple bar: "This isn't a lovable experience."
You can't always define it upfront, but you know it when you feel it: less thinking, fewer clicks, more delight.
Taste isn't subjective if you look at friction.
Lesson 6: Compare inputs, not tools
One of the most useful moments in the build was this realization.
The tool matters less than the inputs you give it.
The fastest way to build intuition is to compare the same outcome built with different levels of clarity.
Practical takeaway: one outcome, four starts
Pick something simple, like an ROI calculator. Build it four ways:
- Vague idea, asking the agent to "use your best judgment"
- Clear context and constraints
- Short PRD
- Remixed template
Compare results. That's how you develop taste fast.
If your build goes off the rails, don't prompt-engineer forever.
- Ask the agent to list what it thinks the goal is (and what it's optimizing for).
- Ask it to ask you clarifying questions until ambiguity is gone.
- Have it propose 2-3 correction plans and pick one.
- Revert / roll back, then apply the plan in one pass.
Lesson 7: First success beats feature depth
Early value changes everything.
When someone feels value in the first few minutes:
- Adoption increases
- Trust increases
- Selling gets easier
This is true for AI tools and SaaS alike. The selling motion changes too: instead of walking into a meeting with slides, you can increasingly walk in with a prototype, then flip the screen and build the first version live while the customer is still talking to really captivate them when their intent is at its highest.
Practical takeaway: define the 10-minute win
What is one thing your user can accomplish in 10 minutes that proves value?
Build toward that moment.
Why the comedian test matters
AI is excellent at deterministic work. It's not great at reading the room.
Lazar doubled down on Lenny's Podcast:
"There are zero comedians being replaced. AI's never going to write good comedy. It's impossible." — Lazar Jovanovic
The people who will win in this next phase are the ones who can:
- Pack real value into short moments
- Understand what their audience needs next
- Translate human insight into clear instructions
- Build tools that feel thoughtful, not automated
That's true for content, GTM, and AI-powered products.
As AI commoditizes, the moat isn't "we have AI." It's access, customization, and speed to value. Plus the distribution and trust to get someone to try you in the first place.
A note on Lazar and the room
What stood out about Lazar Jovanovic wasn't just speed. It was how he showed up.
He was generous with context, optimistic about AI as efficiency augmentation rather than replacement, and deeply respectful of where people were starting from.
He openly admitted that he learns and relearns on the job every day, even as a top 1% vibe coder. Lazar repeated this sentiment on Lenny's Podcast, saying he'd likely be wrong about 90% of the things he said five months from now.
That framing matters.
If even the most advanced builders are operating with that level of humility — learning in public, revising their mental models, and actively pulling others along — the playing field has never felt more level. The work isn't about being right. Or the best. It's about getting clearer, faster.
Watching Lazar read the room like a comedian — take opaque, often half-formed questions and turn them into clear, pragmatic guidance — was a masterclass. That's not something you can automate.
But it is something you can practice. And tools like Lovable make it all too easy to get in the reps.
If you're newer to AI building, start here
You don't need to be technical to build now. But you do need to be clear.
As Lazar told Lenny:
Most experienced vibe coders aren't spending their time chasing clever prompts or new tools. They're spending roughly 80% of their time planning, asking questions, and working through intent with an agent, and only 20% actually building. — Lazar Jovanovic
Start with:
- A well-defined customer
- A specific outcome
- A small X → Y problem
- A willingness to iterate
Clarify the idea. Let the tools do the heavy lifting. Focus on delivering value faster, not sounding smarter.
That's the real lesson I'm carrying forward from CGU, and the bar I want my builds and Anchor GTM content to meet. Fun fact: the Anchor GTM blog hub and details pages are the very byproduct of the CGU hackathon, inspired by conversations with Elena Verna and community lead Whitney Menarcheck earlier that week, where the nuggets of wisdom felt far too good to gatekeep.
Where to find Lazar Jovanovic
If you're learning how to combine clarity, taste, and speed as a builder, Lazar is worth following closely. You can also learn where to catch him at events like CGU's Vibe to Value to see his thinking in real time.
- Lazar's LinkedIn: Shares reflections, builds, and lessons from inside the Lovable ecosystem
- Lazar's YouTube: Walks through live builds, demos, and how he thinks while creating
- Lazar's Lovable profile: His builder profile on Lovable
- Lenny's Podcast Featuring Lazar: Getting paid to vibe code, what's possible with AI, and the future of AI-related jobs
- Lenny's Podcast ft. Elena Verna: On Lovable's growth trajectory and why she hired a Vibe Coding Engineer for her team
- Lovable Community: Templates, fast tracks, and vibe-coding examples to remix
- Lovable UI style guide: Design patterns and building inspiration from Felix Haas's newsletter
- Lovable base prompt generator: Start your next build with a strong foundation right from ChatGPT
- Lovable PRD generator: Generate structured product requirements right from ChatGPT
- Felix Haas's newsletter: Building inspiration and Lovable ecosystem updates
- SheBuilds on Lovable: Join us on March 8th for International Women's Day as we build together
Built With
(Building in Public)About
Anchor GTM Anchor GTM is a space for first-hand operator insight from the messy middle of building, shipping, and deciding what comes next. No playbooks. No hot takes. Just pattern recognition from people close to the work.
You might also like

What Operators Do After a Big Ship
After a build, momentum creates opportunity and pressure at the same time. In this conversation, Lovable Ambassador and SheBuilds Season 01 winner Kat Hill Contag shares how operators decide what's next and turn a ship into leverage without rushing to scale.

Optionality Isn't a Luxury. It's a Strategy.
After a build, you might find yourself asking "what now?" once the ship dust settles. In this conversation, Elena Verna shares how to think about optionality as a strategy when figuring out where to place your bets and why the best next step is often the one that keeps the most doors open.

Momentum Is Emotional Before It's Operational
After a build, momentum doesn't fail because strategy is wrong. It fails when the emotional load becomes too heavy to carry alone. In this conversation, Whitney Menarcheck shares what helps people stay in the game long enough for momentum to compound.

