This article was published on November 23rd, 2025 on Design + AI(Link). I’m resharing it since it got so popular and it’s worth reading for every engineer. I wrote it together with Felix Haas.

Something different is happening in software teams right now. Designers are shipping code. Engineers are making design decisions. And the boundaries that used to define these roles are dissolving.

AI is transforming how we build software, and in doing so, it’s blurring the lines between designers, engineers, and product managers. As tools like Codex, Claude, Cursor, Lovable, and Vercel’s v0 increasingly generate production-ready code from natural language or design files, the traditional workflow of “design → handoff → implementation” is breaking down. For startup founders, this shift represents a new era of leaner teams, faster iteration, and hybrid roles.

The key question: what happens when everyone becomes a builder?

Designers as builders

Modern AI tools now allow designers to move beyond static mockups and directly build working software. OpenAI’s GPT can turn a hand-drawn sketch into a live website in seconds. Tools like Cursor, Lovable, or Vercel’s v0 let designers describe what they want and generate deployable components without writing code from scratch.

Anthropic has reported similar results internally—designers feeding concepts into Claude and receiving usable frontend code back. As one Vercel engineer put it, “We’re seeing new product designers blend UX, UI, and code in one creative flow.” AI becomes the glue between design intent and execution.

This doesn’t mean every designer must become a software engineer. Rather, it means AI fills the gap, letting designers test, ship, and iterate independently. Human oversight is still needed for polish, integration, and system thinking, but the barrier to implementation has dropped dramatically.

Engineers must learn design

As AI handles more of the coding grunt work, the role of engineers is shifting. “AI has completely changed what it means to write software,” said OpenAI CEO Sam Altman in 2025. Engineers no longer differentiate themselves by writing boilerplate—they add value through system design, product intuition, and quality judgment.

Vercel’s Lee Robinson describes this as the rise of the “product engineer”—someone who understands both code and UX, and can deliver features end-to-end. In the AI-first world, engineering is less about implementation and more about defining what to build and why it matters to users.

That requires engineers to embrace design thinking: user flows, aesthetics, ergonomics. AI can generate five UI layouts in seconds, but only a thoughtful engineer can choose the best one. And with faster iteration comes a need for engineers to own product decisions, not just execute them.

Rise of the product engineer

The convergence of design and engineering is giving rise to hybrid roles: product engineers, design engineers, AI product creators. These are people who think across disciplines and use AI to amplify their reach.

Lee Robinson notes this trend began before AI but is now supercharged. One person can realistically ideate, build, and ship an entire feature. Some even talk about the “single-person startup”—a founder or product engineer building an MVP solo using AI copilots like Lovable.

Falk Gottlob frames this as a new role: the AI Product Engineer, who combines “the strategic thinking of a PM, the technical skills of an engineer, and the creative instincts of a designer, all amplified by AI.” This isn’t theory. Small teams are already doing it. With AI, iteration speed becomes a core advantage. New ideas can be tested in hours, not weeks.

What happens to product managers?

If designers and engineers are shipping faster and taking on more product thinking, where does that leave PMs?

Some suggest the role could shrink or even vanish in small teams. Ryan Ford provocatively asked: “Why do we need PMs if designers do more and engineers disappear?” In AI-native startups, the old model of a PM coordinating between silos is less relevant because the silos themselves are disappearing.

Still, most experts agree that PMs aren’t going away—they’re evolving. AI generates outputs, but it can’t define strategy, understand users emotionally, or prioritize trade-offs. Vince Law argues that PMs now play a bigger role in steering the team, not just writing specs. When everyone has a “turbo paddle,” someone needs to steer the boat.

Future PMs will spend less time writing Jira tickets and more time synthesizing feedback, defining goals, and making sure the team builds the right thing. They may also take on AI-specific duties like model governance or managing AI-integrated products.

A new model for product teams

AI is dissolving the boundaries between traditional roles. Designers can now build. Engineers must design. PMs shift from task managers to strategic leaders.

Startups that embrace this fluidity can move faster and do more with fewer people. They can ship prototypes using tools like Lovable, tweak them with AI, and test them with users—all in days, not months. The most innovative teams aren’t rigid org charts, but integrated units of humans and AIs solving problems together.

This doesn’t mean every team member must be a generalist. But it does mean the walls between “design,” “engineering,” and “product” are coming down. The best creators in this new era will be those who speak all three languages and know how to wield AI as a co-creator.

Final thoughts

The AI revolution isn’t about replacing designers or engineers—it’s about augmenting them, accelerating them, and blending their workflows. For founders, this means rethinking how teams are structured. Instead of three separate departments passing work down an assembly line, imagine a few product engineers collaborating directly with AI to ship features from idea to execution.

Those who adapt fastest—by hiring hybrid thinkers, embracing AI tools like Lovable, and flattening communication—will have a huge edge. Because in 2025, speed of iteration is the ultimate competitive advantage.

LFG

Last week I watched our CTO Aike sit down at his desk, open Cursor and spend the next 40 minutes speaking to an AI agent. Not typing instructions. Talking. Describing what he wanted, getting back questions, refining his thinking out loud. By the end, a feature was built. See the picture below for his setup.

I’ve been writing about vibe coding and agentic engineering for a while now. But this moment hit different. Because what I was watching wasn’t just AI-assisted development. It was a fundamentally different interface between human intent and working software. And I don’t think enough people are taking it seriously

The physical bottleneck nobody talks about

For decades, the real bottleneck in software development wasn’t intelligence. It wasn’t creativity or problem-solving ability. It was physical.

Your brain generates ideas. Your fingers type them. That gap, between thought and code, has shaped everything about how software gets built. The rituals around “deep work” and “flow state.” The frustration when you’re interrupted mid-thought.

We never questioned this constraint. It was just the cost of building things.

Talking to your code changes the equation entirely. Stanford and Baidu researchers measured this in 2016: speech is 3x faster than typing, with 20% fewer errors. And that’s just the raw numbers. The cognitive reality is more interesting. Speaking and thinking happen largely in parallel. Typing is serial since your hands can only keep up with your brain if you deliberately slow your brain down.

The moment you switch to voice, you can stream ideas at the speed you think. Provide full context in seconds instead of minutes of typing. The feedback loop gets so tight it stops feeling like programming and starts feeling like thinking out loud.

I’ve seen this with Aike & Niklas at Kombo and I’ve felt it myself. There’s a point where the interface stops being visible. You stop thinking “I am telling the AI what to do” and start just... thinking. The gap between idea and implementation collapses to almost nothing. We’re not at Neuralink yet. But this is the logical step before that.

The tools are already here

Andrej Karpathy’s original “vibe coding” tweet from February 2025 got 4.5 million views. Most people focused on the “forget that the code even exists” part. But buried in there was something equally significant: “I just talk to Composer with SuperWhisper so I barely even touch the keyboard.”

That wasn’t incidental. That was the workflow.

SuperWhisper (or any other speech-to-text tool) runs in the background on your Mac, using Whisper to transcribe locally. Hold a hotkey, speak, release and whatever you said appears in Cursor, Claude Code, or whatever terminal is focused. There’s also Wispr Flow, which has native IDE extensions for Cursor and Windsurf specifically. Developers using it report dictating at 175+ words per minute. For context, a fast typist does 65.

The pattern that’s emerging looks like this: voice tool in the background, AI coding agent in the foreground, the developer as the person directing traffic. You speak intent, the agent translates to implementation, you speak corrections, the agent adjusts. Back and forth, no keyboard required.

Most engineers I talk to haven’t tried this yet. They know about Cursor. They’ve maybe used Claude Code. But they’re still typing everything, treating AI coding agents like a smarter autocomplete rather than a conversational partner you can actually speak to.

One engineer, five things happening at once

Voice is one part of this. The other part is parallelism. A year ago, the mental model of AI-assisted development was: you and one AI agent, taking turns. You write a prompt, it responds, you review, you follow up. Essentially a chat interface bolted onto your codebase. That model is already obsolete.

Boris Cherny, who created Claude Code, runs 10 to 20 agents in parallel at any given time. Earlier this year, Anthropic’s engineering team built a production-quality C compiler using 16 Claude agents running simultaneously, each with a specialized role, coordinating with each other, producing 100,000 lines of Rust that can compile Linux across three chip architectures. Two weeks of work. Sixteen agents.

Cursor 2.0 was redesigned around this idea. You can delegate tasks to eight different agents at once. Claude Code has an experimental agent teams feature. Open-source tools like Claude Squad let you spin up multiple instances across git worktrees.

What this means practically: when you combine voice input with parallel agents, you become something closer to a director than a developer. You describe what you want, in conversation, while several agents are already working on different parts of the problem. You’re not blocked waiting for one agent to finish before starting the next thing. You’re orchestrating. Checking in. Redirecting. Thinking about the next problem.

The feedback loop isn’t just tight, it’s concurrent.

This is not vibe coding. It’s something more serious.

I want to be careful here, because there’s a version of this story that’s naive. The “anyone can build anything now” take. Just talk to the AI and ship. That’s not what I’m describing.

Karpathy himself made this distinction in early 2026, proposing “agentic engineering” as the professional evolution. The framing: you are not writing code directly 99% of the time, you are orchestrating agents who do and acting as oversight. That’s meaningfully different from just vibing your way to a codebase that technically runs.

Addy Osmani from Google’s Chrome team put it well: the spec is not a prompt anymore. The spec is the product thinking made explicit. When you’re directing 10 agents in parallel, vague thinking doesn’t slow you down, it multiplies. The quality of your output becomes almost entirely a function of the quality of your specification.

What’s changing is not whether engineering skill matters. It’s which engineering skills matter most.

Raw coding speed becomes irrelevant. Syntax memorization becomes irrelevant. The ability to hold the architecture in your head, think clearly about system boundaries, anticipate failure modes, evaluate whether what the agent built is actually what you meant becomes everything. The METR research lab ran a controlled study earlier this year and found experienced developers were actually 19% slower when using text-based AI tools, because the constant stop-prompt-wait-review cycle broke their flow state. Voice interaction is a direct answer to that problem. You stay in conversation. The flow state survives.

Gergely Orosz, writing in The Pragmatic Engineer at the end of last year, described his experience: any time he now has to type precise syntax by hand, it feels like a tedious chore. “My biggest problem now is coming up with enough worthwhile ideas to fully leverage the productivity boost.”

That sentence is the tell. The constraint has moved. The bottleneck is no longer your hands. It’s your thinking.

Where this goes

For 50 years, programming has forced humans to enter the machine’s environment. Learn its syntax. Match its precision. Adapt to its constraints. Every abstraction layer, from punch cards to command line to GUI to IDE reduced that burden somewhat. But we’ve always been meeting the machine more than halfway. Voice + AI agents is the first interface where the machine genuinely comes to us.

J.C.R. Licklider predicted this in 1960, in his paper “Man-Computer Symbiosis.” He spent time studying his own work habits and concluded that most time was lost on “clerical” tasks e.g. getting into position to think rather than actual thinking. He explicitly called for automatic speech recognition as a prerequisite for effective human-computer partnership. Sixty-five years later, we built the thing he was describing.

The gap between “idea in your head” and “implementation” is collapsing fast.

Every abstraction layer that made programming more accessible has created more programmers, not fewer. FORTRAN reduced programming effort by 10x in the 1950s and the U.S. tech workforce grew from 200,000 to 1.6 million in the decades that followed. Now we are seeing for the first time, that AI could actually reduce the number of engineers that we need.

What I’m excited about is that it removes the translation tax. The physical friction that has always stood between thinking and building. The part where a good idea dies somewhere between your brain and the keyboard.

Watch what the best engineers do when that friction disappears. Watch what they build when the bottleneck is no longer their hands, but their thinking. That’s the shift worth paying attention to.

Sources & Further Reading

• Andrej Karpathy, “vibe coding” tweet, February 6, 2025 — x.com

• Andrej Karpathy, one-year retrospective on vibe coding, February 2026 — x.com

• Ruan et al., “Speech Is 3x Faster than Typing for English and Mandarin Text Entry on Mobile Devices,” Stanford HCI Group / Baidu, 2016 — hci.stanford.edu

• METR, “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” July 2025 — metr.org

• Addy Osmani, “The Factory Model: How Coding Agents Changed Software Engineering” — addyosmani.com

• Addy Osmani, “The future of agentic coding: conductors to orchestrators” — addyosmani.com

• Anthropic Engineering, “Building a C compiler with a team of parallel Claudes,” February 2026 — anthropic.com

• Gergely Orosz, “When AI writes almost all code, what happens to software engineering?” The Pragmatic Engineer — newsletter.pragmaticengineer.com

• J.C.R. Licklider, “Man-Computer Symbiosis,” 1960

• Mark Weiser, “The Computer for the 21st Century,” Scientific American, 1991 — calmtech.com

• JetBrains State of Developer Ecosystem 2025 — blog.jetbrains.com

• DX AI-Assisted Engineering Q4 Impact Report 2025 — getdx.com

• Wispr Flow, “Vibe coding supercharged with voice” — wisprflow.ai

• Mathias Klenk, “Thriving as an Engineer in the Era of Vibe Coding,” TechFounderStack — techfounderstack.com

• Mathias Klenk, “Agentic Engineering: How AI Agents Are Reshaping Software Development,” TechFounderStack — techfounderstack.com

Are you building AI into your product, or are you building an AI product?

It sounds like semantics. It’s not. It’s the difference between Notion adding AI summaries to its workspace and Cursor building an entire code editor around AI from the ground up. Both use large language models. Both ship AI features. But their businesses, their moats, and their risks couldn’t be more different. Having built two startups myself, I’ve seen how early architectural and strategic decisions compound over time. This one compounds faster than most.

Two Paths, Two Business Models

The startup world is splitting into two distinct camps: AI-enhanced companies and AI-native companies. Understanding which camp you’re in isn’t just an identity exercise. It determines almost everything about how you build, sell, and scale.

AI-enhanced companies take an existing product or workflow and layer AI on top. Think Canva adding Magic Design to generate templates from text prompts, or Shopify embedding an AI copywriter into its product listings. The core product existed before AI, and it would continue to function (albeit less impressively) if the AI layer were stripped away. The product solves a known problem. AI makes it faster or smarter.

AI-native companies are built from the ground up with AI as the core value proposition. The product simply couldn’t exist without it. Cursor, Midjourney, and Perplexity are textbook examples. Remove the AI and there is no product, just an empty shell. These companies aren’t enhancing a traditional workflow. They’re creating an entirely new one.

Thanks for reading Tech Founder Stack! Subscribe for free to receive new posts and support my work.

This distinction matters because it fundamentally changes your unit economics. Traditional SaaS enjoys gross margins of 70-80% because one more subscriber costs almost nothing. AI-native products, however, pay for compute every time a user sends a prompt or generates an image. Your best users, the power users you’d normally celebrate, become your most expensive users. AI-first SaaS gross margins often run between 20-60%, which is a completely different business. Even OpenAI, with over $13 billion in revenue, reportedly burned $8 billion on compute in 2025. Getting the economics right isn’t optional. It’s existential.

When AI Should Be a Feature

If you already have a product with real users and a clear value proposition, embedding AI as a feature is often the smarter play.

You already have distribution. The hardest part of any startup is getting people to use your product. If you’ve already solved that, adding AI features gives your existing users a reason to stay, upgrade, and pay more. Notion didn’t need AI to be useful. Millions of people already lived inside it. But adding AI summaries, writing assistance, and autofill made the product stickier and justified a price increase. Canva followed a similar playbook, raising its Teams pricing by up to 300% while pointing to AI-powered features as the justification.

Your moat is the product, not the model. When you embed AI, you’re typically calling an external model via API. OpenAI, Anthropic, or an open-source alternative. You don’t need to train your own model or build infrastructure for inference. Your competitive advantage stays where it always was: in your UX, your user data, your integrations, and your brand. The AI is a force multiplier, not the foundation.

