Ready for Vibecoding

There is a new way to build small automations for your everyday administrative work, and it does not require any technical background. You describe what you want in plain language, an AI builds it, and you keep talking to it until the thing works. It is a variation of what people call "vibecoding," and a practical way to start exploring the practice without committing to anything bigger.

For an election office, this is genuinely useful. A lot of the small, repetitive, spreadsheet-shaped problems you solve by hand could become simple tools. It is also genuinely risky if you are not deliberate about it, because the same ease that lets you build something in ten minutes lets you build something broken, insecure, or quietly mishandling data in ten minutes.

Just like vibecoding, you do not need any coding background to use this guide.

Thank you to the Election Security Exchange for its review and feedback on this guide.

---

The term comes from AI researcher Andrej Karpathy, who described a way of working where you "give in to the vibes." You tell an AI what you want, accept what it produces, and iterate back and forth until you are happy, without reading every line of code yourself. The barrier that used to separate people who can describe a tool from people who can build one mostly disappears.

How It Works, Step by Step

• Describe your tool

  In plain language: "Build me a page where I can paste in a list of poll worker names and it splits them evenly across five precincts."

• The AI writes the code

  You do not write it, and you do not need to read every line of it.

• You see it run

  Most modern tools show you the working thing immediately, right there in the window.

• You direct revisions

  You trigger changes by talking. "Make the precinct names editable." "The totals are wrong when there is an odd number." You describe the problem; it fixes it. Repeat until the tool does what you need.

Where these tools live Background

The AI platforms people use to build these automations fall into a few buckets:

• Chat assistants (like Claude or ChatGPT) that can write and, in some cases, run a small app inside the conversation.
• Prompt-to-app builders that turn a description directly into a working web app.
• AI coding environments aimed at people who already write some code.

For your first tool, a chat assistant that can build and run a small app in the window is the simplest and the safest place to start. You are not deploying anything; you are just describing and looking.

What It Is Good At, and What It Is Not

Vibecoding is excellent for small, self-contained, throwaway tools: calculators, formatters, checklists, schedulers, one-off data reshuffles. It is not a substitute for professional software development. And it comes with one honest catch worth stating plainly.

---

The safest way to learn this is to build something that cannot hurt anyone even if the code is completely wrong. A tool is zero-risk when it passes all four of these tests.

Good First Projects for an Election Office

• A poll-worker shift scheduler that spreads fictional names across precincts.
• A countdown-and-checklist dashboard for pre-election tasks.
• A readability checker for voter-facing communications.
• A tool that turns a public dataset into a clean chart.
• A practice-quiz generator for staff training.
• A memo formatter that takes a few inputs and produces a tidy draft.

None of these can cause harm if they misbehave, because there is nothing real on the line.

The Starter Prompt

Here is a script you can copy, fill in, and paste into an AI tool to get a zero-risk application started. The guardrails are built in, so you do not have to remember them each time.

The last two sentences matter most. They turn the AI into a partner that flags when you are wandering out of zero-risk territory, instead of quietly building something it should not.

A Quick Worked Example

Say you fill it in like this: "A tool where I paste in a list of made-up poll-worker names, tell it how many precincts I have, and it splits the names evenly across them and shows the count per precinct." You will get a working page in the window — something like the one below. Now test it the way Part 3 describes: try eight names across three precincts and count by hand. Does the math hold when it does not divide evenly? That habit of checking is the skill worth building, more than the tool itself.

---

Everything above keeps you safe by keeping you small. The moment you want to publish — put the tool on a real server, give it a live link, connect it to anything, or let it handle real data — you are no longer the only person with a say. Now you have to get past your security office.

So picture the person who owns that decision: a Chief Information Security Officer who has seen a decade of "quick little tools" become the soft spot an attacker walked through. Their default posture toward a vibecoded tool is skepticism, and they are right to hold it.

These are the ten technical requirements that gate publication. Each one names why vibecoded tools tend to fail it, and what a passing answer looks like. "We think so" is not a pass. "Here is the evidence" is.

1. No secrets in the code

   Secrets are the information used to prove identity and gain access. If they sit in the code, they are visible to anyone who can read it — and your secrets are no longer secret. Credentials of any kind (API keys, passwords, tokens, connection strings) must not appear in the source, in client-side code the browser can read, or anywhere in the version history. Secrets live in a managed secrets store or environment variables, injected at runtime and scoped to least privilege. Anything ever exposed is rotated before launch.

   Why it fails

   AI routinely hardcodes keys to "make it work," and drops them into browser-side code where anyone can read them.

   Pass

   A secret scan of the code and its full history comes back clean.

