Software Engineering · PiniShv

The Vibe Coding Backlash Is Right. Seniors Are Losing the Argument Anyway.

Fri, 24 Apr 2026 14:00:00 +0300

Something finally broke this week. Forbes published Vibe Coding Will Break Your Company. Senior engineers are circulating it. Other senior engineers are writing their own versions. The pushback on vibe coding culture has been brewing for months, and it just hit mainstream media.

The seniors are right. And they’re about to lose the argument anyway.

Here’s why, and what needs to happen if they actually want to win it.

What the seniors are right about
#

The data at this point isn’t close.

Multiple independent audits of AI-assisted codebases are converging on the same picture: AI-co-authored code ships with materially more “major” issues than human-written code. Audits of no-code AI app-generation platforms keep finding meaningful percentages of generated applications going live with real security holes: hardcoded API keys, client-side-only authentication, unsanitized user inputs.

In July 2025, a Replit AI agent deleted a live production database during an explicit code freeze, affecting over 1,200 executive users. The agent had permissions. The permissions were never meant for an agent. Nobody designed for the possibility.

Across the industry, Stack Overflow’s trust-gap research and DX’s Q1 2026 impact report tell the same story: 84% of developers use AI daily. Only 29% trust the code reaching production. PR throughput is up 46% in some teams. Defect rates are up 50% in some of the same teams.

And the perception gap keeps embarrassing us. METR’s study measured experienced developers as 19% slower with AI while they believed they were 20% faster. 39 percentage points of self-deception. The feeling is real. The feeling is wrong.

The craft didn’t change. The pressure to ship faster without understanding what shipped did. And when you ship what you don’t understand, you pay for it later, with interest. The next generation of senior engineers is taking the brunt of it.

The seniors are not wrong to push back. They’re watching production systems rot in slow motion.

What the vibe coders are also right about
#

For a lot of what companies actually ship, fast-and-rough is genuinely fine. Internal tools nobody will maintain in two years. One-off data migrations. Prototype features for customer calls. Throwaway scripts. The economics of fussing over these pieces changed. If an agent ships them in thirty minutes and they work, that’s a real win.

The vibe coders are also right that a lot of “senior engineering rigor” is muscle memory from an era where code was expensive to produce. Gatekeeping code review, nit-level style comments, architectural debates that take longer than the feature itself. Some of it was always noise. More of it is noise now that the economics flipped.

And they’re right that the pushback often sounds like resistance to change from people protecting their role.

Both sides are right about different things. The fight isn’t which side wins. It’s where the line gets drawn.

Why the seniors are losing anyway
#

In most engineering orgs, the pushback against vibe coding is losing. Not because the data is wrong. Because the seniors can’t make their case in the meetings where throughput metrics get shown.

Imagine the scene. Quarterly review. Director pulls up a dashboard.

PR throughput: up 46%
Commits per engineer: up 2.1x
Features shipped: up 34%
Deployment frequency: up

Then the senior engineer raises a hand and says “but the code quality is degrading.”

Where’s that dashboard? What’s the number? Can you point to the specific incidents that didn’t happen because you caught them in review? Can you show the rework that wasn’t done because you stopped a bad architecture at design time?

Usually, no. The senior engineers have the instinct and the experience. They don’t have the receipts.

Throughput is legible. Judgment is invisible. In a fight between legible and invisible, legible wins every time.

This is the real problem. The seniors are right, and they’re losing, and they’re losing because the thing they’re right about doesn’t show up on the charts.

What “legible judgment” actually means
#

In organizations doing this well, the senior engineers who keep winning this argument don’t do it by being louder. They do it by making the prevented damage visible. Five concrete moves.

Write down the decisions you stop from shipping. When you block a PR because the approach is wrong, don’t just close it. Write a one-line note: “Rejected: would create a race condition under load. Suggested redesign: queue-based.” Collect these. After six months, you have a measurable “incidents prevented” count. That’s a number. Numbers win.

Track rework on AI-generated code specifically. Most PR analytics can’t distinguish AI-generated from human-written code. If yours can, instrument it. Show the quarterly trend: what percentage of AI-generated commits get reworked within 30 days? If it’s higher than your human-written baseline, that number is your argument.

Tie blocked architectures to real incident data. When an incident happens that a senior flagged earlier, say so in the postmortem. Not as blame. As calibration data. “This failure mode was identified in PR #1847 on March 3 and was not addressed before ship.” That’s the receipt.

Put a senior on every AI-native system’s design review, not just the code review. Code review is too late. By then the architecture is set and the only conversation left is stylistic. Design review is where senior judgment actually prevents expensive mistakes. Move your seniors upstream.

Run quarterly “prevented incident” retros. Once a quarter, the senior engineers present what they caught and the counterfactual. What would have happened if this had shipped? What did it cost to catch it? That reframes senior time as prevention, not overhead.

The bigger reframe
#

The vibe coding debate is a symptom. The underlying issue is that engineering organizations built their scorecards for a world where code production was the bottleneck. In that world, throughput meant progress.

That world ended sometime around late 2024. The bottleneck isn’t production anymore. It’s ownership. Review capacity. System understanding. Architectural coherence across the full surface area. Governance. Incident response.

