Vercel recommends starting AI automation with bounded, verifiable tasks

Vercel has published a guide on choosing the first jobs an organization should automate with AI agents. Its central proposal is deliberately less dramatic than autonomous rewriting: begin with repetitive tasks that have a clear endpoint and produce an outcome another person can check without watching the entire process. An agent’s value is measured by the quality of its decision and the cost of reviewing it, not by the amount of code it generates.

The criterion is particularly relevant to teams that already automate builds, deployments, or shallow review checks. A candidate task should answer a specific question. For example, investigating whether an issue still affects a supported release can be a good first workflow if the agent must provide evidence, check repository history, and leave the final decision to a maintainer. Automatically closing issues or modifying code in response to ambiguous signals, by contrast, combines investigation, authority, and execution in one operation that is difficult to audit.

The guide refers to work by a Next.js team agent that investigated older reports after inactivity-based closure proved unreliable. According to the article, the workflow analyzed closures associated with already-fixed issues and duplicates. The lesson is not that those figures prove universal automation, but that bounded investigation can save work even when the agent is not allowed to close issues or submit changes. The boundary between preparing evidence and acting on the repository should remain explicit.

Vercel also recommends sizing a pilot to the team’s actual review capacity. A batch of one hundred unattended proposals cannot show whether the system works; a small batch reviewed in full can reveal recurring errors, poor task classification, and places where context is insufficient. The intended outcome of the pilot is not to prove that an agent handles everything, but to determine whether it reduces human work in one concrete workflow without hiding uncertainty.

The warning matters for maintaining legacy systems. A rewrite may look like a suitable agent task because it contains a great deal of repetitive code, but the main risk is often discovering implicit behavior. If the team cannot describe what must remain equivalent, the right work is to investigate first, define one bounded flow, and record the rules that must be preserved. Generating thousands of lines is not the same as understanding the system.

The final recommendation is straightforward: start with investigation, classification, or reproducible fixes; require tests and artifacts a reviewer can inspect; record known failures; and never treat repeated retries as evidence of correctness. In AI-assisted engineering, maintainability depends less on delegating more than on designing better boundaries. A useful agent is not one that acts without asking, but one that delivers a checkable conclusion inside a perimeter the team understands.