How to work with AI like a Senior Developer

A practical workflow for turning generated code into changes you can understand, verify, and ship.

You ask an AI coding assistant to add team invitations to your SaaS. It creates the database migration, endpoint, email, and Vue component. The happy path works. The pull request looks convincing.

Then you ask a few more questions. Can a member invite someone as an admin? Can an invitation from one organization be accepted into another? What happens when two requests use the same token at the same time?

Those questions determine whether the feature is ready to ship.

Using AI like a senior developer means directing its attention toward the decisions that make software reliable. You define the behavior, expose assumptions, control the scope, and require evidence that the change works.

Here is how to apply that approach to a real development task.

1. Define what “working” means before generating code

“Add team invitations” leaves important product decisions open. The assistant has to choose who can invite, which roles they can grant, how long invitations last, and what accepting an invitation actually does.

Make those decisions explicit. For our example, an organization admin can invite someone as a member. Invitations expire after seven days. Acceptance requires an authenticated account with a verified email matching the invitation. Each invitation can be consumed once.

Now you have behavior that can be evaluated.

Give the assistant a brief like this:

Implement team invitations in this existing Laravel and Vue app.

Behavior:

• Only organization admins can create invitations.
• Invitations grant the member role and expire after seven days.
• Acceptance requires a verified account matching the invited email.
• The organization comes from the invitation record.
• An invitation can be consumed once, including under concurrent requests.

First inspect the existing authorization, membership, and email flows.
Identify unresolved product decisions and propose a small implementation plan.

One unresolved question might be what happens when the recipient is already a member. Settle it before implementation. Otherwise, that decision gets buried inside whatever code the assistant happens to generate.

1. Make the assistant discover your application's existing patterns

A mature repository already contains decisions about validation, permissions, transactions, errors, and tests. The assistant needs to find the relevant ones.

Ask for a short map of the existing implementation:

Locate the code responsible for:

1. Resolving the current organization.
2. Authorizing organization administrators.
3. Creating memberships.
4. Sending queued transactional emails.
5. Testing organization access boundaries.

Reference the files and symbols supporting each finding.
Separate confirmed behavior from assumptions.

That last line matters. A confident explanation of a policy class is only useful if the class exists and applies to the request being changed.

Check the findings. If membership creation already has a shared action, point the assistant toward it. If email jobs depend on transaction timing, bring that behavior into the plan. You are giving the assistant the context a human teammate would need during onboarding.

Scale this effort to the task. A label change needs a quick edit. An invitation flow deserves investigation because it crosses identity, permissions, persistence, and email. Anthropic's own coding guidance similarly recommends planning when uncertainty or scope warrants it, while handling obvious small changes directly. Source

1. Size tasks around what you can review

A useful task ends with behavior you can inspect and verify.

For the invitation feature, start with issuing an invitation: persistence, authorization, validation, and focused tests. Follow with safe acceptance. Then connect the interface to those verified endpoints.

Each task should state what it depends on and what evidence will establish completion. If acceptance relies on the invitation schema, establish that schema before starting dependent implementation.

Keep the review manageable. File count alone tells you little: a small change across eight files may be straightforward, while a dense rewrite in one file may demand substantial investigation.

Ask yourself whether you can explain the change after reading the diff. If you cannot, split the work or investigate the confusing part before continuing.

AI can produce changes faster than you can understand them. Your review capacity should influence how much work you ask it to produce at once.

1. Design tests around ways the feature could fail

Tests generated alongside an implementation can share its assumptions. A passing suite is useful evidence only for the behavior it actually checks.

Write down the important failure cases yourself, then use AI to implement and expand those checks.

For our invitation flow, the review should include these scenarios:

Scenario

Expected result

An ordinary member creates an invitation

Request rejected; no invitation or email created

An admin targets an organization they do not administer

Request rejected; no changes to either organization

Someone accepts an expired or consumed invitation

No membership created

A different verified account accepts the invitation

Request rejected; no membership created

Two requests accept the same invitation concurrently

One successful consumption; one membership created

The last case deserves special attention. Checking whether an invitation is unused and then creating a membership leaves room for a race unless the implementation coordinates those operations correctly.

Ask the assistant to explain what enforces single consumption. Examine the transaction behavior and database constraints. Exercise concurrency against the database engine used in production; a sequential test that calls the endpoint twice does not demonstrate concurrency safety.

For a bug fix, require a regression test that reproduces the defect against the old implementation. That gives the test a concrete reason to exist.

1. Debug through evidence

When a generated feature fails, repeated “try again” prompts can produce a pile of speculative changes.

