AI / Agentic
Agentic Coding: My Implementation and Review Workflow
By Vivek Jalondhara · 4 min read
Published Apr 2026 · Updated
AI tools help with repetitive implementation; architecture, review, and verification still need engineering judgment.
I use agentic coding tools for bounded implementation work: scaffolding, repetitive refactors and test setup. I still make architecture decisions, inspect the changes and verify the resulting behavior.
The skill isn't typing prompts; it's decomposition. I break a task into verifiable steps, give the agent tight context, and review every diff like I would a junior's PR. The agent is fast; I am the one accountable for correctness.
The benefit depends on the task. I review each change and verify the result before treating generated code as finished work.
Distinguish coding assistance from an AI product
My workflow uses tools such as Claude, Codex and Cursor to help implement and review software. That is different from delivering an application that autonomously plans actions and calls business tools. A portfolio should describe the work actually performed, so this article explains AI-assisted development rather than claiming an autonomous-agent product.
The example is a CRM form-builder change: allow a text field to become required. It is intentionally small enough to inspect across the editor, saved schema, renderer and server validation. A change that looks like a checkbox can still affect historical forms and submissions that arrive directly through an API.
Write the acceptance cases before requesting code
List what optional and required fields should accept, including an empty string and whitespace. Decide how existing forms behave when the new property is absent. Keep field identifiers stable and describe the error that a user should see. These are product decisions; asking a tool to infer them can produce a plausible implementation of the wrong behavior.
Use an independently chosen example for each important case. If the tool writes both the code and the assertions from the same mistaken premise, a passing test can reinforce the mistake. Review the expected behavior before treating generated tests as evidence.
Give access and context a clear boundary
Provide the relevant components, schema and API path, along with repository conventions. Avoid including real customer submissions, credentials or unrelated private documents just to make a prompt longer. Use representative synthetic records when explaining the issue and keep external side effects behind the application's normal approval and access controls.
Repository text, logs and downloaded documentation can contain instructions that are not part of the user's request. Treat that material as data to inspect. An instruction embedded in a file should not authorize sending secrets, installing an unrelated tool or changing a production account.
Review the entire behavior change
Inspect how the editor saves the required flag, how an older definition is read and how the server validates a submission. Hiding or marking a field in the browser does not enforce a backend rule. Check that the diff has not changed unrelated fields or replaced an established validation mechanism with a second inconsistent one.
Run the narrow regression cases, then the relevant existing checks. Open the actual form and exercise the keyboard path, error message and correction flow. A compiler cannot tell you whether the error is discoverable or whether an older saved form still works.
Measure completed work, including review
Evaluate the time from a clear task to a verified change, including revisions, debugging and review. A fast first draft is not the same as faster delivery. Record defects found during review and after release if you want to compare workflows over time, using comparable tasks and an explicit measurement method.
I do not attach a fixed productivity percentage to every AI-assisted task. The practical test is whether the result is correct, understandable and economical to maintain. A useful agent workflow leaves the human able to explain the final behavior and the evidence that supports it.
Give an agent a bounded form-builder task
A small acceptance checklist is more useful than asking an agent to improve an entire CRM. The example below defines a change to the form-builder workflow and the behavior that must remain intact.
Illustrative example · Task brief · Simplified for explanation
Task: add a required-field option to a text block.
Preserve: existing saved forms and field identifiers.
Verify: empty input fails only when required is enabled.
Verify: optional fields still accept empty input.
Review: renderer, editor, and server validation together.- Specify behavior
- Implement a small change
- Review diff
- Verify the user flow
Conceptual flow for the example above.
Tradeoff to keep in mind
Narrow tasks make review easier. Passing a generated test is insufficient if both the test and implementation share the same mistaken assumption.