AI coding without shipping slop

AI is a force multiplier for developers who already know what good looks like. It’s a risk amplifier for teams who paste answers they can’t explain. Clients shouldn’t care about the hype word on the invoice — they should care whether the site is secure, maintainable and finished by a human who owns the outcome.

Here’s how I use AI-assisted coding on real projects without releasing “slop”: generic UI, invented APIs, half-secure forms, and code nobody wants to maintain. The goal is faster drafts with stricter review — not autopilot production.

Where AI genuinely helps

• Boilerplate and refactors — renaming, extracting helpers, first-pass tests
• Exploration — unfamiliar APIs, alternative approaches, edge-case brainstorming
• Draft copy and UI variants — then edited for brand voice
• Review prompts — “what did we miss on CSRF / accessibility / mobile?”
• Documentation drafts — README skeletons, changelog notes
• Migration helpers — bulk renames, converting repetitive markup, sketching SQL

Speed here is real. The job is converting speed into quality, not skipping judgment. Treat every suggestion as a pull request from a very fast junior who has never met your host, your brand, or your threat model.

Where it fails hard

• Invented APIs and packages — confident nonsense that doesn’t exist
• Security-sensitive auth and payments without scrutiny
• Architecture that looks neat and hides coupling or copy-paste modules
• Accessibility theatre — attributes without real keyboard behaviour
• “Works on my laptop” CSS with no responsive or cross-browser thought
• License and secret leakage if tools see private code carelessly
• Outdated patterns — deprecated PHP, insecure crypto, old WordPress APIs

Treat AI-assisted code like junior code: review it as if production depends on it — because it does.

A workflow that stays professional

1. Specify the outcome — acceptance criteria, not “make a contact form”
2. Generate a draft — narrow prompts, one concern at a time
3. Read every line you keep — if you can’t explain it, rewrite it
4. Run it — browser, phone, form post, error paths
5. Security pass — auth, CSRF, XSS, uploads, secrets
6. Performance pass — weight, images, third parties
7. Commit with a human message — history should make sense without the chat log

Prompts that work better are concrete: stack version, file boundaries, constraints (“no new dependencies”, “PDO only”, “must work without JS”). Vague prompts produce vague architecture.

// Example acceptance criteria you can paste into a prompt
// - PHP 8.2, PDO prepared statements
// - CSRF token on POST
// - Escape all output
// - No new Composer packages
// - Works if JS disabled (full page POST)

Security non-negotiables

• Never paste production secrets into public tools
• Prefer private/enterprise tooling when code is client-confidential
• Payments, password reset, and permission checks get human design — not autocomplete
• Dependency suggestions get version and audit checks
• Generated “crypto” or token schemes are guilty until proven against known good libraries

Also watch for subtle leaks: sample .env files with real-looking keys, hard-coded staging URLs, or comments that reveal internal infrastructure. Clean those before the code ever leaves your machine.

Architecture still matters

AI is good at filling files. It’s bad at deciding system boundaries. You still own:

• Where state lives (server vs client)
• How data is modelled (posts vs tables vs APIs)
• What must be transactional
• What must be audited (who changed what, when)
• What must survive a bad deploy (feature flags, backwards-compatible schema)

If the generated structure fights your hosting or your team’s skills, change the structure — don’t paper over it with more generation. One coherent module map beats five “clean” folders that don’t match how the product actually works.

Code review checklist for AI output

• Does every query use bound parameters?
• Is user HTML escaped or sanitised on the way out?
• Are error messages safe for production (no stack traces, no path leaks)?
• Do forms re-display input and errors correctly?
• Is there a clear owner file for this feature six months from now?
• Did it introduce a dependency you didn’t approve?
• Do names match the rest of the project’s vocabulary?

If you only skim for “does it look right”, you will miss the bugs that matter: race conditions, wrong permission checks, off-by-one validation, and silent failure paths.

Testing: light but real

You don’t need a thousand unit tests on a brochure site. You do need:

• A checklist for critical paths (quote form, login, checkout)
• Regression checks after AI refactors (“did this still work?”)
• Staging that mirrors production PHP/Node versions
• At least one unhappy path per critical form (invalid email, empty required fields, CSRF failure)

// Minimal PHPUnit-style idea for a pure helper
public function test_email_reject_missing_at(): void {
  $this->assertFalse(is_valid_email('not-an-email'));
}

For UI, a five-minute manual script on a phone is still worth more than green tests that never touch the browser. Automate where repetition is high; don’t fake coverage with assertions nobody trusts.

Working with design and content

AI can draft section copy and layout variants quickly. Brand still needs a human pass:

• UK English spelling and tone
• Claims you can defend (no invented awards or stats)
• Consistent component usage so the site doesn’t look like five templates glued together
• Accessibility of colour contrast and heading order

Generated “premium dark UI” often arrives with low-contrast greys and missing focus states. Fix those before the client demo.

Talking to clients about AI

Be honest: AI can reduce calendar time on well-scoped work. It does not remove the need for craft, review, or accountability. “AI built it” is not a warranty. “Human-reviewed, production-ready” is.

Good client framing:

• We use tools to accelerate drafts and exploration
• A named human reviews security, UX and maintainability
• You still get documentation, a deploy path and someone to call

Bad client framing: implying the model is the delivery team, or hiding tool use as if it were a secret. Transparency builds trust; mystery invites unrealistic expectations.

A practical policy for small teams

1. Define which tools are allowed with client code
2. Ban production secrets from prompts
3. Require human review on auth, payments, data export and admin permissions
4. Prefer small diffs over giant generated dumps
5. Keep architecture decisions in the README, not in chat history

Worked examples (AI workflow)

Prompts and review checklists you can reuse — the code still needs a human pass.

1) Prompt that forces constraints

Build a PHP contact form handler for a UK business site.

Constraints:
- PHP 8.2, no framework
- PDO prepared statements only
- CSRF token required
- Escape all output in the success template
- Return JSON {ok:true} or {ok:false,error:"…"}
- Do not invent Composer packages
- Include a short comment on rate limiting (where to hook it)

Output only the handler file and a minimal HTML form.

2) Review checklist (paste into a second AI pass)

Review this code for production:

1) SQL injection / XSS / CSRF
2) Secrets or .env values hard-coded
3) Error messages that leak stack traces
4) Missing validation on email/length
5) Accessibility issues on the form
6) Anything I cannot explain in plain English

List findings as: severity · issue · fix.

3) Human-owned acceptance test script

// Manual QA after any AI-touched change
// [ ] Form works without JavaScript
// [ ] Bad email rejected
// [ ] CSRF missing → 403
// [ ] Success state is clear on mobile
// [ ] No console errors
// [ ] Staging uses production PHP version

4) Keep AI out of secrets

# .gitignore (minimum)
.env
.env.*
!.env.example
vendor/
node_modules/
*.sql
uploads/

Curious about an AI-accelerated build with human finish? Book a free call →