In 2026, AI native Individual Contributor has now the influence and role of at least the former jr. manager.

First: Delegate ownership, not accountability

The most basic principle, and the most forgotten one, as a leader you own the failure, and you share the success. This is the core of ownership vs accountability.

I’ve seen many inexperienced leaders fail at this in all roles. And I was a victim of some of these early in my career. They believed that someone doing their job poorly in their team justified not meeting a deadline, and that their performance was still brilliant. It wasn’t. Others would burnout taking on the heavy load from the rest of the team with a simple: “I can code faster than them”. The best ones, though, would build mechanisms in place to ensure things happened in time and manner.

Initially, they would lean heavily on choosing teammates that are “up to their standards”, they’ll invest heavily in hiring, mentoring, and firing, trying to ensure each team-member is perfect. Eventually this, even though necessary, won’t be enough. When a code-base/solution/organization grows sufficiently, smart people also need context. Onboarding becomes a challenge, and you don’t have the time to constantly train your team on what other 100 people are doing in a remote office. At that point, the answer is unequivocally ‘safeguards’, a.k.a. ‘guardrails’.

This was the thesis behind all our products at Desplega Labs, and the first manager intuition that paid off. Every time I found myself reviewing an issue with our system, the question was: why did this happen?

Three examples that reflect on that:

1. Agent swarm user database.
   Agent swarm kept confusing me with Taras in our different platforms. Linear, Github, Slack, email. Even though it had definitions and relationships defined in different MDs, it struggled to keep those relationships working.
   
   This is how our Unified user identity system came to be.

2. Agent swarm Coordination challenge

   I found myself actually coordinating tasks way too often. Even though our swarm run with different worktrees, and separate, isolated agents, the tricky part was ensuring things happened in the ‘correct order’.

   

   
   We decided the agent leader should be more aggressive in coordinating tasks. There’s no single PR on this, it’s the system that ensures we check similar tasks happening and we coordinate internally.

3. Litmus tests for all communications
   Every time we generated content for marketing or our users, my question was the same: is this meant for my audience?
   
   That’s when I started implementing litmus tests for each content piece. Initially it was quite simple, one pass, one score, if bad, throw it out.
   
   Nowadays, it’s a complex loop that can decide if we need to start from scratch and choose a completely different approach, or if it can be fixed with minor adjustments. It also has a powerful DB to avoid repeating itself, use the right tone, tags, and images according to our branding.
   
   By the end, the work produced is ‘good-enough’ to be reviewed weekly or even less.

The motivation is always the same: we are accountable for the outcomes, their quality, effectiveness and efficiency, even if we don’t own the implementation. The mindset then, is that of systematically understanding the whole, and focusing on accelerating the parts. Which takes us to our second point.

Second: Eliminate the Toil

Understanding that the only way to make significant progress is to make yourself redundant is the most dreaded question by ICs. Individual Contributors tend to see their job as a static set of tasks. In fact, they are not used to the idea of infinite work.

Truth is closer to Parkinson’s Law, work expands. Managers know latency is the silent killer in business, and that whenever you delegate, it’s fundamental you take on the immediate next hot topic. It’s never enough, you can always do more, faster, and better. You need to do this, because everyone is doing this, and because your customers deserve it.

Add to that the ever-growing definition of Toil. Three years ago, SEO required a lot of unavoidable manual labor. Generating a glossary in your website, consistently posting content for different audiences, refreshing your content periodically, adding the right meta tags, including the relevant links, creating appealing header images, etc. You needed a team to produce just 4 entries a week, and most of these tasks seemed unaffordable to automate. My Marketing Growth journey started there.

I created my early tinkering with a Content Strategist. It would suggest topics, do some web search, eventually even write a draft. However, the work was tedious. What happened since day one:

• It would repeat itself, and I would need to correct it. So I added a DB.

• It would forget who to write for. So I added the reviewer agent mentioned before.

• It would struggle to generate images. So I started using imgflip to generate wonderful memes.

• It would still require me to prompt to code it. So I integrated it into our repo, and CI/CD.

• It would run on my laptop… So I started using agent-swarm.dev.

Eventually it became such a powerful thing that for 5 minutes every morning I would review the content, and simply say ‘not today’, when it wasn’t really adding value. We also started using it to generate our releases, FAQs, and more documentation.

Today I don’t have less work, I have other jobs. That’s the interesting thing. At the end of the day, you will need to keep defining tasks, and your job will start looking more and more as a Leader than an IC. Nowadays, I review once a week how our SEO is doing, and I ask myself what new topics should we be looking into. That’s the job, to make sure each day you are one step higher.

Third: Decisions make or break careers.

Today the choice for any Individual Contributor is how much they want to own. Should they own:

1. The input, features delivered, lines of code contributed, etc,

2. input & output, quality & reliability of the features delivered, or

3. the outcome, usage, revenue, engagement, etc…

Managers intuitively chose outcome over output, and output over input. That’s how they grow their teams. They consistently ask themselves, how is my team helping the company succeed? Furthermore, they are trained to pick those critical projects with high likelihood of success that balance perfectly with risk. That’s their job, and the more senior they are, the more they excel at making critical decisions.

In You Have a Choice, Eric argues you “decide whether to just react as we have always done previously, or to choose a new option that might open up new possibilities of growth”. Through that thought process, it’s important to understand the role of a leader, and how our influence changes as we partner in different capacities with an organization.

That’s the mindset that allows you to introduce real changes. My last two contributions to desplega.ai weren’t fast to code, or direct improvements. In fact, by all metrics, I am probably coding less in desplega.ai than 3 months ago. However, our users truly benefit from these additions:

1. Shared test caches
   I focused for a month on sharing browser state across tests. This meant sharing login credentials (think multi-tab login) across different browser instances. Implementing this resulted in direct savings for our customers, they literally consume less tokens and their tests run faster. Win-win-win.

2. Self-improving tests

   We implemented a Night Agent that periodically revisits tests and tries to improve them following a formula that considers reliability, speed, and cost. Again, something that if we had to be taking care of every little fix in our app, we wouldn’t be able to tackle. Now we had time for the big things, while redesign happens in the background.

The one thing: Only the Paranoid Survive.

Truth is most managers will also fail. Even those that have been labelled as superstars. Superstars came to a job with a playbook, they talked about their experience and how they did it in the past. They seldom talked about the new world. Those overconfident leaders are the real risk.

The Paranoid, always looking outside, always chasing what others are doing better, always improving themselves and their teams, always looking at users & competitors. Those will be your successful ones. Those that constantly doubt their methodologies, adapt their playbook, and recognize they need constant help keeping up-to-date.

If you are asking yourself why do I spend so much time learning, and spreading those learnings, it’s because technology is getting deprecated faster than most can learn it. Your teams cannot take care of the day to day while keeping up with the latest trends. It’s not about years, it’s about weeks.

That’s my paranoia, it’s knowing that What Got You Here Won’t Get You There.

If replicating software is now marginally more expensive than checking out a repo, and accessing top talent is an API call away, then our technical leverage is organizational operational knowledge.

In that world, open sourcing code, seen as giving knowledge away, seems to be the worst option. That is wrong.

First: Open Source evolution.

Peter Levine wrote two amazing articles in 2014 and 2019 describing the business evolution behind Open Source solutions during the past 40 years. The path we followed was this:

1. 80s: Open Source as a tool for hardware adoption.
   
   BSD & GNU allowed anyone to actually use their new hardware. OEMs needed a way to ensure their devices could be used by as broad an audience as they could, and having a centralized organism made it so that they could grow faster.
   

2. 90s: Open Source meant broader talent available.
   
   Once Operating Systems became more standardized, and software companies grew enough to actually create deep collaborations with OEMs, the “driver” era wasn’t a problem anymore. OS companies will usually develop the basic integrations themselves, and help users adopt new technologies, favoring those companies they worked with.
   
   The new problem was actually running those large datacenters with particular architectures. That’s when support as a service originated. Large organizations needed experts that would help them run their software, even if they had the code. And they knew developing their own custom solutions will greatly reduce their available talent pool. They also knew they weren’t in the business of developing such solutions, and they couldn’t afford to depend on a private player, like Microsoft.
   
   RedHat, Ubuntu, and other Linux flavors revolved around selling those support services. They’ll provide you top support, develop specific solutions following a well known standard and, still, be flexible enough that you could potentially find others to take on the challenge. This is key, having “small competitors” working on their open sourced codebase was part of the value offered.
   

3. 10s: The SaaS shift
   
   Two things happened in 2010. Smaller teams started providing software solutions, and those teams didn’t have time to invest on running particular infrastructure or specialize on certain stack levels. That was the key for Software as a Service.
   
   Still, Open Source meant eventually you could run the software, however the true cost had shifted to optimize the infrastructure use. That was the most prominent billing item, and economies of scale didn’t kick in until your need for a particular product was too great.
   
   Hence, the math worked: running & maintaining a software solution for a fraction of the cost it would take you to do it seems like a no-brainer.
   

   Great examples of that are: Github, MongoDB, Databriks, Elastic, and more. Yes you could implement and run those, and competitors could provide alternative services, but usually going to the source meant you’d get a better pricing and, in many cases, the latest features early on.

The interesting part is not how the business evolved, but that in every stage the advantage of choosing an open source solution stayed the same for businesses. You could always have the assurance that choosing Open Source meant low lock-in, and protected IP on your business layer.

Why?

You can always branch the solution and start your own, or look into their community, while deploying and evolving the software yourself, giving 0 visibility to external parties.

Second: The fallacy of these last 3 months.

Tailwind is no example of a business model that didn’t work with the new AI paradigm, in fact, it’s the worst one to reflect on. Their business model was predicated on access to specific add-ons, for life, almost like template as a service. The problem for SaaS is different.

Most SaaS, and those with Open Source versions are more vulnerable, are predicated on the idea that expertise on the area, combined with the cost of developing, deploying, running and maintaining software is sufficiently expensive that you are willing to pay the cost of 1 Software Engineer a year to have premium access to said solution. The math has changed.

For most SaaS, you don’t need their latest version and it’s now cheaper than ever to build that 80/20 solution. Hence, the argument that Sequoia makes around Outcome-as-a-Service.

Their thesis is simple: “if you can deliver outcomes, then you can capture the existing outsourcing budget (6x that of software)”. They paired this with the idea that AI will allow you to increase margins, however they fail to recognize a simple reality:

This is key, the budget for software is less because it’s software, ie. the expectations on pricing for software are ~15% of the cost of outsourcing. That is a standard SaaS practice. In particular, Sequoia refers to turnkey outsourcing (outcome based) and how that could be a software behind the scenes.

For Open Source, this is relevant because it is a particular way of turnkey outsourcing, it’s a way in which you keep all sub-products, and have full transparency on how something is being operated. This is always the preferred option for outsourcing for most serious businesses.

Finally, there’s a big ‘if’ in this scenario: AI doesn’t move fast enough, you can always be one step ahead, and your job is to always be there. To say it differently: you can leverage your customer base learnings to grow your product faster than they can and always give them better value:

Assume what you call judgement today, will be table-stakes tomorrow.

That’s actually more powerful that it seems.

Third: AI native Open Source will win

Back in 2010, one of my first jobs was to develop a way to update firmware on a network of custom hardware devices. It wasn’t my only responsibility, but it did take weeks of work to reach a stable state. Years before that, it would have required a whole engineering team to do so. Python libraries made it so that a quite junior engineer could do it. 15 years later, Tech accelerated significantly.

Nowadays, Claude Code can code that in less than an afternoon with the right prompting. That’s normal software evolution, and that’s also the power of Open Source projects. Why?

When we decided to Open Source our Agent Swarm, it was a result of hearing: “Tell me how you are doing it, we are trying to do the same” multiple times during December. It was a wake up call. The top startups in Barcelona, the ones we aspired to become, were lagging here. Furthermore, they couldn’t comprehend what we were already doing. It looked like magic to them. Since then, our swarm kept improving with self-learning, supporting multiple LLMs, and expanding beyond Software development. But that’s not the amazing thing, the amazing thing is the community around it.

Since we open source it, we have done more than 15+ workshops, talked to over 300+ individuals, and found out use cases beyond Engineering (e.g. Customer Support & Marketing). That engagement is motivated by giving away value, beyond software. In fact, our Agent Swarm is just a particular way to apply those learnings. That’s the new model:

It needs to be open source

If these agents are actually operating the company, then they are of such importance to the business as a collective, that they need to have full control. Vendor lock-in would be a no-go from day one. They would need to know they can easily scale and run this solution with competing providers, before being at the mercy of a single provider. Which is the known strategy of these big players.

In fact, daily operators should be company employees. You need them to react immediately, be able to influence the organization, be accountable and available 24/7. Above all, you need them to deeply understand your business, your customers, and your vision. They also need to be your subject matter experts, and that’s a challenge when added to all the rest. Hence also the importance of a community or advisory, to make that part of their job just that, a part of it.

To the two concerns above there’s a third one: would my providers become competitors? We’ve seen this play out before through history, Google Stich just threatened the whole Figma business model. It’s not exactly the same (Figma spends 100million USD/yr in AWS vs GCP), but you can see how it could be the case otherwise.

This IP challenge is a major one, when it’s so easy for companies providing this service to ‘anonymize, learn, and replicate’.

Judgement-as-a-service

We define Judgement-as-a-service as the continuous process of helping teams assimilate new capabilities faster than the market moves, an ongoing partnership tied to outcomes. Although counter-intuitive at first, it is the immediate corollary from combining Sequoia’s arguments of Outcome as a Service and Compounding learnings.

If Agents learn at a speed beyond that of their base models, then the only key value you can deliver to an organization is that of helping teams kick-off efforts in the right direction, and then ensure their learnings keep compounding exponentially. A continuous onboarding process.

During our last event with top AI leaders, we were surprised by the three learnings they shared:

1. Enabling new capabilities has an extremely fast compounding effect.
   This means, if you use AI well, the value that you get could be seen in hours. Hence, the question is how can you learn faster?

