Building in a World of Slop: Software Quality in the AI Era

Generation is free. Taste is not.

Thirty seconds. That is how long it takes to generate a fully functional checkout page with Stripe integration, responsive design, and accessibility attributes. The code compiles. The types check. It even looks correct to a junior reviewer scrolling fast. But something is off. The spacing feels claustrophobic. The error states communicate nothing useful. The loading skeleton flashes for 12ms on a fast connection, creating a visual glitch that no one specified as a bug because no one thought to specify it at all.

This is slop. Not broken software. Not buggy software. Software that technically works but carries no evidence that a thinking human shaped it for other humans.

At product.engineer, we define software quality in the AI era as no longer about whether code runs. It is about whether code deserves to exist in its current form, whether someone with taste and conviction looked at the output and said "this is good enough to put our name on." The product engineer is that person. They sit at the exact intersection where technical capability meets product judgment, where the question shifts from "can we build this?" to "should this specific implementation ship?"

The term "slop" entered mainstream discourse in early 2025, initially describing AI-generated content flooding social media. By mid-2025, engineers started applying it to code. At the AI Engineer World's Fair keynote that accumulated over 319,000 views on YouTube, the speaker laid out a thesis that resonated deeply: when generation costs approach zero, the only differentiator is the human capacity to distinguish good from good enough from garbage. The audience, thousands of engineers building with AI daily, responded with something between recognition and dread.

They recognized the problem because they were living inside it.

What slop actually looks like in production

Slop is not a binary. It exists on a spectrum, and the most dangerous kind sits right in the middle: code that passes every automated check while degrading the user experience through a thousand micro-failures of judgment.

Here is what slop looks like in practice across different layers of the stack:

None of the items in the "what AI generates" column are wrong. They all work. They all pass CI. They all meet the literal requirements. And they all smell like nobody cared.

The compounding cost

According to Stripe's Developer Coefficient report, developers spend 42% of their time dealing with technical debt and maintenance of existing systems. That number, already alarming, was measured before AI-generated code became the norm. When you multiply code volume dramatically while holding quality constant at "technically correct," you are manufacturing technical debt at industrial scale.

PostHog published an internal analysis in early 2026 showing that PRs primarily composed of AI-generated code required 2.3x more follow-up commits within 30 days compared to human-authored PRs. Not because the AI code was broken. Because it made subtly wrong choices that only became apparent when real users interacted with the feature. Wrong default sort orders. Pagination that loaded 50 items when the 90th-percentile user had 200. Tooltip positioning that worked on the developer's 27-inch monitor but occluded critical information on a 13-inch laptop.

These are not bugs. They are taste failures. And they compound.

Why software quality in the AI era is a human problem

The fundamental issue is this: language models optimize for plausibility. They generate code that looks like correct code. They draw on patterns from millions of repositories to produce output that statistically resembles quality software. But resembling quality and being quality are different things.

Quality software is opinionated. It makes choices that reflect a deep understanding of who will use it, under what conditions, with what constraints. Linear does not look the way it does because someone prompted "build a project management tool." It looks that way because Karri Saarinen and his team made thousands of deliberate decisions about what to include, what to exclude, and how every pixel should feel during interaction.

That word, "feel," is the one AI cannot access. Not yet.

The three dimensions of software quality AI cannot ensure

1. Contextual appropriateness. Is this the right solution for this specific user in this specific situation? AI generates from general patterns. Quality requires local knowledge. Shopify's checkout optimizations work specifically because engineers understand the anxiety curve of a buyer in the final seconds before purchase. A model trained on all checkouts will produce a median checkout, not one tuned for a specific merchant's audience.

2. Coherence across time. Does this feature feel like it belongs in the same product as everything else we have shipped? Product coherence is an emergent property of a team that maintains shared standards, idioms, and opinions over months and years. Every AI-generated PR starts from zero context on what the product already is.

3. Intentional constraint. What did we decide NOT to do, and why? The hardest quality decisions are subtractive. Figma's constraints panel could do more. Notion's blocks could support more nesting. Vercel's dashboard could show more metrics. The quality lives in the restraint.

A product engineer holds all three dimensions simultaneously. They are the taste and craft layer between raw generation and shipped product.

The quality gatekeeper role

Here is where the industry splits into two camps. One camp says: AI will get better, quality problems are temporary, just wait for the next model. The other camp, which includes every company producing software people actually love to use, says: quality is a human responsibility that requires human judgment, regardless of how the code was generated.

