--- title: "My AI-Assisted Engineering Workflow" description: "The seven rules I follow to use Claude Code and similar agents on production code with confidence — not a skeptical take, a discipline manifesto" url: https://sade.dev/en/journal/ai-assisted-engineering-workflow/ lang: en author: "Muhammet Şafak" published: 2026-05-10 updated: 2026-09-06 section: Journal tags: ["ai-workflow","productivity","opinion"] summary: "Two years of daily work with coding agents produced seven rules, and all seven make the same point: the agent changed who types the code, not who is responsible for it. No writing without an approved plan, limited access, tests you run yourself rather than trust, review as strict as a junior's, decisions written down in the repo so the agent has a past, and no merge of a line you could not defend." --- # My AI-Assisted Engineering Workflow > Two years of daily work with coding agents produced seven rules, and all seven make the same point: the agent changed who types the code, not who is responsible for it. No writing without an approved plan, limited access, tests you run yourself rather than trust, review as strict as a junior's, decisions written down in the repo so the agent has a past, and no merge of a line you could not defend. I've worked with AI coding agents daily for 2 years. The first year I used them naively; the second year I built discipline. This post is that discipline, made concrete. How much faster I got numerically doesn't matter — what matters is that **the quality of the code didn't drop**. If anything, I produced fewer bugs than the juniors coming into the codebase. That's not a brag, and it's not an ad for not using agents — it's an observation about what they're actually good for. ## 1. Make the agent plan first, approve it, then have it write "Write me an auth module" = uncontrolled. The flow that works: 1. "Draft a plan for the auth module. Endpoints, DB tables, edge cases." 2. Read the plan, ask questions, correct it. 3. "Write it per the plan" — but step by step on large modules. Don't grant permission to write code without an approved plan. **Ever.** ## 2. Grant limited access An agent doesn't need to be able to run `rm -rf`. Prefer a sandbox: - Filesystem read-only outside specific mounts. - Network access only to specific endpoints. - Access to production secrets **never**. Use a local mock or a scrubbed copy. This isn't a "the agent is malicious" assumption — it's an "it can make mistakes" assumption. ## 3. Have it test, run it, roll it back The agent wrote code. Now: 1. **Have it write tests** (or run the existing ones). 2. **Run the tests.** Its claim that they pass isn't enough — actually see it. 3. **Do a manual smoke test.** Trust your eyes, not the agent's claims. 4. When in doubt, `git checkout .` — try again. The agent's summary isn't reality. It's not lying — it just assumes its own output is good. Verification is a human job. ## 4. Don't skip the code review step Code an agent produces should be reviewed like code a junior engineer produces. Don't fall for the "the agent already checked it" fallacy. Especially: - **Security.** SQL injection, XSS, auth bypass. - **Performance.** N+1 queries, needless cache invalidation. - **Boundary conditions.** Empty input, very large input, Unicode. Static analysis is good for catching these, but the human eye is indispensable. ## 5. Keep the context Don't forget the agent "has no past." Every session, you have to explain why you reached each decision. To automate that: - I keep a live snapshot of state in the repo, in something like `CLAUDE.md` or `.ssot/`. - I write the important decisions there: "We use PostgreSQL because…, Redis runs in cache-only mode because…". - The agent reads this at the start of the session and makes more consistent decisions. ## 6. Don't put the agent in place of a single engineer Putting an agent *in place of* a senior engineer is wrong. Using the agent as an **extension** of a senior engineer is right. Telling juniors to just "have the agent do it" is usually a disaster — because: - They don't know how to read the agent's output critically. - They haven't yet learned to ask the right question. - They can't yet feel the difference between "it works" and "it works correctly." The task you give a junior can be to **audit** the agent — but not to direct it. ## 7. You are responsible for every line of code that reaches production This is the most important one. If you merged a SQL injection hole the agent wrote, the responsibility is yours. "The AI wrote it" is no excuse in a PR review. In practice: don't merge anything the agent produced until you're sure it's code you've **actually read** and understood, and could defend if you had to. ## Conclusion Agents are incredibly powerful tools. Seeing them as "magic wands that ship a feature in 30 seconds" is failure. Seeing them as "an intern that extends a senior engineer" is success. Which side you pick determines the quality of the software that comes out. Two years on, I still follow the same discipline because it works. ## Frequently asked **Should an agent be allowed to write code without an approved plan?** Never. The flow that works is plan first, read the plan and correct it, then have it written per the plan — step by step on large modules. Asking for a whole auth module in one sentence is uncontrolled work. **Is it enough that the agent says the tests pass?** No. Run the tests yourself, do a manual smoke test, and when in doubt throw the work away and try again. The agent's summary is not reality; it is not lying, it just assumes its own output is good. Verification is a human job. **Can a junior engineer be told to just have the agent do it?** Usually that is a disaster. A junior cannot yet read the agent's output critically, has not learned to ask the right question, and cannot yet feel the difference between it works and it works correctly. The task you give a junior can be to audit the agent, but not to direct it. **Who is responsible for agent-written code that reaches production?** You are. If you merged a SQL injection hole the agent wrote, the responsibility is yours, and the AI wrote it is no excuse in a PR review. In practice: merge nothing you have not actually read, understood, and could defend if you had to.