Answer an AI mandate with a smaller, testable proposal

When a company asks for an AI project before it can explain the problem, the engineer's useful response is a smaller proposal with evidence. Define the work, establish what success would mean, and identify the conditions needed to try it responsibly. A blanket refusal leaves the owner without a route forward. Uncritical agreement turns an unclear ambition into an expensive commitment.

The right starting point is a measurable business problem and an operating base appropriate to the proposed use. That does not mean every system must be repaired before anyone may experiment. It means the scope of the experiment should fit the consequences the company can understand and recover from.

Separate an essay's warning from a diagnosis

Nikhil Suresh's essay of 19 June 2024 attacked AI initiatives in organizations struggling with basic software delivery and backup testing. Its anger made the contrast memorable. Its accounts of organizations and incidents are the author's testimony and opinion, not a representative survey of companies or a diagnosis of your business.

Looking back from November 2026, the useful question remains whether a proposed AI system depends on capabilities the company has not established. If the project needs accurate customer records, unresolved duplicate records are part of the project. If it can change live orders, recovery from incorrect changes is part of the project too.

An engineer should explain those dependencies without borrowing the essay's insults or claiming its experiences as their own. The owner may have a real competitive problem. Their choice of technology may be premature while their concern about wasted time is entirely justified.

Write the business decision first

Consider an illustrative distributor whose staff spend time sorting incoming customer requests. The owner asks for an AI agent. Before discussing models, describe the proposed job: suggest a queue for each request, with staff approving the routing before anything reaches a customer or changes an order.

Choose an outcome the company can observe, such as the time needed to route a request correctly, including correction time. Establish a baseline from the current process. Define what counts as a wrong route and who decides ambiguous cases. No baseline, savings figure or experiment result is supplied here; those measurements would have to be collected by the business.

Compare a simpler alternative too. If a form field or a small set of explicit rules solves the same problem, that belongs in the decision. AI earns its place when the task needs interpretation that the simpler approach cannot handle well enough, and the remaining mistakes are manageable.

This changes the conversation from permission to use a fashionable tool to permission to investigate a defined problem. It also lets a senior engineer disagree with the implementation while supporting the commercial objective.

Ask only for foundations the scope needs

For the distributor, examine whether past requests are available, whether their use is permitted, and whether staff agree on the correct queues. If two departments disagree about ownership, a model cannot supply the missing management decision. Resolve that ambiguity or preserve an explicit route for human judgment.

Next, identify the boundary between advice and action. A suggestion shown to a member of staff has a different failure path from a system that emails a customer or writes to an order database. The proposed pilot should state which actions are impossible, which require approval and who handles an uncertain result.

Backup readiness is similarly specific. Google's SRE chapter on data integrity discusses recovery and the need to exercise restoration. A successful backup job alone is insufficient evidence that this business can recover the records and application state it needs. For a write-enabled pilot, demonstrate the relevant recovery path before granting that authority.

That does not require copying Google's infrastructure or adopting its numerical objectives. The source supports the recovery principle. The business must choose its own tolerable loss and interruption for the operation concerned.

Make the objection a decision document

A short proposal can name the current problem, the permitted input and the pilot's limited output. Add the acceptance criteria, the person who checks results and the condition that stops the trial. Keep unknowns visible. An unresolved data-permission question should prevent using that data, rather than vanish into an optimistic project plan.

For the routing example, a stop condition might be an unacceptable category of misrouting or review effort that removes the expected benefit. Choose the rule before running the pilot. Do not redefine success afterwards because the demonstration looked impressive.

Allocate a bounded amount of work and a review point. Ask the owner to choose between a limited experiment, repairing a prerequisite and a simpler non-AI change. These are proposed decision options, not a process this article claims to have used with clients. No pilot or restoration test was executed for this article.

Experimentation can be the fastest way to learn

The strongest counterargument is that a readiness checklist can become a permanent veto. Some organizations cannot justify cleaning an entire data estate before they know whether a use case is valuable. A small experiment can reveal which records and labels actually matter.

That objection is sound when the experiment is isolated and its inputs are permitted. Historical examples, synthetic examples clearly identified as such, or a read-only suggestion tool may allow learning while production recovery work continues. The pilot must not quietly grow write permissions because a demonstration succeeded.

Google's SRE discussion of risk frames reliability as a tradeoff with cost and delivery speed, rather than an absolute pursuit. Apply that principle proportionately. A draft suggestion that a person checks and a system committing an irreversible business action need different evidence. Neither perfection nor enthusiasm is an adequate universal rule.

For business automation, the practical brief is a problem someone owns, a result someone can check and a failure someone can handle. Engineers should turn justified skepticism into those conditions. Owners should expect a credible route to learning, including a clear reason to stop when the proposal cannot earn the next step.