{"slug": "how-to-work-with-ai-like-a-senior-developer", "title": "How to work with AI like a Senior Developer", "summary": "A developer outlines a workflow for using AI coding assistants the way a senior engineer would: define explicit behavior, ask the assistant to map existing authorization, membership and email flows before writing code, separate confirmed behavior from assumptions, and sequence work into verifiable tasks. Using a Laravel and Vue team-invitations feature as the example, the approach requires evidence that each change works and warns that tests generated alongside an implementation can share its assumptions.", "body_md": "A practical workflow for turning generated code into changes you can understand, verify, and ship.\n\nYou 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.\n\nThen 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?\n\nThose questions determine whether the feature is ready to ship.\n\nUsing 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.\n\nHere is how to apply that approach to a real development task.\n\n“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.\n\nMake 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.\n\nNow you have behavior that can be evaluated.\n\nGive the assistant a brief like this:\n\nImplement team invitations in this existing Laravel and Vue app.\n\nBehavior:\n\nFirst inspect the existing authorization, membership, and email flows.\n\nIdentify unresolved product decisions and propose a small implementation plan.\n\nOne 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.\n\nA mature repository already contains decisions about validation, permissions, transactions, errors, and tests. The assistant needs to find the relevant ones.\n\nAsk for a short map of the existing implementation:\n\nLocate the code responsible for:\n\nReference the files and symbols supporting each finding.\n\nSeparate confirmed behavior from assumptions.\n\nThat last line matters. A confident explanation of a policy class is only useful if the class exists and applies to the request being changed.\n\nCheck 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.\n\nScale 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\n\nA useful task ends with behavior you can inspect and verify.\n\nFor 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.\n\nEach 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.\n\nKeep 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.\n\nAsk yourself whether you can explain the change after reading the diff. If you cannot, split the work or investigate the confusing part before continuing.\n\nAI can produce changes faster than you can understand them. Your review capacity should influence how much work you ask it to produce at once.\n\nTests generated alongside an implementation can share its assumptions. A passing suite is useful evidence only for the behavior it actually checks.\n\nWrite down the important failure cases yourself, then use AI to implement and expand those checks.\n\nFor our invitation flow, the review should include these scenarios:\n\nScenario\n\nExpected result\n\nAn ordinary member creates an invitation\n\nRequest rejected; no invitation or email created\n\nAn admin targets an organization they do not administer\n\nRequest rejected; no changes to either organization\n\nSomeone accepts an expired or consumed invitation\n\nNo membership created\n\nA different verified account accepts the invitation\n\nRequest rejected; no membership created\n\nTwo requests accept the same invitation concurrently\n\nOne successful consumption; one membership created\n\nThe 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.\n\nAsk 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.\n\nFor a bug fix, require a regression test that reproduces the defect against the old implementation. That gives the test a concrete reason to exist.\n\nWhen a generated feature fails, repeated “try again” prompts can produce a pile of speculative changes.\n\nGive the assistant observations it can investigate: the request, expected result, actual result, relevant logs, and a reproducible sequence. Redact credentials and unnecessary personal data.\n\nFor example:\n\nTwo concurrent acceptance requests sometimes create duplicate memberships.\n\nTrace the token lookup, consumption, and membership insert.\n\nIdentify a likely failure mechanism and the evidence supporting it.\n\nCreate a reproduction that distinguishes that explanation from alternatives.\n\nApply a focused fix and rerun the reproduction and relevant tests.\n\nReport the commands run, their results, and any remaining uncertainty.\n\nThis gives you a way to judge progress. A hypothesis predicts something observable. A reproduction checks that prediction. A fix must change the outcome.\n\nRead the verification report carefully. If the database was unavailable, the concurrency behavior remains unverified. Keep that limitation visible in the pull request.\n\nAs 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.\n\nKeep 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.\n\nWhen handing work to another session or model, include the current task, relevant files, accepted decisions, and verification requirements. Give it a clear starting point.\n\nChoose 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.\n\nEvaluate 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.\n\nBefore merging, read the diff and explain how the feature behaves under normal use and failure.\n\nFor 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.\n\nA second AI review can suggest issues worth investigating. Ask for specific failure scenarios, affected code, and supporting evidence. Validate those findings yourself.\n\nThe 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.\n\nPut this workflow into practice with Vibe Coder Planner\n\nYou 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.\n\nEnter your stack, existing behavior, desired outcome, and acceptance criteria. For this example:\n\nAdd organization invitations to an existing Laravel, Vue, and PostgreSQL SaaS.\n\nAuthentication and organization memberships already exist.\n\nAdmins can invite members. Invitations expire after seven days.\n\nAcceptance requires a matching verified account and must be safe\n\nagainst simultaneous requests using the same token.\n\nGenerate ordered tasks for issuing invitations, accepting them,\n\nand connecting the interface. Include dependencies, acceptance criteria,\n\nand verification steps for each task.\n\nThe project planner generates a task breakdown you can edit and reorder. Review that plan against the repository findings and resolve missing decisions before execution.\n\nUse 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.\n\nFor our example, record the organization resolution pattern, permission rules, invitation lifecycle, and test commands. Update it as the implementation establishes new facts.\n\nOpen 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\n\nFor 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\n\nFor 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\n\nInspect 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\n\nFor dependent work, make sure the previous change has been reviewed and merged before executing the next task that needs it.\n\nTake one feature from your backlog, turn it into a plan, and follow it through to a pull request you understand well enough to maintain.", "url": "https://wpnews.pro/news/how-to-work-with-ai-like-a-senior-developer", "canonical_source": "https://dev.to/martintonev/how-to-work-with-ai-like-a-senior-developer-2h2k", "published_at": "2026-09-24 22:03:24+00:00", "updated_at": "2026-09-24 22:59:12.487910+00:00", "lang": "en", "topics": ["ai-tools", "developer-tools", "ai-products"], "entities": ["Laravel", "Vue", "Anthropic"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/how-to-work-with-ai-like-a-senior-developer", "markdown": "https://wpnews.pro/news/how-to-work-with-ai-like-a-senior-developer.md", "text": "https://wpnews.pro/news/how-to-work-with-ai-like-a-senior-developer.txt", "jsonld": "https://wpnews.pro/news/how-to-work-with-ai-like-a-senior-developer.jsonld"}}