If your scorecard only measures production throughput, you will systematically underfund the ownership layer. The senior engineers trying to protect that layer will keep losing quarterly reviews while the on-call pager gets louder.

The seniors aren’t wrong. The scorecard is.

What senior engineers should do right now
#

Three moves, in order.

Stop arguing about vibe coding. The debate is a distraction. Every hour spent defending “slow careful engineering” in principle is an hour not spent proving prevented cost in practice.

Start a prevented-incident log today. One line per blocked PR, rejected design, caught architectural issue. Share it monthly with your manager, not as complaint, as data. Six months from now you’ll have a case you can actually make.

Volunteer for the AI incident response playbook. When the next AI agent deletes something important (and it will), be the person with the playbook. Incidents shift organizational gravity. You want to be the person organizations call, not the person who said “I told you so.”

The seniors who survive this era will not be the ones who pushed back the loudest. They’ll be the ones who learned to make their judgment measurable, visible, and impossible to dismiss when the throughput chart is on screen.

The vibe coders are going to keep shipping. That’s fine. The question is who’s going to own what they ship in production three months later. That’s the open job. If you’re a senior engineer, that’s your job. Go take it.

What prevented-incident data do you actually have from the last quarter? Find me on X, Telegram, or LinkedIn.

Disclaimer: This article references specific studies, surveys, and public commentary for illustrative and educational purposes, including work from Forbes, Stack Overflow, DX, METR, Medium authors, Replit and Lovable incident reports, and industry analyses available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies or tools mentioned. This is commentary, not investment, legal, career, or business advice.

AI Is Now Reviewing AI's Code. That Should Make You Think.

Mon, 23 Mar 2026 07:00:00 +0200

Three things happened in the first two weeks of March 2026.

Anthropic launched Code Review for Claude Code. A multi-agent system that automatically reviews GitHub pull requests, dispatching specialized agents that analyze code for bugs, security issues, and logic errors. Internally at Anthropic, 54% of PRs now receive substantive review comments, up from 16%.

Cursor shipped Automations with security review triggers that fire on every code push. No human initiates the review. The system does.

GitLab made agentic code reviews available at $0.25 per review, including false positive detection for security scanning.

The industry is converging on the same answer to the same problem: AI generates more code than humans can review, so AI should review it too.

That answer is partly right. And partly something we should think harder about.

The bottleneck is real
#

Anthropic’s own numbers make the case. Their code output grew 200% year-over-year, but their human review capacity didn’t. That’s not unique to Anthropic. Any team using AI coding tools aggressively is hitting the same wall. More PRs, same number of reviewers, reviews get thinner.

The Plandek 2026 benchmarks across 2,000+ teams confirmed this: as AI speeds up coding, the bottleneck shifts downstream to review, testing, and integration. Bottom-quartile teams take 35+ hours to merge a pull request. That’s not a coding problem. That’s a review problem.

So AI code review tools are solving a real constraint. And early results are genuinely impressive. Anthropic reports less than 1% of Code Review findings are marked incorrect by engineers. On large PRs (1,000+ lines), 84% receive findings averaging 7.5 issues per review. That’s catching things humans were missing because they didn’t have time to look carefully.

The part that should make you think
#

Here’s my concern.

If AI writes the code and AI reviews the code, the human becomes the person who approves the merge. Not the person who understands the change. The approver.

That’s a fundamentally different role than reviewer. A reviewer reads, questions, understands, and decides. An approver looks at the green checkmarks and clicks the button.

I wrote this week about how the culture shifted toward rewarding speed over understanding. AI code review accelerates that shift. Not because the tools are bad, but because they make it even easier to ship code nobody on the team truly understood.

When the AI-generated PR gets an AI-generated review with AI-generated test suggestions, and a human clicks “approve” because all the signals are green, what exactly did the human contribute? And when that code breaks at 2 AM, who debugs it?

The right way to use this
#

I’m not arguing against AI code review. The bottleneck is real, and these tools catch things humans miss. Arguing against them would be arguing for worse code.

But I think the right approach is to treat AI review as a first pass, not the final word. Let the AI catch the mechanical stuff: unused variables, security patterns, style violations, common bugs. That frees human reviewers to focus on the things AI is still bad at: architectural fit, business logic correctness, failure mode analysis, and whether the approach makes sense given context the model doesn’t have.

The worst outcome is AI review replacing human review entirely. The best outcome is AI review making human review more focused and more valuable.

The difference depends on whether your team treats the green checkmark as the end of the process or the beginning of a better conversation.

That’s a culture decision, not a tooling decision. And based on what I’m seeing across the industry, most teams haven’t made it consciously.

Using AI code review on your team? Seeing it change how humans review? I’d love to hear how it’s working. Find me on X or Telegram.

AI Didn't Replace Software Engineering. It Made Bad Engineering Easier to Ship.

Sun, 22 Mar 2026 00:00:00 +0000

Something shifted in the last year and I don’t think enough people are talking about it honestly.

“Ship fast with AI” became the default expectation. Not just in one company. Everywhere. I hear it in conversations with other engineering leaders, I see it in open source repos, I notice it in how people talk about engineering work online. The assumption is that if you’re not shipping faster with AI, you’re falling behind. And if you push back, if you slow down to ask whether anyone actually understands what shipped, you look like you’re blocking progress.

