Development & AI

Development is where the rubber hits the road. Where I actually start to build your product, based on your business requirements and user experience designs.

Off-the-shelf or bespoke?

I can do both. The choice is entirely determined by your needs.

Off-the-shelf — Buying and integrating an existing technology into your tech stack is usually the fastest, cheapest option. Think Airtable, SmartSuite, Notion, HubSpot, Asana, Zendesk, WordPress, Shopify, Zapier, and so on. It probably won't give you everything you want, but it'll be close, and I can always build some add-ons that bring it even closer.
Bespoke — If the off-the-shelf compromises are simply too expensive, building something from scratch is the only way forward.

In practice, this decision is made long before we actually get to development. I'll usually recommend one or the other as part of my quote.

Both are now faster, and more affordable

Thanks to AI, you no longer need humans to write code.

This has obvious benefits for bespoke products, because they’re entirely code. You don’t need a whole team of programmers anymore, or a project manager to herd them.

For off-the-shelf products, the benefits are subtler, but still real. The product itself may not need to be built from scratch, but it still needs to be integrated with the rest of your infrastructure, and it may need to be enhanced, to better meet your needs. Code is usually the best way to do both, and now you don’t need a programmer to write it.

Either way, your labour cost is reduced. And because AI is a lot faster, your timeline shrinks too. (A script that would take even the most experienced programmer days takes Claude a matter of seconds!)

All you need is a human to do the important thinking

With AI doing the grunt work, all you need is someone to tell it exactly what to do. And make sure it does it.

In practice, this means capturing business and user needs, diagramming business and software logic, designing the UX, writing user stories, prioritising tasks, identifying & solving problems, correcting misunderstandings, planning adaptations, communicating with you, and testing the end product.

That's obviously still a specialist skill, but — thanks to yours truly — it's not the work of a whole team.

I've been directing human developers for 15+ years

From freelance developers to teams of five to ten, I've been directing human developers since 2010.

Directing developers 2010 – present

Present

Digital Product ConsultantGlennMurray.com.au
2023 – 2026

Director of Business SystemsMatthews Cleaning Co
2017 – 2023

Customer Experience DirectorEaseware Technology
2020 – 2021

FounderMyCornerShop.com.au
2016 – 2017

User Experience ManagerAppliances Online
2012 – 2016

FounderBlurb Maker
2010 – 2020

UX Design, Customer ExperienceSilver Pistol

Now I direct AI developers instead

When AI arrived, the development world changed. My day-to-day evolved from directing human developers to directing AI developers.

Weirdly, though, that hasn't been the revolution it might sound. In fact, once the novelty wore off, I discovered that directing AI developers is mostly the same as directing human developers: I still have to decide how the product will work, communicate that requirement, and make sure it gets done right.

Obviously AI codes way faster, but that's something you start to take for granted within days. After that, it's actually the sameness that strikes you.

But AI needs more governance

All developers — whether human or AI — need governance to stop them doing damage and ensure they do a good job. But AI developers need more of it.

Human developers learn in countless ways. They soak up knowledge — often without even thinking. AI developers don't. They can't chat over lunch, read between the lines or read the room. They don't share your culture, joys, frustrations or past experiences. And they can't fall back on common sense and intuition, when all else fails.

An AI's understanding of your needs and its authority is determined entirely by what you know, what you're able to articulate and what you remember to tell it.

And even if every one of your prompts is perfect, there's a good chance it'll just ignore you. Remember, AIs make their own decisions, and ignoring you is a decision they're always free to make.

What you need is a framework that enforces your critical guardrails and embeds your expectations in the context of every task:

Give your AI very narrowly defined jobs, so there are very few decisions to make.
For each decision you can predict, provide exhaustive, precise instructions that tell the AI exactly what to do when a decision needs to be made.
For unforeseeable decisions, explain as precisely as possible how a human would approach those decisions.
Strategically limit the damage your AI can do (its 'blast radius') when it eventually does make the wrong decision (because it definitely will).
Ensure the damage isn't done silently. You need to know as soon as your AI messes up, so you can immediately undo the damage.
Ensure there's a way to quickly and easily undo the damage.
Institute a process that ensures the error, damage and fix can be immediately and easily documented, and used to refine your future instructions and containment barriers.
Ensure that this process is followed.

So I built an AI governance framework

