Some people work with AI like magic. Others make it look like struggle.

Recently, I spent 3 hours debugging why our AI started giving weird outputs in Flyway, one of the tools we've built at Be01 for idea creation and validation. The AI was supposed to validate startup ideas against market research, but suddenly it started rejecting viable concepts and approving obvious duds. Luckily this was on internal dev branch where we were preparing the next set of updates to deploy.

I checked everything; logs, model versions, data pipeline. The AI was technically working fine. No errors, fast responses. But something was off.

Turns out it was three words buried in a system prompt: "be more critical."

It's something I had tweaked a week earlier, thinking it would improve quality. Instead, it significantly shifted the AI's evaluation framework on market validation. Our tests passed, but the outputs had fundamentally changed character.

Three words. Three hours of my life.

The Watchers

This got me thinking about the builders I know who seem to have an almost sixth sense for when AI-generated work is about to cause problems.

Most people generate code, check if it runs, ship it. They treat AI like a magic compiler: ask for a function, get a function, move on. But some people have developed something different: they can look at perfectly working AI output and sense where it's going to break.

They're not just asking "does this work?"
They're asking "what assumptions is this making?"

Take error handling. AI loves try-catch blocks. They look clean, handle exceptions gracefully, very textbook. But experienced builders will spot when that try-catch is papering over a deeper issue. Maybe the function should fail fast instead of swallowing errors, or maybe the real problem is upstream in the data validation.

Or take data structures. AI will generate code that uses a dictionary when a set would be faster, or builds a list when you really need a queue. The code works perfectly in testing with 10 records. In production with 10,000, it crawls.

These builders have internalized something that others haven't: AI doesn't just solve problems, it makes assumptions about problems. Those assumptions are where things break.

The Production Gap

Here's what I've learned building with AI over the past year: the real failure mode isn't dramatic crashes. It's subtle degradation.

Your unit tests pass. Your integration tests look fine. But you're slowly accumulating systems that work great until they don't. The generated authentication flow that assumes users always provide valid tokens. The data processing pipeline that works beautifully until someone uploads a file with special characters. The API wrapper that handles normal responses but chokes on edge cases the third-party service occasionally returns.

Traditional debugging doesn't help here because there's nothing to debug. The code is correct. The problem is in the assumptions.

This is why some builders seem to have superpowers with AI while others struggle. It's not that they understand transformers better or write better prompts. They've developed an eye for spotting AI's blind spots before they become problems.

Why this matters now

Many founders I talk to are perhaps obsessing over the wrong things. They want faster models, cheaper tokens, better benchmarks. But the real competitive advantage is simpler: teams that can sense when AI-generated work is making risky assumptions.

Because here's the thing: AI is getting good enough that most implementations will technically work. The question is whether you'll catch the subtle issues before your users do.

My hypothesis is that the companies that will win with AI aren't the ones with the biggest models. They're the ones whose people can look at working code or functioning prompts and think: "This looks right, but what happens when..."

That observational skill, being able to read between the lines of your AI collaborator, might be the actual superpower in an AI-first world.

The three-word bug cost me three hours. But it taught me something valuable: AI doesn't just fail. It succeeds in ways you didn't expect.

And learning to spot those unexpected successes before they become expensive problems? That might be the skill that matters most.

What unexpected AI behaviors have you caught before they became problems?

While many worry that AI is making us dumber by doing our thinking for us, I've experienced the opposite: AI has made me a better critical thinker.

I used to think the biggest AI productivity gain was speed—fewer dev doc tabs, less syntax debugging, faster feature delivery. But after building closely alongside AI for some time now, I've discovered something deeper about my making process: I'm not just building faster, I'm learning exponentially faster.

Every interaction has become a mini-masterclass. Not because AI is teaching me like a traditional tutorial, but because it's creating a feedback loop I've never experienced before. I approach a problem with my usual mental model, AI meets me there, then consistently shows me angles I hadn't considered. The result isn't just working code—it's an upgraded way of thinking about the problem itself.

