Bad AI Workflow Example
This page shows what happens when you build with AI without planning, reviewing, or testing. It's the "vibe coding" approach — and it's the fastest path to a broken, insecure app.
We'll build the same feature as the Good AI Workflow example (a contact form) — but this time, we'll do it the wrong way.
The Setup
You need a contact form for your website. You open your AI tool and type:
Prompt: "Make me a contact form"
The AI generates something. It looks good. You copy-paste it into your project. It works. You move on.
Time spent so far: 2 minutes.
What the AI Generated
Here's what the AI might generate for that simple prompt:
<form action="send_email.php" method="POST">
<input type="text" name="name" placeholder="Your Name">
<input type="email" name="email" placeholder="Your Email">
<textarea name="message" placeholder="Your Message"></textarea>
<button type="submit">Send</button>
</form>
And the backend:
<?php
// send_email.php
$to = "admin@myapp.com";
$subject = "Contact Form Submission";
$message = "Name: " . $_POST['name'] . "\nEmail: " . $_POST['email'] . "\nMessage: " . $_POST['message'];
mail($to, $subject, $message);
header("Location: thank-you.html");
?>
Looks simple. Looks like it works. Let's see what's wrong.
Problem 1: No Input Validation
What's wrong: Anyone can submit anything. No fields are required. No email validation. No length limits.
What an attacker can do:
- Submit empty forms
- Submit fake email addresses
- Submit 10,000-character messages
- Submit malicious content
How to fix: Validate all fields on both client and server side. Check that fields are not empty, email is valid format, and content is within reasonable length limits.
Problem 2: No Spam Protection
What's wrong: Anyone can submit the form as many times as they want. There's no CAPTCHA, no rate limiting, no honeypot.
What an attacker can do:
- Submit the form 10,000 times in an hour
- Flood your inbox with spam
- Overload your server with form submissions
- Use your form to send emails to arbitrary addresses (email injection)
How to fix: Add rate limiting (max 3 submissions per IP per hour), a honeypot field, or a CAPTCHA.
Problem 3: Email Injection Vulnerability
What's wrong: The mail() function in PHP is vulnerable to email header injection. An attacker can add extra headers to the email, including additional recipients.
What an attacker can do:
- Use your form to send spam to thousands of people
- Your server gets blacklisted as a spam source
- Your email reputation is destroyed
How to fix: Never pass user input directly to mail(). Use a proper email library that handles headers safely.
Problem 4: No Data Storage
What's wrong: Submitted data is only sent via email. If the email fails, the data is lost forever.
What can go wrong:
- Email server is down → you lose the submission
- Email goes to spam → you never see it
- You accidentally delete the email → data is gone
- No record of who submitted what or when
How to fix: Save submissions to a database before sending the email. This gives you a permanent record.
Problem 5: No Confirmation to User
What's wrong: After submitting, the user is redirected to a "thank you" page. But there's no feedback about whether the submission was actually successful.
What can go wrong:
- Email fails → user thinks it was sent, but you never received it
- Validation error → user is redirected without knowing what went wrong
- Server error → user sees a blank page or error
How to fix: Show a clear success or error message after submission. Handle errors gracefully.
Problem 6: No Error Handling
What's wrong: If anything goes wrong (email server down, database connection failed), the user sees a generic error or blank page.
What can go wrong:
- User thinks the form worked, but it didn't
- User gets frustrated and leaves
- You don't know anything went wrong
How to fix: Add try/catch blocks, log errors, show user-friendly error messages, and set up error monitoring.
Problem 7: No HTTPS Enforcement
What's wrong: The form submits over HTTP (not HTTPS). User data is sent in plain text.
What an attacker can do:
- Intercept the form submission on public Wi-Fi
- Read the user's name, email, and message
- Modify the form data before it reaches your server
How to fix: Enforce HTTPS on all pages. Redirect HTTP to HTTPS.
Problem 8: No Logging
What's wrong: There's no record of form submissions, errors, or suspicious activity.
What can go wrong:
- You can't tell if the form is being abused
- You can't debug errors
- You can't prove a submission was made
- You can't track submission patterns
How to fix: Log all submissions, errors, and rate limit events.
The Full Picture
Here's what the "simple contact form" actually looks like when you account for everything:
| Problem | Severity | Impact |
|---|---|---|
| No input validation | High | Malicious data, spam, abuse |
| No spam protection | High | Inbox flooded, server overloaded |
| Email injection | Critical | Your server sends spam, gets blacklisted |
| No data storage | Medium | Lost submissions, no audit trail |
| No user confirmation | Medium | Users don't know if form worked |
| No error handling | High | Silent failures, frustrated users |
| No HTTPS | Critical | Data intercepted in transit |
| No logging | Medium | Can't debug or detect abuse |
Total problems in a "simple" 10-line form: 8.
The Cost of This Approach
Immediate Costs
- You spend hours debugging when something breaks
- Users get frustrated and leave
- You miss important submissions
Long-Term Costs
- Your domain gets blacklisted for sending spam
- Your server gets compromised
- You have to rebuild the feature properly anyway
- You lose user trust
The Irony
Fixing all these problems would take about 30 minutes with proper planning. But finding and fixing them after deployment takes hours or days — and by then, damage has already been done.
The Comparison
| Aspect | Bad Workflow | Good Workflow |
|---|---|---|
| Time to first version | 2 minutes | 30 minutes |
| Time to production-ready | Never (it's broken) | 30 minutes |
| Security issues | 3 critical | 0 |
| Reliability | Low | High |
| Maintainability | None | Good |
| User trust | Low | High |
The Bottom Line
The "fast" approach is actually slower. The "slow" approach is actually faster.
The bad workflow feels fast because you get something working immediately. But that "working" thing is full of problems that will take longer to fix than they would have taken to prevent.
The good workflow feels slow because you spend time planning. But that planning prevents problems that would take much longer to fix later.
Speed without discipline is not speed — it's debt.