2. Companies are looking for Elasticity in candidates
   They want highly adaptable individuals that are always challenging their fundamentals to introduce new technologies and practices. Once they have that, they need to implement those across the organization, hence

3. They devote 50% of their time to introduce new practices, and improve their internal systems.
   This is for organizations that can afford it, which tend to be either new organizations or those that have a surplus of talented individuals available. Unfortunately, that’s not the majority of cases.

Welcome to the business model for Open Source solutions: Teams need an effective and efficient way to keep up with current trends through a trusted source. The bottleneck is not really the technology, but the humans that need to assimilate those new tools constantly. At least for the next 2 years.

The service is really continuous training in the fundamentals, tied to business outcomes, and free software updates. Whoever is capable to show that value, and earn the respect of organizations, will be able to convert their Open Source product into an entry point for their services.

The one thing

The value behind Open Source hasn’t changed in the last 40 years. It’s the value of the community, low vendor lock-in, and full control.

Through the years, we experienced the same cycle: businesses built around technical MOATs suffered when those were removed or reduced, and the first ones to experience that pain were actually Open Source Solutions.

As a leader then, you should look closely into what’s happening in the Open Source Ecosystem and ask yourself:

The business model that can’t survive open source isn’t a business model, it’s a ticking bomb. Start thinking on a pivot.

1. Leap 1: From copy & pasting chatGPT to AI-powered IDEs.

2. Leap 2: From AI-powered IDEs to CLIs.

3. Leap 3: From CLIs in local, to agent swarms in the cloud.

4. Leap 4: From swarms, to self-learning and always busy coding agents.

Each leap is a series of brutal, distinct, cognitive loaded, new learnings. You go from non-stop “coding”, to an abundance of perceived “idle time”, to re-wiring one of your core mental models that held true for the past 20 years. And the worse part, once you finally feel like you’ve got a mild grasp of this new paradigm, you leap again.

You need to acknowledge the serious cognitive load we are exposed to as software engineers.

Traditionally, Software Engineers have been exemplary at keeping up with trends. We are avid readers, we explore new technologies constantly, and we pride ourselves on being innovators. We are known to be early adopters and quick learners that could move across industries flawlessly. So what’s happening?

The floor is shifting so fast that it’s not about keeping up with trends in a quarterly manner, it’s about what happened yesterday. In December, very few knew about agentic coding, in fact Taras & I were just starting to build our system. Today, it feels like if you are not using it, you are in the past.

This is, by any older standards, just bollocks.

When people are “so tired” after work nowadays, it’s more likely that their Germane Load is the one giving up, resulting in a false feeling of lack of accomplishment.

My advice: embrace it. These days learning for an hour pays off in minutes.

Here a simple framework with 5 stages, 4 leaps, and how to reach “Beast Mode”.

First: The 5 AI stages you’ll leap across

Nowadays teams are in one of these 5 stages. In fact, most teams are in Stage I, a few are tinkering with Stage II, and every CTO will tell you they are in Stage III. That’s OK!

The story goes as follows. Everyone starts by coping & pasting. That’s the C&P stage. Maybe your boss doesn’t know it, but you are doing it. You heard ChatGPT is awesome, so you copy a file, a stacktrace, maybe more, and you paste it in your personal ChatGPT account. You feel a bit dirty about it, but the result is amazing. After a few weeks, you start asking yourself, how can I do this with less C&P?

This is how it happens in each stage, you are always ‘trapped by an activity’. Each leap will be an attempt to remove that human bottleneck, so that you can go faster. Having said so…

Alas! Another activity will pop-up, one that you considered minor before, and that’s the target gap to fill with the next leap.

IDE & CLI stage

We make a distinction between using an IDE and a CLI, even though IDEs have background agents, inboxes, and cloud support. This is intentional, and the answer is very simple:

How much code you are reviewing on a daily basis implies how much you trust your Agentic coding set-up.

When using IDEs (heavily) you are still reviewing most of the code, so you are closer to an extremely powerful auto-complete, than to be working in a higher level of abstraction.

CLIs, instead, force you to have a completely different relationship with your LLM. You will define criteria, steps, hurdles, and other mechanisms that your AI needs to overcome before it considers something done. That means the maturity of your AI Software Development Lifecycle will need to be greater, otherwise your team will immediately revert to an IDE. And they’ll be right to do so.

Swarms

Everyone is lying on the internet! They talk about their agents as if they were peers, that code for them, and they treat them as interns… liars!

Well, it’s not, sorry, you should be there, and you aren’t. But it’s understandable. It’s impossible to get there without doing all the homework in the previous stages.

Having an agent swarm means you now operate with your agentic coders in a fully asynchronous peer based communication style. In our case, that is through slack and github PR reviews. Every now and then, you’ll go deeper into a task, or tackle a specific project locally. However, 90% of the contributions will be coming from the cloud, and in some cases no-one will be reviewing them.

Beast Mode: what’s next.

We are working hard on this. It's what you hear as ‘back-pressure’, ‘success/objective functions’, ‘compounding’ or ‘self-learning’.

This is truly autonomous coding agents, where you set a direction, and they continue to make relentless progress in that direction, with you having weekly 1<>1s with them.

If you want to get into Beast mode, shoot me a DM.

Second: Becoming code agnostic

The first two leaps share a common thread: learning to disregard the code. This is the thing you were the best at. In fact, this is probably what made you progress. Either because you mastered how to diagnose issues in seconds or, because you were capable of truly understanding in depth the technologies you were relying on. Now it feels weird.

You feel like you are spending more time reviewing what the LLM did, than actually doing it yourself, and you have the confidence that you would have done it better. In fact, each bug you find, is a testament on how poorly LLMs work. What you have is confirmation bias.

You have an intern without their learning attitude, and your feel the intern is trying to get your job, and you keep reminding everyone that they are not you. Good news! They aren’t. Bad news! You’ll need to admit, sooner or later, that there is something they do better.

If you are lucky to get over this hurdle, then there is another thing that would come up: you need to choose wisely which technology to adopt. Here you spend weeks looking at all possible providers, and you decide to go with the one that is ‘easiest’. You also start thinking about how many quarters and training your team is going to need, and how slow or fast the roll-out will be. That’s the second wall: organizational inertia.

Finally, there’s a third and last serious blocker that results from combining confirmation bias and organizational inertia: lack of urgency. Basically, there are always more important, and urgent, projects to deliver. After all, we know how to solve those the old way, and we will tackle innovation next week, or maybe the week after… once we understand exactly what needs to be done.

Funny enough, after a few weeks of delay, you pat your own back, happy because now something new came out, and you tell your boss: “aren’t you glad we didn’t waste our time on Devin?” when in reality your organization just missed a chance to learn this when it was easier to understand.

How to make the first leap:

1. Break the standardization mandate
   Choose any IDE, I recommend Cursor and/or Antigravity. Everyone should have different ones:

   1. LLMs have made it so that IDE set-ups are trivial,

   2. Remember IDEs are an intermediate step, no need to customize or unify this.

   3. From trying multiple IDEs the team will learn what good looks like.

2. Keep reviewing the code, you are not ready to fully trust AI, and AI is not ready for you either.

3. Do it now!

   1. Block a day in your calendar per week to introduce new AI workflows in your development lifecycle.

   2. Check how much progress you make after moving to an IDE, you won’t believe it. In the first leaps, you’ll probably 2x your pace within a day or less. The feeling is thrilling.

Leap II: CLI Revolution

It will take a few months, but eventually your team will master the AI IDE. And you’ll start hearing a few complaints.

Suddenly, some will mention how they spend so much time reviewing code before sending the PR, or how some people are sending PRs that are “horrible”. You will also hear how features that require more work, or go across repos, cannot be tackled by the planning mode, or how the background agents sound good in theory, but they don’t work because “something, something, something”.

Whatever you are hearing, you can group complaints into:

• Opaque system prompts
  Suddenly the AI IDE cannot be customized as much as you’d like. In fact, you try the latest Codex 100.2x or Sonnet 3302.21 and it’s the same as that cheap QWEN, or maxmode. Everyone is revving about those models, for your team, nothing changed. The truth is probably it didn’t.
  IDEs were important for you to understand how to work with AI when you didn’t have deeper knowledge on how it works. Now that you have a better grasp, the scaffolding they have added it’s limiting you, and this is more evident in their…

• Arbitrary frameworks
  Each IDE has a different way of understanding your codebase, and it was optimized with a different customer in mind. They are very good at superficial things, but suddenly the team starts sharing “proven prompts”, or simply doing things manually because “it’s faster”. You are missing the command, skill, and agent layer from the CLIs, in a way that you can tweak faster.

• Proximity to code
  “I don’t have time to review all the garbage it produced”. The key thing here is that your team is working still so close to the code, that they feel they need to review each line. That also makes it so that they usually “wait” for the LLM to finish, as some people used to wait while “it compiles”. They are not parallelizing enough which means…

• The inbox paradox
  Moving from a real-time editor to an asynchronous “inbox” or terminal-output mindset feels unnatural. You are no longer coding; you are reviewing and dispatching. And to be honest, you are trying to review as little as possible.

Take the leap!
Yes, it’s that easy, here what’s holding you back is the actual IDE and your habits. If you just give any CLI a try, and you use a framework (you’ll finally develop your own, like we did). That would take you out of this loop in weeks.

The secret to get the best out of it: move to Antigravity first, start using their inbox feature, and then claude-code. That’s so natural that your team won’t even notice the transition.

Third: The “Idk what to do” phase

This is the most jarring transition. You will be moving from CLIs to full-blown Agent Swarms. You will eventually have background agents coding 24/7. The emotional blocker of this phase is the reality of making yourself redundant. The promise on the other side is scary, soon your team will be thinking: “Idk what to do.”

From CLI to Swarms

The emotional toll to start using agent swarms is massive. Your ICs need to relinquish the activity they love the most, reviewing code, and become TLs that review the work assigned, scoping and planning documents. This means the code won’t be reviewed until it’s too late, in the PR review phase at best. In some cases, not even then. Our advice in this step: focus on the message. Managers and TLs have known for decades that making yourself redundant is actually a strength in senior roles. You need to make High Output Management a mandatory read for all Software Engineers.

The second step is actually the technically challenging one. Blockers are centered on updating your Software Development Lifecycle (SDLC) to that of a team of 10x your size. That’s what it needs to be AI ready, and that means tackling the 4 stages of Semantic Distance while updating the jobs to be done by your team. We already wrote extensively about it, so here a short summary of what we’ve seen:

• Defining specs & Reviewing implementation plans
  Usually your team will start spending most of their time meticulously defining what the LLM needs to code. They will fall into the “Verschlimmbesserung” trap. They’ll start making something more and more complex in an attempt to make it better.

• Manual validation & Verification
  Another classic trap, features get delayed because most of the review happens manually, from coding styles, libraries used to actual business functionality. In a worst case scenario, your team is doing a checkout of each PR generated by your LLM and testing it locally.

• Complex dev-setups
  If you don’t have an agentic way to easily spawn your local dev, this is actually the most challenging part. Many will say they need to configure providers, or they don’t have ephemeral environments. It’s not a must, but it’s something you’ll need to address for sure within the next 2 leaps.

By the end, you’ll go from non-stop coding to an abundance of idle time. But it’s not a relaxing idle time; it’s an anxiety-inducing, high-cognitive-load idle time. You will feel every hour your swarm is not working, you are wasting time.

How to survive it
When we hit this leap, we spent weeks monitoring the swarm like anxious parents. The fix was realizing that validation, not verification, is the new job description. You have to stop reviewing the plans (the “how”) and start rigorously defining the evaluations (the “what”). You overcome this leap by investing heavily in robust linters, pre-merge hooks, automated E2E testing, observability, etc. Not just for humans, but also tools for your agents to understand what’s not working, and what are non-functional requirements for your business. This will become the majority of your work going forward, optimizing your machine that builds the machine..

Leap IV: Beast Mode

This is the frontier. We are here right now, and the playbook is being written as we speak. The premise: You aren’t assigning specific tasks to the swarm, you are defining a continuous Objective, a Northstar.

The objective could be as simple as the acceptable latency in an API response, or as complex as conversion rate in an onboarding funnel. It could involve defining health metrics around churn, or costs. And it needs to be a self-learning experience. The friction lies in setting up the feedback loop tightly enough that the swarm doesn’t silently destroy your business or rack up a $10,000 API bill in an hour trying to solve an NP-hard problem.

If your business is unique, your objectives are unique, hence your agent swarm will need to be unique. It’s now your Company Operating System

Hence, the only way “Beast Mode” doesn’t implode your company is if your Software Control (QA, Monitoring, Observability) is fluent in business outcomes. That’s what we are working on.

The-one-thing: Embrace the learning curve

The biggest shock of the Leaps isn’t how much you need to improve your SDLC, it’s the psychological toll of the idle time it creates and how it forces you to redefine your team’s work over and over again.

When you strip away the toil, the syntax-wrangling, and the manual testing, your engineers are left staring at a void of essential complexity. They are forced to think purely about product architecture, user validation, and business logic.

Don’t let your team fill this new idle time with micromanagement. Acknowledge the cognitive load.

Name the leaps. Push them through the discomfort of losing “proximity to the code”, and teach them how to be technical managers rather than coders. And above all, it’s time to look for help, you need to get the learnings fast, and they won’t come from your own company echo chamber.

That’s the way to get into Beast Mode.

You have an agentic coding workflow that makes sense. Your team is finally using the LLMs for much more than a smarter autocomplete. In fact, now you have background agents coding 24/7 for you. A few kick off automatically to update libraries, fix sentry errors, the simple stuff. As a result, your team is neither happy, nor feels more empowered. They are overwhelmed.

They are the silent victims of their own demise. They have carved out the fun parts of their job, the mindless things that they did when being ‘in-the-zone’ and given those to their AI bots. As payment, their job now resembles that of a poor man’s product manager or an extremely expensive manual QA. In turn, that means you are not seeing the ROI you expected. You are producing more LOCs, but you are releasing more brittle code, and your team spends countless hours mindlessly reviewing generated code, re-writing features, manually testing corner cases, and making sure UX keeps making sense after 10 different features were added and they didn’t even know about them. We were there not so long ago.

