Coding Agents Need Smaller Tasks and More Code Review

Experienced open-source developers took 19% longer to finish tasks with AI tools in a trial reported by the source. AI coding tools can speed up generation without shortening the work needed to finish a task. The source recommends changing the workflow: define success, narrow context and tasks, then verify the result. Here is how to apply that approach.

For a team shipping a frontend, the difference matters beyond how quickly a component appears. Validation, error handling, responsiveness and accessibility can be incomplete, while generated code still looks convincing. The dev.to source article describes the resulting trade-off: AI compresses generation time, but it often expands verification time.

What the trials actually show

METR reported 19% slower completion in a randomized controlled trial with experienced open-source developers; GitHub reported developers coding up to 55% faster with AI assistance in its own controlled trial. These are the findings it presents:

The useful distinction is between producing code and completing work. The author describes generating demo apps quickly, but also spending longer repairing other output than writing it directly would have taken. A convincing first result was not necessarily a finished result.

I'd measure an AI-assisted task through verification and rework, rather than stop the clock when the agent finishes generating. That is a question of model evaluation and validation, not just whether the output looks plausible. The practical goal is less total work, not a larger volume of generated code.

Define frontend success before asking for code

An underspecified feature leaves the agent guessing about details that determine whether the implementation is acceptable. The source specifically calls out validation, error handling, responsiveness and accessibility as areas that can be partially implemented or skipped.

Its recommendation is modest: write down what the feature should and should not do, with basic acceptance criteria, before starting. This does not require an elaborate requirements document. A short Markdown file can establish boundaries that an open-ended request leaves unresolved.

For example, consider a hypothetical form component. “Build the form” leaves much more undecided than a task that identifies its validation rules, error behaviour and relationship to the existing design system. The point is not to describe every implementation detail. It is to make the expected behaviour reviewable before code exists.

• State the behaviour the feature must provide, including relevant failure cases.

• State what the task must leave unchanged, so a local feature does not quietly become a wider rewrite.

Define success before generation. Otherwise, checking the output also becomes an exercise in discovering requirements that should have been settled earlier.

Keep AGENTS.md focused on project rules

More context is not automatically better context. The source describes context windows as limited, with their capacity influenced by the selected model. Filling that space with loosely relevant Markdown can make the agent search through unnecessary information.

The article cites research across over 60,000 repositories that found context files were often too long or vague. It also reports an accuracy drop from 87% to 54% in one study involving context overload. Those are reported study results, not a prediction for a particular repository.

There is a cost angle too: the source notes that sending unnecessary information consumes tokens. A file that keeps accumulating background material can therefore add expense without giving the agent better directions.

Keep lasting project rules in AGENTS.md and feature-specific requirements in the task brief. That follows the source's distinction between useful project context and an indiscriminate collection of Markdown files.

• Keep relevant coding practices, tabs-versus-spaces conventions, design-system guidance, API contracts and rendering requirements.

• Remove irrelevant material and update guidance when the project changes.

For Kiro, the source discusses steering files alongside AGENTS.md. The underlying recommendation is the same: give the agent information it needs for this project, not every piece of information available.

Break application work into reviewable changes

Generating an entire application in one request can sacrifice architectural consistency. The source describes agents solving the same problem differently across files and introducing contradictory patterns when asked to build everything together.

A quick prototype or demo is a different case: the article explicitly allows that a broad request could work there. Its objection concerns treating that approach as suitable production work without accounting for the rework it can create.

For normal feature development, the proposed alternative is narrower tasks. Build a component. Refactor a defined set of tests. Describe the edge cases for one part of the application. Each request should leave a result that can be checked before the next request expands the change.

Kiro's spec-driven development is the source's concrete example: break complex features into requirements, design and tasks, then inspect the plan before code generation. Other tools are described as offering planning workflows too. The useful property is the opportunity to reject a mistaken plan before it becomes a large implementation.

Scope the request to something you can review. The source's comparison is straightforward: finding a problem in 50 lines is easier than finding it in 2,000.

Review behaviour instead of trusting clean output

Code that runs and passes initial checks can still contain edge cases or design decisions that need correction. The source describes this gap directly: output looked convincing until closer inspection exposed problems.

“AI compresses generation time, but it often expands verification time.”

That changes where the developer's attention belongs. On the frontend, the article identifies weak accessibility, brittle logic, duplicated behaviour and poor design as recurring concerns. Reading the implementation is part of the task, not an optional step after the tool has supposedly finished it.

• Read the changed code and test the behaviour, including the relevant error paths and edge cases.

• Inspect the interface for accessibility, responsiveness and consistency with the intended design.

Tests help, but the author warns that AI can sometimes game them too. The recommendation remains human verification: understand the code, assess the design and challenge its assumptions. This is a concrete place for human expertise, rather than an assumption that generating a passing test settles the question.

Keep generated abstractions understandable

Fast generation also makes unnecessary structure cheap to produce. The source warns about excess wrappers, components, abstractions and APIs, leaving developers responsible for code they did not fully think through.

This is a different review question from whether the feature works. A feature can behave acceptably while its implementation makes the next change harder to understand. The article's maintenance concern is ownership: someone will need to work on this code later, and that may be the developer accepting it now.

My test would be whether the new structure makes the behaviour easier to explain. If a wrapper or abstraction merely adds another place to look, I would ask the agent to justify it or simplify the change before acceptance.

The source does not argue against abstraction itself. It argues against letting generation speed replace deliberate design. Accepting less code can be the better outcome when the extra structure does not serve the feature.

Put a smaller AI coding workflow into practice

Apply the recommendations to a single feature before expanding the agent's scope. For a hypothetical form component, here is a task-brief template to start with, then replace the general references with the project's actual requirements:

# Task
Implement the form component only.
Do not change unrelated components or API contracts.

# Acceptance criteria
- Validate input using the agreed project rules.
- Present errors using the existing design system.
- Check responsiveness and accessibility.
- Reuse existing components where they fit the task.

# Review requirements
- Explain the implementation and its assumptions.
- Test validation and error-handling behaviour.
- Identify any new wrappers or abstractions.

1. Set the feature boundary. Write the intended behaviour and exclusions. Resolve unclear acceptance criteria before asking the agent to implement them.

2. Supply relevant context. Review AGENTS.md or the steering file, remove stale guidance and provide the design-system or API information the task actually needs.

3. Inspect the plan, then request a bounded change. Check the proposed requirements and design before allowing a broader implementation.

4. Verify and simplify before continuing. Read the code, exercise the relevant behaviour and question unnecessary structure. Continue to the next task only after checking the current result.

The ordering matters. Requirements constrain the plan; the plan constrains generation; review determines whether the result is acceptable. Generating first and deciding what the feature should mean afterwards reverses that process.

Planning tools do not guarantee a productivity gain

The source does not establish a universal speed-up or slowdown for a particular team. It reports opposing trial results—METR at 19% slower, GitHub at up to 55% faster—but does not provide enough detail to turn their percentages into a forecast for your repository. The author's explanation—that approach matters—is a practical argument, not proof that workflow alone accounts for the difference.

Spec-driven development, plan modes and checkpoints do not remove the need for judgement. The article presents them as workflow improvements while retaining the same requirements for useful context, code review and maintainable output.

I'd use a broad generation request for a disposable prototype, where the source says it can fit, and choose smaller reviewed tasks for production features. If a feature's acceptance criteria remain unclear, I would wait to generate the implementation. Faster output does not resolve an undecided requirement.

The payoff is not a promise that every task becomes faster. It is a workflow that makes the result easier to inspect, correct and own.