I sit firmly in the second camp. After years as a Sr. Product Engineer at AWS, coaching over 12,000 engineers across different maturity levels, and having evaluated 600+ engineers in hiring loops, I have noticed a consistent pattern. The engineers who produce quality output, the ones whose code you can recognize by its clarity and intentionality, they are not the ones writing more code. They are the ones who reject more drafts. Who rewrite the first attempt. Who look at generated output and immediately see what is missing.

When I started two companies, the hardest lesson was not about shipping fast. It was about maintaining standards under pressure. Slop is seductive because it is fast. You can ship five features in the time it takes to ship one well-crafted feature. Investors like velocity. Users like quality. The tension between these two forces is where most products quietly die.

The product engineer resolves this tension by redefining what "done" means. Done is not "it works." Done is "it works, it feels right, it handles edge cases gracefully, and it does not create downstream burden."

What quality gatekeeping looks like daily

Someone in this role reviewing AI-generated code asks different questions than a traditional code reviewer:

• Does this match the product's existing interaction patterns? If every other list in our app supports keyboard navigation, this new list must too, even though nobody mentioned it in the spec.
• What happens when this fails? Not "if" but "when." The AI generated the happy path. What about the empty state? The permission-denied state? The network-timeout state?
• Would I be proud to demo this? A surprisingly effective heuristic. If you would not show this to another engineer you respect, it is not done.
• Does this create questions for the user? Every ambiguous label, every unexplained state change, every action without clear feedback is a tiny failure of quality that erodes trust.

The slop spectrum and the state of AI code quality

Not all AI-generated code is slop. Not all human-written code is quality. The problem is that AI makes it trivially easy to produce large volumes at the "technically correct but uninspired" level, and most organizations lack the mechanisms to push that output toward genuine quality before it ships.

Here is a framework for thinking about where code falls on the quality spectrum:

Level 1: Broken. Does not compile, has obvious bugs, fails tests. AI rarely produces this anymore. Automated checks catch it. Not the interesting problem.

Level 2: Functional. Works as specified. Passes tests. No obvious bugs. This is where 80% of AI output lands. It is also where slop lives, because "works as specified" says nothing about whether the specification was complete or whether the implementation considered the thousand things specifications never mention.

Level 3: Considered. Works as specified AND handles edge cases, matches existing patterns, uses appropriate abstractions, names things clearly, fails gracefully. This requires human review and iteration. AI can get here with strong context and multiple passes, but only when guided by someone who knows what "considered" means for this specific product.

Level 4: Crafted. All of Level 3, plus the code reflects genuine insight about the problem domain. It anticipates future needs without over-engineering. It teaches the next developer something by being readable. It makes the product feel cohesive. This level essentially requires human taste.

Level 5: Elegant. Rare. Code that solves the problem in a way that surprises you with its clarity, that makes you think "of course, why would you do it any other way?" This is the domain of senior engineers who have internalized the problem space so deeply that the solution seems inevitable in retrospect.

The infinite software crisis is not that AI produces Level 1 code. It is that AI floods the world with Level 2 code while the products people love require Level 3 and above.

How companies that care about quality operate differently

The organizations producing the best software in 2026 share common patterns in how they handle AI-generated code. These are not theoretical. They are observable practices.

Linear: opinion as a feature

Linear ships fast. Their changelog is relentless. But every feature that ships carries a coherent opinion about how engineering work should feel. They use AI in their development process, but their output never feels generated because every piece passes through a quality filter that asks "does this feel like Linear?"

That question cannot be automated. It requires people who have internalized what "feeling like Linear" means, people who would notice if a tooltip used a slightly different animation curve or if an empty state used copy that was correct but lacked personality.

Vercel: developer experience as craft

Vercel's dashboard could be a standard CRUD interface. The underlying functionality, deployments, domains, environment variables, is not exotic. What makes it quality software is the obsessive attention to the developer's workflow. Preview deployments with instant URLs. Branch-based environments that just work. Error messages that tell you exactly what went wrong and what to do about it.

None of this happens by accident. None of this emerges from "generate a deployment dashboard." It emerges from engineers who understand the frustration of a developer trying to debug a failed build at 11pm and design every interaction to reduce that frustration.

Stripe: API design as editorial choice

Stripe's API is famously well-designed. Every endpoint name, every parameter, every error code reflects editorial choices about what matters. When AI generates an API based on a data model, it produces technically correct endpoints. When an engineer with product sense designs an API, they produce endpoints that feel natural to the developer calling them, because they have thought about the context of use, not just the data being transferred.