You can iterate without betting the farm. Shipping an AI feature is a product decision, not an existential one. If the feature underperforms, you can pull it back, tweak the prompt, swap the model, or try a different approach. You’re not rebuilding the company. You’re improving a feature. This gives you room to experiment, which is exactly what you need when the underlying technology changes every few months.

The risk is obvious though. If AI is just a feature, it’s also easy to copy. Every SaaS company can bolt on a ChatGPT integration. If your AI feature isn’t deeply embedded in your workflow or powered by proprietary data, you’ve built a nice-to-have, not a moat. Bessemer’s State of AI report put it well: features built atop large models commoditize quickly. Each new capability triggers a flurry of copycats.

When AI Should Be the Foundation

On the other side, building an AI-native product is harder, riskier, and potentially far more rewarding.

You’re creating a new category. When Cursor launched, they weren’t adding AI to an existing IDE. They rethought what a code editor should look like when AI is a first-class citizen. When Midjourney appeared, it didn’t enhance Photoshop. It made image generation accessible to people who had never opened a design tool. AI-native products don’t compete with existing solutions on features. They compete on a fundamentally different vision of how work gets done.

The compounding advantage is enormous. AI-native companies build what the industry calls a data flywheel: every user interaction generates data that makes the product better, which attracts more users, which generates more data. This is incredibly hard to replicate from the outside. A traditional SaaS company can add an AI feature, but it can’t easily build the feedback loops and proprietary datasets that an AI-native competitor has been accumulating since day one. I wrote about this same dynamic in my piece on network effects. The compounding loop is the same principle, just applied to data instead of users.

The financial upside reflects the ambition. According to SaaStr’s recent research, the best AI-native startups are achieving $700,000 in ARR per employee. When your product does the work that used to require a services team, your unit economics look completely different. Customers understand they’re paying for outcomes, not seats. And they’ll pay accordingly.

The risk here is equally clear: you’re exposed to model commoditization. If your product is essentially a thin wrapper around GPT-4 or Claude, you have zero defensibility the moment the next model drops. The AI-native companies that survive are the ones building deep domain expertise, proprietary data pipelines, and user experiences that can’t be replicated by prompting a foundation model. If your product can be rebuilt in a weekend with a new API, you don’t have a company. You have a demo.

How to Decide

So which path should you take? In my experience, it comes down to three honest questions.

1. Does your product fundamentally require AI to deliver its core value?

If you’re building a legal research tool that reads thousands of case files and surfaces relevant precedents in seconds, that’s AI-native. The product doesn’t work without the model. But if you’re building a project management tool and you want to add smart task suggestions, that’s AI as a feature. Be honest about this. Calling yourself “AI-native” when you’re really “AI-enhanced” doesn’t fool investors, and it certainly doesn’t fool customers.

2. Where does your defensibility come from?

If your moat is proprietary data, a unique training pipeline, or a novel model architecture, you’re in AI-native territory and you should lean into it. If your moat is distribution, brand, user habits, or network effects, keep AI as a feature and double down on what actually makes you hard to replace. The best companies know where their real advantage lives and invest there.

3. Can you afford the economics?

AI-native products have a fundamentally different cost structure. Every API call, every inference, every generated image costs real money. If you’re bootstrapped or running a lean operation, the compute costs can be brutal. Model this out before you commit. Know your cost per user at P50 and P90 usage levels. If your heaviest users cost you ten times what your average users do, you need a pricing strategy that accounts for that from day one. Not after you’ve already scaled and your margins are underwater.

The Line is Blurrier Than You Think

Many of the best companies start as AI-enhanced and evolve toward AI-native as the technology matures and they accumulate proprietary data. Others start AI-native and realize their real value is in the workflow they’ve built around the model, not the model itself.

The mistake isn’t picking the “wrong” camp. The mistake is not being intentional about which camp you’re in. When you’re unclear about whether AI is your feature or your foundation, you end up with confused hiring priorities, messy architecture, and a pitch that doesn’t resonate with anyone. You over-invest in ML infrastructure you don’t need, or you under-invest in the data flywheel that would actually give you an edge.

As with most things in startups, clarity is a competitive advantage. Know what you’re building. Know why AI is in your product. And know what your company looks like if the AI layer changes, because it will.

The founders who get this right won’t just survive the current wave. They’ll be the ones shaping it.

There is a particular kind of founder anxiety making the rounds right now. It sounds like this: “I don’t have a machine learning background. Am I already behind?”

The short answer is no. But there is a catch.

You do not need to understand backpropagation or be able to fine-tune a transformer from scratch. What you absolutely must understand is the architecture that sits between a model and your users. The decisions you make about that architecture will determine your cost structure, your latency profile, your reliability guarantees, and ultimately whether your product survives contact with scale.

This is the minimum AI stack every technical founder needs to understand. Not to build it from scratch, but to make better decisions about it.

Why This Matters More Than the Model Itself

Most founders fixate on the model. GPT-4o vs. Claude vs. Gemini, as if model selection is the primary architectural decision. It is not. Models are commoditizing faster than anyone predicted. What a competitor cannot easily copy is the infrastructure reasoning you build around the model: your caching strategy, your retrieval approach, your fallback logic, your cost controls.

The technical founders who are winning right now are not the ones who trained a better model. They are the ones who built a faster, cheaper, more reliable product on top of the same models everyone else has access to. That is a stack problem, not a model problem.

The Five Layers You Must Internalize

1. The Model Layer (API vs. Self-Hosted)

At the top of the stack sits the model itself. The practical choice in 2025 is almost always between calling an API (OpenAI, Anthropic, Google, Cohere) and self-hosting an open-source model (Llama, Mistral, Qwen).

The build vs. buy tension here is real and consequential. API providers give you state-of-the-art capability with zero infrastructure burden, but you are paying a per-token tax on every request, accepting their latency, and depending on their uptime. Self-hosted models give you cost control and data sovereignty, but require you to manage inference infrastructure, and that is genuinely not trivial.

The decision rule is simple: use APIs until your token costs become a meaningful line item in your P&L or until your data privacy requirements force the issue. Then evaluate self-hosting at the margin.

What you need to understand here is how tokens are priced, what context window size costs you, and how model capability differences actually map to your use case. Flagship models are rarely 10x better, but they are often 10x more expensive.

2. The Orchestration Layer

This is where most of the product logic lives, and where most founders underestimate complexity. Orchestration covers everything that happens between receiving a user request and sending it to the model: prompt assembly, conversation history management, tool calling, multi-step reasoning chains, and routing between models.

Frameworks like LangChain, LlamaIndex, and the emerging wave of agent frameworks (AutoGen, CrewAI) abstract a lot of this. But abstraction has a cost. These frameworks add latency, introduce failure modes, and can obscure what is actually happening in your pipeline. A lot of production teams have quietly started writing thin, custom orchestration rather than depending on a heavy framework.

What you need to understand is the difference between a single inference call and a multi-step agentic chain. The latter can multiply your latency and cost by 5 to 10x while introducing compounding failure probability at each step.

3. The Memory and Retrieval Layer (RAG)

Pure in-context prompting has a hard ceiling: the context window. Retrieval-Augmented Generation solves this by storing knowledge externally and retrieving relevant chunks at query time. If your product involves large knowledge bases, long documents, or personalized user history, you are almost certainly building some form of RAG.

The components are a vector database (Pinecone, Weaviate, Chroma, pgvector) and an embedding model (OpenAI text-embedding, Cohere Embed, or open-source alternatives). The architectural decisions around chunking strategy, embedding model quality, similarity search parameters, and reranking have an outsized impact on both answer quality and cost.

What you need to understand is that retrieval quality directly constrains generation quality. A retrieval system that surfaces the wrong context will produce wrong answers regardless of how capable your model is. Garbage in, garbage out still applies.

4. The Inference and Serving Layer

If you are self-hosting models, this layer becomes critical fast. Tools like vLLM and Hugging Face’s TGI handle the problem of serving large models efficiently by managing memory, batching concurrent requests, and delivering consistent throughput. Without optimized inference, a 70B-parameter model serving 100 concurrent users will grind to a halt.

Even if you are API-only today, you should understand this layer conceptually, because it governs the latency and throughput guarantees your provider can actually deliver. It also explains why streaming responses exist: delivering tokens progressively reduces perceived latency without actually speeding up total generation time.

What you need to understand is the difference between time-to-first-token, which is what the user feels, and total generation time, which determines throughput. Both matter, but they call for different optimizations.

5. The Observability Layer

This is the layer most early-stage teams skip and later regret. In traditional software, a 500 error is deterministic and reproducible. In AI systems, failures are probabilistic. A model might hallucinate on 3% of inputs, degrade in quality as context grows, or behave differently at the edges of your prompt templates.

Without observability, you are guessing. Tools like LangSmith, Langfuse, and Helicone let you trace individual requests, log inputs and outputs, monitor cost per session, and catch quality regressions before your users do.

What you need to understand is that you cannot optimize what you cannot measure. Setting up basic logging and tracing from day one costs you almost nothing. Not having it when something breaks quietly costs you a lot.

The Build vs. Buy Mental Model

Every layer in this stack presents a build vs. buy decision. The heuristic that has served the best founders well is to buy the undifferentiated infrastructure and build the differentiated logic.

Your retry logic, your fallback routing, your cost guardrails, there are vendors and open-source tools for all of this. The prompting strategy tuned to your specific use case, the retrieval pipeline that encodes your domain knowledge, the evaluation harness that catches regressions in your product quality, that is where you earn your moat.

The founders who build everything themselves in the early days are not being rigorous. They are being slow. The founders who buy everything and never understand the plumbing beneath it will be stuck when the vendor bill becomes existential or when they need to debug a systemic quality problem.

What “Understanding the Stack” Actually Means

You do not need to be an ML engineer. You do not need to write CUDA kernels or implement attention mechanisms.

You need to be able to answer these questions without reaching for Google:

• Where does my token cost go, and what would halve it without sacrificing quality?

• What is the latency budget of each step in my pipeline, and where is the bottleneck?

• What happens to my product if my primary model API goes down for 20 minutes?

• How do I know if my model’s answer quality is degrading over time?

If you can answer those, you have the minimum viable understanding of the AI stack. The rest is implementation detail, and implementation detail you can delegate.

The stack is not the moat. Your judgment about the stack is.

For most startups, engineering is the single biggest investment they make. Salaries, cloud infrastructure, tooling, opportunity cost, it all adds up quickly. And yet, when founders or boards ask, “What’s our ROI on engineering?”, the answer is often vague, hand-wavy, or avoided altogether.

That’s not because engineering ROI is impossible to measure. It’s because it’s easy to measure the wrong things.

Engineering doesn’t behave like marketing spend. You don’t put one euro in and immediately get three euros out. The impact of engineering work is often indirect, delayed, and spread across multiple parts of the business. But that doesn’t mean it’s unmeasurable. It just means you need a different mental model to fully understand it.

Why Engineering ROI Is Hard To Measure And Why It Still Matters

The core difficulty with engineering ROI is attribution. A feature shipped today might increase retention three months from now. A refactor might prevent an outage that never happens. An internal tooling investment might not show up in revenue at all but it may allow the team to ship 30% faster for the next two years.

Because of this, many teams fall back to proxy metrics: velocity, number of tickets closed, number of deploys. These are easy to track, but they don’t answer the real question: Is engineering effort translating into business value?

If you don’t answer that question, you risk two failure modes. Either engineering becomes a cost center that constantly has to justify itself, or it becomes a feature factory that ships lots of things with unclear impact. Both lead to poor decisions.

Measuring engineering ROI is less about producing a perfect number and more about creating clarity and alignment.

A Better Way to Think About Engineering ROI

A useful way to approach engineering ROI is to separate what gets built from what changes because it was built.

Engineering always produces outputs: features, systems, improvements. But ROI lives one layer higher in outcomes and impact.

A simple mental model looks like this:

Engineering work → product or system change → measurable outcome → business impact

Not every step needs to be perfectly quantified, but the chain needs to exist.

For example, imagine a team invests a quarter into improving onboarding. The output is a redesigned flow and a set of backend changes. The outcome is higher activation and fewer drop-offs. The business impact is increased conversion to paid plans and lower acquisition costs. That’s engineering ROI even if you can’t attribute every euro precisely.

The same logic applies to infrastructure work. Reducing deployment failures or improving system reliability may not increase revenue directly, but it reduces risk, improves customer trust, and frees up engineering time. Prevented losses are still returns.

What Good Engineering ROI Measurement Looks Like

Teams that do this well tend to focus on directional signals, not vanity metrics.

They track delivery speed and flow things like cycle time, deployment frequency, and predictability. Because faster feedback loops mean faster value realization. But they don’t stop there.

They also measure how shipped work is actually used. Feature adoption, usage depth, funnel movement, or even qualitative customer feedback are all strong indicators of whether engineering effort is landing in the right place. A feature that ships and is never used has near-zero ROI, regardless of how efficiently it was built.

At the business level, they look for clear connections. Revenue growth enabled by a feature. Churn reduction after stability improvements. Cost savings from automation or infrastructure optimization. One befriended CTO shared an example where a focused engineering effort to reduce churn cut monthly churn in half, increasing projected annual revenue by millions on a relatively small engineering investment. That’s ROI you can explain to any board.

The key is balance. Speed without quality leads to fires. Quality without delivery speed leads to stagnation. Outputs without outcomes lead to busy teams and weak businesses.

Making ROI Visible Without Creating Perverse Incentives

One common fear is that measuring ROI will turn engineering into a spreadsheet exercise. That only happens when metrics are used as weapons rather than signals.

The goal isn’t to assign a euro value to every pull request. It’s to create shared understanding: why certain work matters, what success looks like, and whether we’re moving in the right direction.

Many teams use lightweight dashboards or quarterly reviews that connect engineering initiatives to outcomes. Not in a punitive way, but in a narrative one. “We invested in X, which led to Y, which moved Z.” Over time, patterns emerge. Some types of work consistently pay off. Others don’t.

That feedback loop is where ROI measurement becomes powerful. It informs prioritization. It shapes roadmaps. It helps engineering leaders say no to low-impact work and yes to the things that truly move the business.

The Real Point of Measuring Engineering ROI

Engineering ROI isn’t about proving that engineers are “worth the money.” Good founders already know that. It’s about focus.

It’s about ensuring that limited engineering capacity is spent on the highest-leverage problems. It’s about making trade-offs explicit. And it’s about turning engineering from a perceived cost center into an obvious value engine.

You don’t need perfect data. You need honest signals, clear narratives, and the discipline to ask after every major effort: Did this meaningfully help the business?

If you can answer that consistently, you’re already measuring engineering ROI better than most startups.

From an engineer’s point of view, good product management is surprisingly simple to define and painfully obvious when it’s missing.

Good product management creates clarity. It helps engineers focus on solving the right problems, instead of just shipping features. Bad product management, on the other hand, turns engineers into ticket-takers, drains motivation, and slowly converts promising startups into feature factories.

Many of the best ideas about product management (e.g. from Elad Gil, Ben Horowitz, Lenny Rachitsky) converge on one truth: product management is not about managing engineers or writing specs. It’s about owning outcomes.

Product Management Is About Outcomes, Not Output

Engineers tend to think in systems, constraints, and trade-offs. We like clear problem statements and hate vague goals. The best product managers understand this instinctively.

Good PMs don’t start with “we need feature X.” They start with “users are failing at Y, and that’s costing us Z.” That framing matters. It invites engineers into the problem instead of handing them a predetermined solution.

Ben Horowitz famously described a good PM as someone who behaves like the “CEO of the product.” From an engineering lens, that doesn’t mean authority, it means responsibility. A good PM owns the success or failure of what gets built. They don’t blame engineering velocity, unclear requirements, or market conditions. They absorb complexity and turn it into direction.

This is why engineers respect PMs who are decisive. Someone who can synthesize inputs from design, engineering, sales, and leadership, and then make a call. Engineers would rather work with a PM who makes a wrong decision quickly and corrects it than one who never decides at all.

