Execution is cheap, quality is not

I reentered the techverse after 5 months of living in the wilderness to find my world turned upside down. "Oh yeah, we don't code anymore," one of my fellow senior co-workers chided with an incredulous edge. I laughed nervously, eyebrows raised. "What are you talking about?"

Back in February, we were using AI tools but there were clear limits — a delineation between the types of tasks that were "good for ai", and those that still required a human touch. I still opened my IDE, wrote code, perhaps using AI as a pair programmer or reviewer, but I was in the driver's seat. PRs that were fully vibe-coded were limited to the realm of prototypes and heavily scrutinized during review. I still felt fully engaged in the design and problem solving process of creating technical products. I knew that I added value to my company, and saw AI as an augment to my hard-won skills.

Fast-forward to September 2026, reengaging after my sabbatical I decided to take my coworker's lead and began using various harnesses to let AI write code while I dictated and morphed the brief. We had switched chairs. Now I was the pair programming assistant, watching the LLM do all the heavy lifting while I pointed out issues, pushed for polish or suggested alternative approaches.

"We had switched chairs. Now I was the pair programming assistant, watching the LLM do all the heavy lifting"

The agents were good, I mean really good. I was blown away at the models' improvements over such a short time span. In certain repos, we use a multi-layered system where you create with one agent, assign another agent to shepherd the PR and different agent(s) review the work. The real work now is in crafting the brief, deciding the scope of the task and what comes into the session context. I became deeply curious about tracing the boundaries of a well-scoped task. How much ambiguity was too much? What is the right size task for optimal output? For larger tasks that I didn't quite know how to solve, I spawned dedicated ideating sessions to craft the brief which was then fed into fresh sub-sessions to implement. I came to taste the power of utilizing agents like a swarm of surgical tools for precise execution. The challenge now is arriving at the necessary level of coherence to effectively realize your goal.

In "traditional" or human-powered software development, you are often tasked with a problem that you don't quite know how to solve. This is what we coders love — the uncertainty, the puzzle of it all. Experienced developers probably have an idea of how they will do it, but the real work began when you got into the details of the code. You chiseled away at the problem space, identifying new wrinkles to discuss with your team. In a human paced feedback loop, the solution shaped itself. Today, this cycle of reasoning about code through writing it is entirely usurped.

"I became deeply curious about tracing the boundaries of a well-scoped task."

Every engineer laughs at the notion of estimating timelines. This is because we acknowledge the entropy in any system. Even projects that at the onset have a well known shape will morph in reaction to implementation discovery. Humans can't contain all of the complexities of a system in their brain at one time, agents are getting better at this. Edge cases and dependencies are always hiding beneath the surface. And if you are working on critical product paths, extra care is needed to ensure quality and prevent incidents.

The problem now is that our creative feedback loop has transmuted into a "planning session" with a coding agent. High level system design and general decisions about product behavior still occur during human meetings, but beyond those broad strokes there almost always lurks an absurd amount of unknowns. Along the way, developers make microdecisions that affect architecture and products long term. We used to check in about these forks, getting feedback from our fellow engineers during the review cycle. An awareness of the ever-shifting guts of a product was cultivated by a forum of reviewers at a daily clip. It took a lot of time and effort to be truly fluent in a codebase.

Reviewing used to be (and I argue should still be) a big bottleneck due to the lossy nature of context switching. For the reviewing engineer who didn't propose the changes, wrapping their mind around what was entering the system demanded a context loading cost. If you stayed close to a product, this came easily. You could spot things quickly and give meaningful feedback. Sometimes if the team was under pressure, you would give it a light review and offer a disclaimer, "I'm trusting you to make these changes even though I don't quite understand every detail". On a high trust team, this was acceptable. The more work your co-workers did that ran well in production, the more you trusted them to give a rubber stamp.

"Over the course of months, we have garnered a high enough level of trust with agent output and review cycle that we are beginning to treat them like solid mid-level co-workers."

Over the course of months, we have garnered a high enough level of trust with agent output and review cycle that we are beginning to treat them like solid mid-level co-workers. The longer you work this way, the more desensitized you get to not understanding every single line or change. And frankly, we don't have time. The expectations of output for engineers are extreme because "execution is cheap," right?

The software creation workflow now feels analogous to constantly reviewing large PRs on consequential terrain with a mediocre level of context awareness. The deeper you get, you start running multiple sessions in parallel to tackle various angles of a problem at once. Excelling at this involves holding multiple work-streams in your mind, switching effectively between them to lasso context, making good design decisions on the fly, and sensing when things go off the rails. Context switching is certainly the highest deficit in the system now. Weary developers will cede focus territory out of sheer overwhelm. They will defer to to the agents' suggestions without thinking too deeply because they just need to get the thing done.