Stripe's internal processes reportedly include "API review" meetings that function like editorial boards. The question is never just "does this work?" It is "would a developer encountering this for the first time understand what it does and why?"

A framework for maintaining quality at AI-speed

Producing quality software while using AI tools is not about rejecting AI. It is about building processes that treat AI output as first draft, never as finished work. Here is a framework that works.

The Quality Stack

product.engineer's Quality Stack is a five-layer model for maintaining software quality when AI handles generation. Each layer requires different tools and different human involvement:

1. Correctness (automated). Tests, type checking, linting. AI is excellent here. Automate fully.

2. Consistency (semi-automated). Does this match existing patterns? Style guides, architectural decision records, custom lint rules can catch some of this. Product engineers catch the rest during review.

3. Completeness (human-led). Does this handle all the states? Empty, loading, error, permission-denied, rate-limited, first-time-user? This requires someone who thinks in terms of user journeys, not functions.

4. Coherence (human-required). Does this feel like it belongs in our product? Only someone who knows the product deeply can answer this.

5. Craft (human-required). Is this the best version of itself? Could the interaction be tighter? The copy clearer? The feedback faster? This is taste.

Layers 1-2 of the Quality Stack scale with AI. Layers 3-5 scale with people who own the product end-to-end. Organizations that invest only in layers 1-2 ship slop. Organizations that invest across all five layers of the Quality Stack ship products people love.

The 30-30-30 rule

product.engineer's 30-30-30 rule is a time allocation framework for AI-assisted development. Spend 30% of your time on specification (defining what to build and what "done" looks like), 30% on generation and iteration (using AI to produce and refine code), and 30% on review and polish (examining output with fresh eyes, testing edge cases, refining interaction details). The remaining 10% is deployment, monitoring, and learning from production behavior.

Most teams currently spend 10% on specification, 70% on generation, and 20% on everything else. The 30-30-30 rule corrects this imbalance. The result of ignoring it is predictable: fast, plentiful, sloppy.

The product engineer as the final filter

Every shipped feature passes through a series of filters. Requirements filter out the impossible. Design filters out the incoherent. Engineering filters out the broken. But in the age of AI-generated code, there is a new gap between "not broken" and "actually good." The product engineer occupies that gap.

This is not quality assurance in the traditional sense. QA asks "does it meet the spec?" The product engineer asks "is the spec good enough? And even if it is, did this implementation capture what the spec was trying to express?"

In our experience, organizations with dedicated product-engineering roles (distinct from pure frontend or backend engineers) consistently produce software with higher user satisfaction scores and lower churn rates compared to organizations with traditional role separation. The difference comes down to holistic ownership of quality from concept through delivery.

This matches what I have seen across every team I have coached. The engineers who own quality end-to-end, who feel personally responsible for how the software feels, not just whether it works, those are the ones whose products survive contact with real users.

What happens when nobody gatekeeps

The alternative to intentional quality is drift. Slow, invisible drift toward mediocrity. It happens like this:

First sprint: AI generates a component library. It looks clean. Ships fast. Everyone is happy.

Third sprint: new components are generated in slightly different styles. Nobody notices because each PR is reviewed in isolation.

Sixth sprint: the app has three different button sizes that were supposed to be the same, two competing approaches to form validation, and error messages that range from hyper-technical to patronizingly simple depending on which AI session generated them.

Twelfth sprint: a new engineer joins and cannot tell what is intentional versus accidental. They ask "is this a pattern or a mistake?" and nobody can answer confidently. The codebase has lost its opinion. It has become slop, not through malice or incompetence, but through the absence of someone who cared enough to say "no, not like that."

This is the infinite software crisis playing out at the individual product level. Infinite generation without finite judgment produces infinite mediocrity.

Building the muscle for software quality in the AI era

Software quality in the AI era is a skill that can be developed. It is not mystical. It is not "you either have taste or you do not." It is a muscle built through deliberate practice.

Here is how senior engineers develop the quality instinct:

Study the best. Use Linear, Figma, Notion, Arc, Raycast daily. Not just as tools. As case studies. Notice every micro-interaction. Ask "why did they do it that way?" The answers are never "because the AI suggested it."

Maintain a rejection log. For one month, save every AI output you reject or substantially rewrite. Categorize the reasons. After 30 days, you will have a clear map of where AI fails for your specific context, and that map is your quality framework.