Early-Stage Product Management: Scrappy, Founder-Led, Execution-Heavy

In early-stage startups, “product management” is usually a misleading term. Most of the time, the founders are the product managers and that’s a good thing.

At this stage, speed matters more than polish. You’re still searching for product–market fit, and heavy process actively hurts you. Roadmaps longer than a few weeks are mostly fiction. What matters is learning fast.

Good early-stage product management looks like this:

• Talking to users constantly

• Shipping small changes weekly (or daily)

• Doing things that don’t scale

• Treating the product as a hypothesis, not a roadmap

Airbnb is the canonical example. When growth stalled, the founders didn’t debate features, they flew to New York, met hosts, and took photos themselves. That wasn’t “scalable product management,” but it solved the core user trust problem. The result was a step-change in growth.

From an engineer’s perspective, early-stage PMs (or founders acting as PMs) are valuable when they remove ambiguity and unblock execution, not when they introduce process. A great early PM is often half project manager, half user researcher, half firefighter. Yes, that’s more than one whole person, which is why founders usually do it themselves at first.

Hiring a heavyweight PM too early can be a mistake. Until you have product–market fit, vision matters more than coordination.

Scaling Product Management: From Shipping Fast to Shipping Right

Once product–market fit exists, everything changes.

The product now needs to scale across teams, customers, geographies, and use cases. This is where real product management becomes essential.

At this stage, good PMs start introducing structure, but only enough to maintain clarity. Their job shifts from “what should we build next?” to “how do we keep building the right things as the organization grows?”

This is where roadmaps start to matter. Not because they predict the future accurately, but because they align teams around priorities and trade-offs. Engineers benefit enormously from knowing why one project matters more than another.

Amazon’s “working backwards” approach is a great example of scaled product management done well. Writing a press release before building anything forces clarity on customer value. Engineers don’t just get requirements, they get context. That context enables better technical decisions throughout the build.

Facebook’s evolution from “move fast and break things” to “move fast with stable infrastructure” is another example. At scale, stability becomes a feature. Good product management recognizes when the definition of “good” has changed and adjusts incentives accordingly.

Where Product and Engineering Commonly Clash

Most product–engineering friction comes from one of three things:

1. Unclear priorities

   When leadership doesn’t explicitly choose between speed, quality, or growth, product and engineering will make different assumptions and conflict is inevitable.

2. Feature-driven thinking

   When PMs focus on outputs (“ship this feature”) instead of outcomes (“reduce churn”), engineers lose autonomy and motivation.

3. Lack of technical empathy

   PMs don’t need to code, but they do need to understand constraints. Engineers quickly lose trust in PMs who treat complexity as an inconvenience instead of a reality.

Good PMs reduce friction by making trade-offs explicit. They acknowledge technical debt, protect engineering focus, and say “no” — especially to sales-driven one-off requests that don’t align with strategy.

The best PMs also involve engineers early. Not to ask how long something takes, but to explore what’s possible. Many of the best product ideas come from engineers if you give them the problem instead of the solution.

What Engineers Actually Want From Product Management

If you ask engineers what they value most in a PM, the answer is rarely documentation or process.

They want:

• Clear goals

• Honest prioritization

• Context for decisions

• Protection from chaos

• Ownership and accountability

A good PM makes the team feel like they’re working on something that matters. They reduce cognitive load instead of adding to it. When things go wrong, they step forward not sideways.

Final Thought

From an engineer’s perspective, good product management isn’t about controlling the roadmap or translating business requests into tickets. It’s about turning ambiguity into clarity and effort into impact.

Great PMs make teams faster and smarter. They adapt their style to the company’s stage. And most importantly, they treat engineers as partners in solving meaningful problems not just builders of predefined solutions.

When product management is done right, engineers don’t complain about it. They barely notice it. Things just work.

Startups have a notorious failure rate – some estimates say 9 out of 10 startups eventually fail. Yet, contrary to what many first-time founders expect, startups rarely fail because a giant competitor swoops in or because of some external “homicide.” Instead, most startups die by “suicide,” meaning their demise is self-inflicted by internal issues. As YC founder Paul Graham once noted, “Startups are more likely to die from suicide than homicide.” In my experience building two startups, I’ve seen that the biggest threats usually come from within the company’s own walls, not from the outside world.

Suicide, Not Homicide: Internal Collapse vs. External Threats

There’s a saying in Silicon Valley: “Startups don’t die, they commit suicide.” Entrepreneur Justin Kan used this phrase after observing how many young companies implode long before they run out of options. Startups often give up on themselves while they’re “still very much breathing”. Founders burn out or lose heart, and the team calls it quits. In Kan’s words, “the people in them give up and move on… or they realize that startups are hard and [cause] massive… exhaustion”. Founders may abandon ship – taking another job, going back to school, or simply drifting away – even when some hope remains. Y Combinator’s Harj Taggar noticed the same pattern: many companies fail simply because the founders stop trying. “The startups that take off are the ones that continue to keep going… the ones that succeed are the ones that keep going. Like PG says, the way to win is to not die.” In short, giving up too early is often the real killer.

Why would a passionate founding team quit on their own company? Often it’s the accumulation of internal problems – no clear traction, constant obstacles, team disagreements, stress – that leads to despair. Taggar explains that at YC’s stage, “companies fail because they give up or the founders don’t get along”, and another big reason is “the company is not making what people really want.” When you’re not hitting product-market fit or you’re fighting with your co-founder every week, it’s easy to see why some founders lose the will to continue. External competition alone rarely directly kills a startup; if you have a great product and a solid team, a competitor can’t easily destroy you. Far more often, startups defeat themselves through inaction, conflict, or loss of focus, effectively “committing suicide” while the competition simply watches.

Running Out of Money – The Final Symptom

One of the most visible ways startups die is running out of cash. If a company can’t pay its team or its bills, it’s game over. Indeed, in an analysis of 100+ startup post-mortems, “running out of cash” was the #2 most-cited reason for failure. Often startups fail to raise their next funding round in time, or their revenue never materializes before the initial funds dry up. But lack of money is usually a symptom, not the root cause. The deeper issue is why the startup ran out of money in the first place. In many cases, it’s because the startup never achieved product-market fit – they were making something few people truly wanted, so revenue and investor interest stayed low. Venture capitalist Marc Andreessen puts it bluntly: “The #1 company-killer is lack of market.” If you build a product no one needs, it doesn’t matter how much seed money you have; eventually, the cash will burn away with nothing to show, and fundraising will be impossible. Andreessen argues that startups fail when they never reach product/market fit – in other words, they couldn’t find a real, paying market for their product.

Besides product-market fit, financial mismanagement can accelerate the demise. Some teams spend too aggressively (hiring too many people, lavish marketing) before they’ve validated the business, causing a cash crunch. Others are too slow to monetize or raise funds, and simply run out of time. Interestingly, many founders who “ran out of money” were in fact on the verge of success but quit too soon. As Justin Kan noted, it’s rare to see a founding team give up when metrics are skyrocketing – most give up when growth is flat and funds are low. That is exactly the moment when patience and iteration are needed: “One thing many entrepreneurs don’t realize is that patience and iteration are critical in achieving product-market fit… overnight successes never actually happen overnight.” Those who persevere and find a way to stretch their runway – by cutting burn, pivoting, or securing a bridge round – get a shot at turning things around. Those who don’t, wind up in the startup graveyard marked “out of cash.”

Founder Conflict and Team Breakups

If running out of money is the final nail in the coffin, co-founder conflict is often what built the coffin to begin with. A popular (and startling) statistic from Harvard researcher Noam Wasserman found that 65% of high-potential startups fail due to conflict among co-founders. I believe it. In the early stages, the founding team is the company – if that team falls apart, the company often falls apart with it. Co-founder infighting can scare away investors, cause paralysis in decision-making, and poison the company culture from within. In fact, choosing the wrong co-founder can be as fatal as choosing the wrong idea. Startup lore frequently compares co-founders to a married couple; if the relationship turns sour, a messy divorce can kill the startup even if the product is promising. Misalignment on big questions (Should we expand fast or pace ourselves? Do we sell the company or aim for IPO? How do we define success?) will eventually lead to irreconcilable differences. If one founder envisions building a billion-dollar unicorn while the other would be happy with a small, stable business, they’ll clash on strategy and goals.

Beyond outright conflict, there’s also the scenario of a key founder or early team member leaving. When a co-founder quits, it’s incredibly hard on a young startup’s morale and operations. The remaining team now has a “single founder” problem – all the burdens fall on one person’s shoulders. Paul Graham actually warned about having a single founder from the start. He observed that startups with multiple founders have an edge: “Starting a startup is too hard for one person. …You need colleagues to brainstorm with…and to cheer you up when things go wrong.” When you lose that camaraderie, the low points in a startup can become unbearable. I’ve seen companies crumble soon after a founding team member left, not just because of the lost skills, but because the emotional glue was gone. In some cases, remaining founders lose confidence and momentum, leading to a slow fizzle. As an investor friend once told me, “bad bedfellows” – meaning a poor fit between founders or team – can sink even a good idea. Ensuring the founding team is aligned and works well together is absolutely critical to a startup’s survival.

Loss of Focus and Founder Burnout