Over the past two years, I've created a proven AI governance framework. It shifts the burden of governance from your manually-typed prompts to a codified collection of instructions, workflows and automations that can be applied within any tech stack or business environment.

The framework contains five types of governance, each described in detail below. Expand each section to see what's involved:

01Instruction ·Telling the AI what to do

Governance measure	What it does	How it works
INS-1The standing brief	Before any AI designs a change, I set it working from a fixed project brief — how to approach the work, what to check, how to write it up.	A standing instruction set loaded into every planning session: response rules, file-sourcing discipline, regression rules, house patterns, and documentation and work-tracking conventions.
INS-2Read before you change	I give the AI that writes code an operating manual telling it, for each part of a system, which reference document to read before touching that part — so it reads before it changes.	A working brief built from “read this document before you touch that area” mappings — in a system I've built, one area alone points to around 25 files and the behaviours they encode.
INS-3Build from the same blocks	I have new screens built from a shared set of building blocks and copied from an existing example, so a product stays consistent instead of each piece being reinvented.	New pages and components modelled on named reference files plus a conventions file that must be read before any interface change.
INS-4Never work from memory	I stop the AI relying on its memory of a file — it pulls the current, real file first. It holds because the correct way is also the easy way.	A hard rule that the AI requests the real current file before using it; cheap to follow because it hands back a single command that gathers every file it needs at once.
INS-5Resolve the unknowns first	Before build instructions are written, the AI has to list what it's unsure about. If any of it could change the build, it stops and checks first — instead of confidently building the wrong thing.	Before any implementation instruction, unresolved uncertainties are enumerated; if any could affect the build, a plan-review step is written instead.
INS-6Trace what depends on it	Before anything changes, I have the AI trace everything that relies on the thing being changed — so it doesn't fix one thing and quietly break three others.	Every consumer of what's changing is mapped, the dependent code paths traced, the area's reference doc re-read, and whatever couldn't be verified is stated plainly.
INS-7The quality bar, every time	Every set of instructions opens with the same reminder of the standard — “gold standard, not gold-plated” — so quality doesn't drift across hundreds of small jobs.	A fixed quality-bar line heads every instruction file.
INS-8Define “done” before starting	I have work written up in a fixed format before it starts — what, why, and how we'll know it's finished — so nothing is vague or open-ended.	Work is drafted as issues in a fixed shape (what / why / acceptance criteria / dependencies / labels) from a controlled label set, defining “done” testably before work begins.
INS-9Safe rules for database changes	I set written rules for changing a database safely — for example, always identify a record by its name, never by an internal ID that differs between the practice and live copies.	Target rows by stable natural keys, not hard-coded IDs; apply database changes only through the command-line path; never write through the database connector.
INS-10Stay in scope, invent nothing	Any AI feature that writes customer-facing documents, I instruct to stay in scope and never invent client names, places, or numbers.	The generation prompts forbid out-of-scope claims and invented names, locations, references or figures. (This is instruction to the model — what actually contains bad output is the validation and approval gate below.)

02Constraint ·Making it impossible for the AI to do harm

