Twelve pages.

At least this one is only twelve pages.

It is the seventh document I have received today. A steady stream of PRDs, technical specifications, incident reports, and QA testing plans. Each one looks impressive. They are thorough, professionally formatted, and full of tables, edge cases, diagrams, and implementation details.

At a surface level, they all seem smart and comprehensive, and it gives the confidence that the organizational engine continues to churn. Work continues moving through the process.

I pull up the latest PRD. It is long, however, and I have a growing pile to get through, not to mention all the other tasks on my plate. I put it into AI and ask for a summary, risks, and priorities. Once I get the response, I then take the time to roughly conceptualize the project in my head and ask a few questions and validate several assumptions. AI assures me that the requirements are clear and the important specifics have been accounted for, so I sign-off with a few notes that someone downstream should validate certain implementation details.

The PRD is asynchronously handed off to engineering and design. Design uses AI to build out assets and mockups. Engineering uses AI to turn it into a technical plan. QA runs it through AI to generate acceptance criteria.

Work is underway.

Faster than ever, a pull request comes in, the code is done. Copilot has already reviewed it and left a series of notes about error handling, naming, and possible edge cases. After some back and forth with a few coding agents, the code gets the approval of AI and another real human engineer and it moves to testing.

QA uses AI to help validate the implementation against the acceptance criteria that AI generated from the AI-generated PRD and designs that AI distilled from someone higher-up’s AI stream of conscious notes. The PM signs off. Design signs off. QA signs off. All are real humans.

The feature goes to production in record time.

A day later, we roll it back.

Several events are missing. Important data is not being populated. There is a duplicate-record bug that can allow someone to create multiple accounts, and even if it had gone out, we learn that the feature was not actually what was envisioned by the key stakeholders at conception.

The next two weeks are spent triaging, level-setting, and trying to figure out what happened.

Meetings are scheduled. Requirements are clarified. Ownership is debated. Tests are added. The team goes back through the original documents and assets, and discovers that some things were never specified, other things were technically specified but interpreted differently, and a few critical assumptions existed only in someone’s head or not at all.

Eventually, we ship the feature again. But now it has taken much longer than it should have. Multiple stakeholders are frustrated. The team has lost some trust in the process and in each other.

Still, from the outset, every individual step appeared to move faster.

The AI Slop Spiral

AI has changed the way we work.

This is not coming. It already happened.

It is an enormously powerful tool. It allows people to write, research, analyze, design, and build things faster than ever. A single person can produce an amount of work that would have seemed absurd only a few years ago.

But AI has also made it much easier not to think. Worse, it has made it possible not to think while producing something that looks very much like thinking.

A twelve-page PRD gives the appearance of rigor. The corresponding technical specification is filled with jargon and detail that exudes understanding. A set of polished mockups makes it look like the user experience has been carefully considered. Forty acceptance criteria look like comprehensive and well-thought coverage. A pull request with dozens of comments and several follow-on commits looks like a careful review.

We live in a world now where none of those things mean that anybody understands what is being built. More to the point, none of this means that at any point did the team have a shared understanding of the work being done and its impact area.

An AI product requirement document begets → AI mockups and assets begets → AI technical specification begets → AI acceptance criteria begets → AI-generated code begets → AI code review begets → AI testing. It is a game of telephone played between teams and within teams, with AI participating at every step. Context is compressed, transformed, expanded, and then transformed again, and shared understanding is lost along the way.

I call this The AI Slop Spiral.

Artificial Confidence

The real danger is not that AI produces bad work, to be fair, humans have always produced bad work. The danger is that AI produces work that looks finished, and is powerful enough to finish it, in whatever way that means.

It turns a vague thought into a polished document before the thought has been fully formed. It fills in the gaps, smooths over the contradictions, and confidently supplies the details that nobody actually discussed. Those details may even be reasonable, but reasonable is not the same as agreed upon.