Another common self-inflicted wound is when founders lose focus or motivation. Startups demand single-minded dedication; if the leaders start getting distracted, it’s a bad sign. In fact, “losing focus” was listed among the top 20 reasons startups fail (it was #11) in the CB Insights analysis. This can take many forms. Sometimes founders start chasing new side projects – maybe tinkering with another startup idea, or taking on consulting gigs, or even dabbling in a new hobby – instead of pushing their main venture forward. Other times it’s more subtle: the team keeps pivoting in new directions without committing to one strategy, or spreads itself thin pursuing too many features at once. Either way, the startup loses momentum because its leaders aren’t all-in on one clear vision.

Loss of focus is often tied to loss of passion. In the early days, you need a huge amount of enthusiasm to get through the inevitable challenges. If the founders’ hearts just aren’t in it anymore, progress grinds to a halt. I’ve seen founders mentally check out when growth stalled – instead of doubling down, they started daydreaming about other opportunities. Justin Kan described how the temptation to quit hit him multiple times during Justin.tv: he would come to the brink of “packing it up and moving on” when things looked bleak. It’s human nature to want to escape a painful grind, and running a startup can certainly become a grind. Founders also face extreme stress and burnout, which can sap one’s motivation. Long hours, pressure to survive, and the emotional rollercoaster can lead to exhaustion. When a founder is burned out, they might start procrastinating, avoiding tough problems, or delegating critical decisions – all signs the fire in the belly is dying out. Eventually, if the passion doesn’t reignite, the startup slowly withers from neglect. As one founder quipped, “Startups don’t usually starve to death; they drown in all the opportunities and distractions.” Keeping focused on the mission is harder than it sounds, but absolutely necessary to avoid a self-induced death.

How to Avoid a Startup Suicide

The good news is that knowing why startups die also highlights how future founders can maximize their startup’s chances of survival. After years of my own trial and error (and observing many others), here are some key lessons to heed:

• Choose Your Co-founder(s) Wisely and Align on Vision: Picking a co-founder is arguably as important as picking the idea. Make sure you share values and long-term goals. Misaligned aspirations (e.g. one founder wants a quick sale, the other wants to build forever) will lead to conflict. Remember that 65% of startups fail due to co-founder conflict, so treat your co-founder relationship with care and communicate openly. It’s better to hash out expectations (equity splits, roles, exit strategy) early than to fight later.

• Make Something People Want (Achieve Product-Market Fit): This is the golden rule from YC – “not making something users want” is the ultimate killer. Talk to your target users incessantly, validate that you’re solving a real problem, and be willing to iterate until you hit a nerve. If customers genuinely love your product, you’re far less likely to die. Traction solves a lot of problems – it attracts investors, boosts team morale, and gives you revenue to extend your runway. As Harj Taggar said, many startups fail because “the company is not making what people really want.” Don’t fall in love with your tech for its own sake; solve a pain point that truly matters to people.

• Manage Your Runway and Finances Cautiously: Running out of cash is a preventable failure in many cases. Always know your runway (months of cash left) and plan fundraising or revenue milestones well before you hit empty. Keep costs under control – hire slowly and spend on what moves the needle, not on vanity. Many startups burn money on nice-to-haves and regret it later. As a rule of thumb, try to raise enough money to reach the next major milestone (product launch, user target, revenue goal) plus a buffer. If things take longer, be ready to cut expenses or raise an extension round. It’s not glamorous, but survival often comes down to prudent cash management. Investors will ask “What will you do if you can’t raise in time?” – have an answer (e.g. reduce burn, find a strategic partner, etc.) so you’re not caught in a crisis. Essentially, buy yourself time to find what works.

• Stay Focused and Commit Fully: Don’t try to run two companies at once, and don’t treat your startup like a side hustle. The startups that thrive are usually the ones where founders jump in with both feet. Shiny new ideas will always tempt you – resist chasing every rabbit. Paul Graham’s advice in “Startups in 13 Sentences” was simply: “Focus.” You and your team should know your top priorities each quarter and say no to distractions. This also means persevere through the tough times. If you keep making progress, even small wins, you’ll outlast the many who quit. As the saying goes, the only way to guarantee failure is to stop trying. Nearly every successful startup went through a phase where things looked grim, but the founders kept at it. Cultivate determination and resilience as core team values.

• Nurture a Healthy Co-founder Relationship and Team Culture: Since internal discord is such a startup killer, invest in keeping your team aligned. Communicate constantly with your co-founder(s) – have the hard conversations about performance, equity, and direction sooner rather than later. If roles or compensation need adjusting, address it. Set up a mechanism to resolve disagreements (e.g. a trusted mentor or board member who can mediate). Many conflicts can be softened by clear communication and empathy – remember you’re on the same side trying to make the startup win. Also, build a culture where everyone can voice concerns and where burnout is acknowledged. Encourage people (including yourselves as founders) to take breaks when needed to avoid total exhaustion. A supportive, mission-driven culture helps prevent the frustration and misalignment that often lead to “startup suicide.”

• Plan for Success (and Failure) Together: It may sound pessimistic, but discuss upfront what happens if things go south. If one founder wants out, how will you handle it? If an acquisition offer comes, are you both open to selling? Aligning on these scenarios can save a lot of heartache later. On the flip side, make a shared plan for success: what is our vision if all goes well? Having a common vision keeps everyone motivated during the dark days. It’s easier to stay committed when you and your co-founder see the same endgame and why it’s worth fighting for.

In conclusion, most startups don’t meet their end because of some predator in the market. They meet their end because of internal missteps, broken relationships, or loss of will. The post-mortems and essays from seasoned founders all echo this truth: your startup’s fate is largely in your own hands. The flip side is empowering – if you avoid the classic pitfalls and take care of your team, you greatly increase your odds of survival. Build something people want, keep your team united, spend wisely, and never ever give up too early. Do that, and you’ll dramatically raise the chance that your startup doesn’t just avoid “suicide,” but actually thrives and lives to see its vision come to life. As Paul Graham famously implied, “the way to win is to not die.” Stay alive, and you give yourself the chance to eventually succeed.

Sources & Further Reading

This article draws on insights from leading startup thinkers and investors, including Paul Graham (Y Combinator), Sam Altman, Justin Kan, Harj Taggar, and essays from a16z, Sequoia Capital, First Round, NFX, Index, and Accel. It also references research such as CB Insights’ analysis of 100+ startup post-mortems and Noam Wasserman’s The Founder’s Dilemmas on co-founder conflict.

Network effects – where each additional user makes a product or service more valuable to other users – are among the most powerful forces in the tech startup world. Many of the most successful companies of the internet era, from Amazon and Google to Facebook and even community-driven platforms like Wikipedia, have grown on the back of strong network effects. In fact, venture studies estimate that roughly 70% of the total value created by tech companies since the 1990s has come from businesses with network effects. For aspiring founders, understanding and harnessing network effects can be the key to building a product that doesn’t just grow, but accelerates in value and defensibility as it scales.

What Are Network Effects?

In simple terms, a network effect occurs when a product or service becomes more useful as more people use it. The classic illustration is the telephone: one telephone alone is useless, but each new telephone owner increases the utility of the network for everyone by adding another reachable connection. Over a century ago, AT&T’s president Theodore Vail recognized this, famously noting that “a telephone – without a connection at the other end of the line – is one of the most useless things in the world. Its value…increases with the number of connections.” This insight – that the value of a network grows as more nodes (users) join – later came to be quantified as Metcalfe’s Law (value ~ N² for N users).

Network effects can be direct (same-side), meaning each new user directly adds value for existing users (as with telephones or social networks), or indirect/cross-side, where one user group adds value for another group in a two-sided platform (as with buyers and sellers in a marketplace). In all cases, the core idea is the same: usage begets more value, which in turn begets more usage. This positive feedback loop often creates a flywheel effect for growth, and, importantly, a defensible moat around the business as it becomes harder for new entrants to compete without a similar network in place.

Note: Network effects are not the same as viral growth. Viral marketing or “growth hacking” can help acquire new users (for example, users inviting friends), but network effects are about retaining users by making the product inherently more valuable as others join. Both concepts often work together in successful startups, but network effects specifically drive long-term user value and lock-in, rather than just initial user acquisition.

Why Network Effects Matter for Startups

For startups, network effects are a holy grail of growth and competitive advantage. They are widely regarded as the strongest form of defensibility in the digital age, even more powerful than things like brand or scale alone. Companies built on robust network effects tend to dominate their markets and enjoy winner-take-all dynamics. As the team at NFX (a venture firm named after “network effects”) puts it: Network effects are the #1 way to create defensibility in the digital world. Once a network effect kicks in, a competitor can’t easily lure away your users without first building an equal or greater network, which is a huge barrier to entry. This is why a startup that successfully builds a network effect can turn into an enduring market leader.

Empirical data backs up the outsized impact of network effects. NFX’s research found that even though companies with true network effects are a minority, they accounted for about 70% of the tech industry’s value creation over the past few decades. Investors like Sequoia and Andreessen Horowitz regularly observe that the tech industry’s most legendary companies owe much of their success to network-driven growth. The presence of a network effect can also lead to self-perpetuating growth loops: as more users join and create value, that product attracts even more users organically. Engaged users tend to stick around because leaving means losing the unique network value they can’t get elsewhere.

However, founders should note that network effects often require reaching a critical mass of users before they truly ignite. In the early stages, a network-dependent product might feel only marginally useful (or even useless) until enough participants are onboard. Most products with network effects “must ultimately reach critical mass in order to fully take advantage of their defensibility… Before that point, the product remains quite vulnerable and may not have much value to users.” Overcoming this initial “cold start” or chicken-and-egg problem is a key challenge. But once critical mass is achieved, a startup can benefit from an accelerating, compounding advantage that is very hard to disrupt.

Examples of Network Effects in Action

Many iconic tech startups have leveraged network effects as the engine of their growth. Here are a few examples and how they achieved it:

• Facebook and Social Apps: Facebook’s early growth was driven by direct network effects – people joined because their friends were there, and each new friend on the platform made it more engaging for others. The same pattern holds for social and communication apps like WhatsApp, Instagram, Snapchat and others: the more users on the network, the more useful and sticky the service becomes for everyone. A user is far less likely to leave Facebook or WhatsApp when “there are more people that you can connect with” on it than anywhere else. This connectivity effect led these platforms to go from niche products to billions of users with very little paid marketing, as the network itself pulled in new members.

• eBay and Craigslist (Online Marketplaces): In two-sided marketplaces, buyers and sellers each create value for the other. eBay and Craigslist are classic examples: buyers flock to where the most sellers list items, and sellers go where the most buyers are searching. This mutual reinforcement meant that the network itself provides the majority of the value – not the website’s features – which is why eBay and Craigslist remained market leaders even while their interfaces stayed largely unchanged for decades. A competitor offering a prettier UI had no chance if they couldn’t match the breadth of eBay’s marketplace inventory or Craigslist’s local community of users. The network effect here created huge staying power.

• Uber and Lyft (Ride-Sharing): In ride-hailing services, cross-side network effects connect riders and drivers. More drivers on the network lead to shorter wait times and more route coverage, which attract more riders; more rider demand in turn encourages more drivers to sign up – a virtuous cycle. Uber famously used this dynamic city by city to achieve liquidity. Once a city’s Uber network had, say, sub-5-minute average wait times, it became very hard for a new entrant to compete. (In fact, beyond a certain point, adding yet more drivers doesn’t improve rider experience further – e.g. wait times under ~3 minutes – which shows the limits or asymptote of a network effect in this case. But reaching that critical mass first gave Uber a lasting edge.) The flywheel of drivers ↔ riders allowed Uber and Lyft to scale rapidly while keeping competitors at bay.

• Airbnb (Peer-to-Peer Lodging): Airbnb applied the marketplace network effect to travel lodging. As more hosts listed homes on Airbnb, the platform could offer travelers a wider variety of locations and prices than traditional hotels. This selection in turn attracted more guests, which incentivized more homeowners to join as hosts. Over time, Airbnb built such a large and diverse inventory that a traveler could almost always find something fitting their needs – an advantage a smaller site could not match. The breadth and liquidity of Airbnb’s two-sided network became a formidable moat. For example, Airbnb can show lodging options across every neighborhood and price range in a city, making it “more valuable on both sides of the marketplace than a site that just shows a commoditized set of hotel rooms.” This differentiated network effect helped Airbnb grow from a small online community into a global hospitality giant.

• Windows, iOS and Platform Ecosystems: Operating systems and developer platforms demonstrate network effects between users and third-party developers. Microsoft Windows and Apple’s iOS gained dominance partly because of their rich app ecosystems. A large user base attracted more developers to build software for the platform, which in turn made the platform more attractive to users due to the abundance of apps. This two-sided platform effect created high switching costs – e.g. many people won’t switch to a new OS that lacks their favorite apps. Microsoft famously cultivated this network by courting developers (even giving software away to universities so students would enter the workforce already familiar with Windows). Today, Apple’s App Store and Google’s Android platform similarly thrive on the cycle of more users → more developers → more apps → more users. Additionally, ecosystems like Atlassian’s Marketplace show how B2B software can leverage networks: Atlassian’s suite (Jira, Confluence, etc.) spawned a marketplace of 1,250+ third-party plugin developers, resulting in 28,000 app installs per week and over $2 billion in sales for those partners – a strong network effect that continuously adds value for Atlassian’s customers and locks in its products as an industry standard.

• Waze (Data Network Effects): Network effects aren’t only about person-to-person interaction; they can also be driven by data contributions. Waze, the GPS navigation app, is a great example of a data network effect. Every driver using Waze also contributes real-time traffic and road information (just by driving, or actively reporting incidents). As more users contribute more data, Waze’s maps and traffic predictions become more accurate for everyone on the platform. In turn, a superior navigation experience attracts more drivers to start using Waze, who then contribute yet more data. Because this loop is continuous and real-time, the value keeps improving with scale – there’s essentially “no traffic jam” of diminishing returns in Waze’s data; even the 1000th user in an area can add new value by reporting a fresh incident. This has made Waze incredibly competitive against traditional GPS services. Other products like Yelp also exhibit data network effects (more user reviews make the service more useful), though often with some limits (e.g. the 50th review of the same restaurant might not add as much value as the first five).

These examples illustrate how varied network effects can be – spanning social networks, marketplaces, platforms, and data-driven products – but also how central they are to the growth of tech companies. In each case, the startup reached a tipping point where the network itself became the biggest asset and driver of further growth. As Reid Hoffman famously quipped, “First scalers” in network-effected spaces can achieve runaway momentum that latecomers struggle to match.

Lessons for Aspiring Founders

For entrepreneurs, the takeaway is clear: if you can build authentic network effects into your product, you can create a self-sustaining engine for growth and a durable competitive moat. Here are a few key points to keep in mind:

• Design for Network Value: Think about how each new user (or each new data point, creator, transaction, etc.) can enhance the experience for existing users. If adding users doesn’t improve the product, you don’t have a true network effect. Strive to introduce mechanisms that let user interactions or contributions compound value. As NFX emphasizes, “for Founders looking to build a strong competitive moat, the ability to identify and understand network effects is invaluable.”

• Solve the Cold Start Problem: Early on, a network-effect startup faces the chicken-and-egg challenge – the product is only valuable with a network, but you need to provide value before the network exists. Tactics here include starting with a focused niche or geography, offering strong single-player utility, or seeding the network manually. For example, Facebook began on a single college campus to ensure density, and Airbnb initially attracted hosts by scraping listings from Craigslist to seed supply. Remember that until you reach a critical mass of users, your product will be vulnerable, so plan how to cross that chasm. Sometimes providing extra utility or content yourself can attract the first users until the user-generated value kicks in.

• Focus on Engagement and Retention: A network effect will only pay off if users stick around to benefit from it. Ensure your product is engaging and sticky so that as the network grows, users keep returning (this might mean fostering content creation like posts/reviews, facilitating connections, or otherwise making the network’s value apparent). High engagement not only boosts retention but also accelerates the network effect since active users contribute more value for each other. Sequoia Capital’s team notes that engagement drives retention, which drives growth in a networked product – engaged users will sustain your network through the early stages and beyond.

• Monitor Quality and Negative Effects: As your network scales, pay attention to potential negative network effects. Sometimes growth can introduce friction – e.g. too many connections on a social network can reduce people’s willingness to share, or too much marketplace choice can overwhelm users. Keep the value proposition evolving: introduce curation, matchmaking, or other features to ensure that more users continues to mean more value, not noise. The best companies actively manage their networks (through algorithms, community guidelines, etc.) to preserve the quality of interactions as they grow.

• Layer Multiple Network Effects (if possible): The strongest startups often have more than one type of network effect reinforcing their business. For instance, Apple benefits from a two-sided app ecosystem (platform network effect) and also a kind of social/bandwagon effect where its products’ popularity itself drives adoption. Facebook in its heyday had direct social network effects and also data network effects (more user data improving feed relevance). If you can stack network effects – or combine a network effect with other moats like brand and high switching costs – your startup will be even harder to disrupt. Each type of network effect has its own playbook, so be open to leveraging multiple “colors on the palette” as you scale.

In summary, network effects can transform a startup from a small project into a platform with exponential growth and deep defensibility. They create a scenario where success feeds on itself: the bigger your user base grows, the more value your product delivers, which then attracts even more users. This is why top venture firms and experienced founders obsess over network effects. As NFX observes from decades of building and investing in such companies, “defensibility is what will define the success of your business. More than anything else, network effects are the key to that.” For an aspiring founder, internalizing this principle – and executing strategies to trigger network effects – can make the difference between a product that plateaus and one that becomes a category-defining, scalable network with a life of its own.

Sources: Network Effects Manual; Network Effects Bible; NFX Archives; Sequoia Capital Insights; Andreessen Horowitz analysis; Accel insights; and other industry case studies.

Early-stage investors often boil startup success down to three factors – team, market, and product. These are like three legs of a stool, all important for stability. There’s long been debate about which leg matters most. Some VCs, like early Silicon Valley pioneer Arthur Rock, argue that backing an exceptional team is paramount. After all, a smart team can pivot and adapt. But others, like Sequoia Capital founder Don Valentine, firmly believe “the marketplace comes first, because you can’t change that, but you can change the people”. In other words, even an A+ team will struggle in a bad market, whereas a B-level team can ride a great market to success.

So, which is truly most important? Let’s explore why many experienced founders and investors say market always wins.

Why the Market Matters More Than Anything

A popular theory in startup land (championed by Marc Andreessen and others) is that product-market fit – and specifically the market – is the biggest determinant of success. The reasoning is straightforward: in a great market, customers are hungry for a solution, any viable solution. Demand is high, almost pulling the product out of the startup’s hands. As Andreessen famously put it, “In a great market… the market pulls product out of the startup. The product doesn’t need to be great; it just has to basically work”. In such a scenario, the market’s momentum will forgive imperfections – “the market doesn’t care how good the team is, as long as the team can produce that viable product”. In other words, if you’re selling something people desperately want, you can screw up many other things and still win. As VC Andy Rachleff quips, “If the dogs are eating the dog food, then you can screw up almost everything… and you will succeed”.

Contrast this with a terrible market: you might have the flashiest product and a world-class team, but no one wants what you’re offering. Andreessen didn’t mince words here either: “In a terrible market, you can have the best product in the world and an absolutely killer team, and it doesn’t matter – you’re going to fail”. You’ll spend years trying to lure customers that just don’t exist, and even a great team will get demoralized and quit. Rachleff’s Law of Startup Success captures it well: “When a great team meets a lousy market, market wins… When a lousy team meets a great market, market wins… When a great team meets a great market, something special happens.” Lack of market demand is the #1 startup killer.

Empirical data backs up the primacy of market. Investor Jeremy Liew cites a McKinsey study analyzing 100 companies: overall market growth explained 43% of the variance in growth rates, whereas differences in execution (market share gained) explained only 22%. Simply put, being in a fast-growing market had roughly twice the impact of superior execution. Or as Liew summarizes, “riding market growth in a fast growing market is a lot easier than trying to take market share in a slow growth market.” Even a mediocre product/team in a booming sector benefits from a “rising tide lifting all boats” effect. On the flip side, if you’re fighting uphill in a stagnant market – trying to sell something people don’t really feel a need for – it’s nearly impossible to win.

I’ve witnessed this dynamic in my own startup journey. A friend of mine, an excellent founder, built a venture (Kyte) with a strong team. But they were battling in a tough market, and despite their talent, product-market fit remained elusive. Similarly, my previous startup Midlane was in the HR software space – a crowded sector that wasn’t rapidly growing. We had a great team and worked hard, but without strong market tailwinds, gaining traction felt like pushing a boulder uphill. In contrast, my first startup Passbase entered the online ID verification (KYC) space at a time when that market was exploding. Cryptocurrency exchanges and fintech companies urgently needed KYC solutions, and we rode that wave. The market demand was so huge that our product adoption naturally grew with minimal marketing – a case of being in the right place at the right time. Our team certainly had to execute well, but the market’s growth did a lot of the heavy lifting.

💡 Lesson learned: A great team is invaluable, but even a stellar team cannot easily overcome a fundamentally bad market, whereas even an average team can prosper in a booming market.

The Product Comes Last (Iterate Until It Fits)

Where does the product itself rank in this hierarchy? Counterintuitively, it’s often third. This isn’t to say you can peddle a terrible product and succeed – you eventually need a great solution – but in early startup stages the product is malleable. If you have a capable team working in a fertile market, they’ll iterate the product until it finds the demand. In a hot market, customers will tell you exactly what they need, and you can adjust accordingly. That’s why investors often claim a great market + great team will inevitably find product-market fit if they keep tinkering. The core product idea might pivot two or three times before locking into what the market wants (many founding teams go through false starts and painful pivots before finally unlocking growth ). But as long as you’re in a high-potential market, those iterations are heading in the right direction.

By contrast, a beautifully crafted product in a market with no appetite is just art – it won’t become a business. As one founder/investor mantra goes, “If you address a market that really wants your product, you can mess up lots of things and still succeed. On the other side, if customers don’t want what you’re selling, you have no chance.” In practice, this means it’s often wiser to launch a “good enough” MVP quickly and see if there’s a real market pull, rather than spending years perfecting a product in isolation. You can improve your product, you can even swap out team members, but you can’t swap out a stagnant market for a vibrant one. As Ameet Ranadive concluded in his Market Always Wins essay, “If you choose the wrong market, no matter how great a product you build or how smart your team is, you won’t be able to iterate your way to a big success. An exceptional market will pull product out of the team. A terrible market will inevitably kill the startup.” In short, nail the market selection first, then adapt the product to fit that market’s needs.

How to Find a Great Market: Look for the Shifts

If market selection is so critical, how do you find a great market for your startup idea? Often, breakthrough markets emerge from major shifts – moments of change that create new problems and opportunities. Here are three big types of market shifts to watch for:

1. Regulatory Changes: Laws and regulations can overnight create a new market or expand an existing one. For example, when Germany deregulated long-distance bus travel in 2013, it opened a huge opportunity that was previously blocked. Startup founders at FlixBus seized this chance – launching as soon as intercity buses were allowed – and quickly scaled to dominate a brand new market. Similarly, changes like new financial regulations or data privacy laws (think GDPR) often spur a wave of startups addressing the needs or loopholes created by those rules.

2. Technological Shifts: New tech breakthroughs enable products that were not feasible before. A current example is the explosion in artificial intelligence. Advances in AI (especially generative AI) have unlocked use cases from AI coding assistants to AI-generated content. Whenever a technology hits an inflection point (e.g. smartphones in 2007, cloud computing, blockchain, now AI), it’s like new “fast-moving water” enters the river. Founders who jump into those rapids – solving problems with the new tech – can ride that accelerating current. If you suspect a technology is at an exponential takeoff, alarm bells should go off in your head that “something big is happening”.

3. Black Swan Events: Major unexpected events can dramatically reshape markets. The COVID-19 pandemic, for instance, instantly created massive demand for things like remote collaboration tools, telehealth, delivery services, and yes, nasal swabs and test kits. Companies that pivoted or launched to meet these needs often experienced hyper-growth. Likewise, geopolitical upheavals can spawn new markets. A stark example: Russia’s invasion of Ukraine in 2022 spurred many countries to boost defense spending to record levels, “fueling a new generation of startups” in areas like drones, cybersecurity, and defense tech. In fact, European defense startups attracted 50% more VC funding in 2025 than the year before as governments opened their checkbooks. When the world changes overnight, pain points appear that nobody was addressing – fertile ground for entrepreneurial problem-solvers.

Beyond these, there are other shifts and trends to keep on your radar. Demographic or cultural changes (e.g. aging populations, Gen Z consumer behaviors) can gradually open up enormous needs. Macroeconomic shifts or industry disruptions (like a big incumbent failing or a supply chain breakdown) can leave gaps eager to be filled. The key is to continually “read the river” of technology and society – identify where currents are starting to rush. Ask yourself: What’s newly possible that wasn’t before? What sizable problem is suddenly becoming urgent? A great market often starts as a small trickle that turns into a fast-moving stream.

Conclusion: Team + Market = Inevitable PMF?

When evaluating startup ideas, remember that market is the wind in your sails. A capable crew (team) and a sturdy ship (product) are of course needed – but it’s the wind that determines how fast you go. As the saying goes, “a rising tide lifts all boats.” A huge, growing market can carry even an imperfect product to success, whereas in a shrinking market you might not get anywhere despite flawless execution. So put market analysis front and center: hunt for that fast-moving water where demand is strong and accelerating.

This doesn’t mean team and product don’t matter – they do. A great team in a great market is an unstoppable combination, and ultimately you need to craft a product that satisfies customers. But if you start with a fertile market, everything else becomes so much easier. Your users will be more excited, sales cycles shorter, marketing cheaper, investors more willing – you’ll feel momentum rather than constant friction. As NFX’s James Currier advises founders, if you realize you’re “in an eddy” (slow water), have the courage to steer your company into faster currents – even if it means a pivot. No startup ever succeeds without some degree of product-market fit; your job is to increase the odds of finding it by choosing a winning arena to play in.

In summary, market always wins. So when brainstorming your next venture, ask first: Is this market big, growing, and driven by a real change? If yes, you’re already halfway to product-market fit. Get yourself into a market that’s pulling you forward, then iterate like mad. With a bit of persistence (and yes, a bit of luck), a great market will reveal the product you need to build. And when a great team finally meets a great market – well, “something special happens.” 🚀

Sources: The insights above are informed by lessons from successful investors and founders: Andreessen’s guide to product/market fit, Andy Rachleff’s famous startup laws, Jeremy Liew’s data on market vs. execution, James Currier’s “fast-moving water” metaphor and my own startup experiences. Each reinforces the core idea that choosing the right market is the foundation of finding strong PMF. Remember: choose wisely, and may the market be ever in your favor.

Imagine asking an AI to build a feature, write tests, and deploy your code – and it actually does it. This isn’t sci-fi anymore. It’s called agentic engineering, a new approach to software development where AI agents can autonomously perform complex, multi-step tasks. Unlike traditional scripts or assistants that require micromanagement, these agents act with agency – they understand goals, reason through tasks, and use tools to execute actions. In short, they behave like junior developers with superpowers.

What Is Agentic Engineering?

Agentic engineering refers to the design and implementation of autonomous AI agents that can sense, think, and act toward a goal with minimal human input. Rooted in early AI concepts of “intelligent agents,” the term has gained traction with the rise of powerful language models like GPT-4. These models can now not only generate code but also plan actions, analyze results, and adapt on the fly.

The difference between a traditional tool and an agent is initiative. A script runs a fixed routine; an agent figures out what steps are needed based on context and carries them out. In software development, this means agents can do everything from refactoring code across multiple files to debugging, running tests, and deploying applications.

How It Works

Agentic engineering relies on a “sense-think-act” loop:

1. Perceive (Context Engineering): The agent takes in relevant information – codebase, user requests, or system state. Giving the right context is critical to avoid hallucinations and keep the agent focused.

2. Reason (Planning): The agent uses a language model to break down a task, make decisions, and plan next steps. This often involves frameworks like ReAct (Reasoning + Acting) or modular workflows called agentic pipelines.

3. Act (Tool Use): The agent executes commands, edits files, runs tests, or calls APIs. It’s not just generating text but taking real actions – often through tool integrations or sandboxed environments.

4. Evaluate (Feedback Loop): The agent observes outcomes, learns from mistakes, and iterates. For example, if a test fails, it may try a fix and re-run it. This loop allows agents to self-correct and improve reliability.

Cursor: The Agentic IDE

Cursor is one of the clearest examples of agentic engineering in action. Built on VS Code, it goes beyond autocomplete to offer a true coding agent. Users can assign high-level tasks like “refactor the payment logic” or “add authentication,” and the Cursor agent will edit files, create new ones, and reason about the whole codebase.

Cursor’s strength lies in its project awareness. It understands not just the file you’re working on, but the architecture of your entire repo. It can make changes across modules, run tests, and even collaborate with testing agents. Cursor also enables “24/7 agents” – background workers that continue coding or debugging across devices, letting you assign tasks from your phone and review later on your desktop.

One standout feature is its integration with agents like testers.ai, which can auto-generate and run tests. These agents even communicate with each other – e.g., a test agent reports a failure, and the code agent fixes it autonomously. This is the core of what Jason Arbon calls the “agentic engineering loop” – where agents handle development cycles themselves, only escalating to humans when necessary.

Vercel: AI Agents at Scale

Vercel, the company behind Next.js, is also embracing agentic workflows. They’ve introduced an AI SDK for developers to build task-specific agents using language models. These agents can be wired into workflows – for example, optimizing frontend performance, managing deployments, or handling customer support triage.

Vercel’s own agent, v0.dev, takes a user prompt and generates fully working web applications, deploying them automatically. With proper scaffolding and deployment tooling, agents built on Vercel’s platform can manage an entire app lifecycle – from idea to live product.

Importantly, Vercel emphasizes a no-nonsense approach: use deterministic code where possible and reserve AI agents for tasks that benefit from judgment, flexibility, or reasoning. This hybrid approach makes agents safer and more predictable in production environments.

From Assistant to Collaborator

Agentic engineering changes how we think about software development. With AI agents capable of acting as collaborators, the developer’s role evolves from being the primary builder to becoming a reviewer, guide, and architect. It’s no longer about typing lines of code but about curating, testing, and steering an increasingly intelligent machine.

In many ways, this mirrors the shift that happened with high-level programming languages – developers moved up the stack, focusing on logic and systems rather than bits and memory. Now, with agentic AI, we’re moving even higher: developers work through intent and iteration.

The Future Is Multi-Agent

As these systems mature, we’re heading toward multi-agent collaboration. Different agents will specialize: one for coding, one for testing, one for deployment, all coordinating to deliver features or fix issues. Think of it as a virtual engineering team operating under your supervision.

Of course, there are still challenges: agents need better reliability, evaluation metrics, and safety mechanisms. But the trajectory is clear – the next generation of developer tools will be built not just around editing code, but around engineering agents that write, test, and ship it.

The term “10x engineer” has been floating around the tech industry for decades. An almost mythical figure believed to be ten times more productive than their peers. But in 2025, with the rise of AI tools and a shift toward collaborative engineering cultures, it’s time to rethink what being “10x” really means.

The Origins of the 10x Myth

The roots of the 10x engineer concept go back to the 1960s. A seminal 1968 study showed that the best programmers were up to 10 times more productive than the worst. Fred Brooks cited this in The Mythical Man-Month and proposed a “surgical team” model: one rockstar engineer supported by a team of helpers. While not widely adopted, this seeded the myth of the lone coding genius.

Over time, stories of engineering legends like John Carmack and Linus Torvalds reinforced the idea that some developers could do the work of ten. In startup culture, the quest for “10x engineers” became an obsession.

From Productive to Problematic

By the 2010s, the 10x engineer became a controversial term. A now-infamous 2019 Twitter thread tried to define the 10x engineer as a reclusive, meeting-averse code machine who preferred working at night and avoided social interaction. The internet responded with memes and mockery. Most in the industry agreed: if someone delivers value while alienating their team, are they really 10x or just toxic?

Even Gergely Orosz (The Pragmatic Engineer) has warned that some so-called 10x engineers are actually “code sprinters,” “info hoarders,” or “credit stealers”, people whose impact appears big but leaves a trail of unmaintainable code, burned-out teammates, or fragile systems. As he put it, “‘10x developer’ behavior can actually be undetected toxic behavior under a different label.”

What a True 10x Engineer Really Is

The real 10x engineer isn’t a lone wolf, it’s someone who multiplies the effectiveness of the entire team. They’re the kind of person who makes five engineers 2x better by mentoring, sharing knowledge, making smart architectural decisions, and unblocking problems that stall momentum.

Michael Lopp (Rands in Repose) described this archetype as “the Wolf”, a deeply competent individual who moves outside the traditional structure and consistently works on what matters most. They don’t ask for permission. They just deliver results that move the company forward.

In my own view, a 10x engineer is someone who:

• Makes critical architecture decisions that avoid years of future pain

• Spotlights high-impact problems and simplifies solutions

• Helps others level up by mentoring and sharing deep context

• Prevents bad code and poor product decisions before they happen

Their real superpower isn’t writing code faster. It’s raising the bar for everyone around them and making better decisions earlier.

One real-world example: a team struggles with a flaky, high-priority system for months. Then a single experienced engineer takes a few days, gets to the root of the problem, and ships a fix that stabilizes everything. That one action might not be 10x lines of code, but it’s 10x in value.

The 10x Engineer in the Age of AI

AI is changing the game. Tools like GitHub Copilot, ChatGPT, and automated CI/CD systems mean that writing boilerplate code, debugging, or even architecting systems can be partly automated. So what does being 10x mean when AI is your copilot?

Andrew Ng puts it well: “10x engineers don’t write code 10 times faster. Instead, they make architecture decisions that result in dramatically better downstream impact.” In the AI era, the 10x engineer is someone who knows what to build, how to build it efficiently, and when to use AI to shortcut the grunt work.

This doesn’t mean AI replaces engineers. Instead, it elevates those who can orchestrate AI tools effectively. A great engineer might now be:

• 2x faster thanks to AI-assisted coding

• 2x better at identifying high-leverage work

• 2x more impactful by unblocking others faster

That’s your 10x, through smart leverage, not raw output.

A Shift in What We Value

We’re entering an era where being a 10x engineer is less about velocity and more about multiplier effects. The best engineers are those who:

• Reduce the risk of future technical debt

• Unify the team around a clear technical vision

• Drive simplicity over complexity

• Make high-quality decisions faster than others

In short, they aren’t just engineers. They’re accelerators, people who leave their entire environment better than they found it.

Conclusion

The 10x engineer of the past was a mythical coder who single-handedly built empires. But in today’s world and especially in the age of AI the most valuable engineers are the ones who lift others, simplify decisions, and guide teams toward impact. They are humble, collaborative, and deeply technical but also strategic, communicative, and proactive.

You won’t find them working solo at 3 a.m. in the dark corner of the office. You’ll find them in code reviews, pairing with juniors, designing resilient systems, and showing up to the hard conversations. They’re not just building software. They’re building leverage.

And that’s what makes them truly 10x.

In 2025, the rules for hiring software engineers have been rewritten. With AI coding assistants capable of generating production-ready code in minutes, the traditional interview toolkit – take-home assignments, whiteboard algorithms, remote coding quizzes – is increasingly irrelevant. If your hiring process still tests raw coding skills in isolation, you’re already behind. The real differentiators now are the human skills: collaboration, communication, and the ability to guide both teams and AI tools toward solving real problems.

Take-Home Assignments Are Dead

Take-home projects once filtered good candidates from bad. Now, anyone can feed a prompt to Cursor, Codex or Claude Code and get a solid solution in minutes. Some managers admit their main goal is now to verify “the code you wrote is your code.” Tools like Cluely even allow candidates to cheat live during video interviews by providing hidden AI suggestions in real-time. This makes remote algorithm challenges and homework tasks poor indicators of actual skill.

AI Writes Code; Humans Solve Problems

As coding itself becomes commoditized, what matters is the thinking around the code: breaking down complex problems, translating vague requirements into actionable solutions, and communicating with teammates and stakeholders. As one CTO put it, “We used to hire people who could code; now we hire people who can think, then use AI to code their thoughts.”

This shift also elevates so-called “soft” skills, which are now mission-critical. Can a candidate talk to users, understand customer pain points, and collaborate across functions? These are the abilities that separate strong engineers from AI-assisted coders. A developer who can wield AI tools effectively – checking, refining, and steering their output – is infinitely more valuable than someone who can only write code from scratch.

The Only Real Test: Work With Them

If quizzes and take-homes can be gamed, how can you tell who’s the real deal? The answer is simple: collaborate in real-time. Invite candidates into the office for a half-day or full-day pairing session. Work with them on a real (or close-to-real) task and observe how they approach problems, communicate their thinking, and adapt to changing requirements.

Pair programming interviews are nothing new, but in the age of AI, they’re becoming the gold standard. You’ll learn more from a few hours of side-by-side collaboration than from a week of back-and-forth assignments. Pivotal Labs famously used this model years ago, pairing candidates with engineers to gauge teamwork and problem-solving. In 2025, this isn’t just a “nice-to-have” – it’s essential.

Embrace AI During Interviews

Banning AI in an interview is unrealistic. If candidates will use AI on the job, why not let them use it during the interview? The point isn’t to see if they can recall syntax, but to see how well they can guide AI tools, debug their suggestions, and use them to speed up meaningful work. Observing a candidate interact with AI reveals their thought process and judgment – qualities no take-home test can measure.

Many forward-thinking companies now encourage candidates to use AI coding tools during live coding sessions. This mirrors real workflows and highlights the skills that matter: clear prompting, critical evaluation of AI output, and creative problem-solving.

References Matter More Than Ever

In a world where candidates can “fake” a lot of coding skill with AI, references are becoming the ultimate truth serum. Don’t just collect reference names as a formality. Call former teammates and managers. Ask tough questions: Would they hire this person again? How did they handle ambiguous or high-pressure situations? A few honest conversations with past colleagues will tell you more than any algorithm puzzle.

How Top Companies Are Adapting

Top tech companies like Stripe and Airbnb are already shifting toward real-world, collaborative assessments. Their interview processes emphasize system design, communication, and high-level problem-solving over whiteboard tricks. OpenAI reportedly encourages candidates to use coding assistants during interviews – reflecting the reality of how modern engineers work. These companies recognize that hiring for the ability to think, adapt, and lead is more valuable than hiring for raw coding speed.

The New Hiring Playbook

To interview engineering candidates in 2025, ditch the outdated rituals. Focus on:

• Collaboration over coding tests: See how they work with your team in realistic scenarios.

• AI fluency: Let them use AI tools and observe how they leverage them.

• Human skills: Evaluate communication, adaptability, and problem-solving under real-world constraints.

• Reference checks: Validate their track record with former managers and colleagues.

The Bottom Line

Engineering interviews are no longer about who can manually solve a binary tree problem fastest. AI can do that for anyone. What matters now is who can think critically, collaborate effectively, and use AI as a powerful amplifier. If you’re still hiring like it’s 2015, you’ll miss out on the best talent – the ones who see coding as just one piece of a much larger puzzle. In 2025, the strongest engineering teams will be built by leaders who recognize that interviews must simulate the real job: working with humans (and AI) to build something great together.

Many engineers dream of launching their own startup, envisioning that their technical brilliance will naturally lead to a great product and a successful company. In reality, the transition from being a software engineer to being a founder is a massive shift in role and mindset. It’s not just about writing code or building features anymore – it becomes about building a business. The skills that made you a great engineer (attention to detail, focus on perfection, deep technical focus) aren’t the only ones you need now. Instead, you must learn to scale yourself through others, iterate quickly with imperfect solutions, focus on customers and sales, and survive an emotional rollercoaster. This essay explores key lessons for technical folks making the leap to founder, drawing on startup wisdom from books, blogs, and my own founder experiences.

Building a Team: From Solo Coder to Leader

As an engineer, you’re used to solving problems yourself. But as a founder, you won’t scale if you try to do everything alone. Your time and energy are finite, and coding 100 hours a week isn’t a sustainable strategy to grow a company. Success comes from assembling a team and empowering others to build with you. This means your people-management and leadership skills suddenly become as important as your coding skills. In fact, once your startup grows, “your main role as founder will be of strategic and tactical decision-making combined with communication and people management skills”. In other words, you move from being a builder to being a leader of builders.

One of the most important abilities to cultivate is effective delegation. Great founders learn to hire smart people and trust them with critical tasks. Delegation is often cited as an “undervalued skill for founders” because it helps you scale your business and maximize output. You simply cannot micromanage every line of code or every decision once your team grows. As one startup coach aptly put it, “Founders thrive when they lead, not micromanage!”. By delegating responsibilities, you free yourself to focus on higher-level strategy and preventing bottlenecks. It also means setting clear vision and culture for your team. Building a strong team and startup culture early on will multiply your effectiveness far beyond what you could ever achieve coding solo.

Speed Over Perfection — Embracing Scrappy Execution

Another big shift for engineers-turned-founders is breaking the habit of perfectionism. In software engineering, we’re trained to avoid bugs, write tests, and refine features until they’re “just right.” In a startup, however, speed of learning beats polish. You have to build scrappy and fast to get a minimum viable product into users’ hands and start gathering feedback. Chasing a perfect product can actually kill your startup – if you spend too long in development, you risk building something no one wants, or missing the market window.

Reid Hoffman (LinkedIn’s founder) famously said, “If you are not embarrassed by the first version of your product, you’ve launched too late.” This isn’t an encouragement to write bad code, but a reminder that getting your product out quickly is crucial. Early on, no one will remember if your v1 was a bit rough around the edges; “they’ll only remember if your product created value for them”. By shipping sooner, you can learn sooner. As the Baremetrics startup academy notes, “By shipping as fast as possible you’re able to find out as soon as possible how to best serve your market. Stop trying to attain the perfect product.”. In practice, this means favoring quick iterative development and rapid prototypes over exhaustive refinement. Write just enough code to test your idea with real users and adapt. It may feel uncomfortable for an engineer used to elegant solutions, but done is better than perfect in the startup world.

Crucially, this scrappy approach must still focus on solving a real user problem. Shipping something buggy for its own sake helps no one. The point is to prioritize user feedback and learning over internal code ideals. As one technical founder reflected after struggling initially, he had obsessed over performance and completeness, “trying to improve things that didn’t need improving,” when in reality, “why make it [super fast or polished] if it doesn’t even solve the problem?”. The lesson: Build the simplest version that delivers value and test it in the real world. Your engineering instincts might cringe at foregoing unit tests or using duct-tape solutions, but in a startup the ultimate test is the market. Iterate based on user responses; you can always refactor or optimize later once you’re sure you’re building the right thing.

Focus on Sales and Customers, Not Just Code

Perhaps the hardest lesson for technical founders is that a startup is not just a product, it’s a business. Writing great code is important, but code alone does not make a company. You need users, revenue, and a viable business model. Engineers often fall in love with their solution and assume customers will magically appear. This “build it and they will come” mentality is a classic mistake. In reality, you’ll be extremely lucky if users just show up. More often, a technical founder spends far too much time building versus talking to users, looking for early adopters. Customer development – talking to users, understanding their needs, and actively marketing your product – is just as vital as building the product itself.

In fact, many engineer-founders realize too late that the only thing that really matters is having customers who want what you built (and ideally paying for it). You can build the most perfect product, but if there are no users or no sales, it doesn’t matter. This truth hits hard. As startup investor Graham Wood notes, “it doesn’t matter how good your product specs are; if you are not focused on sales, marketing and business strategy, then you won’t get off the runway.” In other words, no customers = no business. Technical prowess alone can’t save a startup that doesn’t address a market need. This is why many successful startups insist on “business model over product” when evaluating ideas, ensuring there’s real demand behind the technology.

To embrace this lesson, shift your obsession from the technology to the customer’s problem. One experienced founder put it bluntly: “Stop being obsessed about tech; be obsessed about the customer and their problems.” All the features and optimizations in the world mean nothing if they don’t solve a pain point for someone. Instead of adding “cool” features, spend time talking to users, gathering feedback, and even doing sales – activities that might be outside your comfort zone. Jens Neuse, a technical founder, admitted that for a long time he “sucked as a technical founder” because he kept coding endlessly and was “forgetting the most important thing: Building a business!”. He only gained traction when he started blogging, marketing, and listening to what customers wanted – in his case, landing a first paying client by building features that client needed. The takeaway for technical folks is clear: your startup succeeds not when the code is perfect, but when you’ve created value that people will pay for. That means learning to sell – whether that’s selling your vision to customers, investors, or future employees. If selling isn’t your forte, find a co-founder or mentor to help, but don’t ignore it. In a startup, engineering and sales are two sides of the same coin – you need both to win.

The Emotional Rollercoaster: Loneliness and Reward

Finally, it’s important to recognize the emotional challenges of being a founder. Starting a company can be intensely lonely and difficult – a far cry from the steady routine of an engineering job. You bear the ultimate responsibility for every decision and outcome. There will be extreme highs and lows, and stress that few others around you truly understand. Many founders later confess that had they known how hard it would be, they might never have started. The journey often involves long hours, uncertainty, and tough trade-offs that can take a toll on your mental health. Founders can’t openly vent to employees or investors when they feel doubt, and that isolation adds to the burden.

One aspect rarely talked about is just how isolating the founder role can feel. You may be working with a team, but as the founder you’re the only one who sees the full picture of the business’s problems and fears. Startup founder loneliness isn’t just common, it’s baked into the role. Even successful founders have acknowledged this. Airbnb’s founder Brian Chesky admitted, “No one told me how lonely it would be.”. There is often a sense that you can’t fully share your worries with others – you don’t want to panic your team, bore your friends, or disappoint investors. This can lead founders to bottle up stress, which only increases the sense of loneliness and pressure. It’s important to be aware of this dynamic and find healthy outlets – whether it’s connecting with other founder peers, seeking mentors or coaches, or being honest with a co-founder – to avoid burnout.

And yet, despite all these hardships, being a founder can also be incredibly gratifying. You’re creating something from nothing, building a product and a company that is your vision. The sense of ownership and accomplishment when things go right is unlike any other job. Many founders describe it as a personal growth journey with immense rewards on the other side. “Every successful person started with 0 users and 0 revenue,” as one startup mentor reminded – the difference is they kept going despite the hardships. Those who persevere often find that the struggle was worth it. In the words of Anish Dhar, an engineer-turned-founder, starting a company is “truly one of the most gratifying and impactful experiences that you can have. It’s painful, but it’s worth it!”. Bringing an idea to life and seeing it help real customers can give a profound sense of purpose and pride. You’ll have moments of triumph – landing that first big customer, hitting a milestone, seeing your team gel – that make the sleepless nights and stress fade away. In the end, most founders say they wouldn’t trade the experience for anything, because successfully building a startup is not only a financial or career achievement, it’s a deeply personal victory.

Key Takeaways for Aspiring Technical Founders

• You can’t do it all alone – build a team and lead it. Your coding skills won’t scale without delegation. Strong people management and communication skills will define your success. Learn to trust your team and empower others instead of micromanaging. As one expert notes, effective delegation “helps you scale your business” and prevents burnout.

• Done is better than perfect in a startup. Don’t waste months polishing code that might change completely. Launch early, iterate fast, and let user feedback guide you. Remember Reid Hoffman’s rule: “If you’re not embarrassed by v1, you launched too late.” Speed of learning is your competitive advantage – use it.

• Customers and sales come first, not the code. A startup lives or dies by whether it solves a real problem that people will pay for. Spend at least as much time on customer development and sales as on coding. No product succeeds in a vacuum. If you are not focused on sales, marketing and business strategy, your product – no matter how brilliant – “won’t get off the runway.” In short, build a business, not just a product.

• Brace for an emotional journey – it’s hard but worth it. Founding a company will test you in ways a normal job might not. Expect loneliness, stress, and doubt, especially in the early days. Many founders say that if they had known the difficulty upfront, they might not have started. Yet those who persist also call it the most rewarding decision of their lives. It’s “painful, but it’s worth it!”. The pride of creating something from nothing and steering it to success can be unparalleled.

By keeping these lessons in mind, technical entrepreneurs can better prepare for the leap into founding a startup. The transition from engineer to founder is not easy, but with the right mindset changes – from solo coder to team leader, from perfectionist to pragmatist, from builder to seller – you dramatically increase your odds of turning your technical idea into a thriving company. Embrace the challenges as part of the journey. In the end, you’ll not only have built a product, but also grown into a well-rounded entrepreneur who can truly bring ideas to life.

Good luck on your startup adventure!

Startups are defined by speed. Moving quickly, shipping features, testing hypotheses, chasing product-market fit often determines who wins and who fades away. Yet there’s a tension every technical founder knows too well: the faster you move, the more shortcuts you take. Those shortcuts accumulate as technical debt, and at some point, the interest comes due. The question is not whether to incur technical debt but how to manage it without crippling your ability to innovate.

Martin Fowler, who popularized the concept, describes technical debt as the “deficiencies in internal quality that make it harder than it should be to modify and extend the system.” Like financial debt, it’s not inherently bad. A little debt, strategically taken on, can accelerate progress. But when left unchecked, it compounds, slowing development and frustrating teams.

The Nature of Technical Debt

Ward Cunningham originally coined the term to explain why developers sometimes deliberately take shortcuts. Think of launching a minimal feature in days rather than weeks, knowing you’ll refactor once you get user feedback. In this scenario, debt is a conscious choice, an investment in speed. But when teams cut corners without realizing it or simply ignore the need for cleanup, the debt becomes reckless. Fowler’s Technical Debt Quadrant captures this distinction: prudent vs. reckless and deliberate vs. inadvertent. The healthiest startups lean toward the prudent-deliberate quadrant where shortcuts are intentional, temporary, and carefully monitored.

The danger comes when founders confuse speed with sustained velocity. Quick-and-dirty code feels fast in the moment, but as complexity grows, every change slows. Fowler’s Design Stamina Hypothesis illustrates this perfectly: without care, a codebase that was initially faster to build becomes slower to evolve, while a well-structured codebase steadily outpaces it over time.

When “Just Ship It” Is the Right Move

There are moments when “just ship it” is exactly the right call. Early-stage startups, for example, should prioritize learning over elegance. It makes no sense to spend months perfecting an architecture if you’re still validating whether anyone wants the product. In this phase, technical debt can be a strategic enabler. What matters is speed of learning & iteration.

There are also short-term situations where speed trumps quality: a critical investor demo, a competitive feature race, or a time-sensitive market opportunity. In these cases, taking on debt knowingly, with a clear plan to repay it, is often the pragmatic choice. A prototype that proves a concept can be worth the mess it leaves behind, provided you rebuild when the time is right.

The principle here is intentionality. Debt taken on knowingly, for a purpose, is rarely dangerous. It becomes toxic when teams pretend it doesn’t exist or continuously defer repayment.

When Refactoring Becomes Essential

On the other side of the spectrum, there are times when slowing down to refactor isn’t just wise but necessary. One clear signal is declining velocity. If adding a small feature takes weeks because the codebase is fragile, you’re paying high interest on your debt every day. Another warning sign is quality issues affecting users—frequent bugs, crashes, or performance issues that undermine trust.

There’s also a human cost. Developers hate working in a codebase that feels like a minefield. Morale suffers, and talented engineers may leave. Lou Franco, writing in The Pragmatic Engineer, reflects on the mistake of ignoring technical debt early in his career: focusing solely on features, he found, slowed his team in the long run and cost them productivity. Addressing debt like reducing build times or cleaning up core modules had immediate, positive impacts on speed.

Finally, if your roadmap includes major new features or scaling efforts, building on top of shaky foundations can be disastrous. Taking the time to stabilize your architecture before growth can save months of headaches down the line.

Finding the Balance

The reality is that startups can’t afford to eliminate technical debt entirely, nor can they ignore it. The right approach is a balance of deliberate borrowing and timely repayment.

A few principles help:

• Make debt visible. Track major debt items alongside features and bugs, noting the “interest” they incur: slower builds, recurring bugs, developer frustration.

• Refactor incrementally. Small improvements, done continuously, often yield big results over time. Follow the Boy Scout Rule: leave the code better than you found it.

• Bundle improvements with features. If you’re working in a messy area of the code, clean it while building the new feature. It’s usually cheaper than doing it later.

• Avoid perfectionism. Some debt is harmless. Refactor what slows you down, ignore what doesn’t. Premature optimization can be as damaging as ignoring debt entirely.

Pragmatic founders and engineers see technical debt as a trade-off. A healthy codebase isn’t one with zero debt, but one where debt is managed, intentional, and doesn’t cripple the team’s ability to ship.

A Founder’s Perspective

So how do you decide: refactor or ship? Ask yourself:

• Is this feature critical right now?

• How much future slowdown will this debt cause?

• Is the team already struggling to deliver because of existing debt?

• Will ignoring this debt hurt users or stability?

If the answers lean toward long-term pain, it’s time to refactor. If speed and feedback are paramount, ship now but schedule time to pay off the debt. The worst decision is pretending you can do both indefinitely.

Conclusion

For startups, technical debt vs. product speed isn’t a binary choice. It’s a dynamic balance that shifts as your company grows. Early on, speed is everything, but as you scale, sustained velocity requires investment in quality.

Think of technical debt as a tool, not a flaw. Borrow when necessary, pay it back when interest rates climb, and always keep your eye on the bigger goal: delivering value to customers without grinding your team to a halt.

Ship fast when you must. Refactor when you should. Manage technical debt like you manage cash flow - intentionally and strategically.

In the past, building software products was a clear division of labor. Product managers defined what to build, designers shaped how it looked, and engineers implemented the plan. Over time, this model has evolved. Startups and high-growth companies realized that the best products are often built by teams where engineers deeply understand the “why” behind their work – the user needs, business goals, and trade-offs. This mindset has led to the rise of product engineering, a role that blends the builder’s skill set of a software engineer with the product intuition of a manager.

What Is Product Engineering?

A product engineer is still a software engineer at heart, but one who takes ownership of the outcome, not just the code. Instead of waiting for a spec, they ask:

• “What problem are we solving for the user?”

• “Is this the right solution?”

Product engineers talk to users, analyze metrics, and iterate quickly based on feedback. They bridge the gap between execution and strategy, ensuring that features are not only well-built but also meaningful. As Michael Lopp (Rands in Repose) notes, “The product engineer role expands to include all the responsibilities of the Product Manager (and a little bit of Design).”

What Makes a Good Product Manager?

To understand product engineering, it helps to revisit product management. A great PM is often described as the “CEO of the product” – not because they hold power over everyone, but because they own the vision, priorities, and success metrics. As Elad Gil writes in High Growth Handbook, the best PMs:

• Clearly define what success looks like.

• Ruthlessly prioritize what matters most to users.

• Communicate effectively across engineering, design, and leadership.

• Have deep user empathy and a willingness to say “no” to distractions.

Where product managers coordinate and set direction, product engineers step into this space on a smaller scale, making product decisions in real time while building.

How Product Engineering Differs

Compared to traditional software engineering, product engineers:

• Care as much about why they are building something as how they build it.

• Propose ideas, challenge assumptions, and adjust features based on data or feedback.

• Take responsibility for whether a feature actually solves a user’s problem, rather than just delivering working code.

Compared to product management, product engineers are makers. They combine strategic thinking with the ability to ship fast, prototype, and iterate without long hand-offs. On small teams, a strong product engineer can cover much of the product function, accelerating development.

Why Has Product Engineering Become Popular?

There are a few reasons why this hybrid role is trending:

• Speed: Startups need to move fast. Product engineers reduce the time lost in back-and-forth with PMs.

• Ownership: Teams with engineers who understand the user tend to build better products.

• Modern tooling: Analytics, feature flags, and user feedback tools are now accessible to engineers directly.

• Evolving expectations: Many engineers want to have a say in what they build, not just how.

Companies like Shopify, Atlassian, and Mixpanel have credited product engineers as critical drivers of product success. These engineers act almost like mini-founders within their teams, balancing user experience with technical feasibility.

The Future of Product Engineering

Product engineering is not about eliminating PMs but about creating product-minded engineering teams. Even in organizations with dedicated PMs, engineers who think like product engineers are more valuable: they ship faster, challenge assumptions, and help create products that truly resonate with users.

For software engineers, this trend is an opportunity. Cultivating product sense – understanding user needs, experimenting, and focusing on outcomes – can be a career superpower. In the modern tech world, success isn’t just about writing clean code; it’s about solving real problems.

Letting go of a team member is one of the hardest decisions an engineering leader can face. But keeping someone who underperforms or misaligns with your team can drag down morale, quality, and trust. This article gives you a practical, no-nonsense guide — backed by engineering leaders like Gergely Orosz and Michael Lopp (Rands) — to help you recognize the signs, do your due diligence, and handle the process fairly.

Spotting the Warning Signs

Watch for red flags across delivery, behavior, and cultural alignment. For example, delivery problems might include chronic missed deadlines, incomplete features or constantly buggy code. In Gergely Orosz’s terminology, a “low performer” is someone doing “less or poorer quality work than expected” – essentially coasting or lacking key skills. On the behavior side, look for repeated conflicts, insubordination, or a defensive attitude. Someone who ignores feedback, complains constantly, or undermines teammates can sap morale. Finally, a cultural misfit might breach core values or norms – for instance, repeatedly disregarding team agreements, showing a lack of integrity, or blatantly disrespecting inclusivity or rules. As Ron Koerth points out, keeping a misfit on the team sets a bad example and drags morale down and can poison the whole team feeling. In fact, when high performers see a coasting colleague tolerated, they often become frustrated or start looking elsewhere.

Consider these common symptoms:

• Delivery gaps: Constantly missing goals or generating poor-quality output (e.g. frequent bugs, incomplete pull requests).

• Behavioral issues: Chronic negativity, lack of collaboration, or blatant rule-breaking. Note if peers begin to avoid collaborating or bring up concerns – a good manager’s “sixth sense” often feels when “the team is off”

• Culture/fit problems: Values conflicts that can’t be overlooked (e.g. harassment, dishonesty, or consistent disrespect of team practices).

If you see multiple such signals persisting over time, it’s a strong cue that something deeper is wrong.

Manager’s Checklist Before Deciding

Before deciding on letting someone go, go through a structured checklist to ensure you’ve given every realistic chance to improve:

• Clear expectations: Have you defined the employee’s responsibilities and success criteria explicitly? Rands (Michael Lopp) emphasizes documenting exactly “what success looks like” and reviewing it with the employee. If expectations were vague or moving, you must fix that before proceeding.

• Regular feedback and conversations: Have you raised the issue early and often? Rands famously asks managers: “Have you had multiple face-to-face conversations over multiple months… where you have clearly explained and agreed there is a gap in performance?”. In other words, don’t bring up a PIP out of the blue. Instead, hold at least three substantive, in-person discussions spanning several months. Make each session a two-way dialogue: explain the problems clearly (ideally in writing first) and ask the employee to repeat back their understanding. Only if they really disagree with your assessment after this should you consider parting ways.

• Specific, documented feedback: Have you provided concrete examples of the problems? A common mistake in bad performance reviews is “zero specifics”. For each issue (missed deliverable, problematic incident, etc.), document exactly what happened, why it mattered, and what needed to change. This isn’t about catching someone in a mistake – it’s about giving them actionable data. When you present feedback, do it in a neutral, coaching tone, not a punitive one.

• Support and remediation efforts: Have you offered training, mentoring or re-alignment? If the root cause is skill-related, the manager should have given opportunities to improve. For example, if the tech stack changed or the role shifted, did you re-train the employee? Rands notes that deep changes in performance require months and repeated coaching. Likewise, Gergely Orosz advises that if the person is willing to train up, “in most cases it will pay to invest in them”. Ensure you’ve genuinely given this support before concluding they can’t improve.

• Realistic expectations: Were the goals fair? Sometimes we unintentionally oversell roles. If the employee was hired with over-ambitious promises or if the role has outgrown their skill set, consider whether adjusting the scope or deadline could help. If the bar truly is too high, no one can fairly meet it – but if the expectations were reasonable and unchanged, then lack of progress falls on the employee.

• Team impact: Have other teammates complained or rallied to help? If you sense that other engineers are now doing extra work or are frustrated that someone else isn’t pulling their weight, that’s a significant signal. High performers won’t stick around forever if they feel they’re carrying slackers. On the other side, if you find that only one outlier is struggling while the rest thrive, investigate why that person is so different – that insight helps you decide if they belong on this team.

• Time and closure: Have you really waited long enough? As Rands emphasizes, coaching performance often takes multiple months and iterations. If you’ve already spent a quarter or more trying to fix the issues, and nothing has changed despite the above efforts, it’s reasonable to start moving toward closure.

Use this checklist as a reality-check. If any of the above boxes haven’t been ticked, pause and address the gap. Only after honest, documented attempts should “let it go” enter the conversation.

Growth Potential vs. Misfit

Not every struggling engineer should be immediately offboarded. The key question is “Can this person improve with support?” or are they fundamentally not a fit?

Begin with empathy and curiosity. Assume good intent: as Matthew Spence puts it, “the overwhelming majority of people want to be good at their jobs”. Often underperformance has external causes: mismatched tasks, personal stress or problems e.g. their relationship, burnout, or unclear goals. Ask diagnostic questions: Are they getting the support they need? Is their work aligned with their core skills? Do they understand the company vision and see how their work matters? Have they simply run a bad cycle or are on the verge of burnout? Pinpointing the real cause is critical – Spence notes “identifying the true underlying cause is usually the hardest part”.

If the problem seems like a skill gap or role mismatch (they haven’t learned a new tech, or the team’s needs shifted), check their willingness to adapt. If they are eager to train up, it’s often worth investing more time. You might even try moving them to a different project or mentor, as suggested in Spence’s “Before you fire them” advice. Sometimes a fresh context or leader can rekindle motivation.

In contrast, if the core issue is cultural or values misalignment – for example, they clash with the team’s work ethic or violate trust repeatedly – then there’s a lower ceiling for improvement. Orosz explains that a company’s culture “can be flexible up to a point”, but if an individual consistently can’t meet the team’s standards, “they aren’t a good fit”. In those cases, no amount of skill training will fix the problem. Similarly, if after coaching they show no accountability (deny any gap, blame others, refuse to take feedback), it’s a sign their willingness to grow is lacking.

Quick growth-vs-misfit check:

• Does the engineer acknowledge the feedback and actively work on it? (Good sign.)

• Have they made any progress on smaller goals?

• Do they volunteer for new challenges or only default to complaints?

• Is the performance gap only in advanced skills, or does it touch on attitude and ethics?

If answers lean toward “yes, they own it” and “we can fix this”, continue coaching. If answers look like “it’s everyone else’s fault” or “I won’t change”, that points to a misfit.

Fair, Empathetic Offboarding

If you’ve run the checklist and still see no way forward, it’s time for a respectful offboarding process. Handle it with clarity and compassion:

• Prepare and involve HR: Before the meeting, ensure all documentation (goals, feedback logs, conversations) is in order. Follow your company’s policies for performance offboarding, and get HR or legal advice on severance and any obligations.

• Be clear but kind in the conversation: Schedule a private, face-to-face (or video) meeting. Explain the decision factually: point to the documented gaps and the attempts made to help. Avoid surprises – the employee should already have been aware via your ongoing discussions. Speak in a coaching tone, not a punitive one. Act like a coach even in this hard talk: give them information and closure, not a lecture. Use compassionate language (“I’m sorry this wasn’t the right fit” rather than “you failed to perform”).

• Maintain dignity and empathy: Listen to their questions and answer honestly but respectfully. It’s normal for people to react with shock or sadness – they may feel blindsided even if you think the signs were clear. Keep the tone factual and calm. Don’t say anything personal or blameful. Acknowledge any positives (“You did well on X and Y; we really tried to find a path forward”) to avoid making it entirely negative.

• Handle team communication carefully: After the departure, you’ll need to say something to the rest of the team, but keep details minimal. As Koerth advises, keep the reasons confidential and express general continuity. For example, “Alex has decided to move on; we’re working through the transition.” Speculating or giving too much detail will breed rumors or resentment. Employees respect honesty, but they trust management only if they feel it was done fairly. If your team trusts your process, they won’t jump to conclusions that you were unfair. Never badmouth the departed person to anyone – that erodes trust in you.

• Close with support: Whenever possible, help the person leave on as positive a note as circumstances allow. Offer a reasonable severance package, outplacement support, or references if warranted. Gergely Orosz and others have emphasized treating people humanely during layoffs and cuts – it protects morale and your company’s reputation. Even after letting them go, you want to be able to say “We wish them well”.

In every step, fairness and consistency are key. If you hold this person to a standard different from everyone else, you’ll lose the trust of your remaining team. By contrast, when you communicate and act clearly, empathetically, and professionally, the rest of the group knows that everyone’s being treated by the same rules. That clarity and respect go a long way toward ending a difficult chapter and letting the team move forward stronger.

Conclusion

No manager or founder enjoys letting someone go, but sometimes it’s necessary to keep the team healthy. Watch for persistent shortfalls in delivery, toxic or uncoachable behavior, and misalignment with your values. Before cutting ties, run through a frank checklist: have clear expectations, documented feedback over months, and real support in place. Distinguish fixable skill gaps or temporary slumps (where training or a new role might help) from fundamental mismatches in attitude or mission. If you decide offboarding is the only fair outcome, do it cleanly: honest yet compassionate communication, consistent treatment, and a coach-like demeanor throughout.

In sum, the goal is to be thorough and humane: make sure you’ve truly tried to help, and then carry out the process in a way that respects everyone. By doing so, you keep standards high, preserve team morale, and uphold the values your organization depends on. It’s never easy, but when handled well it’s the responsible thing for the health of the product, the team, and the person in question.

The very first team members of a startup literally write its culture. As Stripe’s founder notes, “the initial employees have a fundamental role in shaping the company culture. Their behaviour, work ethic and interactions establish the norms and values that will define the organisation’s character”. Every communication style, habit and attitude of those first hires become the benchmark for future hires. In practical terms, early team members become the company’s first managers and customer-facing ambassadors, setting unspoken rules on how problems are solved and success is pursued. Smart founders take this seriously: as one startup leader puts it, “your first ten employees don’t just do the work – they define how decisions get made, how people communicate and how the team handles pressure.”. In short, your first ten hires are the DNA of the company.

Because early hires set the tone for everything – from speed of execution to work habits – founders must hire for attitude as much as skill. One entrepreneur sums it up bluntly: Hire missionaries, not mercenaries. That means looking for people passionate about the problem and willing to own outcomes – not just clock-watchers or resume hunters. Big-brand pedigree often doesn’t predict startup success. In fact, many experts warn that “success at a large company doesn’t predict success in a startup environment”. Early-stage startups need scrappy generalists who can create order from chaos, not specialists who rely on established processes. In practice, this means don’t build your startup team by chasing famous names. Instead, hire people who have an entrepreneurial “agency”: those who act like owners, take initiative without being told, and thrive in uncertainty.

In practical terms, a winning profile for the first ten hires often looks like a blend of agency, adaptability, and relentless drive. Founders should favor candidates who solve problems without permission, don’t need to be told what to do and can zoom in and out at will. These are the folks who treat the company’s mission as their own. As Brian Fink writes, the ideal early hire has hard skills that map to real outcomes (coding, selling, designing, etc.) and soft skills that scream ownership – clear communication, initiative, and decisiveness. In short, look for founder DNA: people who think like founders, not employees – who lose sleep over big problems and celebrate the company’s wins as if they were their own.

• Entrepreneurial mindset: Early hires must feel like co-founders. They should approach work by asking, “How will I move the business forward?” as one founder recommends. Candidates who immediately jump to strategize improvements will naturally take ownership of their roles.

• Adaptability over titles: Young companies are messy. Founders should prefer candidates comfortable with change and ambiguity. As one YC startup blog puts it, in the early team you should “optimize for ability to get things done, not any specific experience”. Technical chops are great, but what really matters is flexibility: hires willing to wear multiple hats and pivot as needed. In practice, this often means shunning over-specialized hires; the best early team members become T-shaped, combining deep expertise in one area with a readiness to help everywhere else.

• Relentless ownership: A startup founder says the #1 requirement for success is to “never stop” – a determination that outpaces any normal 9–5 schedule. In a growing startup, no team member should be thinking “clock-out at 5pm”. Instead, early employees should be those who willingly go the extra mile – fixing things late at night or on weekends because they care.

• Values and culture fit: Technical skills can be taught; values and work ethic cannot. Many successful founders deliberately hire younger employees with aligned values because “competence can be acquired, but the character they bring is far harder to replicate”. It’s better to have a team that shares the same mission-driven ethos – even if they need mentoring – than highly experienced hires who aren’t aligned with the startup’s all-in hustle. Building a startup with strict “9-to-5ers” who leave at 5pm sharp is a recipe for trouble.

Another key principle: Balance seniors and juniors. On one hand, you want some seasoned hires – people who have scaled companies before and can prevent catastrophic mistakes. On the other hand, you need scrappy juniors who are hungry to learn and willing to put in the grind. Startups often succeed by mixing the battle-tested judgment of a few veterans with the energy and malleability of younger employees. Fresh graduates or early-career hires might lack experience, but they bring fresh ideas and stamina. Veterans, meanwhile, provide mentorship and strategic oversight. The exact mix varies by startup, but a good rule of thumb is: hire enough experience to avoid obvious pitfalls, then fill the rest of the roster with tenacious builders. As Lenny Rachitsky found, most startups hire engineers first, but they also often hire domain experts or support people early on to complement the founders’ skills.

Above all, early hiring should prioritize mission and trajectory over prestige. Avoid hiring for cachet, for example, someone because they “were at Google”. Such hires often struggle without the big-company support they’re used to. Instead, look for candidates who demonstrate they’ll grow with your startup. The right early hire not only contributes immediately, but raises the bar for everyone else. They set a “benchmark” that future hires are measured against.

In summary, your first ten team members should be mission-driven, adaptable builders who share your startup’s values and aren’t afraid of hard work. They should have either a founder’s mindset or a burning entrepreneurial itch – people who wanted to start their own company and still think like one. Mix in a handful of experienced leaders for guidance, but fill the ranks with versatile juniors ready to hustle. Always remember: early employees do more than fill roles – they create your startup’s culture and momentum. Hire wisely, and you’ll have a founding team that can conquer long odds. Hire poorly, and even great ideas can stall.

Early-stage founders (an especially technical founders) often rush to build. A better approach is the Lean Startup mindset: treat your idea like a hypothesis to test. Build just enough (a landing page, explainer video or service offering) to learn if real customers care. Eric Ries himself defines an MVP as “that version of a new product that allows a team to collect the maximum amount of validated learning about customers with the least effort.” In practice this means spending time on customer discovery and quick experiments instead of premature development.

Talk to (Potential) Customers First

Start by interviewing people who face the problem you want to solve. Ask open-ended questions about their needs, not “Would you use my product?”（the Mom Test approach). For example, ask “How do you solve X today? Can you describe the last time you had that problem?” Frameworks like Lean Market Validation explicitly include “Conduct Customer Validation Interviews” as a key step. Through conversations you’ll uncover real pain points, budgets and workflows – often far different from your assumptions. Don’t lead people to praise your idea; get to the truth.