At the end of a busy day collaborating with agents, my brain feels like mush — there's a word for this, "AI brain fry". Despite pushing a ton of changes, my sense of productivity is somehow lessened because the gravity of ownership now occupies liminal territory. Sure, I spawn the sessions and attempt to remain in the driver's seat, but often I don't feel like I am the one doing the work. It's a flavor of managerial imposter syndrome, with a non-human legion at my beck and call.

"Despite pushing a ton of changes, my sense of productivity is somehow lessened with this way of working, because the gravity of ownership now occupies liminal territory."

A vast divide between the cognitive marathoners and the productive passengers is taking shape in our industry. I believe there is true value in drawing lines around what AI should and shouldn't do for you. If you give way the majority of your cognitive load, then why are you in the seat at all? This murky zone for what comprises "acceptable" AI use is constantly shifting and very personal.

As individuals, it's up to us to decide where we exercise our un-aided minds to create things. How do we engage with the tool — as an all-knowing oracle whose suggestions we blindly accept, or as a highly intelligent assistant? Since at the leadership level the expectation is to use AI for anything and everything — the more the better — it comes down to individual integrity.

Despite whatever productivity gains we correlate with token spend, the research shows that using AI as it's currently designed to complete tasks turns our brains off. We learn less, we don't understand fully what we are making. In the long run this will produce suboptimal results, not only for companies but for society.

We winnow this understanding willingly out of eagerness to embrace the new ways of working, or to meet output demands, or even laziness. Taking the time to engage intentionally to retain a holistic connection to what you are building is a privilege, one that may burn certain developers who feel committed to keeping their brains "in shape".

"This murky zone for what comprises "acceptable" AI use is constantly shifting and very personal."

A deep-seated value of mine is maintaining a high bar in all my endeavors. It disturbs me to ship things that feel half-baked. I advocate for transparent communication and organized process in the projects I run, with enough space for polish and a clear vision of the problem we are solving. Throwing darts at the board and seeing what lands is not the way I want to work. I would rather focus deeply on a problem, feel confident it solves a user (or agent) need, and design an elegant well-scoped solution that can be shipped quickly to get feedback and keep iterating.

In a world where people can create apps and products with very little effort or thought, quality will become the new premium. The market will be (arguably already is) saturated with fractured UX, patched-together infrastructure, and a plethora of mismatched solutions. I believe the argument for quality design across the entire stack is paramount, even more so in today's landscape.

Just because actualizing ideas occurs at a faster clip doesn't mean we should chase every one. I've heard, "if it breaks we'll just fix it with AI," or "if there's no market fit, we'll just sunset the product". If these thoughts are being shared, just don't ship the thing — clearly there's still more product shaping to do.

I was recently discussing architecture decisions on a new product and I countered, "This isn't a clean design", vouching for more modularity. Someone mentioned, "Maybe we don't need to care about elegant under-the-hood design anymore". There's a sentiment circulating: if the end behavior is acceptable, does it matter what the code looks like? For people who care about quality, this is a nightmare.

Making good things requires a lot of focus. While it may be tempting to passively lower the bar, I believe our increased efficiency with AI tools should raise it even higher. This requires a measured approach; you can't split your team or your mind into a million directions. We still need to perform deep research and make well-placed bets, using AI to craft useful and wonderful things for humans and non-humans alike.

"In a world where people can create apps and products with very little effort or thought, quality will become the new premium."

This diatribe could read as a senior developer lamenting "how things used to be". But it's more a reflection of the current reckoning in our industry. I oscillate between excitement and terror, and am genuinely in awe of the capacity of these systems. I am motivated to adapt and expand my working style to effectively manage these hyperintelligent tools, and if I'm being totally honest, of course there is a bit of grief. It feels like something has been lost for the human software developers, but it's not zero-sum.

Loss makes space for new skills and new ways of creating things. I believe there is a way to engage with these tools while retaining our cognitive integrity; it just requires a concentrated effort. I am committed to holding high standards for anything I touch and for everyone on my team. We need to keep one another accountable. Under such loose and rapidly changing conventions, there is ripe opportunity for grassroots dynamics to dictate our working life. I stand behind crafting with care; even if you handed over your chisel, you now have the ability to art direct from a different vantage point.

We still need to do some things "the hard way," to not only produce quality results but retain our value in the economy. The software engineering skillset is evolving into something entirely new, and we're all learning it on the fly while shipping more code than ever.