This is the first article of Beyond the Coding Assistant, a multi-part series on AI-assisted software engineering at enterprise scale. The full series is available free of any paywall at https://articles.zimetic.com. Coming next: Article 1 — Your AI Coding Assistant Is Not Enough.
The last few years of AI-assisted development have been remarkable. Coding assistants have crossed real quality bars. Engineers can now produce working code, in unfamiliar languages, against unfamiliar systems, at speeds that would have looked like science fiction in 2022. There are real productivity gains, real new affordances, and a real shift in what an individual developer can do in an afternoon.
And yet — when the conversation turns to the team and the organization — the picture is more complicated. The dramatic gains many leaders were promised haven't shown up on every team. Some teams ship more. Some teams ship the same. Some teams have actually gotten slower, with the AI helping at the keystroke while the wider delivery metrics regress.
That gap, between what's possible at the keystroke and what's actually showing up in delivery, is what this series is about. The question I want to ask, and try to answer over the next several articles, is simple: what has changed, and what changes could take us so much farther than where current AI coding assistants have brought us?
A state-of-affairs question, not a tooling complaint
It would be easy to frame this series as a critique of current tools. That would also be wrong. The current generation of coding assistants is genuinely excellent at what it does. The problem isn't that the tools are bad. The problem is that the tools are designed for a single role on a much larger team, doing a small part of a very large multi-step process.
Software is shipped by teams — developers and product managers, designers, QA engineers, technical writers, program managers, security reviewers, compliance reviewers, devops, and more! Most of those people either don't write any code, or don't spend most of their time writing code. If the goal is team throughput rather than individual keystroke speed, optimizing one role's tooling is only going to get you so far. Instead, this series is looking at how we build tools and restructure the team and its workflows for the dynamics that are here today and will be here in the near future.
There's also a structural part of the story that's only now becoming visible. Token economics are shifting. The "burn-through-it" approach that worked when tokens were essentially free is getting expensive. The teams that have built disciplined development practices around AI tools are pulling away from the teams that haven't. None of this is anyone's fault, exactly. It's the natural moment in a maturing technology when the next set of questions starts to bite.
Where the series goes
I'll work through this in four parts.
Part I — The Shifting Landscape. Why now. The crafting of code is the visible tip of the iceberg, and I'd like to address it and the rest of the iceberg — much of which isn't touched by current AI tools. Recent studies have shown that many teams are actually getting slower with AI, so we will talk about that and why it's happening. And of course the economic changes that are forcing the question of how to make this work economically. And finally, the quality-speed-cost trilemma that frames everything after.
Part II — Reframing the Problem. If the team is getting slower with our current SDLC and processes, are they the right processes for the team going forward? One of the key aspects of the Agile Manifesto was that we continue to improve our processes. So, we owe it to ourselves to evaluate whether the processes we built for a much longer coding step are still the right processes today. Let's also bring into view better ways to use our coding agents as we start to consider having them take on more and more of the SDLC. One of these changes is the true implementation of multi-pass workflows. We will also discuss why different kinds of work need different workflow shapes, and the benefits of specialized agents instead of generic workers. And then we will discuss how organizations may want to manage compute and AI resources in pools that engineers can utilize in a much more economical and controlled manner.
Part III — Design Principles. The coming economic changes are going to make cost a first-class constraint. They are also going to require us to manage the project's context in different ways than we have had to in the past, so that we can get optimal performance and cost effectiveness out of our agents. Managing our shared resources gets more complicated as we start to have pools of agents updating things in parallel. And of course, we need to make sure we are doing all of this in ways where the engineers are not being overburdened, and the entire team gets to come along in a meaningful way.
Part IV — The Road Ahead. I will share some of what I'm building and why I think it will move us forward. But let me reassure you: this series is not a sales pitch for that tool. It is more my way of sharing my thoughts on the state of the industry as we make this monumental transition, and what I think is happening. Feel free to skip Part IV if you are not interested in my tool, but please don't skip the discussion about how our industry is changing.
Each piece stands alone. Read in order, they build a cumulative argument: the next frontier of AI-assisted development is lifecycle orchestration, not better code generation — and it has to serve the whole team, not just the engineer.
A note on tone, and an invitation
These are my thoughts, based on what I'm seeing and hearing across the industry. They're claims, not conclusions. I have opinions and I'm going to defend them, but the whole point of publishing in public is to sharpen the ideas against readers who disagree. Your feedback is welcome, and desired.
I'm also building a tool that applies these ideas. I'll describe it in Part IV, and I'll keep references to it brief in the meantime. The series is about the ideas first; the tool is one way to test them. My goal is to get you thinking about these ideas, these changes and get a dialog going so we can all learn and grow in a meaningful way.
How to follow along
I will be publishing three articles a week (Monday, Wednesday, and Friday), with the goal of having the entire series published in four weeks from start to finish. Feel free to drop by on a regular basis, or to sign up for notifications when articles are published. A hosted landing page at https://beyond-the-coding-assistant.ghost.io/ lists all of the articles in this series, including the expected publication dates of the upcoming pieces. That's the home for the free, paywall-free reading copy of the series. Bookmark it if you want to follow along; subscribe if your platform of choice supports it.
Coming next: Your AI Coding Assistant Is Not Enough. The iceberg of non-coding work, why current tools concentrate almost all their value on a fraction of the engineering job, and why "make the developer faster" is a local optimum that's already running out of room.
If you've read this far, thank you. Please join us for the ride.
Top comments (0)