Matt Senter

Posted on Sep 22 Originally published at mattsenter.com

How To Avoid “Slop Grenades”

#aislop #aiassisteddevelopment #engineeringmanagement #codereview

The advice I give my clients is straightforward: You cannot compete without AI assistance. You also cannot compete by producing AI slop. Use the tools, and retain the expertise necessary to use them properly.

Shopify CEO Tobi Lütke recently described unreviewed AI output passed to coworkers as “slop grenades.” His example included bloated emails that leave the recipient doing the work of extracting the useful information. Somebody gets to feel productive while somebody else inherits the cleanup.

It is a good description. But when this happens inside an organization, my first question is what management has decided to reward, what expertise it has retained, and whether anybody is measuring the work that happens after someone clicks “done.”

I use AI extensively to build software. I am not interested in returning to a world where I manually type every line of code. The combination I recommend is experienced humans with powerful AI tools, and the human contribution begins before the agent writes anything. Someone has to choose an approach, establish the constraints, and recognize a solution worth building.

The management problem comes first

Shopify cut approximately 10% of its workforce in July 2022, with Lütke acknowledging that he had overestimated the permanence of the pandemic’s e-commerce boom. In May 2023, he announced another roughly 20% reduction alongside the sale of Shopify Logistics. That second announcement also highlighted the opportunities of the emerging AI era. Those were leadership decisions about the company’s direction, staffing, and priorities.

In April 2025, Lütke made AI use a baseline expectation, incorporated it into performance and peer reviews, and required teams seeking additional staff or resources to explain why AI could not meet the need. His memo also explicitly advocated multiplying human skill with AI. I agree with that principle.

Those facts do not establish that Shopify’s layoffs caused its slop grenades, or that experienced engineers were replaced wholesale by nontechnical prompt operators. But they do establish why the management question matters. The person setting the staffing policy and the expectations around AI use also owns the responsibility for making that combination work.

My objection is to an operating model that asks employees to demonstrate AI adoption without giving equal weight to the judgment, verification, and maintenance required to turn generated output into useful work. Before asking whether AI can do a job, management should ask what it takes to deliver the result correctly. Those are not the same question.

Can an agent produce a pull request? Fine. Who knows whether it solves the right problem? Who checks the architectural implications? Who owns it when it breaks? How much of another employee’s day will disappear into reviewing and repairing it?

Employees remain responsible for what they submit. But when people repeatedly hand one another work they cannot evaluate, I see an organizational design problem, not merely a collection of disappointing employees. Leadership does not get to take credit for the productivity gains while treating the cleanup as a talent problem.

Pressing Enter is not engineering

There is nothing wrong with nontechnical people using AI to build things. Lowering the barrier to experimentation is one of the most exciting parts of this technology. A person who previously could not get an idea beyond a sketch can now explore a working prototype, and I think that is fantastic.

A prototype and a production system are different responsibilities, though. Someone still needs to understand what has been built, what assumptions it depends on, and what evidence would show that those assumptions are wrong.

Putting a human between an agent and a deployment button does not automatically provide meaningful oversight. That person needs the knowledge to challenge the agent, the time to investigate its work, and the authority to reject the result. Otherwise, the approval step is ceremonial.

This is not just a concern from people skeptical of AI. GitHub’s own guidance warns that its agents can produce incorrect or insecure code, recommends reviewing and testing their output, and says AI code review should supplement rather than replace human review.

Blind approval is a garbage-in, garbage-out problem, but the garbage is not necessarily confined to the prompt. It can be an incomplete requirement, a missing constraint, an incentive to move too quickly, or a review process that amounts to asking the same system whether it did a good job. The solution is to employ people who know when to disagree.

Engineering is knowing how, not just asking what

There is a substantial difference between telling an agent what a product should do and knowing how that product should be implemented. “Build me a system that processes these records” describes an outcome. It says very little about the architecture, expected workload, memory budget, security boundaries, or behavior when something fails.