Give the assistant observations it can investigate: the request, expected result, actual result, relevant logs, and a reproducible sequence. Redact credentials and unnecessary personal data.

For example:

Two concurrent acceptance requests sometimes create duplicate memberships.

Trace the token lookup, consumption, and membership insert.
Identify a likely failure mechanism and the evidence supporting it.
Create a reproduction that distinguishes that explanation from alternatives.
Apply a focused fix and rerun the reproduction and relevant tests.
Report the commands run, their results, and any remaining uncertainty.

This gives you a way to judge progress. A hypothesis predicts something observable. A reproduction checks that prediction. A fix must change the outcome.

Read the verification report carefully. If the database was unavailable, the concurrency behavior remains unverified. Keep that limitation visible in the pull request.

1. Preserve decisions and choose models by the work

As the feature develops, record decisions that later tasks need: how organizations are resolved, which roles can be assigned, how invitation acceptance works, and which command runs the relevant tests.

Keep that record concise and update it when decisions change. An outdated architecture note can steer the next task toward an implementation you have already replaced.

When handing work to another session or model, include the current task, relevant files, accepted decisions, and verification requirements. Give it a clear starting point.

Choose models using evidence from your own repository. An inexpensive model may handle a predictable UI change well. A difficult concurrency investigation may justify a more capable model and additional review.

Evaluate the whole cost: model usage, retries, debugging, and your review time. A low token bill offers little value if you spend the afternoon correcting the result.

1. Review the code as its future maintainer

Before merging, read the diff and explain how the feature behaves under normal use and failure.

For invitations, that means understanding where authorization happens, how the recipient is verified, how token consumption is enforced, and what happens if sending the email fails. For a schema change, consider deployment order and how existing data behaves during rollout.

A second AI review can suggest issues worth investigating. Ask for specific failure scenarios, affected code, and supporting evidence. Validate those findings yourself.

The pull request should make its evidence easy to assess: what changed, which checks ran, what they established, and what still needs attention. Run the repository's required checks and investigate failures before merging.

Put this workflow into practice with Vibe Coder Planner

You can organize this process in Vibe Coder Planner, using a project plan, individual task prompts, and a Kanban board to carry the feature through implementation.

1. Start with a specific feature brief

Enter your stack, existing behavior, desired outcome, and acceptance criteria. For this example:

Add organization invitations to an existing Laravel, Vue, and PostgreSQL SaaS.
Authentication and organization memberships already exist.

Admins can invite members. Invitations expire after seven days.
Acceptance requires a matching verified account and must be safe
against simultaneous requests using the same token.

Generate ordered tasks for issuing invitations, accepting them,
and connecting the interface. Include dependencies, acceptance criteria,
and verification steps for each task.

The project planner generates a task breakdown you can edit and reorder. Review that plan against the repository findings and resolve missing decisions before execution.

1. Add the decisions every task needs

Use Context Memory for the project's conventions, business rules, and architecture decisions. The product documents this as a project Markdown field included in automated task executions.

For our example, record the organization resolution pattern, permission rules, invitation lifecycle, and test commands. Update it as the implementation establishes new facts.

1. Review each task's prompt and model recommendation

Open the next task and check its scope, inputs, acceptance criteria, and expected verification. The planner provides model recommendations based on task complexity and estimated AI costs. Treat those recommendations as a starting point and adjust them using your experience with the task and codebase. Feature overview

1. Execute through your editor or GitHub

For the editor workflow, install the Vibe Code Planner extension in Cursor or VS Code. Open Vibe Code Planner: Open Settings, connect using your account API token, and access the project's tasks and prompts from the sidebar. Use each task prompt with your coding assistant. Editor setup

For automated execution, use a plan that includes the feature, connect GitHub, link the project's repository, and configure a supported AI provider. Moving a task to In Progress starts the documented execution workflow, which creates a branch and opens a pull request. Tasks within a project are queued one at a time. Execution workflow

1. Review before marking the task complete

Inspect the pull request, verify the acceptance criteria, and check CI results before changing its status. The documented GitHub workflow uses Completed to trigger a merge request, so that status is part of the approval process. GitHub workflow

For dependent work, make sure the previous change has been reviewed and merged before executing the next task that needs it.

Take one feature from your backlog, turn it into a plan, and follow it through to a pull request you understand well enough to maintain.

Comments

[Ivan Annovazzi]

The pre-generation brief does a lot of heavy lifting here. Do you find writing it takes about as long as writing the feature yourself, or does the payoff show up later when you would have had to revisit the change?}