Do: Listen for problems, past behavior, and potential commitments.

Don’t: Pitch your solution or ask hypothetical “yes/no” questions. (Rob Fitzpatrick’s The Mom Test is a good guide.)

• Focus on the problem, not your solution. (Ask how they currently cope with the issue.)

• Find evidence of true need (budget, frequency, inefficiencies).

• Seek a commitment: e.g. ask if they’d sign up for early access or pay.

Smoke Tests: Landing Pages, Ads & Pre-sales

Next, validate demand with simple experiments. One common technique is a Landing Page MVP: create a website that sells your future product (features, pricing, sign-up form) and drive traffic to it. Track how many visitors click “Buy” or submit their email. This is even easier today with no-code tools or site builders There are so many services that let you spin up websites with a few prompts e.g. Lovable, Bolt or Replit.

Buffer’s founders launched a two-page site asking visitors to choose free vs paid plans; many people actually opted to pay, proving demand. Similarly, you can run cheap Google or Facebook ads or post on social media to gauge interest (clicks and form-signups are real data). If people are willing to click and pay, your idea has legs.

• Landing Page / Waitlist: Build a page describing your product and invite email sign-ups. Measure sign-ups or click-throughs.

• Explainer Video: Make a short demo video (like Dropbox did) and ask people to register. Tools such as Google Veo 3 can help.