A good AI-assisted engineer supplies that missing direction. They can tell the agent to follow the project’s established coding patterns, reuse an existing abstraction, choose an appropriate data structure, or avoid an algorithm that becomes prohibitively expensive as the input grows. Writing repository instructions is useful only if someone knows what those instructions should say.

That does not mean dictating every implementation detail or assuming the human’s first idea must be better. I want the agent to suggest alternatives and challenge assumptions. But somebody needs enough understanding to evaluate those alternatives rather than accepting whichever explanation sounds most confident.

“Make it efficient” is not a substitute for understanding efficiency. “Make it secure” is not a security model. Those are aspirations until someone translates them into concrete requirements and verifies that the implementation meets them.

Big O did not go away

Consider a simple example: matching records between two collections using unique identifiers. An implementation could repeatedly scan the second collection for every record in the first. With two collections of n records, that can require n² comparisons. Alternatively, for fixed-size identifiers, building a hash-based lookup can bring the matching task to expected O(n) time, at the cost of O(n) additional memory. That is a time-versus-space tradeoff, not a matter of formatting preferences.

Both implementations might produce the correct answer in a small demonstration. The engineering question is what happens under the workload the product actually needs to support. How much data will it process? How much memory is available? Is this an occasional operation or something happening on every request?

An experienced operator can give the agent useful direction: “Avoid rescanning the entire collection for each record. Build a lookup, account for its memory cost, and benchmark the implementation against our expected input sizes.” That instruction comes from understanding the problem, not from discovering a magic prompt.

The same understanding should prevent unnecessary optimization. I do not want an agent turning a trivial operation into an elaborate framework just because someone told it to maximize performance. I want the operator to understand time complexity, space complexity, and the actual requirements well enough to choose an appropriate solution.

Computer science has not become optional because the instructions are now written in English. We changed how we ask for software. We did not change the properties that make software correct, efficient, or maintainable.

Sometimes you have to tell it to build a state machine

Suppose I am building a background import process that can be queued, running, completed, failed, or canceled. A plausible implementation might track its progress through a collection of separate flags. But that design needs to prevent contradictory combinations, such as a job being both running and completed.

A finite state machine gives that workflow an explicit set of states and defined transitions between them. Instead of scattering decisions about what can happen next throughout the application, I can model which events are allowed to move the process from one state to another. Those are the basic concepts underlying state-machine notation: states, events, and transitions.

The agent might propose that approach on its own. Great. But it might not, and the person directing it needs to recognize when the problem calls for it. Sometimes the useful instruction is: “Implement this as a finite state machine. Define the legal transitions, handle cancellation explicitly, and test what happens when a completion event arrives after cancellation.” It is choosing a model for the system’s behavior.

Finite state machines, statecharts, and other automata belong in the human operator’s technical toolbox. Not because every feature needs a formal model, but because the operator should recognize when one would clarify the problem and when it would add unnecessary complexity. Knowing the name of a pattern is not enough. You need to understand where it applies, what it guarantees, and what it leaves unresolved.

And “use a state machine” is not an incantation that makes the implementation correct. I still need to examine the transitions and test the behavior. The value is that I have given the agent a structure I can reason about, rather than accepting an arrangement of conditions simply because it passed the happy-path test.

Human-computer interaction is not optional either

Computer science is not the only expertise we still need. Human-computer interaction matters too, and I am not willing to treat it as an optional finishing touch just because an agent can generate a screen as quickly as it generates the code behind it.

I expect more of the internet to become agent-first. But I still build products that people need to understand and use. Those people need to know what is happening, what their choices mean, whether an action succeeded, and how to recover when something goes wrong. Visibility, consistency, user control, and error prevention are established interaction-design principles, not decorative preferences.

“Make a good UI” is about as useful as “make the algorithm efficient.” A skilled professional can give the agent much more precise direction: organize the information around the user’s task, preserve familiar navigation, distinguish primary and destructive actions, and make progress and failure states understandable. Accessibility adds concrete implementation requirements, including keyboard operation, visible focus, meaningful labels, and accessible status messages.