Engineering discipline became a career risk. That’s the shift.

Not because AI is bad. I’m pro-AI. I want teams using it aggressively. But the culture around it drifted somewhere dangerous: we started treating speed as proof of quality, and nobody corrected the mistake because the dashboards looked great.

How the rot works
#

Here’s the chain reaction I keep seeing play out.

It starts with the culture. Leadership sets the tone: adopt AI, move faster, ship more. That’s reasonable. AI does make the mechanical parts of software cheaper. Boilerplate, scaffolding, migrations, glue code, first-pass implementations. All dramatically cheaper now. One strong engineer with the right tools can burn through work that used to take days. That part is real, and teams that ignore it are choosing to be slower for no reason.

But then the culture starts rewarding output over understanding. The engineer who ships three features in a sprint looks more productive than the one who shipped one but thought deeply about failure modes, tested edge cases, and refactored the interface. The first engineer gets praised. The second one gets asked why they’re slower than their peers.

That’s where discipline starts to erode. Not because engineers are lazy. Because the system is telling them that slowing down to think is unproductive. The incentive points at speed, so speed is what you get.

And the quality problems follow, quietly. A January 2026 study on autonomous coding agents found static-analysis warnings rising 18% and cognitive complexity increasing 39%. The researchers called it “sustained agent-induced technical debt even when velocity advantages fade.” That maps exactly to what I see: the code looks fine on the surface, the PR gets approved, the feature ships, and the complexity accumulates in places nobody is watching.

On the security side, recent data shows AI-assisted commits leak secrets at about 2x the baseline rate. Not because the tool is broken. Because humans under time pressure make worse decisions. Speed without discipline creates exposure.

Meanwhile, nobody connects the dots. The velocity charts are green. The sprint burndown looks healthy. But the on-call rotation gets heavier. Rollbacks creep up. The feature that shipped in two days takes two weeks to debug. The Plandek 2026 benchmarks across 2,000+ teams confirmed the pattern at scale: as coding speeds up, the bottleneck just shifts downstream to review, testing, and integration. The slow teams are still slow. They’re just slow in different places now.

And the skill problem compounds it. Anthropic ran a randomized trial where developers learning a new library with AI scored 17 percentage points lower on mastery than those who learned without it. The largest gap was in debugging. The exact skill you need most when AI-generated code breaks. If your engineers aren’t building real understanding, you’re growing people who can ship fast but can’t fix what they shipped.

The whole chain is connected. Culture rewards speed. Speed without understanding produces fragile systems. Fragile systems produce incidents. Incidents expose the gap. But by then, the culture has already moved on to the next sprint.

The perception gap
#

Here’s what makes this so hard to catch from the inside.

Last year, METR ran a study where experienced developers using AI were measured at 19% slower, while believing they were 20% faster. When they tried to rerun it with better tools, developers refused to participate if it meant working without AI. They’re now redesigning the entire experiment because measuring this honestly is harder than anyone expected.

I don’t think the specific numbers matter as much as the pattern: people feel faster. The feeling is real. But feeling and measurement aren’t the same thing. And in a culture that rewards feeling fast, nobody wants to be the person who says “slow down, let’s check.”

Thoughtworks landed on something important in their February 2026 retreat: AI is actually increasing cognitive load, not reducing it. More output, more concurrent problems, more decisions to make. Same human judgment capacity.

Stack Overflow has been tracking what they call the AI trust gap: adoption keeps climbing, trust keeps falling, and the top developer frustration is “almost-right” code that takes longer to verify and fix than it saved to generate.

Everyone knows this. Nobody wants to be the one who says it out loud, because the culture has made saying it feel like resistance.

Most AI agendas are still theater
#

This is the part where I’m going to annoy some people.

A lot of company “AI strategies” aren’t strategies. They’re tool rollouts with executive branding. Buy licenses. Mandate adoption. Count prompts. Celebrate throughput. Post a screenshot in the all-hands. Hope quality survives.

That’s not transformation. That’s procurement.

If your AI agenda starts with “every engineer must use Tool X” and ends before you redesign review standards, testing expectations, security boundaries, knowledge capture, and learning paths for junior engineers, then all you did was change the keyboard.

You didn’t modernize engineering. You industrialized guesswork.

And if the KPI you’re showing upstairs is “percentage of code written by AI”?

That’s one of the dumbest vanity metrics engineering has ever produced.

I don’t care how much code the model wrote. I care whether we understand what we shipped. I care whether it survives production. I care whether the team is getting better, not just faster.

Simon Willison drew the right line between vibe coding and what he now calls “agentic engineering.” If you reviewed, tested, and understood the AI-written code, that’s still software development. The production-grade version of working with AI raises the bar for tests, planning, docs, automation, QA, and review. It doesn’t lower it.

The problem is that a lot of teams adopted the speed without adopting the bar.

What actually needs to change
#

I’ve written before about how the work sequence shifts and what to do about junior engineers in earlier articles. This piece is about the organizational layer, because that’s where the failure is concentrated right now.