The more polished the output looks, the less likely someone is to challenge it. And the more AI-agents one is managing, the less time there is to monitor closely. A messy two-page document invites questions. A twelve-page document with headings, matrices, diagrams, and a section called “Edge Cases and Failure Modes” creates the impression that the questions have already been answered.

So people skim it. I skim it. I get so much of it lately, I’d be doing nothing but reviewing documentation and code all day if I didn’t. Then we ask AI whether the document is complete, and AI, being very good at evaluating documents as documents, tells us that it is.

This creates a kind of artificial confidence throughout the organization. The PM assumes engineering understands the requirements because the PRD is detailed. Engineering assumes the requirements are settled because the PRD was approved. QA assumes the expected behavior is correct because it was pulled from the PRD. Leadership assumes the process is working because output is up and tickets are moving faster.

We are all supposed to be getting a 100 percent productivity increase from AI, so we need to show results. Any back-and-forth between humans starts to look messy and slow.

Everyone is locally correct. Sometimes we even have the meetings. Everyone walks through the documentation, agrees that it makes sense, and says we are ready to move forward. Because AI told us it was good. Everyone can point to the document they created.

Instead the project fails and the organization has produced a perfect record of nobody understanding the whole thing.

“Use More AI”

We are all complacent in this to a degree.

Nobody wants to fall behind.

There is a fear that exists in every technology hype cycle, but it is especially intense with AI. There is the fear of missing out, the fear that competitors are moving faster, and the fear that another company has discovered some magical new way of working while you are still holding meetings like an idiot.

So the direction comes down from the top:

“Use more AI.” “Maximize tokens.” “AI first.” “Ninety-nine percent of code should be written by AI.” So on and so forth.

These instructions are usually vague because no one actually knows what the correct implementation looks like. If they did, the instruction would be more useful. It would identify which work benefits from AI, which work requires direct human judgment, what success looks like, and what failure modes should be measured.

Instead, AI usage itself becomes the goal.

This is encouraged by the marketing coming from AI companies, consultants, investors, and executives who do not have to live inside the daily reality of making these systems work.

They see the demos. They see the benchmark improvements. They see a person build an application in fifteen minutes. And with everything screaming at you that AI use is the golden key that will unlock all potential in existence, well then of course everyone should be using AI.

Then downtime increases. Rework increases. Costs increase. Projects somehow take longer. People lose track of how the systems work. Nobody can explain why productivity feels worse when every productivity metric appears to be improving.

We are maximizing output and assuming that output is the same thing as progress.

AI is very good at helping us maintain that illusion.

Humans Are Lazy

All that said, this is not really an AI problem, it is a human problem that AI is very good at exploiting. Humans are lazy creatures, all told.

We are also creative, intelligent, adaptable, and incredible. But given the choice between deeply understanding a complex problem and generating something that looks like we deeply understand it, many will often choose the second option. And AI makes that choice incredibly easy by letting us be lazy while appearing thorough.

Better yet, the laziness is often mandated by the company. We are not skipping the hard work. We are “leveraging AI.” We’ve been told non-stop that we need to be at the forefront of AI usage. This is a win-win.

Except the feature does not work. Or it works in the happy path but quietly corrupts data. Or it launches in two days and takes the next month to stabilize. Or six months later, nobody understands the generated system well enough to safely change it, and what was once a simple solution has become exponentially more complex.

The problem is not that AI wrote the code or the document. The problem is that a person accepted responsibility for something they did not understand.

Recently, I started asking people to walk me through the documents that they send my way. Whether that's a PRD, or code, a testing plan, or something else. Get in a meeting with me and walk me through it, non-async. Talk it over as a team. Make sure the shared understanding is not implicit but explicit and make sure AI is not involved in at least that part of the process. And every single time, we find something important.

Sometimes the author cannot explain a section. Sometimes they clearly did not read all of it or really understand every piece written. Sometimes the document says something they do not agree with. Sometimes two people have been using the same words while imagining entirely different behavior.

It’s been wild.

AI Is Not the Enemy