Take the background import process from the state-machine example. Getting the internal states right is only part of the job. I also want the interface to distinguish between waiting to start, actively importing, partially completed, canceled, and failed. The person using it should not have to infer those differences from a spinner.

My instructions to the agent might be: “Preserve the user’s selections after a failure. Explain which records were imported and which were not. Do not display a success message until the operation has actually completed. Show whether cancellation is still possible, and make retry behavior explicit.”

That is implementation guidance, not a request for prettier colors. I still need to use the resulting interface, test the relevant states, and observe whether people understand it. A polished screenshot is not sufficient evidence that the interaction works.

The same applies to agent interfaces themselves. Replacing menus with conversation does not eliminate the need to communicate scope, progress, uncertainty, and consequences. I would argue that an agent acting across several systems makes those design decisions more important, not less. The human still needs a way to understand, interrupt, correct, and approve the work.

An agent-first internet is not a human-irrelevant internet. As long as people are directing work and living with its consequences, somebody needs to design that relationship.

Pressing Enter is not a security or privacy strategy

Code quality is only part of the responsibility. An agent can also request access to files, execute commands, interact with services, and generate code containing vulnerabilities. GitHub’s own guidance explicitly warns about incorrect or insecure output and the need for careful review and testing.

Before approving an action, I want the operator asking what it can access, what it can change, and where the data can go. Does this task require production credentials? Could those debugging logs contain customer information? Why does an operation that only needs to read data have permission to modify or delete it?

These are not details to worry about after the demo works. OWASP identifies excessive functionality, permissions, and autonomy as sources of risk in agentic systems. Its recommendations include limiting capabilities, enforcing least privilege, requiring approval for high-impact actions, and implementing authorization outside the model rather than trusting it to decide what is allowed.

A person who blindly approves every request is not meaningfully evaluating those risks. But the answer is not simply to hire someone experienced and expect them to catch everything, either. Give that person an environment with enforced boundaries, appropriate access controls, and a review process that does not depend on perfect vigilance.

This is why I care about the operator’s understanding. They need to help design the safeguards, not just occupy the chair in front of the approval button.

Compliance is part of the engineering

A product that works in a demo is not necessarily a product an organization can responsibly operate. Someone also has to understand what information it handles, who can access that information, which obligations apply, and what evidence the organization needs to demonstrate that its controls are working.

Depending on the business, that can include SOC 2, PCI DSS, and HIPAA. These are different kinds of obligations and assurance mechanisms, not three interchangeable badges:

SOC 2 is an independent examination of controls against applicable Trust Services Criteria. Those criteria include change management: authorizing, documenting, testing, approving, and implementing system changes. An agent generating a successful build does not establish that the organization followed that process.
PCI DSS establishes technical and operational security requirements for payment account data. Its scope can include systems and service providers that affect the security of the cardholder data environment, not just a database directly storing credit card numbers. Understanding that scope is part of designing and operating the system responsibly.
HIPAA, where applicable to covered entities and business associates, brings requirements for protecting electronic protected health information. Its Security Rule includes risk analysis, access controls, audit controls, and appropriate agreements with business associates. Those responsibilities do not disappear because an AI assistant helped write the application.

I do not expect every developer to be a compliance attorney or an auditor. I expect an experienced team to recognize when these requirements affect a design and bring in the appropriate expertise before shipping it. “Nobody told the agent” is a requirements failure, not an exemption.

For consequential production changes, I want an audit trail that connects the request to the implementation, the tests, the review, the approval, and the deployment. What changed? Why? Which version was reviewed? Who approved it, with what authority? What actually reached production?

That record should be produced as the work happens, not reconstructed afterward from somebody’s memory and an agent’s cheerful summary. A record saying “approved” establishes that someone clicked a button. It does not, by itself, establish that a meaningful review occurred.

An approval is a decision, not a keystroke

Pressing Enter without reviewing the consequences can put the organization, its customers, and the person approving the action at risk. Consider an agent proposing to upload production logs to an external service for debugging. Before approving that request, somebody needs to establish what those logs contain and whether that destination is permitted. The convenience of the proposed fix does not answer either question.

