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.

Defining "Working" Before Generation

Before generating code, clarify what "working" means. The assistant must make explicit decisions about key behaviors:

• Who can invite: Organization admins can create invitations.
• What an invitation grants: Member role assignment.
• Expiration: Invitations expire after seven days.
• Acceptance conditions: Requires an authenticated account with a verified email matching the invitation.
• Consumption limits: Each invitation can be consumed once, even under concurrent requests.

This makes the behavior evaluable and prevents hidden assumptions from silently shaping the output.

Implementing Team Invitations

Provide the assistant a clear brief with defined behavior:

Implement team invitations in this existing Laravel and Vue app.

Behavior Specification

• 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.

With this specification, the assistant produces verifiable outcomes rather than ambiguous code.

Examining Existing Patterns

A mature repository already contains decisions about validation, permissions, transactions, errors, and tests. The assistant needs to locate and leverage these existing patterns. Ask for a short map of the existing implementation:

Responsibility	Target Location
Resolving the current organization	[Locate]
Authorizing organization administrators	[Locate]
Creating memberships	[Locate]
Sending queued transactional emails	[Locate]
Testing organization access boundaries	[Locate]

Separate confirmed behavior from assumptions. A confident explanation of a policy class is only useful if the class exists and applies to the request being changed. Verify each finding before proceeding.

Scaling the Effort

Not all features deserve deep investigation. A label change needs a quick edit. An invitation flow, however, crosses identity, permissions, persistence, and email - requiring thorough examination. Plan accordingly:

• Small, reviewable changes can be handled directly.
• Large-scale modifications benefit from structured planning and multiple reviews.

Source-Size Tasks & Verification

End every task with behavior you can inspect and verify. For the invitation feature, start with issuing an invitation covering four areas: persistence, authorization, validation, and focused tests. Follow with safe acceptance, then connect the interface to verified endpoints. Each task should state its dependencies and the evidence that completion is established.

If acceptance relies on an invitation schema, establish that schema first. Keep the review manageable - a small change across eight files may be straightforward, while a dense rewrite in one file demands substantial investigation. Ask yourself whether you can explain the change after reading the diff. If not, split the work or investigate the confusing part before continuing.

Testing Failure Scenarios

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 the invitation flow, the review should include these scenarios:

Scenario	Expected Result
Ordinary member creates an invitation	Request rejected; no invitation or email created
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 final case requires careful coordination. Checking whether an invitation is unused before creating a membership leaves room for a race condition unless the implementation explicitly coordinates those operations. Ask the assistant to explain what enforces single consumption, examine transaction behavior and database constraints, and exercise concurrency against the production database engine.

Debugging Through Evidence

When a generated feature fails, avoid repeated "try again" prompts that produce speculative changes. Instead, give the assistant observations it can investigate:

• The request payload
• The expected result
• The actual result
• Relevant logs
• A reproducible sequence

Redact credentials and unnecessary personal data. For example, trace the token lookup, consumption, and membership insert for the duplicate membership scenario. Identify a likely failure mechanism and the evidence supporting it. Create a reproduction that distinguishes that explanation from alternatives. Apply a focused fix, rerun the reproduction and related tests, and report the commands run, their results, and any remaining uncertainty.

Recording Decisions & Documentation

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 this record concise and update it when decisions change. An outdated architecture note can steer subsequent work toward an implementation 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, but 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.

Pull Request Preparation

Before merging, read the diff and explain how the feature behaves under normal use and failure. For invitations, this means understanding where authorization happens, how the recipient is verified, how token consumption is enforced, and what occurs if sending the email fails. For schema changes, 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, then 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.

Vibe Coder Planner Integration

Organize this process in Vibe Coder Planner using a project plan, individual task prompts, and a Kanban board. Start with a specific feature brief that captures your stack, existing behavior, desired outcome, and acceptance criteria. For this example:

• Stack: Laravel, Vue, PostgreSQL SaaS
• Existing behavior: Authentication and organization memberships already exist; admins can invite members
• Desired outcome: Add organization invitations
• Acceptance criteria: Invitations expire after seven days; only org admins can create them; acceptance requires verified accounts

Generate ordered tasks for issuing invitations, accepting them, and connecting the interface. Include dependencies, acceptance criteria, and verification steps for each task. The planner generates a task breakdown you can edit and reorder, and you should review that plan against repository findings before execution.

Feature Overview & Execution Workflow

Execute through your editor or GitHub. Install the Vibe Code Planner extension in Cursor or VS Code, open settings, connect using your account API token, and access the project's tasks and prompts via the sidebar. Use each task prompt with your coding assistant.

Editor Setup

For automated execution, design a plan that includes the feature, connects GitHub, links the project's repository, and configures 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.

GitHub Workflow

For dependent work, ensure 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.

---

By following this structured approach, you transform AI-generated code from a black box into a verifiable, maintainable contribution. The key is explicit definition of behavior, rigorous testing of edge cases, and disciplined documentation throughout the development cycle.