Welcome
This tier is for people comfortable with spreadsheets or Power BI who want to build — to automate the repetitive work instead of doing it by hand. By the end you'll be designed to be able to ship one working, verified, data-safe automation, and to do it in a way your IT team can approve.
We assume you've absorbed Tier 1's two habits — check the answer, protect your data. Everything here is built on them.
Module 1 — Vibe coding a real script with an AI pair
The idea. You describe what you want in plain English; the AI writes the code (Python, or Power Query, or a small script); you read it back, run it on a small example, and refine. You're the pilot — the AI is the co-pilot who types fast.
How to do it well. Work in small steps. Instead of "build me a reporting tool," ask for one piece: "write a Python script that reads a CSV and prints the total of the 'amount' column." Run it. Then "now group that total by region." Each step is small enough to check.
Reading code you didn't write. You don't need to understand every line, but you should be able to say what each block is for. Ask the AI to add plain-English comments, or to "explain this script line by line to someone non-technical." If it can't explain it simply, that's a signal to simplify.
Worked example. Ask: "Write a Python script that reads orders.csv and prints total revenue per region, sorted highest to lowest." Run it on a tiny made-up file. Check one region's total by hand. Then extend: "now save the result to a new CSV."
Pick one small data task you do by hand. Vibe-code it in two or three small steps on a made-up file, checking each step.
Small steps, check each one, insist the AI can explain its own code in plain words.
Module 2 — Make a safe sandbox: synthetic data that mirrors yours
The idea. This is the skill that unlocks everything else safely. Instead of building and testing on real, sensitive data, you create synthetic practice data — same shape and patterns as your real data, but none of the real records — and build against that.
How it works (and the honest limits). A good synthetic generator looks at your data's shape — the spread of the numbers, how often each category appears, how columns relate — and produces new rows that match those patterns without copying real ones. Crucially:
- It mirrors structure, it doesn't just delete names. Stripping a name still leaves clues (dates, amounts) that can point back.
- It must run on your machine. If you paste real customer data into a public AI to "anonymise" it, you've already exposed it.
- It reduces exposure — it doesn't make data legally anonymous. Treat the output as low-risk practice data, not as something you can publish freely.
Hands-on with our Sandbox tool. Open the Parkvara Sandbox (a single web page that runs entirely on your machine). Drop in a file. It flags identifier columns — names, codes, references — and replaces them with synthetic stand-ins, keeps generic categories, and mirrors your numbers. It shows you a report: how closely it matches, and whether any real value slipped through (the target is zero). You set which columns are identifiers and which are safe to keep.
Run a small file through the Sandbox. Read the executive summary. Switch one identifier column to "Keep" and watch it warn you — then switch it back. You now have safe data to build on.
Mirror the shape, not the names. Generate on your machine. Reduces risk, not removes it. Build everything else on this sandbox.
Module 3 — Safe vibe coding that earns IT's yes
The idea. Now combine the two: build your improvement inside the sandbox, on practice data, so you can demonstrate a working, data-safe result that IT can approve — instead of working around them.
Why this framing wins. IT blocks unsanctioned tools because they're accountable for any data that leaks. When you show up with a tool that ran only on synthetic data, kept everything on your machine, and produced a checked result, you've removed the exact thing they're afraid of. You become someone they can say yes to.
Working on your own process. Vibe-coding your own SOP or workflow to find improvements is one of the safest, highest-value uses there is — it's your process knowledge. The one rule: don't paste confidential SOPs or documents into a public tool. Describe the steps generically, or work from synthetic examples.
Worked example. You want to automate a weekly summary. You build and test it against sandbox data, confirm the numbers reconcile, then take that — the working tool plus the safety story — to your manager or IT for the green light to run it on the real data.
Sketch how you'd present one automation to your IT team: what it does, what data it touched (synthetic), what stayed on your machine, and how you verified it.
Build in the sandbox, demonstrate a safe win, earn the yes. Never paste confidential material into public tools.
Module 4 — Automating a recurring task
The idea. Take something you do every week and turn it into something you run in one click — a script, a Power Query refresh, or a Power Automate-style flow. The tool doesn't matter as much as the approach.
The approach.
- 1. Write down the steps you do by hand, in order.
- 2. Vibe-code the first step and verify it.
- 3. Add the next step; verify again.
- 4. Once the whole chain works on practice data, run it on the real thing once, watching closely, before trusting it.
Keeping it maintainable. Ask the AI to keep it simple and commented. A clever one-liner you can't read is a liability; a plain, well-labelled version you understand is an asset.
Worked example. A weekly report: read the file → clean the dates → total by category → save a summary. Build it step by step in the sandbox, then run it on the real file under supervision.
Map one recurring task into ordered steps. You don't have to build it all — just produce the step list and vibe-code the first step against practice data.
Steps first, build incrementally, verify each, supervise the first real run. Keep it readable.
Module 5 — The number rule
The idea. This is the principle that separates trustworthy tools from risky ones, and it's the heart of how Parkvara builds: the AI must never compute the figure. A deterministic step does the maths; the AI only helps you ask the question and describe the result.
Why. Because AI predicts words, a number it "calculates" is really a number it guessed — and a guessed figure that looks authoritative is exactly how people get burned. The fix is to keep the AI out of the arithmetic entirely.
What it looks like in practice. When you build a tool, structure it so a real calculation (a formula, a line of code, a query) produces every number, and the AI's job is limited to (a) turning your plain-English question into that calculation, and (b) explaining the result in words. If you ever see the AI itself stating a total it wasn't handed, that's the bug.
Worked example. Plain English: "what was total revenue in the South region?" The AI turns that into a clear instruction; your code or formula computes the exact figure from the rows and can show you which rows it used; then the AI says it back in a sentence. The number came from the data, not the model.
Look at one AI-assisted thing you've built. Identify exactly where each number comes from. If any number is produced by the AI's text rather than a real calculation, that's your next thing to fix.
AI asks and narrates; a deterministic step computes. Never let the model produce the figure. This is the safeguard, and it's our signature.
Where to next
You can now build a safe sandbox, vibe-code a real automation against it, present a win IT can approve, and structure tools so the AI never touches a number. Tier 3 steps up to designing and governing AI-augmented workflows for a whole team — including on-device AI for sensitive data and the governance to back it.
This material reduces risk; it doesn't remove it. Edge, not guarantee.