We often assume that writing more code means creating more value. We track lines, tickets, and hours. We set up dashboards that reward output and celebrate speed. We call busy weeks good weeks. This approach puts teams in a constant cycle of cleaning up after problems instead of preventing them.

Now, this problem is only growing as AI accelerates code creation, making it harder for us to keep up. As we leave crunch culture and endless nights at our workstations behind, those tasks are shifting to our synthetic colleagues, the agents.

This evolution brings us, the human developers, to a crossroad. Are we destined to become janitors in this brave new world? Have we all just gotten a demotion?

But before diving deeper, I should clarify: this is not a continuation of the New York Times hit piece with the same title from 1914. Though the name is the same, the issue today is entirely different.

Crunch culture of the past promised us glory, but often delivered only bleak copies. People worked late and shipped familiar things with fresh names. The original work came from rooms that were allowed to think, not from rooms forced to sprint on fumes of endless caffeinated beverages. This culture shaped how we value output today.

We quietly know this, and yet we still push production toward throughput. We hire a machine for its sheer speed, then pretend that speed, magically, will become quality if we stack enough hours on top. That math never worked, not then nor ever.

The result? We get churn and fragile code, a rising tide of maintenance work that feels unending.

Every line of code you write adds risk. And most likely future work down the line. The codebase needs security, tests, refactoring, and ongoing attention. And, at some point, it will cause problems that need to be fixed.

Therefore, we should value removing code as much as adding features. We really should recognize people who simplify systems and clean up unused parts. After all, a busy week is not always a productive week.

AI itself is not the enemy; it is a valuable tool that helps us code faster and handle routine tasks, such as writing test scaffolding or documentation. The real issue is cultural: if we use fast tools while still prioritizing quantity over quality, we create more problems. We must keep human judgment central, using AI specifically as support for repetitive work, not to add unnecessary complexity.

This problem gradually worsens and accumulates over time. A stakeholder asks for a feature they saw in a presentation. An AI model suggests several versions and a script to add them. The team accepts the draft from the agent without checking the impact. Soon, multiple services depend on the feature, leading to late-night alerts. The team spends time maintaining something that was never really needed. New work gets delayed because old work keeps causing issues. And we all feel worse because of it.

To address this, the solution is to slow down and be deliberate. Before adding a feature, ask if it matters and who will maintain it. Write a short summary with clear goals and a stop condition. Use AI to draft the flow, then reduce it to the essentials. We should ship only what helps someone right now. Remove what adds maintenance but no value. Once things are stable, add small improvements. Focus on quality first; quantity will follow.

A key part of software development is deciding what not to build. Yet, our tools tempt us to write code easily, making us forget this discipline. While shipping new things excites us, we should equally value deleting, merging, and simplifying. There is satisfaction in combining routes, removing unused flags, and replacing custom code with well-tested packages. Making systems smaller and simpler is valuable work, and we should recognize this.

Importantly, we’re not alone in this effort. Our synthetic friends, the AI agents, can support us, not just by writing more code, but also by identifying problems before they multiply.

Ask your agent to list duplicate patterns, spot hidden complexity, or show what can be removed safely. Use it to map dependencies in an easy-to-understand way and make a plan to remove the most painful issues first. Let AI handle the drafts to save time, but keep important decisions firmly in human hands.

Humans need to stay responsible for the code. Accepting machine-generated code without understanding or accountability leads to problems. It might work at first, but it makes us worse over time. Developers should know and own the code they ship, and teams should clearly share this responsibility. After all, AI can write code, but it cannot take responsibility for it. (Not yet, at least)

If this sounds like less output, that’s the point. We should aim for less code, with greater clarity, as it leads to longer-lasting systems. Simply put, Sustainable software is easy to maintain.

We should measure what matters: how many services a feature touches, how often users have to reload, how many unnecessary alerts occur, and how long it takes to remove or rewrite code. These numbers improve when we focus on quality over quantity.

Maintaining code can feel less important than inventing new things, but it is not. Protecting the system’s quality is valuable work. Like a librarian or a city worker, you keep things running and usable. Developers should take pride in this role when it is respected and rewarded. We still create new things, but we also take care of what we build.

Teams can build this culture with small steps, starting by celebrating code deletions. Share a weekly update about something removed or optimized. Set aside time to clean up unused flags and logs, review dependencies, and remove any that are not needed. Reward maintenance work that reduces distractions, and write incident notes that focus on the impact on people and the code changes made.

Architecture also needs protection. AI can write parts, but it cannot see the whole system. As such, the design should be simple. Systems that fail in predictable ways are simply better.

Avoid clever solutions that cause big problems, and design so that code can be deleted easily. Use clear module boundaries and keep a short glossary of key terms, and regularly review what would happen if a part were removed. This makes cleanup easier and keeps the system calm.

There is a risk that tool makers will promote quantity as success. They will offer dashboards that track lines of code and features shipped. Leaders around the world may celebrate, but the software teams will struggle. The real solution is to change what we measure. We should value code deletion, time to remove features, quiet on-call hours, and safe test failures. These metrics show if the system is healthy.

A team I worked with tracked commits per week and felt productive as the numbers went up. But the app got worse. Users had problems, and bugs kept coming back. So instead, we focused a single sprint on refactoring, cleaner code, and better maintainability. As a result, the productivity numbers dropped, but the app quality improved. Bug reports got sparse, and complaints went down, overtime hours disappeared, and the team felt proud of their work again.

If your codebase feels overwhelming, take immediate action. Remove one unused feature today. Merge a module. Write a test to catch a recurring bug. Use AI to find duplicate or dead code and identify safe deletions. Then make those changes, document them, and ship. You will instantly see the benefits and feel more productive.

When we treat software as something to care for, our approach changes. We clean up, reduce noise, and make space for thoughtful work. AI can help with the heavy lifting, but people make the important decisions and keep things safe.

AI is helping us code faster, but by default, it does not help us build better. Yet it could, if we change our culture. When we keep human judgment at the center and use tools to reduce cognitive load, we can move from worshipping quantity to praising clarity. If we treat features like guests, keep the pager quiet (yes, I’m that old), and value code deletion, we set ourselves up to truly embrace the future.

The janitorial problem is both a warning and an opportunity. The warning: speed without discernment makes us cleaners of endless churn. The opportunity: be caretakers who defend sustainable code. We can choose to add less, and celebrate when ‘less’ makes the system stronger and more human. That is not a demotion; it’s a promotion in how we think.