“Sure, why not?”
I find myself saying this phrase to myself way too often these days. Ever since Claude Code and Codex started getting abandonment issues, eagerly suggesting next steps, new ideas, continuations, anything to keep the session going.
Often they are not bad ideas. They are interesting feature ideas, bug fixes found when touching adjacent code, quality of life improvements, logical continuations of the work we just did. Things we used to call scope creep. Things a senior engineer would catch in a code review and condescendingly tell you to address in a separate PR, or better yet, file as a ticket for the next sprint planning. Things that would add days or weeks to a team’s schedule.
These things now just make me go ‘sure, why not?’, and I tell my agent to go ahead. Because it does feel like a logical continuation. It’s so easy, so available, so perfunctory. Yes, why wouldn’t I add a cache here if it’s going to speed things up as much as you say it will. Surely there are no side-effects to consider. Yes, why don’t we update this dependency that you briefly touched in your change, it is a few versions behind.
In a way it feels like an appropriate continuation of the infinite scroll we’ve grown to love and hate in our favorite social media apps. Why think about what comes next? Just take a seat at the slot machine, and keep pulling the lever.
Who we are
Our company, Drippa, was born in January 2026, just as AI-coding started really taking off. As experienced software engineers, tech leads and engineering managers, my co-founder and I had been experimenting with coding agents ever since they were okay-ish. With Anthropic’s Claude Opus 4.5 launch in November of 2025, coding agents were suddenly great. Amazing even. We had just resigned from our roles as engineering managers at IndyKite, and were setting out to tackle the new bottlenecks we had seen popping up as software teams adopted more and more tooling.
In hindsight, the pace of change we had seen at that point was nothing. People were pushing out features a bit faster, sure. Simple bug fixes could be done without really looking at the code. Refactors were less of an inconvenience, but still had to be babysat. But when we hit the ground running in January, software engineering as we knew it was flipped on its head.
We were in an interesting position in the midst of all this - we were a brand new company starting from scratch, total greenfield in the way we operate, no tech debt, no old processes, no ingrained politics. Born at the start of the AI-era. At the same time, the very challenge we set out to solve, and build our product around, was the new challenge of building products in the AI-era. That presented us with the opportunity to find our own learnings, hacks and best practices, and turn them into products.
However we are a small, newly founded startup. We are still only three people after all: two builders and one growth wizard. Thus many challenges (un)luckily didn’t apply to us, so in order to learn about them, we needed to have a lot of conversations.
We spent the better part of the first half of 2026 having conversations and testing prototypes. With software engineers, tech leads, engineering managers and product leaders in a wide range of tech companies. Small and large, US and Europe. They all had new, different, urgent bottlenecks to share. As coding was now close to being “solved” for all intents and purposes, they felt new pains on either side of the process - before and after the implementation work.
The Game of Telephone
On the side before code, we heard from product managers that they were struggling to prepare enough work for their engineers, who were now supercharged with AI. The engineers were smashing tickets at blazing speed, and were now resorting to scope creep sure-why-not-driven-development to keep themselves busy, riffing on ideas and random improvements with their agents, only loosely tied to their roadmap and product strategy, if at all. Scaleups and mid-market companies claimed planning and scoping of work to be their largest inhibitor of speed. They had rolled out agentic coding tools to all their engineers who were now coding and implementing and pushing faster than ever. So fast that they were running out of things to do. The product managers had to create new tickets and product requirements docs (PRDs) in a hurry, which thus were quite underspecified and lacking in context, leaving the details up to interpretation. Pair that with less time spent on reviewing and testing, and you’ll easily see an increase in bugs, and decrease in customer satisfaction.
The journey from “customer asked for X” to a ticket ready enough for implementation is generally quite long, political and manual in non-trivial companies. Bug reports and fixes are usually quite concrete, constrained and easily scoped. But very few teams can have an idea for a new feature or a new change, perhaps based on a number of recent sales calls where prospects all said kind of similar things, or from competitor analysis, or perhaps just a product manager’s showerthought, and just hand the idea to their engineers, unpolished, unscoped, uncontextualized. That’s when interpretations happen, and you run into the language barrier. Not the spoken or written language, but the technical language. Do you remember the childhood Game of Telephone? Where a message is whispered from person to person around a room, resulting in a hilariously changed final statement. Most tech companies with non-trivial complexity play the Game of Telephone every day. Engineers constantly have to interpret what they think the product manager actually meant when they wrote the requirements. They are probably described at a high level, and are influenced by customer conversations the engineers haven’t even read the transcript for, and there are many possible ways to interpret how the requirement fits into the system architecture. So the engineers ask the product managers for clarification, but their questions are too technical, too shaped by the APIs and services they work with every day, details the product team are only aware of at a surface level. And so the Game of Telephone is in full swing, with packet loss at every exchange.
Customer
Sales
PMstatus=overdue or due<now()?”
Engineer
AgentThis game has been a source of frustration, hair pulling, loss of sanity and consumer of time in every company I’ve worked at in my career, long before AI made its debut as a software engineer. It’s a common problem that shows up in every company in various forms. Sometimes alleviated by process, sometimes alleviated by hiring very product-minded engineers, or engineering-minded product people. But in any case, it has been a major bottleneck for every product leader we spoke with. And it’s only exacerbated by the post-AI increased pace of development. When you can run faster, you just get further away faster, if you run in the wrong direction.
When you can run faster, you just get further away faster, if you run in the wrong direction.
This process was previously helped by implementation being slower, allowing teams to catch misunderstanding and discrepancies underway, in the myriad of syncs and standup updates that would occur as part of their cycle. Not anymore.
Move fast and test on your users
On the other side, as more and more code was written by or with AI, at a faster and faster pace, review and communication was becoming a problem. Again, processes that previously were masked by the time it took to actually implement changes. Senior engineers complained about spending a disproportionate amount of their time reviewing pull requests that were more frequent, more plentiful, and more verbose than ever. Product managers who needed to do user acceptance testing became the next buildup in the process. Finally, customer success and sales teams suddenly had too many features and changes to learn, sell and explain to customers. A pain also felt by product marketers tasked with maintaining and communicating a cohesive product strategy in this new rapid pace of software development.
We found that small, nimble, AI-pilled companies, stereotypically the type that consists of a group of “cracked” engineers all bunking together in a small San Francisco apartment, would solve most of these problems themselves, some simply by virtue of being a small, very aligned team. But even for them, code review and testing appeared to be a bottleneck severe enough to cause issues. For some in slowing them down, because they actually did want to continue to review and test. For others in decreased customer satisfaction, because they didn’t want to slow down, and thus let their users be their testers, mitigated by the fact that they can also push fixes just as quickly as they can push suboptimal or broken code.
That was us. We would prioritize just getting new things out there as fast as possible, and figured we could revert, update or fix it just as fast if on second thought it didn’t make sense or didn’t look good. It became almost addicting to “just try it”, to follow Claude’s next suggestion for improvements or continuations of a feature we just added. The problem was that we rarely prioritized the time to give these changes a second thought - that became our customers’ job. Which they didn’t sign up for, and were not happy about. With the abundance of software being produced now, buyers are becoming extremely allergic to slop and half-assed products. The bar is no longer just a useful product that solves a problem, it needs to look and feel well thought out and put together. You need to convey inklings of a cohesive product strategy at least. It became clear to us that we needed to shape up.
An illusion of control
As an AI-native startup born in the AI era, 100% of our code is AI generated, and has been since day one. When we were starting out I at least read through the diff, looked at the files and functions that were added, removed or edited. It gave me an illusion of control, I could pretend I was somewhat aware of what was going on. I convinced myself that I would be able to catch poor choices and weird patterns this way. But I’m now of the firm opinion that this is the worst way to do software development. Either write everything by hand the old fashioned way, or resign yourself completely to AI tooling. Doing both is the worst of both worlds. Code review fatigue of lengthy, frequent and verbose pull requests will get the best of your engineers. And since going back to writing code without AI-assistance obviously leaves a lot on the table, utilizing AI tooling to solve the new problems caused by agentic coding is the only way to go in our experience.
Doing both is the worst of both worlds.
For us, that means maintaining a “product brain”. A company brain consisting of a structured collection of all our company context, with a bias towards anything related to product development, available to all of our AI tools. It helps us collect, sort and cluster signals coming in from customers and market research. Providing us (and our agents) with ideas for what features to focus on next, based on what our customers are asking for, and what’s happening in the market, and with competitors. This makes prepping and scoping work for our engineers and their agents much easier and more efficient, avoiding scope creep and random ideas implemented without evidence.
Great, now we know what to work on, we can do that work faster, and we have enough context to avoid going down the “sure, why not?” rabbit hole with Claude. Now we need to review all of these new glorious features. Not just for bugs and syntax. That’s rather easy, with all the unit tests and checks Claude likes to write and perform, coupled with a code review bot that runs on the pull request.
But user acceptance testing is still a thing, and arguably more important than ever. Did we build what we set out to build? Did it satisfy the requirements we set during planning? Was there scope creep? Is taste retained in the change? Did we follow our own design guidelines? More times than I can count, I have been working on a UI change where the end result is technically correct: the button I wanted to add was added, and works the way it is supposed to, but it just looks… off. To save the time and sanity we would normally have spent jumping into every staging environment, to review and sign off on changes, we implemented agentic user acceptance testing and QA. Multiple agents who run through an actual running preview of the change, with different tasks in mind. A few examples include:
- Design and taste. Checking that the change follows the brand and design guidelines and mockups presented in the planning document.
- User stories. Checking that the feature works as expected, satisfies the requirements, goals and non-goals of the PRD.
Most changes will be accurately reviewed by our agents and we can just wave them through. In some cases the agent will flag something that looks off, could use a second pair of eyes, or something that is just flat out wrong, and ping us to clarify. When we do clarify something, or correct the agent, this gets written back to the product brain, improving the process for the next round.
Lastly, assuming all is implemented according to plan, per the specs, looks good, is tasteful etc., there is still a lot of stuff being pushed. So much so that it’s tricky for both internal and external stakeholders to stay on top of everything, know how to use it, speak about it, sell it etc. In search of a solution to this problem, which can be classified as release management, we had the genius idea to re-use our aforementioned review agents. They already walk through and test the features the way they were intended to be used - so we just had them record and narrate the process. Saves us countless demo meetings or Loom recordings to showcase new features and changes to the internals and externals.
Generally all of these efforts can be summarized as alignment. As a fast moving, albeit small team, it is of utmost importance to us to stay aligned, especially as we are all working remotely, to lift the rest of the organization to the new pace of engineering. For ourselves, and for our customers.
Who will watch the watchmen?
Who cuts the barber’s hair? Which agents can be trusted with reviewing the work of agents?
As our go-to-market strategy expanded into enterprise and other categories of customers with stricter compliance requirements and vendor approval processes, we recently kicked off the process to become SOC 2 Type II compliant. Which has been an interesting, archaic and somewhat comical process when we are as AI-native as we are. Manually recording evidence, often in the form of time stamped screenshots of settings pages, has felt hilariously analog given most work in our company is agentic. And on many occasions, some of the controls and requirements have given us pause, as they make less sense in this new world. For instance, one of the controls asks about human reviews and gates on code changes to production. A sensible requirement. Something no one would even bat an eye at a few years ago. But when agents, or a group of agents, write all of the code, and another group of agents review it, how do you satisfy that control? Taking it one step further, is the premise of the requirement even still sound? Can humans accurately review this code now? It almost becomes philosophical, and feels similar to the question of safety and accountability in autonomous driving vs. human drivers. Autonomous driving is undoubtedly safer and less prone to mistakes, but the accountability of it feels weird and lacking.
These compliance processes feel ripe for disruption in the age of AI, so ripe that if they were fruits they would be falling off the trees. Which is why it isn’t surprising that we have already seen so many AI-native startups pop up to tackle this space. Some arguably disrupted too much, and had too much faith in AI’s role in reviewing work and being accountable. But let’s not delve into that.
Compliance departments love forms with checkboxes that can sign away blame and accountability, and I don’t expect that to change anytime soon. In the meantime I will live on the edge and stay compliant by signing off on my agents’ work, aiding the process with my army of review agents that will report to me what I need to spend my ever-decreasing attention span on giving an extra look.
Sure, why not?
This article has described a myriad of new pains and bottlenecks that have unveiled themselves in the wake of the software and product development lifecycle becoming AI-native.
Which of these pains are greater, which bottlenecks are more congesting, and where they show up, depend greatly on the size, complexity and AI-maturity of the company in question. But they are present in various forms, and it all feels eerily similar to a game of Whack-A-Mole, where you deal with one, and another one pokes its head out somewhere else.
I believe there will be more variety in how companies deal with these problems than before, and that we will see a wider range of tooling and process setups. Where software companies used to all run on similar agile methodologies for how planning and execution was run, I think we will see more custom agentic setups, with way more permutations available, catering to each company’s unique needs.
We still do sure-why-not-driven-development at Drippa. With the process and tooling and the product brain outlined above, it feels less like the spins of a slot machine, and more like the future of software. The language barrier is virtually gone, ideas are rooted in actual market and customer research, and reviews - with some work - are autonomous enough to get out of the way while being trusted. Now when my Claude, so eager to please and so afraid of abandonment it almost feels human, suggests a next step, I happily say “sure, why not?”.