There can also be consequences for the employee who bypasses required safeguards. HHS’s guidance on HIPAA sanction policies, for example, discusses consequences ranging from warnings to termination, while leaving the appropriate response to the organization and the circumstances. That is not a claim that every mistaken approval should cost someone their job. It is a reminder that an approval can carry professional responsibility.

But management cannot fairly assign that responsibility without providing the knowledge, time, information, and authority needed to exercise it. Giving someone a queue of approvals they cannot evaluate, measuring them on how quickly they clear it, and then blaming them for the result is not responsible delegation.

The approval interface itself needs to support the decision. For a deployment, I want the reviewer to see the actual change, the target environment, the relevant test results, unresolved risks, and the recovery plan. I do not want “Proceed? Y/n” to stand in for an explanation of what is about to happen.

Nor do I want a workflow that demands human approval for every harmless action. My goal is to automate low-risk work within established boundaries and reserve human attention for decisions that need judgment. Adding more buttons is not the same thing as adding more oversight.

Ford had to rebuild the expertise it had lost

Bloomberg reported in June 2026 that Ford had hired 350 veteran engineers over the preceding three years, including former employees and engineers from suppliers. They were helping address quality problems, train younger staff, and improve AI tools that had fallen short. This was a story about vehicle engineering and quality systems, not a claim that Ford rehired 350 software developers to clean up generated application code.

That is the lesson I would take into a software company. Before removing an expensive engineer from a spreadsheet, understand what that person contributes beyond visible output. Ask what they prevent, what they recognize early, and what the rest of the team relies on them to understand. Then consider what better tools could help them accomplish.

Stop confusing lower salaries with lower costs

Management wants to cut labor costs. I get it. I run businesses too, and I am not suggesting that companies spend money without expecting a return. But I would evaluate that return against the cost of delivering and maintaining a useful product, not simply the salary attached to each person working on it.

A friend recently sent me a job description for an in-person software engineering position in New York City. It required a master’s degree and six years of industry experience and advertised $200,000. The combination did not make sense to me. For the caliber of engineer I would want directing consequential AI-assisted development, I would structure the position differently.

First, I would drop the master’s requirement unless this were a research position where that training genuinely mattered. I want to know what someone has built, which difficult decisions they have owned, and whether they understand the consequences of those decisions. Requiring computer science knowledge is not the same thing as requiring a particular diploma.

Can they explain why they chose one architecture over another? Can they recognize a security boundary, reason about performance, and design a system that behaves sensibly when something fails? Can they direct an agent toward a good implementation and reject an apparently successful one that does not meet the actual requirements?

Those are the abilities I would hire for. Then I would budget around $350,000 in annual salary, with up to $2,000 a month for AI assistance, and expect the hiring process to establish that the candidate could justify the investment.

That is my proposed budget for a high-impact role, not a claim that every engineering position should pay the same amount. Nor does offering a higher salary relieve management of the responsibility to evaluate candidates properly. The point is to compete aggressively for the expertise the strategy depends on, rather than assume an AI subscription makes that expertise less valuable.

Give the engineer a serious tools budget

The $2,000 monthly allowance would be a total AI tooling budget, not the price of a single subscription or a requirement to spend every dollar. For an approved use case, I am thinking of something like a reimbursed Claude Max plan plus additional usage. Anthropic offers paid usage beyond a plan’s included allowance, with spending controls.

The account and deployment still need to fit the organization’s security, privacy, and contractual requirements. Reimbursing a personal subscription does not settle those questions. The team needs to choose the appropriate arrangement for the information and systems involved.

At the full allowance, that is $24,000 a year in AI spending alongside a $350,000 salary, or $374,000 in salary and tools before benefits, employer taxes, bonuses, equity, and other overhead. The tools cost less than 7% of the salary. I would judge that expense by what it enables the engineer to deliver.

