$What Actually Works for Me in Agentic Development

My first experiments with coding assistants produced code faster than I could review it. That looked productive until I noticed that generated tests often proved only that the implementation behaved as the agent expected.

I started shrinking each task and writing down the intended behavior before implementation. I also began budgeting more time for validation. These changes have helped me more than giving an agent a larger prompt and hoping it makes the right decisions.

This is an account of my current workflow. I have not run a controlled comparison of tools, and I do not assume that the same process will suit every team.

Moving Beyond Autocomplete

Autocomplete receives context from the code around the cursor. A task-level agent may inspect the whole repository, but it still cannot recover decisions that exist only in my head.

A request such as:

implement user session management with appropriate timeouts

leaves several decisions open. It does not identify the security authority or define which requests count as activity. It also says nothing about expiry across tabs, failure behavior, or the tests that should prove the result.

An agent can fill those gaps and produce a coherent implementation. At that point, it is also choosing product behavior and security policy.

Write a Focused Specification

For work that affects more than one obvious code path, I write a short specification covering:

• the user outcome and explicit exclusions;
• relevant architecture and ownership boundaries;
• data or API contract changes;
• security and operational constraints;
• failure recovery and rollback;
• acceptance criteria with verification commands.

I call these documents PRDs, although they are closer to implementation specifications than traditional product documents.

One specification should describe a change that can be delivered and reviewed on its own. Line count is a poor boundary. Fifty lines of authentication code may require more scrutiny than hundreds of lines of generated fixtures.

A Session-Timeout Example

Session validity belongs to the server. A browser countdown can warn the user, but it cannot be the authentication boundary. OWASP’s session guidance also requires timeout enforcement on the server.

Here is the kind of specification I would give an agent:

# Session inactivity timeout

## Invariant

Reject every authenticated request after 30 minutes without
server-recognized activity. Client state cannot extend an expired session.

## Server behavior

- Store or derive the last accepted activity time on the server.
- Evaluate expiry on every protected request using the server's clock.
- Define which requests count as activity.
- Do not let static assets or background polling extend the session by default.
- Make concurrent extension and logout operations race safe.
- Record expiry and revocation without logging session secrets.

## Client behavior

- Show a warning based on the server-provided expiry time.
- Treat the local countdown as advisory.
- Send "Stay signed in" through an authenticated server endpoint.
- Synchronize warnings and logout state across browser tabs.
- Preserve or warn about unsaved work according to product policy.

## Acceptance criteria

- A protected request after server-side expiry is rejected.
- Changing the browser clock does not extend the session.
- A client cannot revive a revoked session.
- Concurrent extension and logout have a documented outcome.
- Tests use a controllable clock instead of waiting 30 real minutes.

The 30-minute value is an example rather than a general recommendation. The application and its risk model should determine idle and absolute timeouts.

This specification identifies who owns the decision and how hostile or conflicting states should behave. The exact implementation still depends on the authentication framework.

Treat Validation as the Limiting Step

An agent can write an implementation and its tests from the same mistaken assumption. I review the result through several separate questions:

If I cannot evaluate a library or pattern, I learn enough to review it before approving the change. Automated tests are necessary, but I also run the feature and exercise its significant failure paths.

Keep the Change Reviewable

I used to target a fixed maximum number of changed lines. That was easy to measure and did not tell me whether a diff was understandable.

My current boundary is a change with:

• one coherent reason to exist;
• a diff that does not require reconstructing several features;
• focused verification;
• a safe rollback path;
• no hidden dependency on unspecified future work.

A large mechanical edit can meet this standard. A smaller change spread across authentication and persistence may require a different review boundary.

Give the Agent Stable Project Context

A short AGENTS.md gives supported coding agents a predictable place to find repository instructions:

## Project

Purpose, architecture, and ownership boundaries.

## Stack

Runtime, languages, important dependencies, and version constraints.

## Commands

Build, test, lint, formatting, and local-run commands.

## Workflow

How to inspect, change, verify, and review work in this repository.

I keep the file specific to facts that remain useful across tasks. Generic advice takes up context without resolving a project decision, while stale commands are worse because the agent may execute them.

Choose the Tool for the Feedback Loop

I use several interaction models without treating one product as the general winner:

Tool names and rankings change quickly. My obligation to validate the result remains.

Measure Before Claiming a Productivity Gain

I am applying this workflow to a familiar TypeScript project and an unfamiliar iOS project. I track:

• elapsed time from specification to a merged change;
• review and rework time;
• escaped defects;
• time spent learning unfamiliar parts of the system;
• changes to the original specification during implementation.

I do not yet have enough controlled data to claim that the workflow improves delivery speed without reducing quality. It currently gives me a clearer review boundary and exposes missing decisions earlier.

That result still depends on my ability to understand the work. Taking regular AI-free days is one way I practise the skills needed to judge an agent’s output.

For now, I treat agentic development as a workflow experiment. I remain responsible for the specification and the deployed behavior, regardless of who or what produced the diff.