From Vibe Coding to Agentic Engineering: A Safe Shipping Workflow
فارسی
The short version: vibe coding is useful for turning an idea into something visible. Agentic engineering begins when the AI can inspect a repository, edit files, run commands, install packages, call tools, or interact with external systems. At that point, the operating question is no longer “Can it generate code?” It is “What is it allowed to change, what evidence proves the result, and how do we recover when an assumption is wrong?”
Coding agents are moving toward longer tasks and coordinated work. OpenAI’s GPT‑5.6 launch describes higher-effort modes and a multi-agent beta. Anthropic’s 2026 trend report forecasts longer-running agents that build larger slices of systems. Those sources describe product direction, not a guarantee that an unattended agent can safely ship your application. Longer horizons increase both leverage and the cost of a bad premise.
Three levels that should not be confused
Vibe coding emphasizes intent and fast visual feedback. You ask for a form, interaction, or fix, inspect the result, and adjust. Agentic coding adds tools and multi-step execution: the model searches, edits, runs tests, and responds to results. Agentic engineering adds the management system around that work: scope, permissions, recovery, acceptance criteria, review, and release evidence.
The distinction matters because output is not evidence. A new file does not prove a feature works. A passing unit test does not prove a browser flow is usable. A successful API response does not prove a deployment reached production. An agent’s “done” message is not a read-back from the destination system. A credible handoff separates built, locally tested, CI-validated, deployed, and publicly verified states.
The seven-gate workflow
1. Write the product contract before the prompt
Start with the user outcome, not the technology. Define what the user can do, what must remain unchanged, which side effects are authorized, and what evidence will count as acceptance. “Build booking” is vague. “Let a user choose a time window, reject invalid input with a clear message, perform no payment action, and pass mobile and desktop flows” is reviewable.
Set system boundaries too. A frontend task rarely needs production database access. A diagnostic request does not imply deployment authority. Narrow boundaries reduce blast radius and make the agent’s search space more useful.
2. Capture the starting state
Read the workspace path, branch, dirty files, runtime versions, and baseline test result before editing. Treat existing changes as someone else’s work unless you know otherwise. Use an isolated branch or worktree for material changes so the result is easy to compare and recover.
The same rule applies outside Git. Re-open the exact CMS record, issue, spreadsheet row, or API resource before acting. Agent memory and earlier messages may be stale. Confirm the destination identity and status at action time.
3. Increase permission in steps
Begin with the least privilege that can answer the current question: read files and run non-mutating checks. Separate editing, dependency installation, network access, external writes, publication, and financial actions into explicit boundaries. Gemini CLI’s official trusted-folder documentation restricts local configuration, environment files, extensions, auto-acceptance, and automatic memory for untrusted workspaces. Its sandbox documentation describes isolation as risk reduction, not risk elimination.
Auto-approving every tool call feels fast because it removes friction, but it also removes useful decision points. Keep secrets out of prompts, logs, and repositories. Load credentials at runtime from environment or a secret manager, and keep receipts redacted.
4. Make tasks small enough to prove
A good task is small enough that a reviewer can understand its behavior and diff together, but not so fragmented that system behavior disappears. “Fix authentication” is too broad. “Reject external post-login redirects, preserve valid internal redirects, and test the positive, negative, and encoded URL cases” is bounded.
Give each task an input, output, owner files, acceptance test, and stop condition. Schema drift, missing access, a red baseline, or an unexpected production dependency should trigger a safe stop rather than a weaker gate.
5. Require evidence, not a narrative
Match proof to risk. A pure function may need unit tests. A browser flow needs rendered behavior, network results, and console checks. A release needs an exact commit, a completed workflow, the intended route, and a destination read-back. Public content needs the live URL, canonical, language, media, and rendered text.
A 2026 preprint manually analyzed more than 3,800 publicly reported bugs across Claude Code, Codex, and Gemini CLI. It found that functionality dominated the reports, while API, integration, and configuration errors were a major root-cause group; tool invocation and command execution were common affected stages. That study concerns bugs in the coding tools themselves, not the defect rate of every generated patch. The practical lesson is narrower: observe and test the tool-execution path as seriously as the edited code.
6. Review the diff and the assumptions
Do not stop at syntax. Ask whether the agent solved the correct problem, touched unrelated files, added unnecessary dependencies, validated only in the client, leaked sensitive data to logs, or omitted failure states. Read the named diff and run the verification independently.
You can perform a strong conceptual review without memorizing every language. Ask for a plain-language contract before and after the change, a list of failure modes, and exact verification commands. Then use a separate reviewer—human or a read-only agent with a narrow role—to compare the claims against code and tests.
7. Treat release as a separate operation
A successful build is not permission to publish unless the contract included release. Recheck secrets, migrations, rollback, health checks, domain, and environment. After an ambiguous workflow error, query the actual run before retrying; blind retries can create duplicate deployments or records.
Verify from outside the build process. For a site, HTTP 200 alone is not enough; canonical, indexability, assets, language, and links matter. For an application, verify identity, authorization, writes, and recovery with safe scoped data. Report what is local, CI-complete, deployed, externally processed, or still unverified.
When multiple agents help
Parallel agents are useful when workstreams are genuinely independent: repository mapping, primary-source research, a read-only security review, or separate modules with clear ownership. They are poor fits when every path edits the same file, depends on one unresolved architectural choice, or must consume the previous path’s output.
- Give each agent an owner area, deliverable, constraints, and acceptance criteria.
- State that other work exists and must not be reverted.
- Use a single integrator to reconcile contracts and run the final suite.
- Measure time to an accepted result, including review, conflicts, retries, and model cost.
“Multi-agent” is an execution strategy, not a quality badge. A single well-scoped agent often beats a coordinated swarm on small or sequential work.
A compact operating checklist
- The user outcome, exclusions, and authorized side effects are written down.
- The branch, dirty state, baseline tests, and target identity are captured.
- The agent has only the files, network, and tools the current stage needs.
- Secrets stay outside prompts and repository files.
- Every task has an acceptance test and safe stop condition.
- Diff, tests, rendered behavior, and external state are reviewed separately.
- Release, rollback, and destination read-back have their own evidence.
Regional access is part of architecture
Technical capability and officially supported access are separate. OpenAI’s supported-country list did not include Iran at this article’s 2026-08-09 review, and the company warns that access from outside listed locations can lead to account restrictions. This guide does not recommend circumvention. Before making a project or client dependent on any provider, verify the current country list, account terms, billing path, data location, and organizational policy.
Bottom line
Vibe coding can be a productive creative front end. Agentic engineering keeps that speed from becoming invisible debt. Write the contract before the prompt, grant permissions in stages, use Git as a recovery boundary, test the real behavior, and call a release complete only after the destination says so.
For deeper acceptance criteria, use the AI agent evaluation framework. For a concrete localization example, see the Persian product AI evaluation set. More project and author context is available on Sepehr Bayat’s site.