On a deliberately simplified comparison of salary and tools alone, $374,000 is 1.87 times $200,000. If the more expensive combination delivers more than 1.87 times as much comparable, useful work, its cost per unit of that work is lower. That is an illustration of the economics, not a prediction. A real comparison needs the full costs on both sides.

The ambition is to turn a 10x developer into a 100x developer. Those numbers describe what I want to pursue, not a guaranteed productivity multiplier. I would expect a carefully selected engineer with strong tools to outperform a hiring strategy built around finding someone cheaper and assuming AI will supply the missing judgment, but I would verify that expectation through the work delivered.

None of this makes junior developers disposable. I want them learning alongside experienced people, using AI while developing the knowledge to question it. The expensive mistake is removing their mentors and assigning them responsibilities they are not yet prepared to own because management decided an agent would supply the experience.

An organization for humans and agents

This is the combination I am building around with Orgabot: humans and AI agents occupying defined roles in an organization, with workflows that specify responsibilities, permissions, checks, and approvals. The point is to make the organization’s way of working explicit enough that autonomous work can happen within meaningful boundaries.

The distinction I care about is between what an agent may reason about and what the surrounding software must enforce. Flexible planning and implementation belong alongside controls over tool access, required approvals, test outcomes, and audit evidence. A requirement to obtain approval should not be a suggestion in a prompt that the agent can reinterpret.

For a consequential production change, the workflow I want starts with a qualified human establishing the objective and constraints. Agents can investigate, propose approaches, implement the change, and assist with testing and review. The responsible people then evaluate evidence appropriate to the risk before the approved change moves into production.

I want approval tied to the version actually reviewed. If the implementation materially changes afterward, it should receive the necessary review again. I also want a clear record of the request, work performed, checks that ran, decisions made, and deployment outcome.

That is what designing Orgabot with compliance in mind means to me: making responsibilities and evidence part of the process. It does not mean installing a tool and declaring the organization compliant. The organization still has to establish its obligations, configure appropriate controls, and demonstrate that they work.

The human contribution matters throughout. Someone has to recognize a need for a state machine, challenge an expensive algorithm, protect a privacy boundary, identify an applicable compliance requirement, or explain why an interface will confuse people. Those responsibilities may belong to several experienced professionals. An org chart should make their ownership clear.

How I would avoid slop grenades

Staff for ownership, not approvals. Assign consequential work to someone who can evaluate the result and remain responsible for it after deployment. Hire for demonstrated understanding, not merely a degree, a long résumé, or enthusiasm for the latest model. Give less experienced people supervision and a path to develop that understanding.

Define success before generating the solution. Write down the behavior you need, the constraints that cannot be violated, and the evidence required to accept the work. Include failure cases. An agent producing code and then producing tests that agree with that code is not enough; verification needs to come back to the original requirements.

Make review real and fund it accordingly. Budget time for inspecting changes, challenging assumptions, testing integrations, and checking the actual user experience. Use AI to assist with those activities, but do not make another model’s approval the sole basis for trusting the result. The person responsible must be able to stop the process without being treated as an obstacle to productivity.

Measure the whole job. Count the time spent clarifying, generating, reviewing, repairing, deploying, and supporting the work, along with the cost of the tools. Compare that with the outcome delivered. A task is not more efficient because one person finished faster while three colleagues absorbed the difference.

None of this requires rejecting AI or deliberately moving slowly. It requires being honest about what “finished” means.

Management owns the conditions

Lütke is right to object to work that creates more work for somebody else. My objection is to treating that behavior as separable from the staffing, incentives, and standards surrounding it. A company’s AI strategy includes who uses the tools, what those people understand, and what management expects them to verify.

I understand wanting to cut labor costs. I would pursue that through better results per dollar, even when it means spending more on an individual engineer. Hire for demonstrated expertise, pay enough to compete for it, and provide the tools and working conditions that let it matter.

Cutting the capacity to evaluate work while expanding the capacity to generate it is a very efficient way to produce slop grenades. You cannot compete without AI assistance. You also cannot compete by producing AI slop. Management owns the conditions that determine which outcome it gets.

DEV Community