Yes! Our plans include verification steps, and we experimented with test driven plans (TDD skill), however what was key for us to crystallize the concept for us and our agents, so that we could target it explicitly. For that, we used Barry Boehm’s definitions:

Instead, Software Verification ensures the software conforms to its specified requirements and design, confirming that internal development stages align with the established requirements baseline. ie. “Are we building the product right?”.

As Engineers, traditionally we tend to overzealously focus on Software Verification, and disregard Software Validation as someone else’s task. Even when we add end-to-end tests we ask others to define such tests. In a world where coding, and software verification, become the norm for coding agents, actual software validation is a main engineering task.

Confusing Validation and Verification, and relinquishing the SWE responsibility in both leads to lower quality, and making it a less defensible product. This is your job.

Below, the 3 strategies we implemented to enhance our software validation & how they empower each other.

Note
This is our fourth installment in our agentic coding SDLC.
Previous related articles here: [0][1][2].

First: Remote browser sessions

Taras started his adventure in AI by contributing on browser-use. Early on, he had conversations with the team on their approach, using CDP, and he continues to monitor their progress. Since then, we also track alternatives like Chrome’s MCP, Open Operator, Skyvern, OpenAI Operator, Playwright MCP, etc. The list is so extensive that we have an internal benchmark on which one can perform different tasks faster and more accurately. However all of them have the same strength: they make things happen.

For us, that is no go. We don’t want a magic solution that generate scripts in python, access the DOM directly or intercept API requests to overcome system limitations. In fact, that would void all our efforts, and make it so that everything/anything works. What we need is something that would act as a human, but faster and more efficiently.

We developed our own browser operator focused on emulating human validation with that in mind. And qa-use browser cli became the tool that made it seamless to use.

The key insights that make qa-use cli such a powerful tool are:

1. 3 types of context: agent, users, business.
   A research and plan before starting implementation are essential starting points, and every tool during the SDLC should have access to it. On top of that, for validation, we introduced two more concepts: Personas, and Business insights.

   1. Session Local Context
      Instead of having a completely isolated system running in the cloud, or even in your local machine, qa-use leverages all the context and set up your coding agent has. This means onboarding to a task is immediate and transparent, most of the knowledge is already there.

   2. Personas
      Prompts shared from product/ux that define user-types, you usually have one or two associated with each feature, and having them handy during these steps means that you can add some ‘color’ to your usability test.

   3. Business context
      The key learning: don’t stress too much about it. In fact, sometimes it’s sufficiently clear if it’s defined in a CLAUDE.md file. We learned quite quickly that simply describing your business in the same way you’d do in a marketing leaflet will take you 80% there, together with the personas it would be good enough.

2. You need to run these remotely
   What’s worse? Having to stop working while your laptop is “using your browser” or cloning the PR an agent sent you and running it locally to see the changes?
   Obviously both are terrible, and neither scales with the amount of work your new agentic flows produce. The only way to achieve this kind of productivity is to have that team working with their own resources, and you be able to review from afar. Hence, running everything in the cloud, and then reviewing recording sessions at leisure seems best… and it is.
   It really feels like you are working with a remote peer now.

3. The silent killer: infra
   This was the most tedious part, and the part that needs continuous time investment. The infrastructure required to run such browser sessions, keep recordings, manage logs, traces, storage, handle specific website controllers, etc. That’s a whole system that would become a real time sink as soon as your team starts producing at that extreme velocity. Eventually, you’ll need an expert team fully dedicated to this.

It’s extremely important to note that once you have this in place, you can actively see, and ask through comments in PRs, actions take place in your web/mobile/desktop app. It sounds wonderful, if it wasn’t because most features affect 10 services, 2 DBs, and need 4 different things to happen to trigger such flow…

Second: MCPs & CLIs

We were so proud, thus so wrong. We thought we had done it, and then we started implementing complex features in larger codebases. Guess what happened?

We found 2 categories of challenges that were making it so we would get in lengthy loops with our agents, Setup & Visibility. We defined Setup as either mocking 3rd parties, running specific routines, creating fake data, etc. Even though this deserves a whole article on its own, our major learning was to KISS and avoid investing countless hours on non business core activities. You can translate that into your agents, by giving them…

Visibility

This one was a key differential, and something that’s usually overlooked; we encouraged a deeper integration of our agents with our deployment and observability tools. In fact, we started implementing layers of tooling that before would have been deemed ‘unnecessary’ just to give that access.

What worked for us has been a mix of MCPs & cli-tools that give our agents full visibility into what is happening in their local/dev environment. A funny simple example was the bump in accuracy & reliability we saw when we started using pm2. Suddenly our agents had a much better understanding of what they could and couldn’t run, what was failing, the logs for all our services, and their state. A similar jump to that we saw when we started using Anthropic’s PostgreSQL MCP.

Another example of visibility that often gets overlooked, is how we allowed the use of APIs to retrieve and validate information. We want to stress that:

Majority of APIs are for our coding agents, in dev or production, so they get insights and act without the burden of UX.

This is a another clear example of why you ought to think of your UX in terms of agents, not humans.

Third: A wrinkle in end-to-end tests.

Yes, you need end-to-end tests. Yes, a lot of them. Yes, you can convert your browser sessions into end-to-end tests. NO, I’M NOT GOING TO TALK ABOUT THAT.

I’m going to talk about the best unexpected use case for our testing cli.

If you are striving for an unearthly app, your end-to-end tests are not there to tell you that something is broken, they are there to tell you you’ve lowered the bar, ie. your app s*cks. That moves them from verification to validation, furthermore, that means your e2e tests are evaluating your app.

“to get a model to perform certain tasks, such as use a web browser, developers might go through an even more laborious process of creating many RL gyms (simulated environments) to let an algorithm repeatedly practice a narrow set of tasks.” - Andrew Ng

If you embrace this RL gym concept, instead of using your end-to-ends in isolation, you’ll start comparing results between builds to ensure the experience is improving, and you’ll use LLMs as a judge to verify such improvements. That’s our qa-use cli true power. You are now running continuously, creating new tests, and comparing between different builds.

This could be too abstract for many, so let’s go over an example we’ve been using for the past 3 months,

Speed run challenge

https://evals.desplega.ai/speedrun/challenge

An essential set of KPIs for everyone using a browser operator should include how efficient & effective the engine is at performing chained, complex, actions. Years ago, that would have meant having thousands of unit-, integration, and end-to-end tests. Nowadays you can flip the concept entirely, a single e2e test that can execute & compare multiple builds simultaneously with a single objective: complete the speed run as fast and seamlessly as possible.

This is counter-intuitive, because you are still used to have a reasurred level of determinism in your code. The shift to see it at a high level, and think of it as benchmark comparison between releases may result foreign. However, this will actually give you a clear understanding of the progress, and your coding agents can self-correct accordingly. Remember, your team is magnitudes larger than before.

The-one-thing

Coding agents need much more clarity than a human. Even when you provide them with the right context & tooling, they will lack the “intuition”, and they overcompensate by being extremely confident. The same way that you wouldn’t trust a new joiner to deliver on a project autonomously without giving them clear objectives and incentives, you should provide your coding agents with clear, accurate, iterative objective functions.

This is the power of our Speed Run, an example on how to increase the autonomy and reliability of a coding agent. Defining those key evaluation mechanisms that would shape your unique Agentic SDLC will become your new tech leverage.

Keep it strong!

For the curious, here an example of our CLAUDE.md utilizes qa-use cli:

## E2E Manual Validation (qa-use)

NOTE: Always run from the git root! If you run from inside `be/` or `new-fe/`, the CLI may not find the right files.

Use `qa-use` CLI to manually verify features work end-to-end. Tests are in `qa-tests/`.

*Before testing:* Worker doesn’t hot reload - restart services first:

```bash

pm2 restart cope-worker cope-api

```

```bash

# Core workflow

qa-use browser create # Create browser session, DO NOT USE --tunnel as API runs in localhost

qa-use browser goto <url> # Navigate

qa-use browser snapshot # Get element refs (ALWAYS run before interacting)

qa-use browser click <ref> # Click by ref (e.g., e3)

qa-use browser click --text “X” # Click by text/description

qa-use browser fill <ref> “value” # Fill input

qa-use browser screenshot # Save screenshot.png

qa-use browser close # ALWAYS close when done

```

*Important:* Always run `qa-use browser close` when done - sessions consume resources.

*Existing tests:* See `qa-tests/` folder for available test definitions.

*Pattern for verifying new features:*

1. Create a session with the feature enabled