Separate prototype mode from production mode. Loose AI prototyping is great for throwaway experiments. It doesn’t belong anywhere near money, customer data, security boundaries, or core workflows.

Make AI transparency normal. If a change was heavily AI-assisted, say so. Show the verification path. Reviewers should know whether they’re looking at a handcrafted change, an AI-assisted draft, or an agent-produced branch. Different creation paths deserve different scrutiny.

Review decisions, not just diffs. Ask why this approach exists. What breaks first. What alternatives were rejected. What do we monitor. If your review culture is still optimized for nit-picking while AI is generating whole subsystems, your process is in the wrong decade.

Measure what matters. Escaped defects. Rework rate. Rollback frequency. MTTR. Time-to-understand for someone new in the codebase. A green AI usage dashboard isn’t evidence that your architecture got better.

Stop rewarding speed without understanding. This is the culture change that matters more than any tool or process. If your system promotes the engineer who ships fastest and ignores the one who catches the architectural flaw before it ships, you’re building the wrong incentives for the AI era.

But honestly? The most important thing you can do isn’t on this list.

Sit down with your team and have an honest conversation about what you actually understand versus what you shipped. Not a retro. Not a metrics review. A real conversation. What did we ship this month that we could confidently debug at 2 AM without the AI? What would break if the model hallucinated something subtle? Where are we trusting output we haven’t verified?

If that conversation is uncomfortable, good. That’s the conversation that needed to happen three months ago.

The craft didn’t change
#

AI changed the toolkit. It changed the speed of first drafts. It changed the sequence of when work happens. It changed how much mechanical effort one good engineer can burn through in a day.

But it didn’t change the craft.

We’re still in the business of turning ambiguity into reliable systems. Still responsible for the trade-offs. Still accountable when the thing breaks. Still need people who understand architecture, testing, operations, failure modes, and human consequences.

The teams that win won’t be the ones that generate the most code. They’ll be the ones that still know what good engineering looks like when the machine gets loud. The ones where discipline isn’t a career risk. The ones where slowing down to think is treated as engineering, not obstruction.

The tool changed. The accountability didn’t.

What’s the worst AI-caused quality problem you’ve seen? Not a hypothetical. A real one. I’d genuinely like to hear it. Find me on X or Telegram.

Disclaimer: This article references specific companies, products, research studies, and industry analyses for illustrative and educational purposes. Information is based on publicly available sources including METR, Plandek, Anthropic, GitClear, GitGuardian, Stack Overflow, and Thoughtworks reporting, available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies mentioned. This is commentary, not investment, legal, or business advice.

SaaS Is Dead. We Just Haven't Stopped Paying for It Yet.

Sat, 21 Mar 2026 00:00:00 +0000

In one of my pieces, I argued that most AI companies are just wrappers around someone else’s API.

This is the same story from the other direction.

A lot of SaaS companies are discovering that being the interface for generic business logic isn’t much of a moat when software becomes cheap to generate, cheap to modify, and easy to integrate.

For years, the SaaS bargain was simple. You paid recurring rent because building custom software was slow, expensive, risky, and annoying to maintain. Vendors amortized that complexity across thousands of customers. In return, you accepted a workflow that kind of matched your needs, a UI you learned to tolerate, and “customization” that usually meant some settings, a few webhooks, and a bigger invoice.

That bargain is breaking.

What I Actually Mean When I Say SaaS Is Dead
#

I don’t mean software delivered over the internet disappears.

I don’t mean every company rebuilds Netflix, payroll, or payment infrastructure from scratch. And I definitely don’t mean every system of record gets ripped out and replaced by some weekend vibe-coded toy.

What I mean is this: the old SaaS model of selling generic workflows through proprietary interfaces, charging per seat, and treating light customization as a competitive moat is losing its reason to exist. That model only worked because the alternative was painful. Now the alternative is getting cheaper every month.

McKinsey’s analysis of gen AI disruption in software from mid 2024! puts it bluntly: natural-language interfaces can reduce incumbency advantages, vendor switching could potentially double, and $35 billion to $40 billion in software spend could shift toward internal builds. That’s not a fringe prediction. That’s McKinsey telling enterprise buyers the math is changing.

The Builder’s Math Changed
#

If you know how to build software, a huge percentage of SaaS products have already started to look weird.

I open a pricing page for some niche productivity tool and my first thought is no longer “should I buy this?” It’s “how long would it take me to build 80% of this?”

And the uncomfortable answer is: probably not very long.

Not because I suddenly became a genius. Because the entire environment changed. I have AI coding tools that can scaffold the boring parts. I have open source projects that already solved half the problem. I have mature infrastructure: hosting, auth, databases, UI kits, workflow engines, and APIs for almost everything. In many cases I don’t need to build from zero. I need to assemble, adapt, and trim.

That’s a completely different economic equation than even two years ago.

GitHub’s 2025 Octoverse reports that AI-related repos now exceed 4.3 million and more than 1.1 million public repos import an LLM SDK. Microsoft Research found a 26% increase in completed tasks across nearly 5,000 developers using AI coding assistants. OpenAI built Codex, Anthropic shipped Claude Code, Cursor keeps expanding what a single developer can do in a sitting, and there are dozens more. This isn’t theoretical anymore. The tooling is here and people are using it.