Governance measure	What it does	How it works
CON-1Small blast radius by design	I isolate each AI feature so it can only touch its own small corner of a system, and can't contact a customer directly. If one goes wrong, the damage is boxed in.	Each feature writes only to its own tables; none has a customer channel — no email, SMS or webhook.
CON-2Practice copy by default	I set everything to point at a practice copy by default, not the real one — so forgetting to say “use the practice copy” is harmless.	A wrapper refuses to apply a change unless the machine is verifiably linked to the practice copy (fails closed otherwise); the AI's database connector is pinned to the practice copy by a settings file.
CON-3The live-system password gate	I put a password only I know in front of every route to the live system, typed by hand each time. The AI can't get past it, because it can't produce the password.	Every scripted route to live is fronted by the same gate: a hidden password checked against a stored one-way fingerprint, aborting on anything wrong. No override.
CON-4Staged, not live	I set website changes to build and stage while the live site keeps serving the old version — going live is a separate, deliberate, password-protected step.	Live-domain auto-assignment switched off at the server, so a push only stages; going live is a separate gated action.
CON-5The tool refuses on its own	I can make the most sensitive tool refuse to touch the live system unless it's handed a go-ahead that's only supplied after the password check passes.	The tool refuses a live write unless a transient confirmation flag is set; the gated wrapper sets it only after a passing password, hands it over, and clears it on exit — never written to disk.
CON-6The honest edge	The hardest case isn't an accident — it's an AI that reads the code and tries to use a system's own keys directly. Measures like these stop accidents and a co-operative AI; fully closing off a determined, self-directed one is the harder frontier, and I'm upfront about where that line currently sits.	The strongest control is credential isolation — the agent holds no key that works on the live system. It's a direction I design toward; gates like the above are strong against accidents and a cooperative agent, weaker against a code-reading autonomous one.
CON-7Reject malformed output	I check whatever an AI produces against a strict template before it's used, and throw out anything malformed — so a bad or made-up answer never lands.	Each feature validates the model's output against a strict schema (types, allowed values, exact counts) and rejects anything non-conforming before use. Where a feature writes live data, this — not “it only drafts” — is the real containment.
CON-8Data, never web code	I have the AI return plain data, never web code — so it can't slip anything harmful into a page.	Models return structured data only; a template renders the markup, closing off markup or script injection.
CON-9Cap parallel calls	I cap how many AI calls a single job can run at once, so cost and load can't spike.	A hard limit on parallel model calls within one job (e.g. five).
CON-10One run at a time	I stop the same job being started twice at once and having the two runs collide.	A database uniqueness rule allows only one running job of a kind at a time; a second is refused.
CON-11Staff-only editing	The AI features that edit documents, I gate to signed-in staff in the right role only.	Editing requires a validated staff token plus the correct group membership.
CON-12Belongs-to-you check	I have each AI feature check that whoever's asking actually belongs to the account they're asking about — so no one reaches across into someone else's data.	Each feature checks the caller against the record's owning account before acting.
CON-13Locked means locked	Once a document is locked or signed, I block the AI from editing it.	AI edits are blocked once a document is locked or a contract signed.
CON-14Shrink and cap what's sent	I shrink and limit the images sent to an AI, keeping cost and load in check.	Images resized and capped in number before sending (e.g. no more than 15 per area).
CON-15Stop fast on a bad key	If an AI's access key is wrong, I have the job stop immediately instead of failing over and over and running up a bill.	An invalid-key error aborts the whole job at once rather than retrying every item.
CON-16Retry a little, then stop	If a call fails for a temporary reason, it retries a few times then gives up — it never loops forever.	The shared caller retries only specific transient errors, a few times with backoff, and never retries a genuine error in the request.
CON-17Same inputs, same answer	Where consistency matters, like pricing, I set the AI to give the same answer for the same inputs every time — no random drift.	Deterministic sampling (temperature zero) on the pricing feature.
CON-18Login rules live in config	I keep login rules in a configuration file rather than in memory or a typed command — so they can't be got wrong by accident.	Each function's login requirement is declared in its settings entry and the deploy doesn't override it; every function declares a posture explicitly rather than relying on a default.
CON-19One doorway for all AI calls	I route every AI call through one doorway, giving a single place to watch, limit and log everything.	All model traffic routes through one shared file — the point the other controls hang off.
CON-20Nothing goes out unsigned-off	Anything an AI writes into a customer document, I mark “not approved” until a person approves it — and the AI can't approve its own work.	Any AI edit resets the section to not-approved; only a staff-gated human action approves, and the unapproved state blocks the document from being sent.

03Verification ·Inspecting the AI's work and surfacing problems