Programming has been part of my craft throughout my design career, but since starting Be01, I've been doing significantly more of it. What surprised me wasn't just how much AI accelerated my coding—it was how the learning patterns applied everywhere. The same compound effect happens when I'm iterating on design concepts, working through product strategy, or even structuring user research. AI doesn't just help me execute faster; it often shows me alternative approaches that upgrade my thinking process itself. Whether I'm debugging code logic or refining a user journey, the meta-skill of learning through AI-assisted iteration has become universally valuable.

From "Solve then Build" to "Build to Solve"

The most fundamental shift has been in my relationship with uncertainty. I used to spend significant time upfront planning and architecting, wrestling with complexity until I had it figured out before writing the initial lines of code. Getting stuck was painful because it felt like failing at the planning stage.

Now? I approach problems with what feels like "iterative confidence"—the knowledge that my initial logic can evolve, and that's not just okay, it's the point. When I'm not 100% sure my approach will be optimal, I jump into trying it out faster, knowing AI might suggest paths I haven't considered yet.

To me, it hasn’t felt like recklessness—but more like a new kind of strategic approach to building. I've grown to develop an open mind toward the idea that my architecture can change mid-build, and rather than being disruptive, this flexibility has become an advantage. I've learned to treat my first solution as a hypothesis, not a destination.

The quality paradox: When simple beats fast

Here's something unexpected: I've stopped optimizing primarily for performance and started appreciating solutions for their cognitive load. When AI suggests a "better way," what makes it better isn't always speed—it's often simpler logic that's easier to track mentally, or cleaner syntax that reduces the mental overhead of maintaining the code.

Last week, I was building a feature that needed to sync user data across multiple components when changes happened. My instinct was to set up a series of event listeners and update functions, each component watching for specific changes. I had it working, then asked AI: 'Is there a better way?' It suggested using a single state reducer with clear action types. Not only was it more performant—it was dramatically easier to reason about. Instead of tracking five different update flows, I could follow one predictable pattern. Now when debugging, I look at the reducer and immediately understand the entire data flow.

This has trained me to think differently about what "good code" means. The best solutions aren't necessarily the most clever—they're the ones that future-me (and future-teammates) can understand and modify without cognitive strain. AI has become my simplicity coach, consistently showing me that there's usually a cleaner path than my first instinct.

The learning paradox: Wanting to be wrong less, but also more