Here’s the deeper problem for SaaS vendors: I don’t need a perfect replacement. I need something good enough, fast enough, and tailored to me.

A SaaS vendor has to build for a market segment. I only need to build for one user: me. I don’t need feature breadth. I need fit. I don’t need a polished onboarding flow for a million customers. I need the thing to work with my files, my naming, my workflow, and the three annoying edge cases that always break every generic product.

Once software becomes cheap enough to personalize, generic software starts to feel overpriced even when it’s technically “good.”

And if I don’t want to build it myself? There’s a solid chance somebody already built most of it in the open. Projects like Appsmith, ToolJet, Budibase, and Supabase have large communities and active development. Better yet, I can spin up Open WebUI and have my own ChatGPT running locally in minutes. A lot of what used to justify a subscription is now a GitHub search away.

The Enterprise Version
#

The organizational version of this matters even more.

For years, companies bought SaaS because custom internal software was expensive, slow, and hard to justify. So they adapted themselves to the product. They changed processes to fit the tool. They renamed stages to match the vendor’s mental model. They built workarounds around missing features. They bought another product to patch the first one. Then an integration layer to connect both. Then an analytics layer because the reporting was bad. Then a consultant because the entire stack became unmanageable.

This is how you end up with “modern software stacks” that are really just expensive collections of compromise.

And Zylo’s data backs this up: SaaS spend averages $4,830 per employee, with an average of $21 million wasted annually on unused licenses. That’s not efficiency. That’s organizational inertia disguised as technology strategy.

AI changes the economics of that compromise.

If I’m running an organization today, I’m not just asking “which SaaS tool should we buy?” I’m asking “which capabilities should remain external, and which workflows should we own?”

Very different question.

Because most organizations don’t actually need generic software. They need software that matches their operating model, their approvals, their language, their exception handling, their reporting, their compliance boundaries, and the weird little pieces of organizational DNA that no horizontal SaaS vendor will ever care about enough to model properly.

That’s where small, sharp internal product-and-engineering teams become strategic. Not giant old-school IT projects. Not six-year ERP fantasies. Small teams focused on building the layers that make the company operate like itself instead of like someone else’s template.

Internal dashboards. Admin surfaces. Approval flows. Cross-system orchestration. Agent layers. Copilots. Task automation. Exception handling. Thin interfaces over existing systems. Tools that reflect how the company actually works.

Gartner expects 90% of enterprise software engineers to use AI code assistants by 2028, and at least 55% of software engineering teams to be building LLM-based features by 2027. Honestly, I think that timeline is already outdated. That report is from mid-2025. As of March 2026, I can’t believe there are companies still letting their developers write code without an AI agent involved. If your engineers aren’t using one, you’re already behind. But that’s a different article, and it’s coming soon.

The smart enterprise move isn’t “replace every system of record tomorrow.” It’s “stop paying premium rent for every workflow that sits on top of those systems.”

Keep the data where it makes sense. Keep the regulated core. Keep the infrastructure you genuinely don’t want to own. But build the working layer closer to the business. Build the layer people actually touch. Build the logic that differentiates how you operate.

Because once the orchestration, interface, and workflow logic can live above multiple tools, the individual tool becomes less important. Gartner predicted 40% of enterprise apps would feature task-specific AI agents by 2026, up from less than 5% in 2025. We’re in 2026 now. Look around. The old UI moat is already thinning.

The Business Model Problem
#

A lot of SaaS companies aren’t really selling software. They’re selling the fact that custom software used to be too expensive.

That’s the real moat they had. Not code. Not design. Not even product vision, in many cases. Just the historical cost of the alternative.

If that cost collapses, a lot of “software businesses” are suddenly revealed as workflow rent.

Per-seat pricing becomes harder to defend when one employee with AI assistance can do the work that used to require a whole team buried in dashboards. Generic interfaces become harder to defend when the real interface is language. As Databricks’ CEO put it, the system of record stays but the product becomes “invisible, like plumbing.” Slow product roadmaps become harder to defend when internal teams can ship the exact missing feature themselves. Vendor lock-in becomes harder to defend when the business logic starts moving out of the app and into an orchestration layer the customer controls.

This is the same reason I was skeptical of wrapper companies. When your main value is “I’m the layer in front of something else,” you should be very nervous when that front layer becomes cheap, replaceable, or user-generated.

A surprising amount of SaaS has that exact problem.

What Still Works
#

Now, to be fair, the dumbest version of this thesis is also the loudest.

No, not every SaaS company dies. Not everything becomes an internal tool. Most organizations are not going to rebuild entire ERP stacks from scratch because a model can now generate React components and SQL queries.

A lot of SaaS still brings real value. Security. Compliance. Reliability. Operational maturity. Ecosystem depth. Support. Domain expertise. Auditability. Trust.

And some categories remain extremely durable because the hard part was never the UI. The hard part was becoming the system of record. The hard part was surviving regulation. The hard part was handling real edge cases at scale. The hard part was building a network, a marketplace, or a trusted operational layer.

Those products survive. Probably thrive, if they adapt.

Here’s what I think stays strong:

