I've recently started getting served outrage content videos from software engineers upset about AI coding. I want to share my thoughts about this content. I want you encourage you to watch the videos, to take them seriously, and to think about why coding with AI is such a divisive issue.
Hot takes and priors
I find these AI coding videos almost addictive. I watch all of them.
Part of my fascination here might just be the novelty of a good debate. I don't usually get served outrage content because I don't usually care publicly about topics that attract outrage. Similarly, because I try to buy my way out of advertisements wherever possible, I get transfixed by commercials at bars or airports or waiting rooms. I have no resistance, no immunity.
But it's more than that here. I'm interested in AI outrage content because it is relevant to me as a software developer. My day-to-day has changed dramatically. I have feelings about it. I need to decide how and whether I want to make software in the future.
However, it's especially relevant to me as a startup founder. Not only do I need to decide how I want to make software myself, it's ultimately up to me to guide my little ship through this moment, to decide how I want my startup to make software, what that means, and how we do it together.
Bad times. Good content!
While some AI coding content creators are absolutely chasing the algorithm with sound and fury, most creators in the category, like @lzsthw or @atmoio above, hold sincere dim views of AI coding.
I believe them when they say that they feel useless, when they say that AI is removing the joy from their work-lives. The cynicism (milk that shit), conspiratorial thinking (AI ceos are coming for you!) or eschatological bluster (two weeks until the bubble bursts!) is nothing surprising. You can find this same type of talk in every ILA union hall quaking before port automation, or any other industry in the process of being disrupted, everyone vowing to charge double as contractors when the machines inevitably break down.
I don't think I need to "take a side" here in order to point out that these videos are pathetic in the strict sense. It's sad to see proud people who have developed great skills and expertise, and who took risks and made sacrifices in order to achieve that expertise, suddenly feel like the special and useful parts of themselves don't matter because of greedy stupid people who can't tell the difference between good work and bad. Even worse when the output is only marginally better than it was before, where a 10% improvement is earned by grinding expert coders into a thin prompt-and-review paste.
It's also pathetic in a funny sort of way to see developers pivot to creating "we're fucked" content for other upset developers, however I appreciate the hustle and know how hard it is to argue with the algorithm. There is a huge audience for this content!
So okay—pathetic—sure———but not merely pathetic.
I think people are smart and rational, most of all my esteemed colleagues in the field of shape rotation. We're not finches. Development is knowledge work and our minds are marvelously plastic. So I think there's something to be learned from this content, and I think you should watch a lot of it, especially if you're in a position of leadership, in order to learn what that is.
Here's my working theory.
My working theory
If you squint like I've squinted at AI coding outrage content, I think you'll see a pattern. Engineers are despairing over AI coding because they're stuck on projects where AI is legitimately boring and harmful while also being unable (for whatever reason) to move to projects where AI would be helpful and where they could develop new skills.
Squaring this content with my own year(s?) of AI adoption in software development, my current working theory is that:
there are old-world projects where adopting new AI tools is extremely difficult, limited, and sort of miserable because the project is still designed for pre-AI development; and
there are also new-world projects where adopting AI tools is extremely interesting and even joyful because the whole challenge (from an engineering standpoint) is to build systems that fully leverage AI to deliver high-quality software.
In other words, the vast majority of software projects are not designed to benefit from AI, while at the same time it is possible (and interesting) to design software projects that would benefit greatly from AI.
Old world
For example, if you're using an issue tracker, assigning tickets, creating pull requests, reviewing code, running CI, making preview deploys, and continuously deploying off of a pristine main branch, then it's not super useful to have Claude rip through your backlog and create 200 pull requests. The system in which this code enters is not designed for it: you'll get stuck reviewing, your automations will choke, your preview deployments will be ignored, and everyone will feel bad.
Even if your AI code lands, if there is an expectation on the project that the engineer who made the change understands what they've done and is able to explain it in depth, then the adoption of AI coding tools is a serious risk to the project. We shouldn't pretend that engineers have the same understanding of code they generated. Heavy use of AI tools in an old-world project will undermine the understanding and, if the project's quality relies on its developers really knowing the code, which most do, then that quality will track downward as understanding falls.
If you're still operating in a project that is set up this way——and almost all projects are—then I think you should push back against adopting AI tools or practices beyond what is actually beneficial to the project. If you're in leadership, then you should listen to your engineers and accept that your existing projects will only actually benefit from superficial use of AI tools: bug scans, research, completion, scripting, and so on.
There are, however, other, newer, types of projects, where this is not the case.
New world
What do I mean by new world?
I mean a software system where the inputs come in the form of intent—requirements, constraints, purpose, design, feedback, or bugs—and the outputs are delivered to humans in the form of applications or other systems in the form of services; and where everything else, everything possibly handled or accelerated or managed by AI, is automated away.
Oh, and the product needs to be excellent. Fewer bugs, better documentation, more robust than anything you've ever made before. You should be shooting for perfection here.
While you temper your expectations of what AI can bring to existing projects, you should at the same time be using every reasonable opportunity to design new projects or re-design old projects that leverage AI in a way that looks completely unhinged from the shoreline perspective of your father's father.
It is entirely professionally appropriate to create and advocate for "new world" projects wherever you can, because there lies the future.
But how
Whatever you see on X or hear at a conference, we're nowhere close to a set of mature practices that maximize the potential of AI tools while still producing good software products. Every domain, project, and team is a unique set of constraints. Everything, everything, is being figured out and designed.
No one knows, and that's why it's good work! The only thing I've really learned is that a new world project should be free to eject as much as it needs.
As an example, in one current project, I'd asked agents to study the codebase and surface correctness bugs, then create pull requests to address the bugs they found. There were hundreds of pull requests.
As I watched those PRs crunch through through checks and tests and previous deployments, I had time to notice how much of a burden CI had been for our agents. The checks felt like a waste. They were slow and expensive —it's a native app—they were bottlenecking our development. Talking it through, it made more sense to let the agent merge all the code it wanted and then clean it up later.
We turned off GitHub Actions entirely for the project, both integration and deployment, so that code could land instantly without consequences beyond a potentially broken commit. With our main branch no longer driving releases, we switched our releases to a dedicated machine in the office. On a 30 minute tick, the machine pulls the latest code, runs a full suite of checks and tests, and then makes a staging release if everything passes. If things fail, it sends an agent off to fix the problem, hoping that the fix lands before the next tick.
None of this would have been a good idea on the main repo, the tldraw SDK, where our automations, social practices, and culture all demand a slower, more understood process. But on this project it was the right move: a beautiful, awful little system that we'll learn from and improve. I'm sure you'll come up with something better.
Reputational damage and other risks
There is, of course, some risk of psychosis, or at least the appearance of psychosis, particularly if you like coming up with little names for everything.
For the sake of your sanity, consider communicating often with someone who is not engaged in this type of work. For the sake of your ambition, however, be also in contact with someone who is going even deeper than you are. If you can continue working on an old world project, I think that's a healthy thing to do.
Because this is all so new, you should expect to start off knee deep in slop. A key attribute of a good new world project is "slop tolerance", and the more bad is good the better. Internal tools, enablement, corporate side projects, prototypes, exploratory work.
Don't let an interesting process tempt you into giving broken software to innocent people. Remember that your job is to deliver excellent software by using AI to its full potential, in that order. If there's something that the AI can't do well enough, do that part the old way until you figure it out.
In conclusion
I think we all need to be honest about what kinds of project we're working on and whether those projects are actually of a kind that benefits from extreme AI coding, and in which ways. I don't think it is a good idea for half of your team to stop reading the code, or to delegate PR reviews to AI agents, unless the project has been designed in a way where these are not required.
Leaders should acknowledge how disastrous it is to suddenly behave as if every project were AI native. Bad software, demoralized developers. Under-used experts just observing the machines as they badly perform 110% of their old work, which is ironically a fraction of what those same machines could do in a real AI native project.
While AI is sadmaking and potentially ruinous for replacing developers within existing projects and processes, the answer isn't to pull back. AI has made possible new ways to develop software, possibly much better ways, where the technology can be fully leveraged and where engineers can contribute as experts with real work to do.
As a developer, you should be a part of this work. You should get extremely interested in the question of "how do I use AI to make great software" and you should find or create projects that allow you to explore that problem and become obsessed with it.
This is a terrible time to be cynical about new technology. If you like to work on hard problems, to craft solutions, and to design systems that produce value and quality, then there's plenty of work to do.