@RobGibson20 There’s a pattern a lot of engineering teams have already felt, even if they don’t always have language for it. Initially, AI-assisted development feels like a huge productivity win. Things move faster, boilerplate disappears, small tasks get done in seconds, and the team feels a step change in output.
And then, slowly, the curve bends the other way.
As the codebase grows, velocity starts to drop. Changes get harder to trust, and quality becomes uneven. More time is spent reviewing, untangling, rewriting, and cleaning up work that was supposed to save time in the first place. What looked like acceleration starts to feel like drag.
AI can clearly help teams move faster in the short term or in greenfield projects. The harder question is what happens six months later, when those fast decisions have accumulated into a codebase people actually have to live with.
Many teams are happy to talk about the early gains. Fewer are willing to talk about the mess that can follow: code that looks plausible but doesn’t fit the system, abstractions introduced without real justification, duplicated logic, fragile patterns, and a growing layer of output that nobody fully understands. In other words, slop.
”We did a full mechanical study of all the diffs that had been written over time and figured out what slop looks like. Broadly speaking, it’s the agent not respecting the architectural principles of the codebase that already exist.” – Alistair Pullen, CEO + Co-Founder
The fundamental danger of AI slop is that it creates bad momentum.
Slop gives teams the feeling of speed while quietly increasing the cost of every future change. And because the decline is gradual, it can be hard to spot until it’s already become part of the development culture. The team is still shipping, but with less clarity, less confidence, and more hidden maintenance burden.
Judging productivity by maintainability
At Cosine, we’re unusually direct about this problem.
We’re not interested in pretending that all AI-generated output is a net positive, or that short-term velocity is the same thing as long-term productivity. They are not the same. If a tool helps you move quickly today but leaves you with a tangled, inconsistent, or less secure codebase tomorrow, it hasn’t solved the problem. It has delayed it.
That’s why this conversation matters so much for engineering leaders.
Legacy in software is not just old code, but the accumulated record of how a team thinks, what it values, and what it leaves behind for the next person. Good engineering means understanding the past and building something that will stand the test of time. Any tool that claims to improve productivity should be judged against that standard, not just against the speed of its first week.
”You need to know what it’s doing under the hood. You need to make sure that what it’s producing is readable, maintainable, and extensible on the other side. That’s what we’re doing here by making sure code quality is a first-class citizen, not a secondary priority.” – Niall Devlin, Cosine Engineer.
Generating code that remains useful inside a living system is the challenge that Cosine is tackling head-on. That requires judgment, context, and tools designed to work with the long-term realities of software, not just the excitement of the first prompt.
Download for Mac