2. Every input validated, every output encoded

   All input is validated and sanitized on the server; all database access uses parameterized queries; everything rendered back to a user is encoded so input cannot execute as code.

   Why it fails

   Vibecoded code tends to trust input and assemble queries by gluing strings together — the exact pattern behind SQL injection and cross-site scripting.

   Pass

   The injection and XSS classes from the OWASP Top 10 are explicitly tested and closed.

3. Real access control, enforced on the server

   If the tool touches anything that is not fully public, it requires authentication, single sign-on, and multi-factor where available; and it checks authorization on every action on the server side, not by hiding buttons in the interface. Least privilege throughout. "Nobody knows the URL" is not access control.

   Why it fails

   Broken access control is the most common serious web flaw, and vibecoded tools frequently guard a page only in the interface while leaving the underlying action wide open.

   Pass

   Access is enforced server-side and tested with a lower-privileged account that is correctly denied.

4. Sensitive data classified, minimized, and encrypted

   The data the tool handles is classified against your policy; no personal or voter data without explicit written approval; HTTPS/TLS is enforced in transit; sensitive data is encrypted at rest; nothing sensitive lands in URLs, logs, or browser storage; retention matches records law.

   Why it fails

   Vibecoded tools default to convenience — plaintext, everything logged, data kept forever.

   Pass

   A data-flow diagram showing exactly what data goes where, reviewed against policy.

5. Dependencies inventoried, pinned, scanned, and real

   A software bill of materials lists every third-party package; versions are pinned; a software-composition scan shows no known vulnerabilities; and each dependency is confirmed to actually exist and be maintained.

   Why it fails

   AI pulls in libraries freely, and sometimes invents ones that do not exist — a gap attackers now exploit by registering those hallucinated names with malware ("slopsquatting").

   Pass

   An SBOM plus a clean dependency-vulnerability scan.

6. In version control and reviewed by a human

   The source lives in version control; a qualified person has actually read and reviewed it; a static-analysis scan has run and its findings are resolved; the build is reproducible. It does not exist only on the builder's laptop.

   Why it fails

   The defining move of vibecoding is not reading the code. Publication reverses that — someone who can read code signs their name to it.

   Pass

   A review record and a clean static-analysis report.

7. Runs in an approved, hardened environment

   Hosted in a sanctioned, isolated environment on least-privilege service accounts — not a personal machine, not an unmanaged cloud account. Default credentials removed, runtime patched, HTTPS only, security headers set (such as Content-Security-Policy and HSTS), attack surface minimized.

   Why it fails

   Vibecoded tools get stood up wherever is fastest, which is the textbook definition of shadow IT.

   Pass

   Deployed to an environment security has approved and configured.

8. Logs the right things, and is watched

   Security-relevant events (logins, changes, failures) are logged; logs are protected, retained, and free of sensitive data; monitoring and alerting are in place so a problem is noticed.

   Why it fails

   Vibecoded tools typically log nothing useful, so after an incident you cannot reconstruct what happened.

   Pass

   An audit trail exists and someone or something is watching it.

9. Fails safely and resists abuse

   Errors never expose stack traces or internal detail to the user; the tool fails closed, not open; public endpoints have rate limiting and basic abuse protection.

   Why it fails

   AI-generated error handling tends to dump internal detail straight to the screen and leaves endpoints wide open to hammering.

   Pass

   Tested error behavior and load behavior, with nothing leaked and nothing left unthrottled.

10. Has an owner, a rollback, and a kill switch

    A named person is accountable for the tool; a known-good backup and a rollback path exist; there is a defined way to decommission it and a named incident-response contact.

    Why it fails

    Throwaway tools drift into being depended on with no owner and no way to turn them off.

    Pass

    Ownership, backup, rollback, and decommission are all defined before launch.

Evidence of Security

Before your new tool goes live, the testing of each of these ten technical conditions should be well documented, with evidence, and verified by someone who can read the code — not the AI itself. If you cannot meet all ten, that is not a failure; it is information. It means the tool stays where it belongs: an internal, zero-risk tool under Part 2, or a project handed to professional developers who can carry it across this line.

---

Vibecoding is a real capability, and it is worth having in your office. Treated as a way to make small, disposable, low-stakes tools quickly, it gives you leverage you did not have before. Treated as a shortcut around the people and safeguards that keep election systems trustworthy, it becomes a liability.

The four conditions for a zero-risk application, and the ten security requirements for anything beyond it, are the things to understand before you build and deploy. Navigate those, and you can build with confidence.

---