When I ask AI "is there a better way to do this?" for structuring implementation logic—which I do almost religiously now—it suggests something I haven’t thought about up to 50% of the time. This creates a strange emotional paradox: part of me wants that percentage to drop (indicating my skills are improving), but part of me would be disappointed if it did (because I'd miss out on learning opportunities).

This tension has taught me something valuable about growth: the sweet spot isn't eliminating gaps in knowledge, it's maintaining enough curiosity to keep discovering them. AI hasn't made me complacent—it's made me a better critical thinker and logic designer precisely because I know there's always another perspective available.

The meta-skills: What's really developing

Beyond specific programming patterns, I'm hopeful that I am developing meta-skills that compound across every project:

Tolerance for productive uncertainty: I'm more willing to tackle problems outside my comfort zone because I know I can learn through the process rather than before it.

Logic design intuition: Constantly seeing alternative approaches has sharpened my ability to architect systems that are functional, maintainable, and extensible.

Pattern recognition: Each "better way" AI shows me creates a reference point for future problems. I feel as if I am building a mental library of approaches faster than I ever could through traditional learning.

What this means for how we build

The more I experience this compound learning effect, the more I believe we're seeing expertise development change in a fundamental way. The traditional model—learn extensively, then apply—is being replaced by learn-through-application at unprecedented speed. This isn't just changing individual careers; it's changing what competitive advantage looks like for teams and companies.

My experience suggests that builders who thrive won't be those who know everything upfront—they'll be those who've developed the meta-skill of learning through iteration, who can hold their initial approaches lightly while remaining committed to their outcomes. They'll be those who've developed the fastest learning feedback loops, because how human expertise develops is fundamentally evolving.

One more point of view: This compound learning effect isn't just changing how I build—it's revealing what human-AI collaboration could become when we stop treating AI as a tool and start treating it as a thinking accelerator. The question isn't whether AI makes you more productive. It's whether you've structured a way to learn from every interaction and compound that knowledge into better judgment over time.

Are you treating AI as a tool that gives you answers, or as a thinking partner that's upgrading how you think about problems? I’ve found that the compound effect only works if you're paying attention to the patterns, not just the solutions.

What's your experience been with AI as a learning accelerator? I'd love to hear about the moments when it showed you something that changed how you approach similar problems.

AI-powered development tools are democratizing creation like never before—but are we ready for a sea of digital solutions and ecosystem problems at unseen scale?

Having built various software for years and currently working on ways to help people make, what I'm witnessing right now is both exciting and terrifying. We're not just democratizing app creation—we may be about to drown in our own digital productivity.

The Numbers Reveal the Scale of What's Coming

While everyone debates whether AI will replace developers, something more fundamental has been happening: AI has been creating millions of new developers who don't know what they don't know.

Adjacent data points point to this scale (Some of these number may even be larger today than when they came out):

• Citizen developers will deliver 30% of genAI-infused automation apps" in 2025, leveraging their domain expertise. Source.

• At large enterprises, citizen developers are predicted to outnumber professional developers by 4 to 1. Source.

• By 2025, 70% of new applications will use low-code or no-code technologies, up from less than 25% in 2020. Source.

• 70% of users without coding experience mastered low-code tools within a month. Source.

• GitHub Copilot users report significant productivity gains, with an 8.69% increase in pull requests and a 15% increase in PR merge rates, reducing time to PR by days (from 9.6 to 2.4 days) in some cases. Source.

• AI app revenue surged to $2 billion in the first eight months of 2024, with projections reaching $3.3 billion—a 51% year-on-year surge. Source.

• The Apple App Store sees about 50,000 new app releases monthly as of 2025, up from 33,000 in September 2024. Source.

But here's what those numbers don't capture: the quality curve is inverting for some of these apps. We're not just getting better apps—we're also getting more apps that solve problems their creators actually understand.

Vibe Coding, the Double-Edged Revolution

There's a lot to get excited about with “vibe coding” (describing what you want in plain English and letting AI generate the code), but it also makes me wonder about the implications. One that particularly concerns me is "solution pollution."

Just like industrial pollution, solution pollution happens when production becomes so easy that we stop thinking about consequences. When anyone can build an app in an afternoon, everyone does—whether the world needs that app or not.

The Development Pyramid Has Flipped

Seven months ago, I watched something that really shook what I knew but assumed were more theory. A client's marketing manager used Claude to create a "better" version of a dashboard feature her product team had spent six weeks perfecting. Her version wasn't technically elegant. It probably broke half of their design principles. But users (people on her team) loved it because she understood their workflow in ways carefully researched personas never captured.

That moment forced the truth about the new world we’re in: Domain expertise combined with AI assistance can now compete with traditional development approaches—even when the code is messy and the architecture is questionable. And this, will lead to even more apps being created.

A healthcare worker who understands patient workflow can now build a better patient management tool using Claude than a developer team working from user stories—even if the code isn't optimized. There are consumers in the market who don’t care about elegant code as long as the solution actually solves the problem.

Traditional software development looked like a pyramid:

• Top: Professional developers (scarce, quality-focused)

• Middle: Technical-adjacent roles (some scripting)

• Base: End users (software consumers)

Now, depending on the scenario, it's inverted:

• New Top: Domain experts with AI tools (fast, problem-focused, quality-uncertain)

• Middle: Professional developers (becoming infrastructure specialists)

• Expanding Base: Millions of AI-powered citizen developers; Tools like Claude, Replit, and V0 are only making it easier to turn casual descriptions into functional applications. The barrier between "having an idea" and "having a working app" has collapsed.

While there are so many great things we’ll see from this, it also creates what the “Maintenance Debt Crisis”. Professional developers used to gatekeep quality. Are they now becoming archaeologists, trying to understand systems built by people who've moved on to other problems?

The Uncomfortable Truth Nobody Talks About

In the current state of the world, it won’t surprise me if 90% of these AI-generated apps become digital pollution within 18 months.

Unlike traditional software development, where high barriers meant only serious (or committed?) solutions got built, the new reality is that every workflow annoyance becomes an app. I'm already seeing organizations with hundreds of tiny applications that don't talk to each other, security vulnerabilities baked in by well-meaning domain experts, and a growing graveyard of abandoned "solutions."

What Dies in This Transition

Several foundational assumptions that some may argue are now obsolete:

• "Good software requires careful planning" → AI rewards speed over forethought

• "Code quality matters for long-term success" → Working solutions beat maintainable architectures

• "Professional oversight ensures security" → Domain experts don't know what they don't know

• "Software development is specialized" → Building apps becomes a general business skill

• "IT controls enterprise applications" → Nearly 60% of custom apps are built outside IT departments (2017 study by 451 Research), with Gartner predicting 80% of low-code users will be from outside IT by 2026

We're moving from a craft mindset (skilled artisans building quality) to an industrial mindset (mass production with externalized costs).

The Fork in the Road

Despite all the excitement with lower hurdle to build software, the flip side of this worries me whether we're approaching a critical decision point:

Path 1: The Polluted Future
Millions of AI-generated apps clutter digital ecosystems. Organizations drown in their own productivity. Technical debt becomes unmaintainable. We end up with a digital world that's more capable and more fragile than anything we've built.

Path 2: The Guided Future
We use this transition to build better infrastructure for creation itself. Professional developers become architects of platforms that make citizen development safe. Domain experts get tools that help them build responsibly. We channel creative energy toward solutions that actually matter.

The latter is a future that would excite me, the artisans, and the consumers of these apps very much.

The Opportunities in the Chaos

To head closer towards the Guided Future, here's where I see the highest impact opportunities for builders.

1. Become a Bridge Builder

The future belongs to people who can connect domain expertise with technical reality. Don't choose sides - become the translator between AI-powered prototyping and engineering rigor needed for scale.

2. Focus on Questions, Not Answers

When anyone can implement solutions, competitive advantage shifts to asking better questions: What problem are we really solving? What breaks when this scales? Who takes responsibility when things go wrong? This is one of the reasons why we've been experimenting with workflow tools like Flyway at Be01, helping teams ask better questions before they build.

3. Build Infrastructure for Chaos

Instead of fighting the app explosion, build the infrastructure that makes it manageable. The opportunities are in governance platforms, integration tools, and security frameworks that citizen developers can't break.

4. Cultivate Judgment

In a world where technical implementation becomes commoditized, the scarcest resource is judgment: knowing what to build, when to build it, and when to stop. This can't be automated. It has to be earned.

Higher stakes than we think?

Look, I don't know if we're heading toward a digital utopia or a maintenance nightmare. Probably both. What I do know is that ignoring this shift won't make it go away—the app explosion is happening whether we’re ready or not.

Maybe we figure out how to channel all this creative energy into solutions that actually matter. Maybe we drown in a sea of abandoned weekend projects and security vulnerabilities baked in by well-meaning builders.

The great app explosion is here, and it seems like a good community problem to figure out together as we go. I'm still figuring this out myself. If you're wrestling with similar questions, I'd love to hear how you're thinking about this transition.

As code becomes design and design becomes code, where do tools like Figma sit at this intersection, and are we all evolving into architects of our own creation processes? These are some of the conversations I'm looking forward to at Config next week.

Two Paths to Creation

What's fascinating is watching the emergence of two powerful yet philosophically distinct approaches to creation. Text-to-code tools like Cursor and Windsurf represent a fundamentally different interaction paradigm—one that's reshaping what gets designed and how.

Figma occupies a unique position in this ecosystem precisely because direct manipulation represents the conceptual counterpoint to prompt engineering. While language interfaces excel at speed and approximation, Figma's canvas offers something increasingly valuable—deterministic precision in an increasingly probabilistic creative landscape.

I'm curious if Figma sees Dev Mode as their opportunity to bridge these worlds. Or will we get the announcement next week that the current prototype mode will go further and become fully deployable apps? A lot of opportunities in transforming visual certainty into functional reality. The company that made design more developer-friendly now has the chance to make development more designer-centric, without abandoning what makes visual creation so powerful.

The Rise of Meta-Making

Beyond the product announcements, I'm drawn to Config for those hallway conversations—particularly interested next week to learn how idea builders are discovering and developing sophisticated methodologies that go beyond individual tools. This seems extra timely considering we're at this transitory state where there are a lot of new tools and new ways of making that we are experimenting with and incorporating into our workflows.

I think we're witnessing the emergence of meta-makers—people whose primary creative medium isn't pixels or code, but the workflows themselves. The most innovative among us no longer simply use tools sequentially; they put technologies hand-in-hand in carefully choreographed processes, each playing to their unique strengths.

This evolution suggests a shift in how we identify professionally. Perhaps we're all becoming workflow architects first, and product creators second—with the ability to design our creation processes becoming as important as designing the products themselves. I am interested to meet and learn from others next week as tools dictate how we make, and what we're learning now together will shape the next wave of tools.

If you're heading to Config next week, I'm eager to hear about your own creation workflows—and what unexpected tool combinations have changed how you build.

Let’s share notes!

And that gap is costing you more than you know.

This realization didn't come from theory. It came from the different AI interfaces we've been building and testing. We saw where users struggled with interfaces that should have worked—but didn't.

In this AI renaissance, the most profound paradox seems to be this: as machine intelligence advances exponentially, the importance of human-centered design increases at precisely the same rate. The difference between transformative AI and frustrating potential isn't the algorithm—it's the interface.

Through Be01's own incubation products like Flyway — a tool for brainstorming and validating ideas — as well as our work in helping shape AI product experiences with partners like Isoform (a startup creating better ways to build bespoke enterprise software) from their beginning, we've been extensively thinking about ways AI and humans can collaborate and build on each other's work. These diverse experiments revealed a consistent pattern: the best AI in the world delivers zero value if users can't effectively engage with it.

One experiment crystallized this:

In a recent incubation project, we built a tool that used AI to synthesize product feedback from across channels—support tickets, user interviews, social media, and app store reviews. The algorithm brilliantly identified patterns and prioritized actionable insights.

Yet in user testing, we watched product managers nod politely at the AI's recommendations—then systematically ignore them when making actual decisions.

The revelation wasn't that we needed better AI. The system was already detecting patterns humans missed. What we needed was a better conversation. By redesigning the interface to expose the AI's reasoning process—particularly, showing the journey from raw feedback to insight—skepticism turned into trust. Same AI, very different outcomes. The algorithm hadn't changed at all. Only the conversation around it had evolved.

That moment captured the essence of effective human-AI collaboration: intelligence without interface is just untapped potential—and unrealized business value.

Most teams are still focused on improving AI capabilities. Few are solving the harder problem: designing the invisible layer between human intention and machine understanding.

The field is evolving beyond "prompt engineering" toward "cognitive choreography"—deliberately sequenced interactions where human and artificial intelligence amplify each other's unique strengths.

Four principles that nurture effective human-AI partnerships:

1. Cognitive load balancing: Great interfaces redistribute mental workload where each intelligence performs optimally.

2. Transparent capability boundaries: Clear communication about what AI can/cannot do eliminates the frustrating "uncanny valley" of partial competence.

3. Collaborative iteration: Interfaces that treat user feedback as a gift rather than a correction build cumulative intelligence.

4. Context preservation: Systems that maintain shared understanding across sessions create compounding value over time.

These aren't theoretical concepts. They've emerged from real projects with meaningful outcomes on the line.

For those eager to develop expertise in this emerging field:

Start smaller than you think.
Choose one specific task where AI adds genuine value.
Create the simplest possible interface.
Put it in front of real users immediately.
Watch silently.
Learn from where they struggle.

I believe we're approaching an inflection point. The companies that thrive won't necessarily have the most advanced AI—they'll have the most thoughtfully designed interfaces that make AI's capabilities accessible, understandable, and actionable.

What's one AI interaction challenge you've encountered that seemed like a technology problem but might actually be an interface issue? I've found the best way to master this new medium is by doing—and learning together. Would love to swap notes.

Subscribe now