2. Use `qa-use browser snapshot

Late November, after a good experience with our cc-plugin [1], we gained enough confidence to believe we would have a positive ROI by building our own cloud coders. We tried multiple existing solutions, think conductor, superpowers, etc; and nothing was remotely up to the standards we needed, so we decided to give it a try.

The first few weeks we seldom used it. It was a fun toy. We were pretty comfortable navigating locally our 5 claude-code tabs, and having to monitor progress in a foreign behavior made it so that it didn’t really feel like an autonomous developer. It felt like training an intern. A month in, though, the first behavior shift happened. We crystallized 2 key learnings:

(1) We are used to working with peers in very integrated ecosystems (github, slack, documents, etc.) and,

(2) Lack of context was the most tedious part of the process.

We were the bottleneck, and that realization is what allowed us to 8x the productivity of our agent swarm in the last 8 weeks.

First: You are not the user, they are

It’s so easy to create a webpage nowadays, that everything you do feels like deserving of their own web footprint. That was our first mistake.

We created a UX meant for us to chat with our swarm, it is quite wonderful and we rarely used it. In fact, I don’t think I ever checked it more than a couple of times a week. Not since the start.

In a world where we are already communicating over so many different apps (whatsapp, notion, linear, jira, slack, imessage, email, github, etc) adding a new one seems so tedious, that in foresight it is obvious we wouldn’t put with that friction. Our first learning was clear:

The first obvious moment was when we were commuting and we wouldn’t find out our agents were stuck. The second one was the extreme frustration to see that an agent had spent the night waiting for a simple “yes/no” answer. That made it obvious we needed to introduce 2 changes:

1. Slack app to interact with our swarm,

2. desplega-bot to interact directly with PRs.
   Funny enough, we had to actually create a github user for our bot, given that github doesn’t allow you to tag apps, otherwise. At least not reliably.

Now our agents are part of every PR, and every conversation. We went from monitoring our agents as you do with software to actually having conversations as we did with our peers. The spike in interactions was immediate, from a couple of times a week, to tens of times a day, as they interacted with our product. Our relationship changed to be much more hands-off, it’s just that they were doing more…

Second: Give them alert feeds

Context, context, context, context. If you use an observability platform, you are used to copy long stack traces and pasting them in your coding LLM. Alas, you are also used to seeing lots of noise, and disregarding half of what you see.

Guess what? LLMs are better than us at understanding those messages, but lack the context to understand the importance of them. Hence our second lesson:

Specifically, gave them access to Sentry via sentry-cli (agents are great at CLIs, but that’s for another article)… and we had to turn it off. The first couple of days were a disaster, we had alerts that were expected, even positive, and agents proposing different ways to break our system. The second week was even worse, agents seem to reply to random alerts, ignore others, and misinterpret everything in that channel. It wasn’t the panacea people promised, at least not initially. Instead, we took the time during the following weeks to actually tag manually the agent on those alerts we wanted them to intervene. For the negligible ones, we also ask them to mute/ignore/change them.

With a self-developed system, the amount of meta-work you could do in every flow is unparalleled, and grasping such a concept early on is absolutely key: you should always ask it to improve itself, and it will.

Week over week, the system continues to finetune itself, with PRs that are either simple fixes, or “correcting” alerts. In a few cases, they would span major refactorings. Seems quite straight forward right?

The next major step: what happens if we give them objectives on performance metrics?

Third: Make them compete

When resources are scarce, you pick one path and commit. That’s how most of us learned to build. But agent swarms break that constraint, we have much more resources than before, and we have to update our instincts.

Microsoft, Google, or Apple have been known for having unlimited resources. As a result, they have multiple teams working on the same product, without even knowing. For example, how many social apps or messaging apps did Google create? What about Apple having multiple competing teams developing the iphone, to then pick the best one at the end? Now you can do the same.

Albeit you probably don’t have those billions of users, you can opt for a similar approach. Now your research and planning costs, and even implementation costs, have reduced greatly, so creating 5 versions of your next feature shouldn’t be that stressful. It’s a world where POCs could succeed. That’s our 3rd learning:

Let me give you an example: You want to unify your web table component across your codebase. Before, you’d ask your team to research all available tools, pick one and then use that one. At best, you’ll ask them to try and implement 2 of those and compare. Now, you can do something completely different, you can actually migrate all your tables (or a good number of them) and then actually see it in production under a feature flag. Is it really smoother? Is it really optimized for our QPS?

It doesn’t mean you are doing it for everything, it just means that now you can have better informed decisions at a fraction of the cost.

The-one-thing

Our leaps didn’t come from coding every imaginable option, they came from realizations after tinkering with AI for days, weeks and months. What initially was counterintuitive, becomes obvious once you’ve done enough.

We found out we were creating teamplayers, instead of a new devex, and that actually completely shifted our approach.

It was a good Monday catch-up with Taras.

1. Reviewing large PRs that seem to be all over the place,

2. Creating brittle systems that seem to break with every change,

3. Gate-keeping areas of code that were ‘human only’, and

4. Keeping up with all the accelerated innovation.

We often will get into infinite loops being ‘totally right’, and then having AI do whatever the h*ck it wanted.

In the meantime, we kept hearing how Software Engineering teams kept multiplying their productivity month-over-month (MoM). But how? If your codebase is non-trivial, and you are working on fairly complex technology, this seems impossible.

In October’25 we started thinking about how to move from AI informed to AI lead, in the hopes of eventually becoming AI driven.

Since then, at desplega.ai, we’ve been doubling our productivity monthly. We did this by reducing the human-in-the-loop to 3 essential moments, and by adding structure to what was initially a set of unstructured prompts.

This article will give you an idea on how to start the path to get there yourself.1

First: Software Development Life Cycle (SDLC) applied to AI

AI coding platforms include a plan mode, a step in which they try to understand exactly what needs to be done and they describe how they’ll do it. That’s wrong. What and How shouldn’t be together, their objectives are different, the thought process is different, and also a mistake on defining What renders the How unnecessary.

That’s why SDLCs have stages with clear separation of concerns bolted in well structured communication mechanisms. The shift-left movement has proven that those steps are cost-reducing and increase overall speed for delivery. Hence, if you merge two essential parts of the process, imagine what you can expect?

First learning

LLMs are compartmentalized. Your coding LLM and your GTM LLM, or your Notion one, don’t have holistic knowledge. Furthermore, they are limited by a context attention span (by size or focus). The same is true for the human reviewing, give them something too long, and they’ll also lose focus or procrastinate. That is our second learning.

Second learning

Now that you understand the problem, and you have smaller tasks, you need to deal with the compounding effect of introduced errors. The earlier you introduce an error, or your LLM assumes erroneously something and keeps that in their context, the higher the impact down the line.

At least for me, it happens often that I find myself switching LLMs for different problems or restarting a new chat, simply because they are on an infinite loop of wrong answers, they just decided wrong at the beginning. It’s not only coding, generating images or text has the same problem. Sometimes you need to just start fresh again, because the context built in a single step has gone awry. That’s the third learning.

Third learning

If you apply this, your software engineers now will behave closer to Tech Leads, than to developers.

Second: Researching, Planning, and Implementing

From those 3 learnings, we distilled three distinctive steps for our SDLC:

Research

Once you have an objective, you start a research on how your current solution, and existing libraries work. It could be a highly intensive process, hence we usually rely on multiple agents, MCPs, and other plugins that investigate the web, architecture, DB, infrastructure, code (even the deprecated one), libraries, docs, etc.

The output is a snapshot on the current systems available to achieve your objective. It’s a well crafted document that summarizes the state of the art at a given point in time. No more, no less.

You can store and version your research, and you can also stop relying on documentation altogether. This was key, now you have fresh research before a task, not outdated documentation that’s more difficult to maintain.

As humans, we review, edit and approve research. For example, you would remove deprecated libraries that don’t need updating, or corner cases that don’t represent business concerns.

Planning from one, or more, research

The tenet here is that you should be able to execute each step only with the output from the step before. That results in planning only requiring research documents as input. No more context, no more distractions, just plan.

The output from planning is a design document. It goes as low-level as showing key code changes. It will describe which algorithms and libraries it’s planning to use. This is all about the How.

No questions allowed. You are looking for decisions that deviate from how you envision the system in the hopes that you can detect edge cases, and lighten your code review phase.

Implement a plan

This is the “easy” part, if you did well before. Plans usually have phases, and each phase doesn’t require the context of the previous one, only the Plan. This is a direct result of how our plan was crafted, as you would do when defining a plan for your team, e.g. the plan should get implemented even if someone is sick, ooo or just got hired. Hence each step needs to be “atomic”.

Atomicity means that you can restart your coding agent with each implementation phase, keeping your context always at bay.

Our implementation agent will ask for impromptu snippet reviews, do multiple commits, and PRs, depending on the size of the feature or the practices of your team.2

Third: DIY or try one in 2 minutes.

As a starting point we opensourced our plugin, and agents, so you can use them as a guide here. If you instead prefer to try it in action, you can:

For claude-code

/plugin marketplace add desplega-ai/ai-toolbox
/plugin install desplega@desplega-ai-toolbox
/desplega:research <your research query>

For anything else (skill.sh)

npx skills add desplega-ai/ai-toolbox

This will get you off the ground, but if you really want to leverage this power, you’ll need to learn and adapt it to your codebase. The mastery comes from actually understanding the patterns you follow in your own SDLC.

Feel free to reach out with questions, and have fun!

The-one-thing

Whatever you do, start using all the knowledge you’ve got from working in teams of hundreds of engineers. Because it doesn’t matter the size of your company, in a few months the dynamics are going to be that of having an unlimited number of colleagues, and you need to master how to deliver at that scale.

I’ve been hearing more and more companies that are 10x’ing personal allowances. They know how much of a gain there is, a single person in 5 minutes could save them years of investment, or decide to leave the company to do it on their own.

You can do it!

Friday afternoon I decided to work on a fun project. For a long time, I’ve been experimenting with gamifying my day-to-day work experience. That’s how the idea for swipe.desplega.sh came to be. I wanted a simple app to swipe through my issue tracker, deciding what I would dismiss, mark as WAI, or assign to claude-code… ehmmm, I meant myself.

That’s when I recalled a convo with a Googler that pushed me to try Antigravity. He was vigorously telling me it was exactly what we used back in the day. As a Xoogler the temptation was too big not to try it. And it was amazing. It took me 10 minutes from nothing to having a proof-of-concept.

I’m not big at planning, neither letting my agents run wild, however they prompted me in the right time to check their inbox feature, and it was a game changer. Suddenly I was writing plans, reviewing them, and adding key features I had never thought of before. But it didn’t stop there, they also detected related repos & configurations while using the inbox, which immediately made it so I started developing important things there.

After 1hr, I had closed Cursor, I was sharing the news with some friends, and I was convinced from now on I would only use Antigravity. I was wrong.

First: Flawless Onboarding

The biggest blocker I find lately to test new solutions is cognitive. It takes an hour to set up, a day to see some ROI, and a week to feel I’m productive. That has been my experience with GTM (rb2b, ahrefs, vidIQ, etc) and Tech tools (Claude CLI, Gemini CLI & OpenCode.ai) alike. Only 10% became tools I rely on, doesn’t matter how hard I try.

From the start, Antigravity felt different. It didn’t ask me for anything other than a folder, my repo, and then it naively suggested in a pop-up that I try their inbox functionality. The plot twist? I didn’t check it. Instead it creeped in when I received the first notification after planning.

The inbox experience was game-changer. Notifications worked like a charm, and commenting on plans was natural. It was during those planning sessions that it kept discovering other repos, and added them to my inbox. By the end, I was doing all my ‘coding’ from my ‘gmail inbox’, and it felt great.

By hour 3, I had closed all my Cursor windows, and I had decided I was going to use Antigravity moving forward. I didn’t need anyone to tell me I was being more productive, I knew I was.

Second: Surprisingly Delightful

Looking back, what really prompted me to close cursor was only ease of use, in two areas:

1. Inbox UX
   Our current coding experience is closer to async reviewing of design documents than it is to chat with someone. The inbox concept recognizes how async the relationship with new IDEs is.
   
   Cursor & others tried to embrace this new paradigm with moderate success, Antigravity is simply better.

   

2. An effective collaborative agent, that reinforces (1)
   During my first few hours, I didn’t really have to re-prompt much. Even when I had to comment on the planning, the implementation afterwards was good enough.
   
   The truth is, I found some things I wasn’t entirely happy with, however, prompting for small fixes was enough. This delightful interactions completely shifted my previous experiences. Antigravity truly understood the type of solutions I was looking for.

You may ask yourself ‘how did I know it was better’? Truth is, last week I built a similar app with Cursor + Claude (https://www.desplega.ai/tools/flaky-or-fixable). Only the swiping took multiple iterations with that setup, and I’m still not happy with the results. In fact, I asked Antigravity to re-do that app, when…

Third: The blackhat wall

After 2 days of smooth sailing, Monday was here and I was looking forward to my Antigravity time. Suddenly, Antigravity decided I had run out of credits… and it did 3 things wrong:

1. Unpredictability.
   I didn’t know I was running out of credits this fast. Actually, I thought I was being extra careful, using fast models for easy tasks and using planning sporadically.
   I wasn’t prepared for a sudden lockout, it was frustrating.

2. Artificial Scarcity
   ‘Your credits will reset on Nov 19th’, that was four days!! Now you are full on blackhat manipulation mode, yup I know the game. My question:
   
   Why are you looking to generate negative feelings?
   
   You got me defensive, and my brain will be looking for any excuse not to do it, and it got worse…

3. Paying was friction-full
   I had Cursor closed, a bunch of things I wanted to do, I was somewhat frustrated, but I thought ‘hey, I’ll cancel my Cursor subscription and that’s that’. Well, that’s when the fun started.

   1. No payment link
      The note referred to a ‘X service subscription’, do I need all that? Why am I paying so much if I only need this. Well, ok, let me check the price.

   2. ‘Not available for your business account’
      Dude, really? I need to use my personal account? Ok…

   3. Yes! Upgrade to Google One for more…
      How much more? I had learned my lesson from (1) & (2), I wasn’t going to become dependent on a scarce, opaque and unpredictable tool.

All of this happened in a span of 30 seconds, by the end I had Cursor opened again, and I was back with my old set up.

If they instead would have used whitehat techniques (‘Here you go, 2 more days on us’ or ‘Share it with this code and you get 2 months free’) my sentiment would have been the exact opposite to this one.

the one thing

Attention is the new currency, and loyalty is your moat.

Antigravity won me over, in just a few hours it had become my de-facto IDE. I had recommended it to colleagues & friends, I was ready to switch my GenAI subscriptions. However…

They destroyed all that trust in 30 seconds by showing they don’t respect their users’ time, or their end-to-end experience, when it matters most. They failed when it matters most.

For me, Monday 2:30pm, I was ready to pay. Their payment flow issues cost them not only my LTV, but they also ended up burning through their CAC for a shot at a quick buck.

How many others did they lose this week?

Every couple of weeks a provider has an outage and we all commiserate about it. Your teams tell you it’s because slack/AWS/Cloudflare/SVB is down and we don’t have the redundancy, even though SOC2 insists we should have a recovery plan. Then the real exercise in futility starts.

I’ve been in multiple conversations where you start planning for a migration that would give you the redundancy and the quality standards that your customers wish for. The team invests countless hours planning a costly migration, integrating with new providers, to come to the realization a month later that leadership has forgotten about this priority. As a result, once this project gets delayed for quarters, two things would happen: (1) You’ll fire your Head of Engineering the next time this happens, and (2) Your team won’t believe you next time you say this is a priority for the business.

Before doing the math together to figure out how much of a real issue this is for your business, and your providers, let’s look into the last five years of incident data to see if this problem is getting worse.

First: The study.

I took the liberty of compiling all self-reported incidents from Cloudflare, DataDog, Github, Google Cloud, Zoom, and Slack. I focused on providers with transparent incident reporting. Surprisingly many major providers cap their public disclosures, or have limited historic data, making accurate comparison impossible.

The curve for Cloudflare speaks for itself. They went from well below 50 incidents a month in 2022, to over 100 during the last 3 years. You could argue they launched multiple products, expanded their user base, and they became the de-facto solution. You could also make the case that they may report incidents multiple times, if those affect several solutions. However, I think we can agree on 2 things:

1. Peaks & valleys from Google Cloud kind-of map those from Cloudflare 🤷🏽‍♀️,

2. Other equally important platforms saw incident increases, too.

The first one, it’s just hearsay, so I’ll skip it, it’s just a curiosity. The second one is much more interesting. If you normalize the curves, it’s clear that while most sustained some degree of increase, particularly Github, Datadog, and Zoom, they didn’t double incidents. Actually, Datadog & Google Cloud improved significantly since 2022, and both seem to be trending downwards. Kudos to them!

In 2011, Blackberry had a 3-day major outage affecting their private network. They went from peak revenue in 2011 (~20Bn) to ~7Bn by 2013. That’s mostly because their customers had multi-year contracts, they probably forgave the issues, but didn’t forget. Their Quality & Reliability moat was eroded after such an incident.

The Blackberry case study is categorical, you should consider that when your customers evaluate what providers to use next, reliability and quality will bite back, hard.

It’s never about the commitment shown by Executives, it’s about trust. In that scenario, explaining what happened is not enough, and asserting that you care, won’t be enough.

Second: Countermeasures

Unfortunately, the services provided by Cloudflare are not easy to replicate. It’s closer to having two ERPs or CRMs, in case one fails. Do you know someone that does so?

No company has Salesforce with a transparent fallback to Hubspot, or viceversa. It’s true that you could build it, and both platforms allow you to have setups running 24/7 to extract and populate data. It’s also true that your customers wouldn’t notice if you are using SFDC, Hubspot or Attio, at any given point in time. However, most organizations wouldn’t invest the resources required for this to happen. In fact, it’s so difficult with a single platform, that teams usually have RevOps experts pulling the data from their own business. It’s their built-in customer lock-in methodology, their moat.

Cloudflare, Google Cloud, Azure, AWS, etc, are in a similar situation. You can have redundancy, and your tech teams can build towards that horizon, however for a growing company this quickly becomes prohibitively expensive in time and resources.

It’s usually because Tech leaders are builders, that they rally behind the idea before evaluating the ROI for such long term investments. As an Executive, the question you need to answer is simple:

Third: The math

Sit down with your Account Management and Customer Support team, they’ll need to help you answer the following questions:

1. Do we have customer agreements that penalize us due to SLAs?
   Even worse, many corporations will include clauses that allow them to cut ties with you immediately if your uptime is below 99.99%. That means your largest accounts will get a free ‘get out of jail’ card. Or, at the very least, you’ll need to have a very uncomfortable conversation.

2. How much new business will we lose during that outage?
   If you lost a whole day to onboard new users, how would that actually look like from a P&L perspective. This is true for C2C/B2C solutions, much less for B2B SaaS.

3. What’s the sentiment of our existing customers after an outage?
   This one is tricky, most people will be understanding at first. They probably were faced with similar issues from other providers, so they will actually let it slip… until…

4. What happens when someone approaches them with a solution that promises better Quality?
   You need a proactive playbook. In an AI world where features aren’t a key differentiator any longer, the non-functional requirements become key.
   It’s Quality that rules, and outages are the biggest expression of failure.

I’m confident if your company is an SMB, or an early stage startup, you can safely ignore the redundancy idea. The only question you may ask yourself is: should I change providers?

the one thing

Quality, Reliability and Service are a key competency for your team. It’s not because the absence of them will mean you’ll lose business immediately, it’s actually because once a user uses your solution, they get savvy.

Customers learn quickly about your solution, competitors, and alternatives. They will quickly consider a switch when price is not an issue, if they have the promise of something that works ‘a bit better’. That’s all the push they need to do that seamless transition, and explain to their superiors how they have done the smart choice. Above all,

References

1. [2020-2025] Self-reported incidents

2. Entering the fast fashion era of SaaS very soon

3. Claudflare: I’m Sorry

4. Cloudflare: postmortem

5. Blackberry: ‘is not acceptable to us or to you’

6. Blackberry: outage-enters-third-day

7. Blackberry: revenue 2004 - 2024

tl;dr: Software Control solutions need to evolve to master business level communication. Most of the nitty gritty details – events, debug logs, assertion, traces, etc — will be consumed by LLMs soon enough, anyways.

Who will be able to abstract complexity?

Before we start, let’s make sure we agree in the following statements:

1. Smaller tech teams are producing more complex software solutions,
   This has been true for the past decades. In the 90s you needed thousands of engineers to build a marketplace, nowadays with shopify and webflow, everyone can do it instantly.
   This is the biggest software promise: never doing the same thing twice.

2. The technical acumen required to develop software is trending downwards,
   Again, a corollary of the above, and something that simply got accelerated in the past couple of years. You can now build your own app without even knowing what coding is, isn’t that great?

3. Software solutions are evolving faster, and becoming less deterministic,
   This is new. Until recently, the nature of any no-code/low-code solution was extremely limiting. You could start a project with them, and as soon as you needed to take it beyond the ‘standard path’, you would need to call an expert.
   A great example of this is the whole DevOps/RevOps ecosystem around SalesForce(SFDC). For those companies using SFDC heavily, it’s usually a good idea to use providers or define a full software development life cycle (SDLC) around that supposedly no-code platform. In fact, they also develop custom plugins and abstraction layers on top of the existing solution.
   
   Tools like Replit, v0, lovable, base44, etc. promise you can actually create what you like, anyway you want, without that burden…

4. It’s a trap!
   The essential complexity of a running software solution is ensuring your software is reliable, accurate, secure, and performant. That to say, we know issues arise from ill conceived software, or users doing the unexpected, or providers failing, etc. Assuming that ‘generating a solution’ is equivalent to ‘generating the right solution’ or even worse ‘generating a production ready solution’ is the trap. And that is the challenge that every mature software faces.
   
   In this article, I’ll use software control, SC, in lieu of observability, monitoring, QA, etc.

If you agree on the above, then here I’ll discuss:

1. First: The trap, how generating “accurate” code is fixed to a point in time.

2. Second: Before, why we built solutions that now are intrinsically outdated,

3. Third: After, how to build towards a holistic approach.

If you don’t agree with my points above, challenge me in the comments. I love when proven wrong.

First: The Trap

This is the trap, and we all fall into it so often, and in such unexpected ways, that we have built professions around it. We first believed translating requirements to code was the challenge, and we have been proven wrong every time we see those that choose the right problem succeed. We still believe Quality Control, Observability, and Monitoring (Software Control) to be challenges, when those are the only mechanisms at our disposal to verify the fidelity of our generated code. And those need to change.

By falling into this trap, we long ignore the inherent properties of the irreducible essence of software systems: complexity, conformity, changeability, and invisibility. Particularly, conformity and changeability force software to be like Proteus, condemned to cycle through endless versions eternally to please its masters. Specifically:

1. Conformity is defined by the human desire for such a solution, and how that changes through time and as we have more individuals using our software. The Kano Model being the ultimate example of this time affectation, we simply get used to features, and we usually experiment with software to give it new meaning and uses.

2. Changeability, to be honest, conformity wouldn’t be such a big deal, if changeability wasn’t there. Most human products evolve, however simply the investment required to change serves to dampen the whims of the changers. It’s because software allows for fast, seamless, iterations, that it creates an expectation of constant improvement. Forty (40) years ago, this was reserved for highly advanced software, nowadays it’s the only way to have a competing product that provides a solution in any industry.

Like a shark that is not moving, if your software is not evolving, then it’s dead.

Second: Building the train vs running the train

We have discussed two seemingly contradictory truths above:
(a) software changes constantly, hence validation is a key challenge, and
(b) testing the fidelity of a software representation is not an essential part of software.

On the surface, they seem to be dichotomous, however the explanation is simpler than expected: validation in (a) refers to the conceptual construct, whereas (b) is directly talking about the systems you need to have in place to verify a solution is working as defined. Unfortunately we haven’t found a way to do (a) without (b), as humans or machines need to verify a conceptual construct by seeing it behave in the wild. Let me repeat it:

Observing is the only effective way we have found to partially address the problem. We believe something works well if we see the system operate under specific conditions for a period of time. That’s all that we know in this area, and it’s very little.

In fact, QA (testing, quality control, unit, integration, fuzzing, end-to-end, load, synthetic monitoring, exploratory, etc) is centered on artificially generating scenarios that we believe would happen in the wild, so that we can observe those to refine our conceptual constructs. The human struggle to prove ‘absence’ is so deeply ingrained, that we are forced to have systems surveilling our software in real-time.

As an example, when you go through a driver license exam they check you know how to drive. They don’t try to corroborate that you won’t ever get into traffic accidents. The first one is what vibe-coding apps are helping with, the latter is what we need to evolve towards, and its complexity is terrifying.

Third: Quality for vibecoders

Software Control solutions are a mess.

Check your APM dashboard and ask yourself if you would ever use something like this in a team of 3. We can do better, we deserve it. They are fragmented, expensive, and terribly complex.

The good news is that with this latest fundamental shift we can re-invent them, due to:

1. Including extra code to observe your system is now ‘free’.
   With AI generating code you can be explicit about anything, e.g. with a simple command you could ensure all software includes multiple calls to different Software Control (SC - ie. QA, Monitoring, Observability, etc) SDKs or services with high reliance and autonomy. This means, you can now invest heavily in an area that traditionally was an afterthought, and a privilege of large organizations. If you are curious, business-use is a good example.

2. You can ‘safely’ reduce the noise.
   Your agents should be able to understand the first layer of output from any SC solution, and make a first attempt to reflect on the meaning of such results. That’s why so many people believe it’s the end of dashboards. Agents can tell you what’s a ‘real problem’, and where to look into first.

3. Computing is sufficiently cheap => cheaper than human labor
   Now you can run swarms of agents to do all your Quality Control, they can try to reach a confidence level that would be close to that ‘absence’ above, in a time/cost efficient manner.

The real challenge will be the UX.

Non-tech users are already looking for a solution in this realm. An experience that allows them to understand what’s happening in a system without the cognitive load of understanding traces, resources, and YAMLs. They won’t have the team to do such translation either, and if you were to facilitate such information, it would be simply copied & pasted into Claude.

We need a solution that feels closer to an ERP or a CRM, a place where you define what matters for your business, and you take limited actions to course correct.

the one thing

While companies reduce in size, CTO & C(x)O roles continue to merge. Individuals wearing the hat of Tech together with Marketing, Product, People, Operations, etc, are not an exception anymore. This was happening even before LLMs, and it has accelerated. Software has become a core competency.

Software Control solutions need to leverage this, they need to get closer to a Company mission control center, than to a Tech solution. They need to start speaking business so that your company sees, understands and decides where to invest their time and resources next. That’s where the ROI will be clear.

It’s time to start considering how your QA/Observability/SC solution can be understood & used by any CEO.

References

1. Domain-Oriented Observability - Martin Fowler

2. Continuous Delivery - Martin Fowler

3. Software Delivery Guide - Martin Fowler

4. Testing Guide - Martin Fowler

5. Continuous Delivery Tag - Martin Fowler

6. Do Things that Don’t Scale - Paul Graham

7. Tweet Thread: Automating Software Engineering - Andrej Karpathy

8. Latent Space: Software 3.0 Deep Dive - Latent Space - Andrej Karpathy

9. Kyle Howells’ Summary - Kyle Howells

10. charity.wtf Blog - Charity Majors

11. The Pragmatic Engineer Podcast - Charity Majors

12. Refactoring Podcast - Charity Majors

13. The New Stack: Testing in Production - Charity Majors

14. Observability Engineering - Charity Majors, Liz Fong-Jones, George Miranda

15. Two Person Teams - Jason Fried (REWORK Podcast)

16. “Just the two of us” - Jason Fried

17. Episode 132: Simplicity by Design - Jason Fried (Product Thinking Podcast)

18. The Three Ways: Principles Underpinning DevOps - Gene Kim

19. Moonshots Podcast: Best Startup Ideas from Paul Graham - Moonshots

Overview

Upon my disappointment with the new Cursor’s plan mode, and a great chat with Sergio Espeja, I decided to give imploid a go; here the lessons learned.

I’ve been using Cursor for well over a year now, and Claude Code for the past 3 months. Both tools have their good, bad and ugly, and learning the caveats on when they are more effective takes a significant amount of time. Furthermore, the setup is the killer, it takes several weeks of trial & error to understand exactly how to most effectively use each LLM, learnings which are not cross-compatible. Let me give you three examples:

+ Jose Valim, creator of Elixir, discussed how for his new project tidewave.ai this is a core part of their added value (great podcast!). Even if they work in a bring-your-own-apikey (BYOK) for LLMs fashion, their actual value is on how they use those LLMs calls. He also makes a point on how the most cumbersome challenge to tackle is testing, something that he doesn’t have the time right now to address. It is clear for him we are moving to the realm of conceptual challenges, more than ‘how to do it with code’

+ Kieran Klassaan from Cora has a similar perspective on the skills needed to run these networks of Agents when talking about Compounding Engineering. He says it in a simple way: whatever works for you, and then shows an amazing set of detailed agents that he has created specifically for his org.

+ Dex Horty, founder of Humanlayer, goes further into how disrupting adopting key patterns could be for an individual. In fact, he actually points out how difficult it is to get beyond that 80% solution that gets actually your product worth it. (watch it!)

If you are half as lazy as I am, you would understand by now why I got excited with Imploid. I love the end result, I would love to contribute, I don’t know if I want to maintain it, though. The same way that I love my coffee, and I would never roast it myself. I have other things to attend.

So, how did I do it?

First: Docker, Docker, Docker

If you think I would go the easy way, and simply install the npm package and wish for the best… you may not know me yet. After so many years as a developer I learned that the easy way is usually the risky way, and I really didn’t want some LLM deciding it would be nice if they had more space in my harddrive and proceeding to empty all my precious downloads. Thus, I follow the standard setup:

(a) Checked out the imploid repo into my repos folder.

(b) Created a new repo, docker-imploid,

(c) Asked very kindly to claude-code if it could review the imploid repo and create a configuration for my Docker. It didn’t work… obvs.

A few lessons learned that should help you save time:

1. Imploid runs claude with ‘--dangerously-skip-permissions’, hence

   1. Your docker runs with a non-sudo user by default.
      Claude code only allows you to use this option if you are not sudo… thank you anthropic!

   2. You need to override your claude binary so it includes an mcp config command. I simply created a wrapper for claude-code, see below.

# ~/bin/claude
#!/bin/bash
# Claude wrapper to always load MCP config
MCP_CONFIG=”$HOME/bin/mcp_config.json”
# Check if this is an MCP management command
if [[ “$1” == “mcp” ]]; then
  # Pass through MCP management commands directly
  exec /usr/local/bin/claude “$@”
fi
# For all other commands, add --mcp-config if the config exists
if [ -f “$MCP_CONFIG” ]; then
  exec /usr/local/bin/claude --mcp-config “$MCP_CONFIG” “$@”
else
  exec /usr/local/bin/claude “$@”
fi

2. Git will use your SSH keys by default
   It’s a bit misleading, but your gh token is only useful for gh, so it’s important to make sure your docker exposes your ~/.ssh directory and does the proper mappings. Personally, I have several ssh keys, so this was a nightmare.

3. Imploid expects a setup.sh file in your repo’s root
   Simply rename your setup script accordingly. It’s good practice, and naming convention, so do it!

4. Map ~/.imploid to your docker directory – that docker-imploid repo I mentioned above.
   That way you can keep track of what’s going on in your agent’s activity. Personally, it made it easy for me to set all my .env variables and also run the system locally when needed.

I know it reads easy, but it took Claude & myself an hour of furious debate to agree on the strategy we followed, and I was extremely happy to find out the decisions were the right ones once I started debugging.

Finally, remember once you have docker up and running, you need to do two things:

docker-compose exec <instance name> bash, and then:
npx imploid@latest –config
npx implid@latest –foreground

Second: It works, It works!

I dipped my toes into the Imploid workflow with three tasks of varied complexity:

1. Easy - Change the default behavior of a filter.
   This was my first change, and the PR was flawless, it felt like I could delegate those intern bugs without giving it a second thought. I simply ask two things:

   1. Make the filter disabled by default, and

   2. Preserve in local storage the user selection.

2. Medium - Add a new floating menu on the left side of our how-to’s
   This is a non-trivial UX change that requires the agent to understand how our how-to section is structured, all the subpages, how I personally want the floating menu to be displayed, and it’s open ended enough that chances are it would fail… it didn’t!

   

   For this task, it was essential to get visual feedback without needing to actually run the branch locally. This is when having a way to do end-to-end tests remotely came handy. More in the next section.

3. Hard - Translate my website to Spanish.
   I took my landing page, and I simply ask it to translate it to Spanish in a new tree under /es/.
   
   At this point I ran into my first hiccups. Claude didn’t feel comfortable translating text for me. On top of that given the size of the task (Translate 50+ pages), the agent decided the task was too big and suggested partitioning it in chunks, and suggested I create multiple tasks at a higher level.
   
   It felt like I was being asked to do something that was part of the planning, but once done, it proceeded without much issues. I ended up doing the following:
   
   1) Task to do a setup for a ‘Spanish web site’
   2…n-1) Multiple tasks translating different subdirectories of content.
   n) A task to make sure the /es/ site linked only to /es/ pages.
   
   By the end, it was clear that the translation task was beyond claude’s scope. I opted for halting the project. If I continue in this direction, I’ll likely use a different LLM to translate the texts.

Third: How are you going to test this?

A nice little thing by Imploid is that it defines your unit-tests by default. In fact, with a little fine-tuning, you can get a fair unit-test coverage on the fly. However, if you read some of my posts before, I’m not a fan of unit-testing. They help you with syntactic correctness, creating a false sense of control over the actual business semantics that you want to validate.

Hence, for the end-to-end experience, I used qa-use-mcp. This actually had 3 great advantages:

1. Real-time feedback
   I’ve got to see in real-time what was happening in the desplega.ai web app; what the agent was trying to test, how it had decided to test the feature, issues it was finding or that were arising.

   

2. Fully remote
   I didn’t need to run the build to verify the functionality.
   Because I had the recordings, I could simply check what was done in the e2e tests and verify the UX was the one I wanted. That actually saved me valuable time, because even if the feature was ‘correct’, I could see the flow and decide I wanted to change parts of it.

3. An extra feedback loop
   Running the tests also generated feedback for claude code. If you think about it, it was now interacting for the first time with a system that had a different objective, not finishing the task, but actually verifying it was a valid functionality for the context and user persona it had defined.
   
   In my case, I allowed the system to decide what e2e tests to create, so it decided to do a mobile test also. By the end, I already had 3 end-to-end tests ready to be used in staging moving forward.
   

   

It wasn’t a perfect experience, but I was able to break through the docker black-box with this little add-on, that otherwise it would have been reading logs and locally running the solution. It’s true it’s not a mandatory step, and in some cases it won’t be difficult for you to run in localhost, however if you are running multiple versions, this truly gets you to be at the next level.

The-one-thing: Give it time

This week Cursor launched their planner, based on similar concepts, and you also have Conductor, HumanLayer, and Tidewave plus many more.

It’s up to you which one you’d choose, always keeping in mind that vendor lock-in and customization are going to be your biggest challenges moving on.

Remember those old days of C/C++, Cobol, Pascal, Assembly, and Fortran, vs Java, Python, C#, RoR, JS, PHP, etc. Their VMs and interpreters may be slower, but the time savings in developer time justified the change immensely. There’s no reason to see it differently this time, this is simply the next leap.

References

1. Hey-Diga/imploid.

2. @desplega.ai/qa-use-mcp - npm

3. Introducing our MCP server: Bringing Figma into your workflow

4. https://github.com/humanlayer/humanlayer/tree/main

5. Conductor

6. Tidewave

7. A new direction for AI developer tooling (Friends)

8. Docker-imploid

Since the introduction of High-level programming languages (HLPL), Software Development has evolved throughout the years introducing new frameworks, repositories, IDEs, and services meant to reduce the complexity of creating new software. The core precept that has guided this evolution is dual: a firm idealized belief that software provides means to solve a problem once, and for all, and a pragmatic realization that the world is always more complex than you could imagine, leading to increasing challenges. Complexity compounds while software eats the world. The reigning belief for the past 50 years has been to simply re-utilize as much as possible, which leads to specialization of software.

Particularly in these past two decades, we’ve seen SaaS and global repositories, like npmjs, become key. Nowadays we don’t implement their own feature-flag solutions, ORMs, or RBAC systems. In fact, multiple startups have been created with tens of engineers, instead of thousands, as a result of this, and it doesn’t end there. Many businesses don’t have a tech team, however they do have their own ecommerce and social media software strategies based on services like shopify or instagram for business. The landscape keeps shifting and adapting to that landscape has been a trademark for our profession.

Most experienced Software Engineers took those notions at core, which lead to two shifts in the last years:

1. It became a lack of seniority trademark to develop solutions from scratch.
   
   There are things that you simply don’t do, unless it’s your team’s sole objective, e.g. creating a UI component library, an ORM, or implementing a search algorithm. Actually seniority is defined as refining systems to decide which providers/libraries to use, and that requires

2. Knowing your core business tech advantage, a must for great Tech leaders.
   
   Long gone are the days in which technologists’ value was locked on knowing the intricate details of a codebase (check the Phoenix Project! Nowadays this is detrimental). For the past decade, it has been always about identifying early on where to focus tech efforts, and delegate the rest. Great Tech leaders are able to place the right bets so that the software they produce becomes key leverage to the business. Their software is core to the value proposition of their business.

Vibe-coding is the ultimate expression of these precepts, and that’s why you should embrace it everywhere. In particular, two things happen simultaneously:

1. You can afford to generate code faster than ever,

2. Your applications can mutate themselves based on user input.

Almost everyone is focusing on (1), very few are exploring (2), and most start-ups are focused (3). Three is the easy path forward, providing infrastructure to all, and skipping the conundrum altogether.

We argue here that you should start leveraging, buying and building, solutions that follow an approach closer to (2). We make a point on why (1) keeps adding tech debt in your codebase, one of the most insidious challenges in this new world. While (2) is actually providing a new HLPL language to your customers, what the industry has been calling no-code/low-code solutions, now in human language.

First: Vibe-coding is, unfortunately, still coding.

You could think it’s funny, sad, glorious or a condemnation, but vibe-coding is still coding. In fact, <rant> it’s a bit worse than old fashion coding, you still need to debug & test – which I really procrastinated on – and you don’t get to write those cool double for-loops any more</rant>.

Actually most vibe-coders are experiencing the same problems any software engineer team had before: lack of security, monitoring, stable releases, “wasting” time in QA, etc. And that has a simple truth: they are generating code without knowing how to manage code.

The main issue for mature tech teams is a bit different, though, it’s that the code generated stays there, possibly forever. Unless you decide to dedicate part of your team to prune your codebase, which humans are historically bad at, the ratio at which you’ll be introducing new forgotten features has grown exponentially. Yes, you now can afford to introduce a new set of features per customer, it also means you’ll end in 2 years with a codebase equivalent to that one that was produced before in ~20yrs with a similar team.

This is a challenge not just for the size, and complexity of the code itself, but also because it means you have a fraction of the time to implement all the measures that came before with decades of maturity. That will take a toll, and you’ll likely end-up investing on:

1. Agents that clean the codebase

2. Agents that remove unused code-paths,

3. Agents that remove unused features,

4. Monitoring, telemetry, etc, those things that you needed with a team of 100 before.

The feeling would be that of a software company that is continuously deprecating their software and reducing the team. Having seen this in the past, the constant burden of maintenance 80% of the time, instead of the classic 20%, I know leads to productivity issues.

So how do you start building systems that don’t need to rely on so much code?

Second: Prompts! are still non-deterministic in nature.

“Code should self-improve with every run”

This has been the main tenet since day one at desplega.ai. The challenge was to adapt and rely on the non-deterministic nature of prompts. Basically, you need to generate code that is stable enough so core areas of your software work as your users expect, and knowing what they expect is always key. Because users will anchor their expectations to some version of the software ( e.g. even if the functionality provided is equivalent, a human will get bothered if buttons change color every time), we decided to use the term ‘anchoring intents’ to denote what we need to be deterministic.

We concluded that whichever strategy we followed, we needed to allow for (a) custom code and (b) a way to anchor certain properties or characteristics down to the detail. If you end up using custom code for (b) then you run the risk of having just code, and that’s something we aim to avoid.

To solve for this, we’ve been working with the following high level flow:

Human-in-the-loop to anchor behavior is an unavoidable requirement, that is either a user action, a PM review, or a Team meeting; the system needs a confirmation. With this strategy your development efforts are now centered on Agents whilst the rest of the team (UX, Product, QA, etc) are still working on their day-to-day customer centric view. If you think about it, you have just done a major infrastructure update that will keep updating itself, and luckily reduced your codebase in the process.

Note

With enough expertise you could easily go and adjust the anchored intents manually, however these are usually bloated prompts with very detailed descriptions that make it so the system is deterministic where it matters.

Third: Expertise still is the key differentiating factor

Just in this high level example, you can see how if your objective was to build an e-commerce platform, you would need to fine-tune at least:

1. A coding agent
   You need a coding agent that knows your technology stack, business principles, design principles and limitations profoundly. It needs to know AWS/GCP, ORM, JS framework, Payment rails, tracking system, etc.

2. An observability agent
   To manage your monitoring, traceability, experiments, etc. A constant oversight on your infrastructure and monitoring production before an incident escalates. It needs to understand your system signals, what systems to interact with, the options at its disposal, and when to alert who and how.

3. A set of agents to handle communications
   Internally and externally, a wide range of agents supporting customers, employees, and prospects. This is your most revenue sensitive set of agents, and maybe the most relevant one,

4. An agent to ensure your quality upon delivery
   Whenever you put your system out there, it needs to work better each time. Either a Web UI E2E testing agents, APIs, evals or all the previous ones, to ensure your application as a whole works as expected for all your customers, all the time. You can focus on the first 3, that if your quality is poor, no-one will use your product.

Each of these agents mentioned above deserves special attention, and potentially a team of individuals working on it. This is why expertise is still needed in each area, and you should find out what’s the right way to get that expertise: in-house or not. You’ll always need someone in your team to review the configurations, and manage these agents, however you may not need someone in your team to develop this agent’s infrastructure in each case. Think of how you pay for DataDog, NewRelic or Grafana, each of the agent networks above would be an equivalent service.

In our e-commerce example, you may consider your products and your network effects are the key competitive advantage, bundled with your unique user experience. In that case, the scope for your team is around controlling these agents, more than creating that infrastructure, and ‘anchoring’ a particular voice and UI. They need to do it exceedingly well, so that you don’t lose the raise against the next e-commerce.

Note

The idea of learning and re-generating the code based on usage, means that majority of the work would be around having a tight feedback loop that allows your agents to regenerate the ephemeral code upon issue discovery to improve a target metric, for example network performance, FPS, etc. Setting up and managing the feedback loop is going to be the majority of the work, and why you need to be conscious there’s an exploding need of better quality solutions, i.e. the quality bar will keep rising.

The-one-thing: Code should be ephemeral

Remember those old days of C/C++, Cobol, Pascal, Assembly, and Fortran, vs Java, Python, C#, RoR, JS, PHP, etc. Their VMs and interpreters may be slower, but the time savings and broader support justified the change immensely.

References

1. AI for IT modernization: Faster, cheaper, better

2. Anchoring AI to a reference application

3. LLMs bring new nature of abstraction

4. Technologists are embracing ‘vibe coding’ as they deploy more AI-enabled tools to boost productivity | Fortune

5. Vibe Coding: The Rise of a Revolutionary Trend in Software Development in 2025 | WebTech Tools

6. Andrej Karpathy on X: “There’s a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It’s possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper” / X

7. The Cost Of Poor Software Quality And How AI Can Fix It

8. AI for IT modernization: Faster, cheaper, better

9. Leap First - Seth Godin

tl;dr: You have 10x productivity from your SWE team, but your quality and efficiency have dropped. This is because you have effectively scaled your team overnight; what was previously a team of 10 now feels like a team of 50. We discuss a few reasons for this, the theory behind it, and how teams have overcome these challenges before… because they have done it in the past!

A few times in my career, I've had the opportunity to be a direct manager of 10+ individuals. My record is actually ~25, and I’m not proud of it. Usually, what led to those circumstances was either me being a late hire after years of poor management practices or a major re-org that resulted in me leading a new organization. I don’t recommend it, however, I would do it again if needed.

This is the art of managing the unmanageable, and in each case, I did two things from day one that proved incredibly rewarding:

1. Put safeguard processes in place that allowed me to shape the work in the organization (over the years, I started calling that ‘defining principles’).

2. Make myself redundant by spotting the talent that would later lead the organization.

To be clear, I have tried many other approaches throughout my career, and I’ve learned quickly that these two were the only things that mattered. I’ve done this for scaling teams in Growth, Product, UX, HR, and Tech many times, and it’s a key area I mentor on. That’s because it used to be a challenge present only in larger teams; with AI, this is becoming a challenge in Tech even with a team of two people.

So let’s talk about those Safeguard Processes and leave the People Management topic for a future post.

Why is this a problem now?

Theories like the Ringelmann effect, Amazon’s Two-Pizza Team rule, and Brooks's Law were all based on humans as the main source of labor. That means humans were the ones producing the work, and very few were leading that work. To be specific:

1. Free-riding is the key concept in the Ringelmann effect, and it’s the result of others being so distracted that they cannot see your lack of contribution. If others are 10x as productive, it means you can ‘vanish’ much earlier on.

2. Single-threaded leaders may not be affordable or needed in a world where 90% of the work is defining a direction, and the rest just happens. Maybe you can save on that second pizza.

3. Brooks's Law focuses on exponential communication as a result of a growing team. However, you can see how exponential communication is also necessary as a result of exponential productivity. There are more things to communicate than before, and humans are particularly slow when it comes to relaying information to each other.

As a result, now more than ever, CEOs, CTOs, Heads of QA, and VPs of organizations of any size are concerned about the same thing,

The good news is that the solution has been around for a while, and it may be easier to implement nowadays, given that your human team is smaller. As I mentioned above, Leading by Principles was popularized by individuals like Andrew Grove, Bill Campbell, and Ben Horowitz as the only way to introduce sustained change in an organization. Tim Howes referred to it as “Make Peace with Repeating Yourself (Ad Nauseam).” I prefer pointing people to my writing, as suggested by Ray Dalio’s Principles or Frederick Brooks’s The Mythical Man-Month.

Here I propose a high-level framework to create a high-velocity, self-correcting system focused on three short principles that are core to bring your SDLC and organization to the next level:

1. Writing, and reading, before doing

2. A single Mission Control Center

3. Eliminating toil!

Before getting into the weeds, I want to stress one thing: This can be used beyond Tech, as this is not a Tech problem but an organizational challenge. Having said that, below I’m going to go into the specifics of how to implement this in Tech organizations. Sorry, not sorry!

First: Writing, and reading, before doing.

Suddenly, your output is not the output of a single person anymore; it’s the output of a team. That means your solutions could introduce larger mistakes, faster than before. You could, let’s say, create a software that spends $1,000/hr in resources in an afternoon, and you wouldn’t notice. Or you could develop what you think is the right feature very quickly, overnight, and expose all the PII data from your customers without notice.

Yes, your lead is going to review the code, but sometimes the issue isn't a distraction; it’s simply a lack of knowledge. The feedback from your CTO or VP will eventually come, and maybe too late. Other times, your team will end up creating an overcomplex solution, e.g. implementing an NP-hard algorithm in the front-end and making your app unusable without anyone noticing. After all, part of the trade is bringing simple solutions to complex problems.

There’s more, though! Diverging is also a major risk. One of the biggest challenges we’ve seen is learning from each other and Breaking Silos. If the person sitting next to you has discovered how to be 2x more efficient in some aspect, you want to learn it, fast! This is the way to accelerate the whole organization long-term, and nowadays that tweaking could give you a key competitive advantage.

To get started on this, start easy, and enforce it:

1. Add 30 minutes a day for a design review (or PRD review).

2. Force constraints:

   • A document size limit of two pages.

   • The document must be shared 24 hours in advance.

   • Only comments added to the document at least 2 hours before the review will be discussed.

   • The output is a clear "yay" or "nay."

3. Shift Left!
   Invite everyone to the meeting: QA, UX, Tech, Product, the CEO if they want to!

4. The magic rule: Speak now or forever hold your peace.
   Discussions could not prolong, you need to move fast, so a decision in that call needs to be held for the next few months at least.

You will get one thing out of this process: a daily cadence for your team. You’ll see how you can remove many ad-hoc meetings if you handle this properly. Above all, the number of ‘surprises’ from someone wanting to change something late in the game should be close to zero, if you are using the magic rule properly.

Second: Mission Control Center

If you are thinking of KPIs and OKRs to track weekly, that’s great… but it’s not what I’m talking about.
Four years ago, having a well-integrated observability dashboard was optional for an early-stage team. You could assume system usage was limited and the entropy added by people changing your system was small, meaning every change could eventually be reviewed by the lead. I remember being on a team of four ICs at Google early in my career, and my manager reviewed every single PR. That worked because we produced like a 4-to-1 team; it won’t work if you produce like a 20-to-1 team.

The Mission Control Center, then, becomes vital to catch your team's “mistakes” before your users do. If your k8s nodes are suddenly restarting every five seconds, or your latest release has no network connectivity, you need to know, fast. And this is going to happen because LLMs make mistakes! And they make those mistakes faster than you can review them… hopefully.

As a leader, enforcing the idea of a single, centralized, up-to-date mission control center will allow you to:

1. React to issues before they become postmortems and churn problems.

2. Remove all data-brawls that may appear when something doesn’t work as expected.

Did you notice how this links to the First point?

It’s in writing & reading where you define your operating principles. ;)
In this case, that’s where you enforce the dashboard update, if needed.

Third: Eliminating the Toil!

This is the most difficult and entertaining part of the job, and it is easy to remember: don’t do the same thing twice!

The most challenging part about toil is the mental space it consumes. If you are thinking all day about that painful five-minute task you need to do, the burden isn't just those five minutes; it's the weight you carried throughout the day. I like to think of it as the source of Parkinson’s Law.

In my experience, the biggest pain of asking people to eliminate toil is that the activity itself becomes toil, which is our favorite thing to procrastinate on. I suggest you follow three strategies to get the most out of it:

1. Buy, buy, buy
   Toil is, by definition, context to your business. It’s that thing you need to do, and if you do it well, nobody cares. On top of that, having toil is detrimental to your team's motivation. Repetitive tasks that don’t help them advance in their self-actualization end up being a source of burnout for talented individuals.
   My advice, if you can, is to buy solutions. Why?

   • You suddenly have an expert team
     They are improving that area of your software, it’s their core value. Think of how you don’t develop your own CRM, HRIS, ERP, or ATS, even though you could. Apply that thinking to each area of your team, e.g., QA automation, Observability, or performance measurement.

   • You can focus on your business
     You don’t have to track progress, manage, or invest time in these areas, and that’s your competitive advantage now. You do not need to understand how to build the best platform for logging, testing, or extracting data from Bitbucket to measure productivity.

2. Mix it up
   Some things you won’t be able to buy, like creating that release dashboard or defining your set of test cases. For those, make them a standard part of a larger project. That way, it’s just eating the whole cake; even if you only like the frosting, at least you get some.

3. Rotations! Rotations! Rotations!
   If you have build-cop or release rotations, a good strategy is to use those weeks for the person on rotation to work on minimizing toil. You should take it one step forward and actually reward toil minimization. A good strategy is to give the person a ‘skip’ in the rotation queue or even a day off if the time saving was significant.

Finally, when focused on toil, always remember to ask: Is It Worth The Time?

the-one-thing: Never be the bottleneck

It’s easy to decide to implement these mechanisms and delay everything else until they are ready. In fact, it’s even easier to say, ‘we are not delivering on time because we need to do <toil>’; that makes you [Tech, QA, Product, etc.] the bottleneck. The other little dirty secret is: If you are the bottleneck, if your organization is the bottleneck, you are not doing a good job.

My advice is that whenever you implement this process, you agree on a timeline, hold yourself accountable to it, and ensure everything is done so that your team is not the bottleneck. Internalize the following:

References

1. Our first outage from LLM-written code (LinkedIn Post)

2. Amazon’s Two-Pizza Team Rule

3. Writing, Briefly by Paul Graham

4. Eliminating Toil (Google SRE Book)

5. Capchase’s Communities Blue-print (Medium)

6. Data Breadlines And Data Brawls (TechCrunch)

7. What I Learned Scaling Engineering Teams Through Euphoria and Horror (First Round Review)

8. Project vs. Product Mindset (Simform)

9. AI is not a silver bullet

tl;dr: The key principle to understand with the Return on Quality Investment (ROQI) is that wealth preservation (saving) is not the same as wealth creation (return). QA leaders should be unafraid to avoid using the term ROI and instead lead with loss avoidance, e.g., "our QA efforts cost X, but they are saving money / helping with wealth preservation / loss avoidance for 10*X.”

For Quality Assurance to be a power center, we need to be able to articulate precisely the value contributed by the team to the organization. Executives will challenge every dollar allocated to what they see as context efforts, and try to divert them to the core; i.e., adding new products, expanding to new geos, etc. That is their job, after all, and they will struggle to understand why your context team needs such heavy investment. [1]

I propose we look into three areas to answer the dreaded question, “Is it worth it?” when defining your budget for your QA team for 2026. Each of these should be seen only through the lens of QA:

1. Feature Delays due to Quality Control bottlenecks.

2. Churn due to low Product Quality.

3. Reputation damage due to Incidents.

The mindset when answering these questions should be always the same: we are optimizing for future revenue, above all. That means, we know our team needs to be lean, and we commit to constantly optimizing costs.

At the end, a short story on how this looked for me in the past, and how a high-level company mindset would help you define a successful team.

First: Gather the data

In preparation for the conversation, you should make sure to gather all available data on the points for your discussion. This needs to be comprehensive and unbiased; you must do your best so this data represents the business reality.

Each area has a slightly different group of stakeholders you need to talk with, which is where your SETIs and QA Analysts can help.

Feature Delays due to Quality Control Bottlenecks

Meet with your SRE or DevOps team and ask them to help you collect metrics that explain to your organization the challenges of not having QA, e.g., building the wrong solution, or involving QA late in the process, i.e. why shifting left is important. A few metrics I’ve used in the past:

• Time from pull request/code merged until deployment
  This is very tactical, but it's easy to translate into how effective we are as a team. You could run your CI pipelines in 5 minutes, and all automated tests could be flawless, but if deployments are only twice a month, then there’s something in the QA process that needs to change.

• % feature rollbacks
  If you are rolling back features often, it means that your practices are not mature enough when either defining or validating those features internally; both require QA involvement early on.

• Avg. time from project conception to full launch
  Related to the above, even if you’ve caught issues before a user ever sees them, the problem may be that your involvement is so late in the process that features take months to be delivered. Again, add a point for shift-left.

Churn due to Low Product Quality

If you read my last article, this is why Customer Support should be one of your best friends. They have the knowledge and expertise to help you communicate the challenge properly. They can provide you with:

• NPS overall for users.

• Expenditure on discounts, rewards, or other financial compensation given to customers due to issues with the service.

• Actual churn due to the quality of our product. For this, make sure they include the category in the forms they give to leaving customers.

Reputation Damage due to Incidents in Production

This is when you talk with marketing and sales reps, and you get a sense of the following things:

• General communications sent to the customer base on topics regarding quality.

• How important is quality for your ICP? A good product marketing team should have these quantified based on interviews.

• Marketing investments done with a messaging around quality.

Armed with all this information, you should now have an understanding of what’s at stake if your product lacks quality in certain areas. For example, you can now argue why the onboarding flows should be flawless, because your users might not use the product if something fails there, or justify why payments could be handled manually, and the QA investment there should be nil.

Second: A fireside chat with Finance

Your finance leader may not care about delivery velocity, or they may equate churn attributed to low product quality with bad customer support; or they may argue the value given by the product is so overwhelming that product failures will be dismissed even if your quality drops. In many respects, it’s a controversial topic.

The difficulty, from a data-minded leader's perspective, is simply that we wouldn’t know if we could have gotten away with similar results with less investment. That’s what a CFO would articulate, and I would say most of us would agree. If you are faced with this conversation, then now is when you flip the script: we agree, let’s experiment!

Option 1: Lookback Analysis

My preferred option, and the good news is that you probably have this information already: Examine those rushed new product launches.

During those crazy launches, you purposely skipped QA practices simply because you were willing to afford it, and the results were self-explanatory. I’m sure your issues spiked immediately, and after 6 months, some of the largest projects were consuming 4x costs in infrastructure, and deliveries were equally delayed. Those 'successful' product launches give you a blueprint of the cost of skipping QA. They are a playground where expectations from your customers are also low.

Option 2: Show Me the Money!

If the objective is to experiment with new tools and processes to reduce costs while sustaining productivity, what you need is a budget to make that happen. You’ll likely need someone working on this full-time, and you’ll also need to try new tools and frameworks.

This is where you commit to a plan and align on how much you are willing to invest and for how long to achieve a clear goal on cost reduction or increased effectiveness.

This is your opportunity to get promoted. If you show you can build a better organization that’s more cost-effective, then you are on the path to being a key asset in your company.

Third: An innovative QA tactic, revenue generating

Let’s imagine you get a chance to present the budget plan and 2026 roadmap to your executive team. They are going to be interested in cost-effectiveness and how to reduce churn; that will make them feel satisfied with the department… and you can do them one better!

You can build an extra case around delivery velocity, and how that could open the door for your team to deliver multiple projects with high quality and customized features to unblock deals without dreading a release will hamper the rest of your system. This could have such a positive impact, i.e., imagine telling a customer that their special fix will take 2 days instead of a month. That even though you would agree it requires consistent investment from the engineering on writing and maintaining tests and infrastructure, you’ll want to do so for the upside alone.

Again, to prove the above you should set an experiment, define how you are going to measure success across the organization, and track those metrics to show this has paid off. For us, it was winning deals because we would implement features in hours, instead of months, and customize flows in minutes, without endangering all our users. Having tech not to be a bottleneck for sales was seen as such a competitive advantage that the investment in the area kept steady for years.

This takes me to my real life example.

A team without QA

In my whole career, I only hired 1 QA leader, and when I hired that person, whom I already knew, I hired them to run the SRE, IT, Sec&Compliance, and QA teams. Why?

Because my objective was to have them so busy with other things that automating Quality Control and teaching the art of Quality Analysts to Tech, UX, and Product, would be their only reasonable path forward. He was in the job for 3 years, we had a team of ~60 engineers at peak, and he never hired a single other person with a QA background. We did hire SDETs, SREs, and trained many others to cover aspects of the QA function to create a QA culture.

You can think this is a fairy tale, but let me show you our metrics and how we defined success:

Northstar: 0 business-critical incidents per Q.

With an incredible idealistic Northstar we defined those KPIs that would get us closer to the goal.

• 1 user reported an incident per quarter max.
  This is key. We didn’t care as much about having issues in our app unless a user reported them. There are two things you should keep in mind though:

  • Given how we implemented CI/CD in an extremely strict manner, CFR and other standard metrics weren’t as meaningful for us.

  • I’m not including anything related to monitoring and alerting in this essay, but there were matching metrics to ensure we were tracking everything meaningful happening in our app in real-time.

  
  Also extremely important, we tracked how many issues we fixed proactively, ie. we would actively fix issues that were blocking users before they reached out to us, and we would notify them once everything was taken care of. That would be tracked as a great achievement in a separate board. There’s nothing better than to reach out to a customer and say: “we’ve seen you experienced a challenge, it’s fixed,” or even better if they never even realized the issue.

• 5-minute CI duration
  This meant running 1500 end-to-end (E2E) tests in under 5 minutes, you can imagine the efforts on parallelization, ephemeral environments, and infrastructure to run these tests in a team of at most 60 individuals.
  All worth it, because as you know, while engineers tend to trust passing test results, they often retry failing tests a number of times and consider failures followed by passing results as flaky. By reducing the length of the CI pipeline, we save hundreds of hours a year, as each minute saved has a multiplying effect. For example, 1 minute saved here for a team of 60 potentially represents 10+ hours saved per week; thus going from 30 minutes, to 5 was an incredible achievement.

• 1-minute rollbacks
  Whenever an issue was detected we would rollback. As fast as possible, as automated as possible. That meant all changes—configuration, flags, db migrations, etc.—needed to be tightly coupled in a single release, and all services needed to be backward compatible. This gave us the confidence of knowing that if we released frequently enough, we would be able to revert mistakes in seconds.

• 95% E2E coverage
  Test coverage is a vanity metric, but the main concern here was: “have we automated 95% of the tests defined for this product?” For different products in different maturity stages, we oscillated between 80-99% coverage.
  It would hold us accountable, and by defining these e2e mandatory tests sets in our design and launch documents, we were able to hold ourselves accountable to the quality we needed in each area.
  This was the enforcement tool for our QA leader to make sure the organization was learning.

The byproduct of these ambitious targets was that two years later we had 2.5 million fully automated E2E test runs per month, from a base of 1500 automated E2E tests. On top of that, we had unit tests, integration tests, and image diff tests to provide more comprehensive coverage. All that was supported by a community of dedicated Software Engineers, and one individual who had this as their main core responsibility. We’ve done deployments at crazy hours with extreme confidence.

The-one-thing: Cost - Quality - Speed.

Counterintuitively, when discussing budget allocation for QA, you need to fix Quality by means of feedback from Marketing, Customer Support, and Sales, and you should center your plan around Speed & Cost. Don’t discuss ideal Quality standards; leverage the voice of your customers. They define what Quality is acceptable. Shift the conversation to what you can do to increase the effectiveness of the team, and talk about velocity and costs for the whole organization.

References

How do you test your tests? (Probabilistic flakiness) - Meta DevInfra
Is Software Security a waste of money? - Schneier on Security
Push for QA as your devex powerhouse - E.-
No ROI? No Problem - Richard Bejtlich
Capchase Communities Blue-print - E.-
Security ROI - Schneier on Security
Core vs Context - Geoffrey Moore
ROQI Calculator - desplega.ai

tl;dr: As AI progresses, the bottleneck shifts to testing fast & well. We argue for splitting the traditional QA role into two strategic functions: QA Analysts, who ensure you build the right thing for the customer, and SETIs, who build infrastructure for devs to ship safely and fast.

Your team is coding faster than ever, and now what was a team of 10 feels like a team of 50. The CEO wants to go even faster, and that has resulted in your CTO pushing for bigger releases, still every few days, maybe a couple of weeks. Flash-forward 2 months, and now you are sitting with Customer Support & the Account Management team. The quality of your flagship product is dropping, and a top customer is about to churn. Now you are in a battle of wits with Product, Customer Support, Sales and Engineering. The blaming dance commences.

Have you seen the blaming dance? I’ve been there. QA says they didn’t have time to review, Engineering says Product wanted it to be released ASAP, Product points at Sales, at best, or back at QA at worst. Sales says ‘isn’t it your job to deliver things right?’. You walk out of the meeting with the certainty that your team is now going to be only doing Quality Control. There’s no time to code, so you have gone back to a team of testers.

You wish it would end on that Defect Escape Rate1 increase since you started using Cursor, it’s not. It seems your leaders think with AI you can do more with less, it’s time to reduce your department costs. So not only are you seeing your DORA metrics spike, you need to do more with less. This isn’t a feeling, it’s a trend, e.g. the 2024 DORA report found that while AI boosts individual productivity, it has been linked to a 1.5% reduction in delivery throughput and a 7.2% decrease in delivery stability.

Personally, I’ve been faced with challenges like this in QA, HR, Data, SRE, Growth and many other orgs, and I’m going to tell you what worked in all cases: reframe the problem, think big, think positive. All that summarizes in a single question:

Each of those times, I found these 3 questions helped me distill what we needed next:

(1) What are you doing that you shouldn’t be doing?
(2) What should you actually be doing to have more impact long term?
(3) How can you shift motivations in your team to make (1) & (2) happen.

Below you can see this plan laid out to move QA beyond QC, a plan that took me 1yr to implement with a 60 people team before the AI revolution; be patient.

First: Fight the Illusion of Quality Control.

If your organization still thinks of QAs as testers, or simply release gatekeepers, it’s key to explicitly name those activities. You need to equate Quality Control activities with ‘toil’ for the engineering team. The key here is to show your peers that these activities are a particular implementation of a broader vision of Quality Assurance. Avoid stepping into exactly what QA is, for now focus on naming each Quality Control activity your team does.

Start by building a list of any and all repetitive tasks that happen once the code has been written, e.g. writing tests, lint, image diff, static code analysis, build, deploy in staging, canary, feature flags set up, etc. Armed with that list, bring your SRE or DevOps team onboard so together you can have a shared, unified, understanding of what are Quality Control activities in your company. For example, you could say Quality Control groups staging monitoring, alerting, performance, all testing, static code analysis, etc. Believe me, they’ll be excited to see you understand the pain of their daily work, and how their time should really be invested in building better infrastructure.

With SREs as allies, start small, educating teams, presenting the difference between Quality Control and Quality Assurance. Add some Engineer Managers to the conversation, and introduce a key core concept: Accountability. At this point you need to have a discussion on who will be accountable for Quality Control. This is why the SRE team can help you, they implement the tools for logging, monitoring, alerting, etc, but Engineering uses those frameworks. Quality Control should center on the same, you provide the tools you don’t enforce the implementation.

At this point, naturally, people are going to start asking themselves what is Quality Assurance; which leads us to step 2.

[Note: It’s important to know you are defining Quality Control for your Company, and you could use arbitrary terms, like Accidental QA, if that simplifies conversations].

Second: Frame QA as an Engineering org-wide Practice

You need to make an effort to remind everyone about a key aspect of Quality Assurance, it comprises avoiding delays not just problems, and customer satisfaction. The defect prevention aspect differs from the defect detection aspect of Quality Control and it is what has been referred to as a shift-left.

You should harness the core concept of shift-left, not into human hours saved by detecting a defect early, but by the reputation damage and potential loss-of-revenue that could result from building and shipping the wrong product. I recommend you use 2 data-points to accentuate the message:
(a) In 2024 alone, these costs were estimated at 2.4Tn in the US alone, the pain is real. You can find similar numbers for whichever geo you are focused on.
(b) Approach customer success & sales, ask them how often they need to waive fees, give discounts, or lose customers because something wasn’t shipped in the right way; either late, faulty, or improper solution.

Those two above translate immediately to mission critical business needs, defined as a need for effective and efficient product delivery.

The final step in your presentation is to translate QA into two key areas that bring value to the company:

1. Quality Analysis (Essential QA)
   Working closely with Product and go-to-market to understand the customer needs.
   QA needs to understand beyond features, the quality and the service expected from customers. That way you can define guardrails for the organization, incl. non-functional requirements, that will ensure your releases are effective.

2. Quality Control (Accidental QA)
   Working closely with devex to accelerate delivery in the ‘right way’. QA is also responsible for providing the tools and frameworks for efficient releases. You’ll collaborate closely with SREs, Engineering and UX to provide that infrastructure that would guarantee fast releases with the right quality, or even faster rollbacks.

We have defined a new scope, it’s time to re-shape QA to have impact across the organization.

Third: Implement The QA Executive Playbook

You’ve done it! Everyone understands how Quality Assurance has a broader scope and it shouldn’t be a gatekeeper, instead it should be an enabler. Now, let’s outplay Tech!

You need to bring it all together with flawless execution, to have company-wide impact and become a powerhouse. For that, you need to ensure you have top performers building strong foundations in each area. Timing is of the essence, every effort you do during the next 3 months needs to be successful so your credibility grows, and it’s going to be impossible to do this alone.

1. Building bridges
   A Quality Assurance Analyst needs to work extremely closely with Customer Support, UXR, Account Managers, Product Managers, and any other person that works directly with customers. If you can spend 10hrs a week listening into customer calls, do it! Your team needs to become a subject matter expert on the needs and expectations from customers. (My hack: Listening to Gong Calls instead of podcasts)
   
   Please make sure to have a clear scope early on: focus on understanding what are those customer needs above all, much less on how to solve for those. This team needs to fall in love with the problem, as solutions should ‘surprise them’ .
   
   Two KPIs to track here: NPS (esp. for new features), and # valid tickets from customer support (think of DER).
   

2. Delegating until it hurts
   Your Software Engineer in Test & Infrastructure team (SETIs) should invest all their time on building the infrastructure so software engineers can implement their own tests, and their managers have visibility on how well they are doing so.
   
   You can always start with quick wins like adding Image Diff, improving record-replay API tests, or adding a new low-touch, no-code, provider.
   
   The KPIs I like to start with are proxies for change-lead-time, and change-failure-rate.

The-one-thing: No-one should be a tester.

Stop asking for your testers to do better and faster, instead teach them how to have exponential impact. Divide them in at least two groups, those that have affinity with technology, and those that have affinity with the product. The former should be trained to become SETIs, working closely with SRE/DevOps, and driving delivery acceleration. The latter need to transition to QA Analysts, with a deep comprehensive understanding of the customers and company vision. They should center on user satisfaction.

Doing only one will render you exposed to the whims of your leaders, and if you manage to do both, congrats! You are on an executive path!

References

1. I Stopped Writing Code. My Productivity Exploded. - Yash Poojary

2. AI in Software Testing: How Artificial Intelligence Changes - testfort.com

3. “The Role of Artificial Intelligence and Machine Learning in Software Testing” – Ramadan et al., arXiv

4. “A Multi‑Year Grey Literature Review on AI‑assisted Test Automation” – Ricca et al.

5. “QA and SDET is the Safest Job during AI Boom (2025 Market Analysis)” – prepare.sh

6. “What Are The Differences In These Positions: QA, QE, and SDET?” – WolfCareers

In this new landscape, I started making a key distinction when talking about tasks, and quality is no exception. For this article, I would call that distinction Accidental vs. Essential QA (yes, I love Frederick Brooks’ ‘No Silver Bullet’).

Accidental QA should be delegated

Accidental QA is the realm of crash-finding, negative testing, and safety rails. Accidental QA has been fading away for a while; it is where your agent swarms can have fun, and potentially you could go deeper with more deterministic approaches.

• Automated exploration & fuzzing.
  Meta’s Sapienz runs tens of thousands of UI-level tests daily, surfacing actionable failures fast—proof that random exploration at scale can find real issues before users do. Antithesis is a good example of a continuous reliability platform that autonomously searches for problems in your software within a simulated environment, ideal for server side applications. [5]

• Static analysis & policy gates
  To catch dependency, security, and style regressions automatically—prerequisites that DORA finds correlate with stronger delivery and organizational performance when paired with solid CI/CD. [1]

• LLM-assisted test coding (not generation).
  LLMs are fairly good at generating simple unit tests to check a well-defined set of inputs, if those inputs were defined by you, or if they are instructed to try a large enough set of input/output pairs. However, this is a sore point. Autonomy in these systems has shown that naïve generators bless buggy behavior because their oracles are designed to pass; that means early design choices prevent them from finding real bugs. [6]

So yeah, the light "random walk + guardrails" check, performed by your smoke test layer, or a lazy jr QA intern could be fairly replaceable. We’ve known for a while that CPUs are good at "Try a lot, fail fast, report (somewhat) clearly." If you haven’t, you should automate this aggressively to reduce your change failure rate without burning human cycles…

Waiting for QA should never happen again, but it’s not the actual strategic bottleneck.

Essential QA is your moat

During my early days in the industry, I dreaded when my CEO, VP, director, Staff PM, etc, would try my functionality. Everything worked, everything looked ok, I would argue I would even have done what they told me to do… but it was obviously at fault, because the photo tile was too small, they couldn’t share that document with two different sets of friends without making copies, or any other arbitrary distinction. I did learn fast that it was that eye that made them who they were in the organization, the visionaries.

This is no different with AI code generation.

Birgitta Böckeler’s recent experiment on autonomous AI code generation consistently achieved "well-tested" code [i.e., great Accidental QA with high coverage, unit/integration/E2E suites]; yet the actual functionality diverged from the intent as complexity grew (the examples were fairly small). They also noted E2E suites "can’t cover all test cases" and that gaps in requirements led the AI to filling in assumptions.

If this reminds you of the old days, it’s because this is the old lesson from Frederick Brooks: the hard part of software is the conceptual design and specification, not the syntax. He framed it as essential vs. accidental complexity (surprise!), our tools can reduce the accidental, but the essence (deciding what the system should do) remains stubbornly human. LLMs are good at guessing what you aimed to say, however the context needs to be transferred so that guess is more informed; this is extremely relevant for complex scenarios where multiple answers could be “right”. [7]

Alas, the human challenge!

If LLMs have taken away the need to code these paths, then what you really need is to train your QA Lead – be it a QA professional, a Product Manager, an Engineer or an Ops person – so that they can actually deeply understand what your customers want out of this new feature. That way they would be defining at a higher level those paths your acceptance tests should follow, and those go beyond a static stage of the product.

So if you ask me, it’s time for another extreme shift-left in QA. It’s the time to ensure your organization puts the work in the acceptance criteria; this is the heavy work. Because in the same way that ML became about data cleansing & optimizing loss functions, if coding fades away, the relationship between customer needs & crafting perfectly balanced acceptance criteria will become the talent moat.

The-one-thing: Divide and conquer

Automate the "Accidental QA" layer ruthlessly, and put your best PMs and QA leads next to customers to make acceptance criteria heavy, executable, and non-negotiable. That’s how hopefully quality will become part of your revenue engine, not a cost center.

References

1. Accelerate State of DevOps Report (DORA) — Google Cloud / DORA Research.

2. Quantifying GitHub Copilot’s Impact on Productivity — GitHub Research Blog

3. "Writing Code Was Never the Bottleneck." — ordep.dev.

4. "How far can we push AI autonomy in code generation?" — Birgitta Böckeler

5. "Sapienz: Intelligent automated software testing at scale." — Engineering at Meta.

   1. ACM Survey

6. "Design choices made by LLM-based test generators prevent them from finding bugs." — Mathews & Nagappan (arXiv:2412.14137).

7. "No Silver Bullet: Essence and Accidents of Software Engineering." — Frederick P. Brooks, Jr. (1987).

8. "Make Something Heavy." — Anu Atluru, Working Theorys.

9. "Given-When-Then." — Martin Fowler (BDD / Specification by Example primer).