The fastest way to get poor code from AI is to ask for a large feature without showing the repository, constraints, or acceptance criteria. The model fills missing context with plausible guesses. A useful coding workflow reduces those guesses before generation begins.
Write the brief before the code
Describe the user-visible outcome, relevant files, current behavior, desired behavior, constraints, and how success will be tested. Include the exact error, reproduction steps, framework versions, and nearby code when debugging. Never paste secrets or production credentials.
“In this Vite/React app, the settings modal loses unsaved form state when the theme changes. Preserve state without moving it to a global store. Existing tests are in settings-modal.test.jsx. First explain the cause, then propose the smallest patch and tests.”
A reliable implementation workflow
Inspect before editing
Ask the AI to locate the entry point, related state, tests, and conventions. A plan grounded in real files is more useful than generic architecture advice.
Agree on the smallest change
Separate the requested behavior from attractive refactors. Small diffs are easier to understand, test, and reverse.
Generate a focused patch
Request changes in the existing style. Ask the model to name assumptions and avoid unrelated formatting or dependency upgrades.
Run the narrow tests
Start with the closest unit or integration test, then expand to linting, type checks, the broader suite, and a production build as risk warrants.
Inspect the actual diff
Read every changed line. Check error paths, empty states, concurrency, permissions, accessibility, and whether the solution silently changes an API.
Verify the behavior manually
For interfaces, use the real app. For APIs, test valid and invalid inputs. Passing tests cannot prove a missing case was covered.
Use AI to debug evidence, not symptoms
Share the full error, stack trace, environment, reproduction steps, and the most recent relevant change. Ask for multiple hypotheses ranked by likelihood and a test that distinguishes them. This prevents the conversation from locking onto the first plausible explanation.
Given the evidence below: - produce 3 plausible root causes, - cite the line or behavior supporting each, - propose the smallest diagnostic check for each, - do not edit code until one hypothesis is supported. Error: [full error] Reproduction: [steps] Environment: [versions] Relevant code: [files or excerpts]
Review security and correctness explicitly
Ask a separate review pass to look for injection, broken authorization, secret exposure, unsafe file paths, dependency risk, race conditions, and privacy leaks. “Review this code” is too broad; name the threat surface.
AI-generated tests can repeat the implementation's assumptions. Add at least one adversarial case yourself: missing permissions, malformed input, network failure, duplicate submission, unexpected encoding, or an empty dataset.
A reusable coding prompt
Outcome: [user-visible behavior] Repository context: [framework, paths, conventions] Current behavior: [what happens] Expected behavior: [what should happen] Constraints: [no new dependency, API compatibility, etc.] Acceptance checks: [tests and manual behavior] First inspect the relevant files and explain the smallest safe plan. Then implement only the approved scope. After editing, run the narrowest relevant checks, inspect the diff, and report remaining risks.
Code with AimiChat
AimiChat's code mode can execute calculations and code, preview small interfaces, and keep the result inside the conversation. Use it for prototypes, debugging, analysis, and review while maintaining the same discipline: inspect inputs, run checks, and understand the diff before shipping.
Where AI coding helps—and where it often creates review debt
| Usually a good fit | Use with tighter supervision | Human judgment must lead |
|---|---|---|
| Boilerplate, test fixtures, small transformations, documentation, unfamiliar API orientation | Cross-file refactors, concurrency, migrations, performance work, infrastructure configuration | Authorization, cryptography, destructive data operations, safety-critical logic, architecture boundaries |
Task fit matters more than hype. GitHub's controlled Copilot study found a major speedup on a bounded JavaScript task. METR's later randomized trial found experienced maintainers were slower with early-2025 AI tools on real issues in codebases they already knew. Do not flatten either result into “AI always helps” or “AI never helps.” Measure the work you actually do.
Write acceptance tests before asking for implementation
A strong coding brief separates behavior from solution. Use this template:
USER-VISIBLE OUTCOME [What a user can do or observe when this is complete] CURRENT BEHAVIOR [Reproduction steps and actual result] REQUIRED BEHAVIOR - Given [state], when [action], then [result] - Given [failure/empty state], when [action], then [safe result] - Existing behavior [X] must remain unchanged BOUNDARIES [Files, APIs, dependencies, performance, accessibility, privacy] VERIFICATION [Unit/integration/e2e tests, build command, and manual path] Before editing, locate the relevant code and identify assumptions. Propose the smallest change. Do not modify unrelated files.
After implementation, ask the AI to prove each acceptance statement with a test name, command result, or manual observation. “Implemented successfully” is not evidence.
A security review checklist for AI-written code
- Data flow: What untrusted input enters, where is it validated, and where is it rendered, queried, logged, or executed?
- Authorization: Is access checked on the server for the specific object—not only hidden in the UI?
- Secrets: Did prompts, source, logs, tests, or generated config expose credentials or internal data?
- Dependencies: Does every suggested package and version exist, remain maintained, and avoid known advisories?
- Failure behavior: Are timeouts, retries, partial writes, duplicate submissions, and rollbacks safe?
- Infrastructure: Treat CI, package scripts, IAM, containers, and deployment config as high-impact code.
- Review independence: Use static analysis, tests, dependency scanners, and a human review—not only another prompt.
OWASP's secure-coding guidance for AI specifically recommends validating suggested versions against vulnerability databases, controlling the context sent to providers, and applying security checks to agent changes beyond application files. NIST's Secure Software Development Framework provides the broader lifecycle: prepare, protect software, produce well-secured software, and respond to vulnerabilities.
Research behind this guide
The productivity claims are grounded in the GitHub Copilot controlled experiment and METR's randomized trial; their different settings explain why both belong in the decision. Security practices draw from the OWASP Secure Coding with AI Cheat Sheet, OWASP's secure review guidance, and NIST SP 800-218.