• Wizard-of-Oz (Concierge MVP): Offer the product manually. For instance, Nick Swinmurn (founder of Zappos) posted pictures of shoes online and, when orders came in, he simply bought the shoes from a store and shipped them. No code was needed – just validate the concept.

• Pre-sales / Crowdfunding: Try to get actual money or deposits before building. If 10 people are ready to pay for your prototype, you’ve validated demand.

In each test, collect data (clicks, signups, conversations). Use tools like Google Analytics, email forms or simple surveys. Remember: real actions (signing up, paying, referring) beat polite answers.

Build a No-Code MVP or Prototype

Once you see interest, you can quickly mock up a prototype without coding. No-code platforms like Webflow, Bubble, Glide, Airtable, or even simple tools like Google Forms and Notion can launch interactive MVPs fast. The point is to iterate rapidly. Even the most technical founders admit that no-code “solutions often bring your experiment to market much faster.” For example, you might use a drag-and-drop builder to simulate an app interface or use an online form (e.g. Typeform) as a “fake backend”. If people react positively, you’ve learned enough to justify development.

• No-code tools: Webflow for pages, Lovable for apps, Airtable/Zapier/n8n for data workflows.

• Manual MVP: Write a blog, make slides or a mockup. Even a simple Google Sheet or PDF can reveal interest.