I know this whole thing may make me sound like an old man yelling at clouds about how things aren’t what they used to be. Let me be clear: I am not anti-AI. Quite the opposite. I am pro-AI. Case in point: I used AI to edit this very blog post. The important word there is edit. I wrote the initial version myself and had AI clean it up afterward, and I edited it again after that. I'm still figuring out how to best leverage it with writing, but I figured it was a meaningful exercise to undertake when writing this specific post.

AI is a world-changing technology. It is an extraordinarily powerful tool, and I use it constantly. I want my teams to use it. I expect it to become a normal part of nearly every technical and creative workflow.

Even as it stands, my hyperbolic doomsday examples aside, it has generally been a huge net positive. But, as they say, with great power comes great responsibility. Anything with this much potential for change is going to come with a period of adjustment, along with new problems created by the change itself.

But it is not a magic wand. Even when we build AI-forward shared context systems for teams to use on every project, such that theoretically nothing gets lost and we are all operating under the same context models, we end up losing context through laziness, AI hallucinations, documents contradictions, and there are any number of other ways information gets distorted or quietly dropped along the way. We are still figuring out how to solve that.

So What Do We Do?

I do not have a complete answer.

I am not going to stop using AI, and I do not want my team to stop using it. Banning AI would be both unrealistic and stupid. But I do think we need to step back and become much more honest about what it is doing to our organizations.

As I mentioned earlier, I have started with something simple: if you hand something off, you present it.

A PRD, a technical specification, a testing plan, or a meaningful piece of code. Walk the other people through it. Talk about it together. Let them interrupt. Let them ask the questions. Discover that three people have three different definitions of the same sentence. Realize what has been written coherently, actually makes no sense and no one actually knows what it means.

At the same time, in life, sometimes the problem can be the solution. As technology continues to evolve, as we learn into the ways AI affects scalability and organizational efficiencies, we may optimize the best way in which to leverage it at scale.

Perhaps traditional role segmentation makes less sense in a world where AI is doing more of the work. If handoffs and the loss of shared context are a problem, why have so many handoff points? In theory, one or two people could use AI to act as the PM, designer, engineer, and QA, maintaining the full context from the idea through implementation and validation. That kind of end-to-end ownership has historically been a startup superpower. The question is whether AI now makes it possible at a larger scale.

In the meantime, my team is continuing to build out an internal MCP server and the surrounding systems, with the goal of making sure context is shared and understood across projects, teams, and tools. We are trying to build a human version of the same guardrails and harnesses we use to make AI perform well: reliable context, clear boundaries, useful tools, and some way to verify that the system is operating on the right information.

In the big scheme of things, this technology is still in its early stages. There will be growing pains, and they will show up in all kinds of ways. The internet completely changed how we work, but the deeper organizational changes came well after the technology itself had matured. Technology can change quickly. People and organizations change much more slowly. You can fight that reality, or accept it and optimize your teams, processes, and systems around it while working toward a better and brighter future.

Or at least a less sloppy one.

The CTO turns to me with a self-assured nod, ‘TensorFlow seems like the optimal solution here, and the investors are excited by the possibilities’.

Silence fills the air for a moment while I gather my thoughts. I manage to make a quiet strangled noise in response. This is not what I was hoping to hear.

At the time, TensorFlow was the new hotness for machine-learning models. It was at the forefront of the AI “boom” and every engineer (and every investor) was hyped up to utilize it in one way or another. Recommendation system? Obviously TensorFlow was a no brainer. AI was the future, after all.

Had anyone on the team used TensorFlow before? Nope.

Did we have the amount and type of data that would be needed to make the recommendations meaningful? Not yet.

Was this feature an important, core part of the app? No, it was something to test if we could increase conversion.

Despite my objections, the project went forward with an AI solution, took triple the time estimated, generated odd results that were a pain to debug, and by the end, was simply replaced with several SQL queries running on a daily background job. The SQL query recommendation system took only a few days to implement and worked just fine for what was needed.

The AI-powered engine was quite exciting, but its complexity eclipsed its usefulness and wasted a lot of time and money as a result.