Practice the empty page. Once a week, build something small without AI assistance. Not to prove you can. To remember what intentional decision-making at every level feels like. When every choice is yours, you notice which choices matter.

Review with a timer. Set a 15-minute timer for each PR review. If you cannot articulate what is good and what is "just okay" in that time, your quality instinct needs sharpening.

Ship and watch. Deploy a feature and then watch three real users interact with it. The gap between what you expected and what happened is your quality education.

The market rewards craft

There is a tempting argument that in a world of free generation, quality does not matter because you can always iterate. Ship fast, measure, fix. The lean startup loop, now at 10x speed.

The argument fails because users form impressions instantly. Research from the Nielsen Norman Group found that users form quality judgments about software within the first 50 milliseconds of interaction. Those judgments are resistant to updating, meaning a poor first impression requires roughly 20 positive interactions to override. You do not get 20 chances. You get one.

The companies winning in 2026 are not the ones generating the most features. They are the ones generating the most considered features. Notion's recent growth has not come from feature volume; it has come from making existing features feel more polished. Vercel's market position is not about having more features than Netlify; it is about every feature feeling deliberate.

The market does not reward slop, even when slop ships faster. Users can feel the difference between software made by people who cared and software assembled by machines without supervision. They may not articulate it in those terms. They will say "it just feels better" or "I trust it more." But underneath that feeling is craft: the cumulative effect of thousands of quality decisions made by builders who refused to let "technically works" be the bar.

The quality imperative

We are 18 months into the age of free generation. The initial gold rush, where speed was all that mattered, is ending. The companies that sprinted ahead on pure velocity are now drowning in maintenance burden, user confusion, and the creeping sense that their product feels like everything else.

The next phase belongs to the builders who treat AI as a first-draft machine and themselves as editors-in-chief. Who understand that the hardest part of building software was never writing the code. It was knowing what good looked like and refusing to ship anything less.

Software quality in the AI era is not an optimization. It is a survival strategy. Build with taste. Ship with conviction. Reject the slop.

Key takeaways

• Slop is software that technically works but carries no evidence that a thinking human shaped it for other humans.
• Users form quality judgments within 50 milliseconds and require roughly 20 positive interactions to override a poor first impression.
• AI-generated PRs require 2.3x more follow-up commits within 30 days because of subtle taste failures, not bugs.
• product.engineer's 30-30-30 rule demands balanced time allocation: 30% specification, 30% generation, 30% review and polish.
• The market rewards craft because when generation is free, human judgment and taste become the only differentiator.

FAQ

What is "slop" in software engineering?

Slop refers to AI-generated code or features that are technically functional but lack intentional design decisions, proper edge case handling, and coherent product thinking. The term originated in content creation and was adopted by engineers in 2025 to describe software that works but shows no evidence of human judgment or craft.

How do product engineers maintain software quality when using AI tools?

Product engineers maintain quality by treating AI output as a first draft rather than finished work. They apply the Quality Stack: automate correctness and consistency checks, then invest human judgment in completeness, coherence, and craft. The key practice is asking "would I be proud to demo this?" before marking anything as done.

Does software quality in the AI era require rejecting AI tools?

No. The highest-quality software teams in 2026 use AI extensively. The difference is process. They invest time in specification before generation, review output against product-level quality standards rather than just technical correctness, and maintain strong opinions about what "good" looks like for their specific product.

How can engineers develop better taste in software quality?

Taste develops through deliberate practice: studying products known for quality (Linear, Figma, Stripe), maintaining a rejection log of AI output you rewrite, building small projects without AI to practice intentional decision-making, and watching real users interact with your shipped features. It is a skill, not an innate trait.

Why is software quality more important now than before AI code generation?

Because volume amplifies quality differentials. When everyone can generate code at the same speed, the code itself is no longer a competitive advantage. The advantage shifts to judgment, taste, and craft. Users can feel the difference between considered software and assembled software. In a market flooded with functional-but-generic tools, quality is what earns trust, retention, and willingness to pay.

Related reading

• What Is a Product Engineer? The foundational definition of the role responsible for quality from concept through delivery.
• The Infinite Software Crisis Why generating more code faster is creating more problems than it solves.
• Taste and Craft in Product Engineering A deeper exploration of how quality judgment develops and scales across teams.
• The State of AI Code Quality Data and analysis on what AI-generated code actually looks like in production systems.
• How to Become a Product Engineer The practical path to developing the skills discussed in this article.