• Iterate with feedback: Show prototypes to users and refine wording, features or prices.

The goal isn’t polishing, it’s learning. One VC once put it “Your most important metric to optimize in the beginning is not money, it’s insights.”

Sell or Consult Before You Build

In some markets, the strongest validation is a paid customer. Consider offering a service or consulting that solves the same problem. This does two things: you earn runway, and you deeply understand customer pain. For example, the founders of 37signals (now Basecamp) began as a web-design consulting firm. When internal chaos made them build a project-management tool, clients quickly asked “Can we use this too?”. They launched Basecamp officially and set a modest goal ($5K/month in a year) which they hit in just 6 weeks. In effect, each consulting project was a micro-validation of their product idea.

The same way my friend Patrick Häde first ran a development agency called Sonic. While doing that he discovered the issue marketing asset creation and how AI can help. So he founded Superscale.

• Consulting/Services: Solve problems one-on-one for customers (e.g. custom implementations). If clients pay to solve the problem, your product is likely needed.

• White-label or Prototype Sales: Offer your solution privately (with NDA) to early adopters or partners.

• Extend runway: Use revenue from services to fund full product development, giving you more time to test and learn.

Share Your Idea (Don’t Hide It)

Many first-time founders fall into secrecy: “What if someone steals my idea?” In practice, execution matters far more than any initial idea. In fact, most people are not looking to copy your concept, and getting feedback can only help you. Talk to peers, mentors and even critics openly. You’ll learn that the idea will evolve anyway. Experienced entrepreneurs often say ideas are cheap – execution is everything. When you share a demo or landing page, you get valuable input and potentially early users. Remember, the goal is to validate your assumptions, not keep them secret.