Infrastructure products, where the burden of operating them matters more than a thin layer on top. Nobody’s vibe-coding their own Stripe integration or rolling a custom Datadog.

Systems of record in regulated or mission-critical environments. Healthcare, finance, legal. The compliance overhead alone justifies the vendor relationship.

Platforms with real ecosystems, where switching costs come from partners, integrations, and data gravity, not just habit. Think Salesforce’s AppExchange or Shopify’s app marketplace. The platform is sticky because the ecosystem is.

Products with proprietary data advantages, where the software gets better because thousands of customers use it and the vendor learns things no single company could learn alone.

Software deeply embedded in execution, not just documentation. The tool isn’t where you record what happened. It’s where the work happens.

But generic horizontal workflow SaaS? The kind that charges you forever for helping you move objects between columns, forms, dashboards, and approval states? That category is in real trouble. Because that’s exactly the kind of thing AI plus internal tooling plus open source attacks from every direction at once.

Where This Ends Up
#

Here’s the question I think matters more than “is SaaS dead?”

Why are we still training humans to think like software?

Why are people still learning vendor terminology, vendor navigation, vendor permission models, vendor workflow assumptions, vendor reporting limitations, and vendor field structures just to do basic work? Why is the rigid thing in the relationship still the software?

That made sense when software was expensive and humans were adaptable. It makes a lot less sense when software is increasingly the cheaper thing to change.

For twenty years, businesses adapted themselves to software because they had no practical alternative. Now software is becoming adaptable enough to fit the business. And once that becomes the default expectation, a lot of SaaS starts to look less like innovation and more like historical baggage with a monthly invoice.

The future isn’t no software. It’s software that’s cheaper to create, closer to the user, closer to the organization, easier to adapt, and far less entitled to recurring rent.

SaaS isn’t dying as a deployment model. It’s dying as an excuse. And once buyers internalize that, the clock starts ticking.

Disclaimer: This article references specific companies, products, and industry analyses for illustrative and educational purposes. Information about market trends, revenue figures, and business strategies is based on publicly available sources, including McKinsey, Gartner, GitHub, Zylo, and TechCrunch reporting, available at the time of writing. I have not independently verified all claims. The analysis and opinions expressed are my own. I have no financial interest, business relationship, or affiliation with any companies mentioned. This is commentary, not investment, legal, or business advice.

The Magic Behind AI IDEs: How Cursor, Windsurf, and Friends Actually Work

Sun, 28 Sep 2025 00:00:00 +0000

You’ve installed Cursor. Or maybe Windsurf, or Copilot. The autocomplete feels magical. The chat knows your codebase. Sometimes it writes entire functions that actually work.

But what’s really happening? How does it know what to suggest? Why does Cursor feel different from Copilot? And why are you paying $20 a month when you already have ChatGPT?

Let’s pull back the curtain. No marketing fluff, no hand-waving. Just the actual engineering that makes these tools tick.

The 10-minute mental model
#

Every “AI for coding” tool is basically three products wearing the same trench coat:

1. The Autocomplete Engine (FIM)
#

This is that instant suggestion that appears as you type. It’s using something called Fill-In-the-Middle (FIM), where the model predicts what goes between your cursor position and the rest of your code. It’s fast, runs on limited context (usually just your current file and a few open tabs), and feels instantaneous.

This isn’t revolutionary tech. It’s a well-studied training approach that teaches models to predict the middle given the before and after. Think of it as smart tab completion on steroids.

2. The Context Engine (Smart RAG for code)
#

While you’re typing, there’s a background system indexing your entire repository. When you ask a question or trigger an edit, this engine:

Searches for relevant code snippets
Pulls in documentation
Finds similar patterns
Grabs your project rules and constraints

Then it builds a comprehensive prompt around all this context. This is where most quality differences live. Cursor’s context engine works differently from Windsurf’s, which works differently from Copilot’s. More on this in a bit.

3. The Agent Harness
#

This is the planner that can actually do things. It doesn’t just suggest code; it can:

Search your codebase
Run tests
Edit multiple files
Call APIs (via MCP)
Create pull requests
Roll back changes when things go wrong

The best systems maintain a persistent plan (like a todo list), make multiple tool calls per step, and know how to recover from failures.

Everything else? The pricing tiers, model selection, pretty UI? That’s just window dressing on these three core systems.

How Cursor actually works
#

Let’s start with the current favorite. Here’s what happens when you use Cursor:

The indexing magic. When you open a project, Cursor computes embeddings for each file. These are mathematical representations that let it find semantically similar code quickly. You control what gets indexed: it respects .gitignore and you can add exclusions. This index stays synced as you work.

Rules as religion. Cursor treats project rules as first-class citizens. Drop a .cursorrules file in your repo with your coding standards, library preferences, and “never do this” warnings. These rules get versioned with your code and automatically steer every suggestion. Sarah on your team prefers functional components? Put it in the rules. The whole team hates nested ternaries? Rules.

Two different brains. Cursor splits “tell me about code” from “change my code”:

Chat helps you understand existing code
Composer (Cmd+K) makes actual edits across multiple files
Terminal integration turns “run the tests” into actual shell commands