Suffice to say, it was not a boring solution

It goes to show that as engineers, as leaders of engineers, and as people creating new products and tools, our “stack” should be as boring as we can make it. When I say “stack” I don’t just mean the tech stack (though that is a part of it), I mean codebases and systems, as well as processes and team structures. The stack of machines, tools, code, hierarchy and tech that we create to push ideas out into the world.

In the case highlighted above, it seems obvious that the solution was overkill for the task, but it can be harder to see that when you’re in it. It is tempting to use the latest tech, bleeding-edge systems, or hot new databases to power our projects. The background decision makers generally don’t like being bored. Engineers don’t like being bored. And if you’re a startup, part of the VC and investment opportunity is fueled by not choosing boring technology. In this way, we wind up with a Kubernetes Service Mesh using Istio as the answer for an app with less than one thousand users. All built out from the start just in case the thing we are building is the next unicorn startup.

Most of the time, you don’t need a service mesh, you don’t need Kafka, and it’s pretty easy to see why. But like everything else, there are tradeoffs to be made, considerations to take, and unique factors to consider. So how do we choose the right level of boring?

What even is boring?

People usually miss the point of “boring”. Boring tech does not imply boring products or ancient languages. Boring simply means minimal surprises.

In any suitably large project, your codebase will start to introduce complexity whether your stack is boring or otherwise. The advantage with boring is that if there is an issue, it’s probably something that you’re able to fix in your own codebase. If not, you can Google it, and it’s likely that someone else will have already tackled the issue. Boring also means you can set alerts and thresholds for the common issues that pop up at scale, and you can prepare for the unknowns more efficiently because the unknowns are on a well-trodden path.

With boring, it’s easier to know what you don’t know. The more moving pieces, the newer the tech, and the more interesting things get, then the more we have things we don’t know that we don’t know.

It seems obvious, so why do we often end up with such complexity?

The drive to optimize

The systems that we create could often benefit from the latest tech or new types of databases. Things could scale better, be faster, and generate better results. Many problems we encounter could be solved more directly with a different set of technologies than the existing ones the rest of the company is already using.

This is the trap of local optimization. The optimal solution is, in many cases, not the right solution. This seems counter-intuitive, so let’s look back to our recommendation engine. The AI-powered engine would have done a better job and given more personalized results than our SQL query solution. It was the optimal solution, but that didn’t make it the right solution for the task.

Local optimization is extremely tempting, no matter who you are. It’s easy to reach a point of frustration and start thinking along the lines of ‘why are we using old stuff when we could just use new stuff and ship it in the next week?’

This happens to engineers of all levels because local optimization does give you a boost. You can solve your problem easier and ship faster. However, in exchange you often end up with a long-term cost that eventually moves the organization in a direction of shipping less. It’s not that innovative technologies are wrong, it’s just that you have to think of the tradeoffs before diving into the “best” solution.

When using boring, well-established technology and tools, the limitations may indeed hold back solving the problem optimally. This can be especially hard to take when we know there are better solutions out there. We’re all about using the right tool for the job, but tools come with tradeoffs and in the vast number of cases, the right tool is what you are already using and what you already know.

There’s a time and a place for complexity. And it’s often much later than we think.

When to be interesting

I’m not arguing to only be boring. There are legitimate reasons to add complexity, and we can explore a few of them.

Sometimes the problem does warrant it. For example, the problem could be central to your product and have a huge impact, so it’s worth the extra effort and complexity.

Sometimes you want to explore newer tech or languages to keep engineers happy and help with hiring. Hiring is no joke, and you need to have a level of interesting tech to attract talent.

Sometimes the most boring things cost extra. Tools and systems that are reliable and easy are often expensive. New Relic, my favorite performance monitoring solution, is not for the thin-of-wallet. Heroku which makes Devops for simple web applications a breeze, has the same issue.

Sometimes you need to scale big. You may have millions of users or thousands upon thousands of requests per second. This necessitates a more complex architecture to handle the load.