• Build in public: Write blog posts, tweet updates or share screenshots. Real engagement helps refine the idea.

• Ask for feedback: Even lukewarm or negative reactions teach you what to fix. Don’t take criticism personally.

• Network: Early users might come from the friends and followers you tell. At worst they give feedback; at best they become evangelists.

Resources and Real-World Examples

The strategies above echo classic startup wisdom. Eric Ries’s The Lean Startup emphasizes “validated learning” through MVP experiments. Steve Blank’s customer-development framework and Rob Fitzpatrick’s The Mom Test drill down on effective interviews. Look to successful companies as models: Buffer validated by pre-launch landing pages, Zappos by selling shoes without inventory, and even Dropbox by gauging interest with a demo video (another low-fidelity MVP). At my own startup Passbase, we followed this playbook: we spent months talking with crypto exchanges and KYC professionals before writing production code, so our product solved real compliance problems.

Key takeaways: Validate before you build. Use no-code tools, landing pages, videos or manual services to test demand. Only write production code after seeing real signs of interest (signups, payments, referrals). This way you save time and money—and build something people truly want. If there’s one lesson from Lean Startup methodology and countless founders, it’s that rapid testing and customer feedback trump hours spent coding in a vacuum.

In a tech startup, the “CTO” title often sounds important, but it can be a catch-all. Studies show most successful startups do have technical leadership. Index Ventures found 78% of top startups had either a founding CTO or a technical CEO. Still, hiring a CTO (especially a co-founder) is a big commitment. Gergely Orosz’s Pragmatic CTO series suggests the CTO role really splits into two halves – inward-looking (hands-on building and architecture) and outward-looking (evangelism, boardroom/PR) – and few people excel at both. Early on, the CTO is usually just the founder with the best tech chops, focused on “using technology to enable the startup business goals”. As Michael Lopp (Rands in Repose) observes, at a startup “the CTO is responsible for building the machine: the product, the service… [this] could have easily been the founding VP of Engineering, but engineers gravitate to the CTO title because it’s shinier”.

• When to consider a CTO: If your product strategy truly needs an innovative technologist at the helm (for example, you’re building deep R&D features or cutting-edge architecture), or if having a public-facing technical leader will drive hiring and sales. A CTO can own strategy (new platforms, big pivots) and act as the “face” of your tech (open-source, conferences, press).

• When you might not need a CTO (yet): If the focus is on getting an MVP or shipping a core product, and you just need strong engineering management, you can delay a formal CTO. As one startup guide says, in early-stage ventures “the CTO’s one job is to figure out how to hit the business milestones using technology”, which often means the existing tech lead or founder wearing that hat. If your main gaps are in day-to-day delivery, process, and culture, a VP / Head of Engineering might suffice.

CTO vs. VP of Engineering in a Startup

It helps to clarify roles. In very early startups these often blur, but experts distinguish them. Michael Lopp advises that a startup CTO “builds the machine” (focusing on the product and technology), whereas the VP of Engineering (or Head of Eng) “runs the machine” (focusing on growing the team, processes, and removing blockers).

In practice, a single technical co-founder often does both at first. David Mytton similarly notes that as you scale, a new VP of Engineering role usually splits off to handle people: “the VP Eng’s job is to make everyone in the engineering organization successful” while the CTO remains “the strongest technologist…often the technical co-founder”. This was also the case for my own startup Passbase. Once we passed 15 engineers, I needed someone to help me run the day-to-day and engineering team, so that I have again time to think more about strategic topics.

In short: if your startup needs someone to manage and grow the team day-to-day, that may be a VP/Head of Eng. If you need someone to set long-term tech vision, drive big projects, or be a public face for your product, that’s more the CTO. Often an early CTO co-founder will eventually hand over team management to a VP Eng, focusing on strategy and innovation.

Three Types of Startup CTOs

Depending on your needs and stage, CTOs tend to fall into one of three profiles:

1. The Tech Innovator (Hands-On CTO): This inward-focused CTO is a builder and architect. They rally small teams of “free electrons” to prototype new products or side-projects. They have deep coding skills and drive technical vision. This CTO shines when you have a stable core product and want to spin off experiments or new features. The downside: they may be less interested in routine management and can wander into “gotta build something cool” territory without managing process.

2. The People-Builder (Managerial CTO): This CTO is as much a leader as a technologist. They excel at recruiting, mentorship, and culture-building, essentially a “culture-hero” for the engineering org. Often they started as an engineering manager. They help scale the team, define processes, and resolve day-to-day roadblocks. Once a startup grows, the VP Eng or similar “focuses on people and process,” while the CTO stays on tech. This type is vital when you need to hire rapidly and maintain cohesion. The risk is they may neglect future product innovation or external strategy, so it should match your priorities.

3. The Evangelist (Outward-Facing CTO): This CTO spends a lot of time outside the codebase: speaking at conferences, writing blog posts, engaging with customers or partners. They amplify the startup’s brand and can attract talent or sales. Gergely Orosz’s Pragmatic CTO blog says an outward CTO needs to be “an excellent communicator, passionate to discuss with both tech and non-tech audiences” to build buy-in. This pays off if raising future funding, recruiting developers, or marketing hinges on having a visionary tech face. However, if they lack technical credibility, the team may see them as disconnected. In early startups, it’s rare one person does everything, so many companies either hire a separate evangelist or wait until later.

In reality, most CTOs blend these. As the Pragmatic CTO author warns, “it’s extremely hard to find a single person who would perfectly fit all of the above” roles, so “one should take a pragmatic approach”. Be clear which strengths you need.

Making the Call

So, do you need a CTO? It depends on stage and strategy. Ask:

• What does our startup most critically need? New product breakthroughs, or solid delivery and team growth?

• Do we need an external tech champion? If investor or marketing confidence depends on visible technical leadership, that argues for a CTO.

• Who is already covering tech? If a founder/CEO or lead engineer can handle vision and hands-on work, a separate CTO might not add value yet.

Remember, a CTO (especially with co-founder equity) is expensive. If your immediate gap is building and managing the engineering team, an Engineering Director/VP might be wiser until you reach the point where you can split roles. David Mytton advises early-stage founders to hire executives based on the next 12–18 months: hire the person whose skills will carry you through your current crunch. In practice, many startups simply label their technical co-founder “CTO” and then hire a VP Engineering or Directors underneath as they grow, handing off the management side.

In summary, don’t hire a CTO just for the title. Instead, pinpoint the critical gaps in leadership or innovation you have today. You might start with a strong technical co-founder or lead engineer, then later bring in a formal CTO (with the right mix of hands-on, management, or evangelism skills) once you’re ready for the next phase. As one expert puts it, the only task for an early CTO is “business, through technology”, everything else is secondary. Stay pragmatic: if you do bring on a CTO, make sure their particular style (innovator, manager or evangelist) matches your startup’s needs right now.

Vibe coding, a term coined by Andrej Karpathy in 2025, is an AI-assisted programming approach that emphasizes intuition, fluidity, and creative flow. In this style, you work with a large language model almost like a pair programmer, “avoiding micromanaging the code, accepting AI-suggested completions liberally,” and focusing on iterative experimentation rather than perfection. Karpathy even describes it as “fully giving in to the vibes, embracing exponentials, and forgetting that the code even exists.”

This new paradigm can be exhilarating and empowering. Vibe coding can significantly amplify a developer's ability to produce working software quickly. But it also introduces a risk: being good at vibe coding does not automatically make you a great software engineer. Why? Because while AI can help write code, it cannot substitute for the human skills that define engineering excellence: sound judgment, system thinking, and, above all, effective communication and collaboration.

Code is Communication

In The Software Engineer’s Guidebook, Gergely Orosz emphasizes that success in engineering isn't just about writing good code. It's about working well with people. Writing clean, understandable code is only the beginning. You also need to:

• Write clear documentation and PR descriptions.

• Explain technical decisions to non-technical stakeholders.

• Understand product requirements deeply.

• Give and receive feedback constructively.

• Navigate trade-offs with your team.

As Orosz explains, engineers are not hired just to type code. They're hired to solve problems. And problem-solving in a modern tech team means aligning your work with others, building on shared knowledge, and contributing to a larger system. AI might write the function, but it won’t align it with the roadmap, consider long-term maintainability, or negotiate a deadline.

The Two Pillars of Engineering Growth

1. Technical Excellence

Vibe coding is undeniably powerful here. It allows engineers to explore ideas faster, try multiple approaches, and spend more time on architecture and logic rather than boilerplate. It encourages experimentation and reduces the friction of starting something new.

But to grow technically, you must not rely solely on AI. You need to understand the code being generated, question its assumptions, and refine your mental models. Read systems code, study postmortems, go deep on architecture. As Orosz notes, senior engineers distinguish themselves by their ability to work across systems, not just within functions.

2. Communication and Integration

This is the pillar vibe coding doesn’t touch and it's often the harder one. The best engineers are those who can:

• Take a fuzzy idea and drive it to a concrete implementation.

• Write design documents that others want to read.

• Lead conversations that surface risks early.

• Mentor others, and scale their impact through influence.

As The Pragmatic Engineer blog often points out, much of senior engineering work is invisible. It’s in the Slack threads that prevent a misaligned launch. It’s in the architecture review that catches a scaling flaw early. It’s in the trust you build that makes your team faster and more confident.

How to Thrive in the Vibe Era

• Use AI to augment, not replace, your thinking. Don’t accept every suggestion blindly. Be the editor, not just the prompt writer.

• Practice writing, not just code. Clear writing is the foundation of clear thinking. Engineers who can communicate well unlock better collaboration.

• Participate in team rituals with intent. Use stand-ups, reviews, and retros to share context, give feedback, and connect your work to the bigger picture.

• Stay curious and go deep. Learn why something works, not just how. Follow the trail of a bug until you understand the root cause.

• Seek feedback often. On your code, your communication, and your decisions. Growth comes from reflection.

Final Thoughts

Vibe coding is here to stay, and that’s a good thing. It can make us faster, more creative, and more fearless. But it is not a substitute for engineering maturity. The best engineers of this era will be those who ride the wave of AI and deepen their ability to collaborate, integrate, and lead.

Because in the end, the art of building software isn't just in the code you write. It’s in how well that code fits into a team, a system, and a shared vision. And that part still depends entirely on you.