--- title: Agentic IDE Workflows for Enterprise Teams date: 2026-02-14 summary: How I run AI-assisted work in Visual Studio and VS Code on a team codebase, with Amazon Q Developer's ask and agent modes, version-controlled context packs, and quality gates that apply to every contributor. status: published tags: amazon q developer, ide workflow, enterprise engineering, context engineering, quality gates mediaSourcePath: /hire-me/ mediaSourceSelector: main, .hero mediaSourceTheme: dark imageAlt: The Hire Me page, where the day-job side of this workflow is described. imageCaption: Teams rarely fail AI adoption on install day. They fail in week three, when outputs start drifting between engineers. --- # Agentic IDE Workflows for Enterprise Teams Most teams don't fail at AI adoption on install day. They fail around week three, when four engineers using the same assistant start producing four different kinds of output, and nobody can say which one matches the team's standard. This is the operating model I use for IDE-first work at my day job, where I'm a QA automation engineer on a government software contract and the person who ended up owning how the team uses Amazon Q Developer. Everything here is about reliability over novelty, because on a regression suite that gates releases, novelty is not the goal. ## Install is step zero After the extension is installed and signed in against the organization's identity, I run a short acceptance check before anyone does real work: 1. Confirm the identity context is the enterprise one, not a personal account 2. Confirm which workspaces the assistant can see and what the data handling expectations are 3. Run one non-sensitive smoke prompt 4. Record the extension version in the onboarding doc The smoke prompt is boring on purpose: ```text Summarize this file in five bullets and propose one deterministic test improvement. ``` If that loop isn't stable, nothing else gets attempted. I've seen more time lost to a misconfigured sign-in than to any model limitation. ## Ask mode, then agent mode, then ask mode again The mode toggle in Q Developer is scope control, and I use it as a sequence rather than a preference. - **Ask** to understand the current state and the options. No edits yet. - **Agent** to apply the scoped change with explicit constraints. - **Ask** again to review the diff for risk and to list what should be verified. - Run the tests and attach the outcome to the pull request. Ask mode keeps me from committing to a change I haven't thought through. Agent mode keeps me from spending the afternoon typing boilerplate. Going back to ask mode at the end is the step people skip, and it's the one that catches the edit that touched a file it shouldn't have. ## Context packs, version controlled Prompt quality is a system problem, not a per-message problem. The single biggest reduction in output variance across the team came from writing the context down and checking it in. I keep two kinds of files. The personal ones are portable behavior constraints, the way I want any assistant to work regardless of repo: ```md Role: senior engineer optimizing for production safety. Priorities: - Regression risk before style feedback. - Scope stays inside the stated task. - Every response ends with a verification summary. ``` The repository ones are engineering rules the whole team owns, reviewed in pull requests like any other change: ```md - Behavior changes require the matching automated test update. - No modifications to files outside the stated task. - Prefer deterministic assertions over timing-based waits. - Non-trivial releases include rollback notes. ``` At work these live as the Rules, Profiles, and Prompts the team uses daily. On my own repos the same idea shows up as `CLAUDE.md` and `AGENTS.md`. The format matters less than the discipline: the file is the standard, the standard has a diff history, and the diff history has reviewers. ## Model routing as an explicit decision The IDE gives you a model picker, and the default habit is to set it once and forget it. I treat it as a per-task decision with a written policy: start on the fastest model likely to pass the quality gates, escalate only when a real failure shows up, and note when escalation happens. The escalation log tells you where the routing policy needs adjusting far better than any benchmark table does. I'm deliberately not listing model names here. They change quarterly. The policy doesn't. ## Quality gates that don't care who wrote the code The same gates apply whether a person or an assistant produced the change: - **Scope gate.** The changed files match the declared task. - **Test gate.** The relevant checks ran and the results are in the PR. - **Documentation gate.** Behavior-affecting diffs update the docs that describe the behavior. - **Risk gate.** Rollout and rollback are both clear. Making those explicit up front has saved more time than any model upgrade. It also removed a category of argument. Nobody has to decide whether AI-generated code deserves extra scrutiny, because all code gets the same scrutiny. ## What changed on the team The measurable part is the weekly regression cycle. Triage, diagnosis, and resolution got faster and more consistent once the shared prompt patterns existed, because a teammate diagnosing a flaky test starts from the same context I would. Script maintenance benefits the same way. The part that's harder to measure is that new people ramp faster, which is what pushed me to build an internal documentation app for onboarding, a story for another post. None of this required the newest model. It required treating the assistant's context like configuration, the assistant's output like any other contributor's, and the mode toggle like the scope control it is.