Sometimes you need to sell the idea. People are fascinated by the newest trends. We see this everywhere from AI to Bitcoin, and more recently biotech and health-focused tech. You may have an easier time convincing your boss, an investor, or a team if you piggy-back on this hype. It may seem like one of the sillier reasons to increase complexity, but at the same time it can be one of the most important ones. If getting your investment relies on using the latest technology or newest database, well, you’ll probably be using it no matter how complex.

The Meaning of Boring

We’ve gone over what boring means, when to be boring (i.e. most of the time), and the tradeoffs of boring versus interesting choices. We have seen how when the goal is to ship a stable product, complexity must be carefully considered and controlled. Choosing boring over optimal, and well-known over new, is not always an easy or satisfying choice, but it can often be the right one. In this way, the more boring our code and tech is, the more room we give our products to be interesting.

Each person’s boring stack will look different, and it should always depend on the team and situation. What’s your boring stack?

Like the article? Check it out on Lead Dev!

Such accusations, and likewise similar sentiments, are being heard around offices with increasing frequency. And the saddest part is, the code is usually not particularly shit. What does that even mean? Could it have been done better? Of course! Most code could be better, and given infinite time and resources would have been. Sure there is some bad code around, we've all seen it, hell we've all written it, but that isn't even the issue here.

The issue is one of having a "this is shit" culture.

It is a culture that I am seeing become more and more common in the web community. Continuing the example above, when I asked my coworker to explain himself, explain why is the code shit, I couldn't get a straight answer.

"It just is, look at it" he replied puffing himself up further and further, his brow furrowing as if I must be half-witted for not being able to comprehend the amount of shit that is the code. And you know what? I start to feel half-witted. I can barely stop myself from scoffing along with him and extrapolating on just how smelly and brown this code we are looking at really is.

Before I go on, I realize this story doesn't paint my coworker in the best light. So let us fix that. He's a great guy. Honestly one of the nicest people I have ever met. He is friendly, has a family he loves to talk about, runs marathons, helpful, smart, etc etc.. Another thing about him: he is a relatively new developer. He is still learning the basics, and this is nothing to be ashamed of, we have all been there at one point. I happen to find myself there on a weekly basis and I've been doing this for some time now. So why would the first instinct of a nice, smart guy who is working on his first large web project be to accuse some code of actually being shit in disguise before even trying to understand it?

Rule of life: the shit flows downward.

This problem is not isolated to just newer developers. Many experienced people act the same way. You can be an amazing, seasoned developer and still have a negative affect on your team and project by behaving in such a manner. Even more so because the newer members look to you as a source of knowledge and experience. And the more people who embrace the "this is shit" culture, the easier it becomes acceptable and even desired. Soon developers are revered not for contributing to the project, but for putting down other's contributions to the project. The most vocal and negative developer soon becomes the most respected developer. Everyone suffers, the project suffers, and a few people get to pat themselves on the back and feel great about themselves for being so full of shit.

So why do we do it?

No one wants to feel stupid, and no one wants to feel inferior or bad at their job. Once a "this is shit" culture starts to spread one of the only ways to make sure that you are on top is to put down others. In the end it is a culture that values negativity rather than focus on solutions.

So what is the solution to this particular problem? Stop it. Don't blurt out negative assessments of others code for no reason, and with no understanding. There are ways to bring up issues with the code base that are not mean spirited. If there is some smelly code out there, look for ways to make it better. Start by understanding the code, and then find ways to improve upon it. If you start to notice a negativity trend in your own projects, don't adhere. If someone says to you "this code is shit" ask them why, and then go through and work on making it better. Talk to the person who wrote the code originally, perhaps there is a reason why they did it that way. Work with your teammates not against them.

Next time I notice a suspicious smell wafting from my monitor, I'm going to turn to my coworker and ask, "How can we improve this?" Because, lets face it, sometimes code is shit, but that doesn't mean we have to be too.

Like the article? Join the discussion on Hacker News!