Part Three: The engine · Chapter 12
AI as leverage, not as a crutch.
Use AI to produce faster, explore unfamiliar work and improve your delivery—but never outsource the understanding for which the client is paying you.
You will use AI. Pretending otherwise is nostalgia.
There are, however, two fundamentally different ways to use it.
The distinction matters more for you than for somebody with ten years of experience because you are still developing the judgement they already possess.
Use AI to produce. Do not use AI to understand on your behalf.
The two ways of using it
One creates leverage. The other creates liability.
Leverage
Generate the first version
Use AI to draft a component, migration, test suite, client email, scope or first version of almost anything.
Then inspect, test, adapt and take responsibility for the result.
False confidence
Accept the output because it looks plausible
Generated code can be fluent, confident and completely wrong in ways that are difficult to see without understanding the system.
Liability
Ship what you cannot explain
If you cannot read the output and explain what it does, you have not built anything. You have acquired a liability.
The liability appears at the worst possible moment.
It appears when the client’s site goes down, payments stop working or customer data reaches the wrong person.
The test that matters
Could you fix it if it broke and the tool was unavailable?
If the answer is no, slow down.
Read the generated work properly. Trace the data. Test the failure cases. Rewrite parts of it if necessary. Continue until you understand enough to diagnose and repair it yourself.
What you must still know cold
Not everything—but everything for which you are accountable.
01
How the data moves
Understand the complete path through the system, from user input to storage and back to the interface.
02
What happens to user input
Know where data enters, how it is validated and what happens before it reaches the database.
03
How authentication works
Understand authentication and authorisation in your stack well enough to explain them aloud.
04
How to read a stack trace
Be able to begin diagnosing an error without immediately pasting it into another tool.
05
Why a database query is slow
Know enough about the database layer to investigate performance rather than guessing.
06
How deployment and rollback work
Understand what happens when you deploy and how to return to a working version when something fails.
These are areas in which generated code can fail quietly. Failure is expensive, and being unable to explain it marks you as someone who assembles rather than builds.
The security part
Generated code can be insecure in ways that are not immediately visible.
Code working in the happy path does not mean that it is safe to deploy.
Input and access
Injection and authorisation
Unsanitised input and missing permission checks may allow users to read, change or execute things they should not.
Configuration
Secrets and dependencies
Credentials may be stored in the wrong place, while generated packages may contain known vulnerabilities or unnecessary dependencies.
Uploads and data
Files that cannot be trusted
A file-upload feature may trust the supplied filename, file type or storage path in ways an attacker will not.
Learn the common categories of web vulnerability. It is a weekend of focused reading and part of the difference between a professional and a liability.
Where AI genuinely wins for you
Use it where speed expands the work you can responsibly accept.
01
Understanding an inherited codebase
Get oriented in an hour instead of a week. That alone can make maintenance work viable at your stage.
02
Working just outside your specialism
A front-end developer can carefully handle a small amount of server configuration if they verify and understand the result.
03
Professional written work
Use it to improve first drafts of scopes, proposals, client emails and documentation, then edit them with the actual context.
04
The unglamorous production tier
Complete necessary boilerplate and repetitive implementation in a fraction of the time. That speed is precisely what can make a £600 project profitable.
What stays yours
The part the client is actually paying for.
- Judgement
- Accountability
- The conversation with the client
- Deciding what not to build
- Recognising when a confident answer is wrong
None of this improves if you outsource the understanding along with the typing.
Those responsibilities are not merely coding skills. They are the reasons somebody trusts you with the work—and the outcome for which they pay.
Part Four: Do it
Next: The 30-day first-payment plan
Chapter 13 turns the complete method into thirty days of practical instructions built around one hour a day and one paid outcome.