Code is a liability, Codes' capabilities are assets. Software engineering is a discipline, if done correctly makes your code legible and future proof. Today more than ever coding is 10x faster - but the liabilities this code introduces have scaled even faster. If you didn't write the code that ships to production, you often don't know what might break this code either, and the impact of this may be significant to your business.

So it is important, that we ensure, every checks and balances are met before asking out coding agent to build any feature for us. There might be lots of ways you could do this, but I follow these steps and process set up before I ask my coding agent to do anything at all.

You might have heard about workflows, they are simply sequences of implementation steps, validations and methodologies you follow to give you the results you want from your coding agent. This post (Part 1) covers how I spec a product and prepare the ground so the coding agent delivers reliable, production-ready code.

Workflow 1 - Spec a product before your coding agent starts building it

• Plan your product by discussing with your llm. This is important, because every back-and-forth with an agent costs you time and money to refine the feature. What you are doing here is basically listing down what your coding agent should and shouldn't do when building your feature.

• Your idea might not be vague for you, but a coding agent might not have the whole picture. So give the agent all the information about your idea, this could be your mental model in a single sentence, bullet points, a wireframe or an image roughly describing your idea

• Refine your spec by removing any unwanted assumptions, adding techincal details. Add the necessary tech stack details to your spec giving the AI clear set of constraints to work with features

• Once you have the spec, ensure that AI is building the product as expected. AI agents can now mock up a draft UX/ wireframe on how the final product would look. This is an oppurtunity to refine you spec further before your actual implementation is done saving you both time and cost.

• Ask AI to review your spec and point out any gaps, failures or confusing areas. Test the spec against specific user scenarios and update if any changes are required.

• Use the refined spec and ask the AI agent to build the high-level list of features. This gives you clear starting point for development, without going into detailed technical decisions yet.

• Scaffold zero feature starter project using the structure outlined in your spec. This step is just prototyping, meaning you can redo the whole thing above if you think the stack you have chosen does not fit the purpose.

Workflow 2 - Goal is for your AI to design a feature to the spec.

• Give every feature its own spec. More details always helps your agent to build to your context like the project structure, tech stack, test plan etc.

• Review each feature spec and lock in the technical decisions that is made.

• Build your features incrementaly, never rush all the requirements in one feature. Build small reveiwable feature in large increments.

• Follow a TDD approach to build your feature. Review the unit test case for all the possible scenarios. Ask your coding agent to write your Test plan before building the feature

Workflow 3 - Guardrails for your generated code

• Ensure basic checks before building like your testing framework, linting, static analysis, types etc

• Understand different modes of AI - permissions, file selection, context, plan mode , model and effort selection. Each gives a different set of control over your AI agent.

• Update your AGENTS.md. Basically this tells your AI agent how to operate within your project scope. Define things like coding standards, development guidelines, preferred tools and packages, tech stack

• Guardrails only help if they run every time. 2 layers of checks will help here

  1. Instructions in AGENTS.md to define the expected checks

  2. Project-level hooks to run those checks after changes are made

• Review the changes and feed back instructions to be updated in your AGENTs.md

• Create small focussed branches for your feature to easily review and refine your agent instructions if necessary. You can also use stackable PRs' if the changes are huge.

• Skill files or checklists might come in handy instead of relying on the context memory every time you review the change

Workflow 4 - Reviewing AI written code

• AI generated code looks right, sytax is clean, it might run without errors in the first try. That sets a dangerous precedence to trust the generated code. But in reality it might have build gone aroud and built something which might not exist for example assume a method or function exists in the previous version of a package so just use it in the new version even though new version might not have them. Just ignore errors instead of logging them correctly, bypass the validation rules in some cases. So it is ideal to have these checklistf for reviewing the code

  1. Correct error handling

  2. Input boundaries - not just happy path but negative scenarious as well

  3. External or API calls - AI might assume features in that never existed

  4. State mutations - Might not check dependency impacts while updating the state

  5. Assume dependencies - May import files that is not existed, env variables never set etc.

• Structure your code review.

  1. Check Types and Interfaces

  2. Data flow - how the data flows, does it get transformed, the response structure.

  3. Business logic - Does the code meet the AC for a requirement.

  4. Edge cases - Are some common negative cases captured in the implementation like error handling, network errors etc

• Break code before your users do. Your users will find the edge cases you didn't test. The ZOMBIES(Zero, One, Many, Boundaries, Interfaces, Errors, Simple) heuristic gives you a fast mental model for generating adversarial inputs. Then, you turn what breaks into real tests.

• Reverse Engineer Code you didn't write. Read code you've never seen and articulate in one sentence what it's trying to accomplish. If you can't state the intent clearly, that's already a red flag!

• Identify dangerous side effects. Do a side-effect audit by searching the codebase for indicator words: write, save, send, delete, update, emit, dispatch, mutate, push, remove, create.

For each one you find, verify three things:

1. Intentional? Should this function be doing this, or did AI sneak it in?

2. Idempotent? If it runs twice (retry, race condition, double-click), does it cause duplicate emails, double charges, or duplicate records?

3. Guarded? If the side effect fails, does the rest of the operation continue in a broken state?

• AI Code Secuirty. The five things that matter

1. Unsanitized user input

2. Resource permissions

3. Hardcoded api keys/ secrets

4. Missing rate limiting

5. Check for both authentication and authorization. One does not substitute the other. both should compliment each other to verify the access.

• AI generated tests. All green does not mean everything is perfect. Check for these patterns

1. Tautological tests - testing with mocks instead of the actual implementation

2. Happy-path only

3. Implementation coupled - breaks for refactoring but not with the wrong results. Test how the code workds instead of what it does

4. Snapshot/ copy paste - minor variations to the test cases, looks comprehensive, but does not cover all the scenarious.

Three questions that can verify this

1. What behavior does this verify ?

2. If I break this feature, would this catch it?

3. Is this testing the code or the mock?

In Part 2 I’ll build and ship a runnable word‑game app using the exact workflows described here. I’ll walk through the full spec‑to‑code pipeline, provide a live demo and a runnable repository, and include every spec file used (user stories, acceptance criteria, API contracts, test plans, and CI/CD notes) so you can reproduce or adapt the process for your own projects. Subscribe or follow to be notified when it publishes.