Your code, their servers. Even when you use your own OpenAI key, requests go through Cursor’s backend. Why? That’s where they assemble the final prompts, mixing your code with context, rules, and prompt engineering. They say they don’t store your code beyond the request lifecycle, and they offer a Privacy Mode for paranoid enterprises.

The secret sauce: It’s not the models (everyone uses the same ones). It’s the obsessive prompt engineering plus the rules system plus that multi-file diff UI that makes saying “yes” to changes so easy.

Windsurf: The operations-minded alternative
#

Windsurf (from Codeium) takes a notably different approach:

Cascade, the methodical agent. Their agent system, Cascade, is surprisingly sophisticated. It maintains a long-term plan while executing short-term actions. Think of it like a senior developer who writes a todo list before diving into code. It can create named checkpoints, revert when things go sideways, and queue up multiple tasks.

Local indexing that stays local. Windsurf explicitly documents their indexing as “optimized RAG for code.” They generate embeddings but store them locally on your machine. No code leaves for indexing. You control what gets indexed with .codeiumignore files.

MCP everywhere. They’ve gone all-in on the Model Context Protocol (Anthropic’s standard for tool integration). Want Cascade to check Jira tickets? Add a Jira MCP server. Need it to query your database? There’s an MCP server for that. Admins can control which servers teams can use.

Secret sauce: An ops-minded agent that actually plans its work, plus genuinely local indexing, plus that comprehensive MCP integration.

Copilot: Distribution is everything
#

GitHub’s Copilot started as autocomplete but is rapidly evolving:

Multi-file edits are here. “Copilot Edits” in VS Code can now change multiple files from a single instruction. No more copy-pasting suggestions file by file.

The agent grows up. GitHub’s rolling out a proper coding agent that can:

Spin up a VM
Clone your repo
Make changes
Run tests
Open a PR

You delegate a task, you get a pull request. That’s the vision they’re building toward.

Spaces: Context containers. Copilot Spaces let you create bubbles of context: “These 5 files, this issue, and these docs are what matters for this feature.” Share the space with your team. Everyone works with the same context. It went GA on September 24, 2025.

MCP support. Enterprises can enable MCP to bring in external tools. GitHub even ships their own MCP server for GitHub-specific operations.

Secret sauce: Distribution. Copilot lives where developers already work: GitHub, VS Code, Visual Studio, and now Xcode. When your AI assistant is one click away in your existing workflow, friction disappears.

Kiro: AWS’s process-first bet
#

Kiro is AWS’s entry, and they’re taking a radically different approach:

Specs drive everything. Instead of “vibe coding” where you chat until code appears, Kiro enforces spec-driven development. You co-write a specification first, then agents implement tasks with tests and documentation. It’s like having a junior developer who refuses to code without clear requirements.

Hooks and automation. Kiro bakes in event-driven automation. Save a file? Trigger tests. Commit code? Update documentation. It’s connecting the AI to your development lifecycle, not just your editor.

AWS-native from the start. Unsurprisingly, it integrates deeply with AWS services. But more interesting: they’re shipping Nova Act, an IDE extension that works in Kiro, Cursor, and VS Code. They’re playing both the platform and plugin game.

Secret sauce: Process over prompts. By forcing specs and integrating with your development lifecycle, Kiro ensures the AI aligns with how you’re supposed to work, not just how you happen to work.

“Why hasn’t JetBrains won already?”
#

Fair question. JetBrains makes the IDEs many of us grew up on. They’ve shipped AI features: inline completions, chat, file-wide edits, enterprise controls. They route to multiple LLMs and even run their own models for certain features.

So why does it feel like they’re behind?

Different DNA. JetBrains built deep IDE tools for 20 years. Their reflexes optimize for correctness, refactoring safety, and enterprise governance. Cursor and Windsurf were born in the AI age. Their reflexes optimize for agent workflows and rapid iteration.

Agent ergonomics matter. The perceived gap isn’t about model access. It’s about the experience of working with an agent. That “task to plan to multi-tool execution to rollback” loop that Windsurf and Cursor nail? JetBrains is still finding their version of it.

Open ecosystem friction. MCP support and “bring your own tools” is where the new players are loud. JetBrains prioritizes security and compliance (great for enterprises, slower for experimentation).

Translation: JetBrains hasn’t failed. They’re shipping for enterprise realities and deep IDE integration. The others are shipping for AI-first workflows. Different games, different rules.

“Aren’t these just expensive wrappers around ChatGPT?”
#

Sometimes, yes. But the good ones aren’t. Here’s what you’re actually paying for:

A context engine that works. Ever tried to explain your codebase to ChatGPT? These tools maintain living indexes with semantic understanding, symbol awareness, and cross-file relationships. That’s systems engineering, not prompt templates.

Agent orchestration. Planning, multi-file diffs, rollback, tool quotas, secure API access. This is distributed systems work. You could build it yourself. You probably shouldn’t.

Privacy and compliance. Zero-retention modes, SOC 2 compliance, team controls, audit logs. The boring stuff that keeps your company’s lawyers happy.

Workflow integration. For Copilot, the value is being one click away in GitHub. For Cursor, it’s that buttery-smooth diff UI. Distribution and UX matter more than model quality.

When you shouldn’t pay:

You only want autocomplete and you’re happy with a local model
Your team can build and maintain your own indexer, agent runtime, and diff system
You’re a solo developer on open-source projects with no compliance requirements

How to build your own (please don’t)
#

Want to understand how hard this is? Here’s the minimum architecture:

IDE Integration Layer
├─ Autocomplete (FIM)
│ ├─ Keystroke capture
│ ├─ Context window management
│ └─ Suggestion ranking
├─ Context Engine
│ ├─ Repository indexer
│ ├─ Embedding generator
│ ├─ Hybrid search (semantic + keyword)
│ ├─ Rules engine
│ └─ Reranking system
├─ Agent Runtime
│ ├─ Task planner
│ ├─ Tool executor
│ ├─ Multi-file diff engine
│ ├─ Checkpoint/rollback system
│ └─ Safety controls
└─ Model Router
├─ Provider management
├─ Cost optimization
└─ Fallback handling
Supporting Infrastructure
├─ Telemetry pipeline
├─ Privacy controls
└─ Audit system

Each of these components is a project. The integration between them is another project. The testing and reliability? Another project.

This is why these tools cost $20/month. You’re not paying for API access. You’re paying for thousands of engineering hours solving problems you haven’t even discovered yet.

What actually matters: A buyer’s guide
#

Here’s the real differentiation today:

What to look for	Cursor	Windsurf	Copilot	Kiro
How good is the context?	Excellent indexing, rules-driven	Local indexing, RAG-optimized	Repository-aware via Spaces	Spec-driven context
Can it plan and execute?	Composer for edits	Cascade planner with checkpoints	Agent with VM execution	Spec to implementation
Tool integration?	Growing MCP support	Native MCP with controls	GitHub-native + MCP	Native MCP + AWS
Enterprise ready?	Privacy mode, SOC 2	Local indexing, controls	Platform integration	AWS security posture
Unique strength?	Rules + diff UX	Planning + local-first	Distribution + GitHub	Process enforcement

The next 12 months
#

Based on current trajectories, here’s what’s coming:

Context becomes product. Expect “knowledge bases” where teams pin architecture decisions, coding standards, and project context. The AI treats these as law. Copilot Spaces is the early signal.

Tool ecosystems explode. MCP adoption is accelerating. Winners will curate safe, useful tool catalogs with enterprise controls. Think “app stores” for AI agent capabilities.

Verification becomes standard. “Plan, change, prove it” becomes the minimum bar. Every change comes with test results, linter output, and security scans.

Specs eat prompts. Kiro’s bet on spec-driven development will spread. Why? Because it aligns AI with how software should be built, not how it happens to be built.

Models commoditize, routing wins. Everyone will offer the same models. The differentiator becomes intelligent routing: which model for which task, based on cost, latency, and accuracy.

Practical advice for today
#

If you want agent-powered editing right now:

Windsurf if you like plans, checkpoints, and local control
Cursor if you want the smoothest diff experience and love rules
Copilot if you live in GitHub and want to delegate entire features
Kiro if you believe in specs and want AWS integration

If you’re married to JetBrains: Their AI Assistant is evolving fast. It’s the safe enterprise choice that prioritizes governance over bleeding-edge features.

If you’re thinking of building your own: Start with open-source. Use Continue for the IDE integration, Langchain for the agent logic, and focus on your unique differentiation. But honestly? Just pay the $20.

The uncomfortable truth
#

These aren’t just “ChatGPT with syntax highlighting.” They’re complex distributed systems solving real engineering problems:

How do you index a million-line codebase in real-time?
How do you maintain context across multiple files without sending your entire repo to OpenAI?
How do you let an agent make changes while keeping rollback ability?
How do you do all this without leaking proprietary code?

The teams winning aren’t the ones with the best models. They’re the ones treating this as systems engineering, not prompt engineering.

Your AI IDE is three systems in a trench coat: autocomplete, context engine, and agent runtime. The quality lives in how these systems work together, not in any single component.

Choose based on your workflow, not the hype. And remember: the goal isn’t to have an AI write all your code. It’s to handle the boring parts so you can focus on the interesting problems.

The magic isn’t magic. It’s just good engineering. And now you know how it works.

Next time someone asks why you pay for Cursor when “it’s just ChatGPT,” send them here. Or don’t. More server capacity for the rest of us.

Software Engineering · PiniShv

The Vibe Coding Backlash Is Right. Seniors Are Losing the Argument Anyway.

What the seniors are right about #

What the vibe coders are also right about #

Why the seniors are losing anyway #

What “legible judgment” actually means #

The bigger reframe #

What senior engineers should do right now #

AI Is Now Reviewing AI's Code. That Should Make You Think.

The bottleneck is real #

The part that should make you think #

The right way to use this #

AI Didn't Replace Software Engineering. It Made Bad Engineering Easier to Ship.

How the rot works #

The perception gap #

Most AI agendas are still theater #

What actually needs to change #

The craft didn’t change #

SaaS Is Dead. We Just Haven't Stopped Paying for It Yet.

What I Actually Mean When I Say SaaS Is Dead #

The Builder’s Math Changed #

The Enterprise Version #

The Business Model Problem #

What Still Works #

Where This Ends Up #