Governance measure	What it does	How it works
VER-1Two AIs, and me in the middle	The AI that plans a change is not the AI that carries it out, and I sit between them — passing each instruction in and each result back, approving every step. A bad plan surfaces as a wrong report, not silent damage.	Separation of roles (planner ≠ executor, reporting back per step) plus a human approval gate at every step — the most effective catch for novel mistakes.
VER-2Automatic tests on every change	I set automatic tests to run on every change, and block anything that would ship a known-serious security hole in an outside component.	The test workflow runs on every non-docs change, fails the build on a critical dependency vulnerability, then runs the suites; integration tests run on merges and nightly. (In a system I've built, roughly 290 unit and integration tests.)
VER-3The nightly health check	I run an automatic nightly review of the whole codebase against a set of quality and safety rules — writing a dated report and raising a ticket on anything wrong.	A nightly engine across a dozen categories — file size, forbidden patterns, build and type-check, database hygiene, duplicate constants, bundle-size growth, doc conventions, docs-index validation, live-system sync, language purity, shared-helper use, and login-posture declaration — filing a labelled issue on any violation.
VER-4The weekly architecture review	I run a weekly AI review of the bigger picture — is a system drifting from its intended shape, is debt building up — flagging what needs fixing.	A weekly review reads the week's nightly reports, the structure, the largest files and the brief, and flags architecture drift, tech debt and rules needing updating.
VER-5The weekly documentation check	I run a weekly check of whether the documentation still matches the code, flagging anything that's fallen out of step.	A weekly job detects reference docs that have drifted from recent code changes and files a documentation issue.
VER-6Show exactly what changed	When the AI rewrites a file, I have it list exactly what changed and confirm nothing else moved — so nothing sneaks in unnoticed.	On any rewrite, the prior version is diffed, the changes enumerated, and “nothing else moved” confirmed.
VER-7Confirm live matches the code	I run checks that confirm a live system is actually running the version it's meant to be, and hasn't quietly fallen behind the code.	The live deploy verifies every change is recorded as applied, stamps a version fingerprint, and the nightly engine re-checks the match.
VER-8Full before-and-after log	I log every AI edit to a document with who did it and the exact before-and-after — so any change can be seen and undone.	Each AI edit writes an audit row with action, actor, and the content before and after.
VER-9Every job on the record	I have every job record who ran it, when, and what it produced, with each result stamped with how it was made.	Each run records actor, time, mode, model, prompt version, outcome and counts; each written row is stamped with its provenance and flagged as AI-created.

04Memory ·The context the AI needs to operate

Governance measure	What it does	How it works
MEM-1The running log of why	I have the AI keep a running log of every change and, crucially, why it was made — so the next session knows what happened and that the current setup is deliberate, not accidental.	A running record updated after every change, capturing the why, not just the what — the AI's working memory across sessions.
MEM-2Fresh start on a cycle	I archive that log and start it fresh on a regular cycle, so it never grows into an unusable mess.	The record rolls over on a set cycle, archiving the prior period; the rollover is a tested, self-contained transform.
MEM-3The reference library	I build the organised reference library that the “read before you change” rule actually reads from.	A tagged corpus under a controlled taxonomy, published as a documentation site. (In one build, ~45 technical reference docs, 30 staff guides and 13 living plans; 30 area tags and 11 system tags.)
MEM-4Docs written on my say-so	Documentation gets written with AI help, but only when I decide — the AI never quietly rewrites the reference docs on its own.	The AI proposes documentation at completion points but never writes or changes reference docs unprompted; a human decides when. Writing is human-plus-AI; checking is automated.
MEM-5A durable record of every action	I have the AI features keep a durable record of what they did — the stamps and logs attached to every piece of work they produce.	Provenance columns and job rows, AI-created-row flags, and before/after audit rows — the durable record of each feature's actions.

05Recovery ·Undoing mistakes and learning from them

Governance measure	What it does	How it works
REC-1Roll back to a known-good state	I keep things so any code mistake can be undone by rolling back to the last good version, because a system's whole shape can be rebuilt from its change history.	The code is in version control and database changes are the single source of truth for its shape, so reverting and re-applying restores a known-good state.
REC-2Mistakes become improvements	When something goes wrong, I have it written down and the instructions tightened so the same mistake can't happen again.	Errors are captured in the log's why-entries and the weekly review's rule-update flags, then fed back into the briefings and rules — the loop that closes back to Instruction.
REC-3Undo a bad live-data run	Where an AI writes live data, I build in reversal: a failed or cancelled job restores exactly what was there before, and a re-run only removes the AI's own earlier entries — never a person's work. The one case it can't auto-undo — a run that finished, looks plausible, but is wrong — is caught by a person reviewing before it reaches a customer.	State snapshotted before writing and restored on cancel or failure; AI-created rows tagged so a re-run deletes only them. Automatic reversal covers failed / cancelled / re-run; the “succeeded but wrong” case is caught by human review, not automation.

It can be applied to your business too

The best part about my framework? It's portable. It can be applied to any business and any tech stack.

I just choose the bits that are relevant to your business, set them up, and get to work.

Obviously I need to tailor it to the workflows you need automated, the decisions your AI needs to make and the consequences of incorrect decisions. But the core of the framework comes for free. The proven principles, the hard-won processes, the ready-made checks and the mechanical control are the lion's share of the work, and they're all portable.

Need help with a digital product?

If you want someone with all the skills necessary to help everywhere you need it, please contact me.

Get in touch