Helen said something on our walk that I have kept turning over.
Technology anxiety is not always a sign that someone cannot cope. Sometimes it hits the capable people hardest because they know enough to see what can go wrong.
I felt that properly one night in May.
I woke at about midnight needing a wee, made the terrible decision to pick up my phone and saw a security warning about React Server Components and Next.js.
That part of the original story was not paranoia. Next.js applications using React Server Components have had real security advisories, including vulnerabilities with specific affected and patched versions. The exact remedy depends on the application and advisory, so the sensible response is to read the vendor notice, check the versions you actually run and test the supported update.
So there I was, half asleep, checking dependencies and wondering whether this was going to become normal.
AI has shortened the distance from idea to working software
For Helen and me, that is extraordinary.
Helen and I can describe a feature, explore an unfamiliar codebase, trace a failure and produce a first implementation much faster than we could before. Work that once needed a larger team can now at least be attempted by a much smaller one.
But “it runs” is a very low bar.
A working screen does not prove that access is correct. A successful request does not prove that hostile input is handled. A clean demo says nothing about backups, logging, package provenance or recovery.
AI can help with all of those jobs, but it does not take responsibility for them.
Microsoft describes the same boundary in its AI shared-responsibility guidance. The provider protects parts of the platform. The organisation using or building the application still owns responsibilities such as data handling, access, configuration and safe operation.
That is a useful correction to the idea that an AI-generated application somehow arrives finished.
The alert is only the start
Modern applications depend on code maintained by other people. A vulnerability in one dependency can affect many projects, but an alert still needs judgement.
Before changing anything, I want to know:
- Does our deployed version fall inside the affected range?
- Do we use the affected feature or execution path?
- What version contains the vendor's fix?
- Does the update introduce a breaking change?
- Which automated and manual checks must pass before release?
- If the change fails in production, how do we roll it back?
GitHub's Dependabot documentation explains what an alert can provide: the affected file, vulnerability details, severity and a fixed version when one is known.
It does not promise that blindly accepting an automated update is safe.
That last decision still belongs to us.
The dangerous phrase is “just make it work”
If I ask an AI assistant only for speed, it will optimise for the instruction I gave it.
It might produce useful code. It might also choose a dependency I have not reviewed, expose more data than the feature needs or skip the awkward failure cases because I never mentioned them.
That is not proof that AI is reckless. It is proof that the request was incomplete.
My working checklist is less exciting than the feature:
- Define who is allowed to do what.
- Keep secrets out of source code and browser-visible output.
- Pin and review dependencies rather than treating package installation as harmless.
- Test the ordinary path, denied path, malformed input and service failure.
- Log enough to investigate without logging sensitive data.
- Make backup and recovery part of the design.
- Keep a human decision before high-impact actions.
The exact controls vary by system. The principle does not.
Knowing more can make the worry worse
Collab365 is led by my wife Helen and me.
We build the product, support customers, create content, think about marketing, handle sales and try not to rebuild the complicated business we escaped from.
Security sits in that list too. Quietly. Heavily.
The more I understand, the more failure modes I can imagine. Some nights that knowledge is useful. At midnight it can feel like a catalogue of open windows.
Then the worry spreads beyond the code.
I think about Katie's job, Hannah's future and what work might look like in five years. Helen sometimes says she would rather put her head in the sand. Not because she does not care, but because she does.
I understand that completely.
Judgement is not the slow part to automate away
The valuable person in an AI-assisted build may not be the one who produces the most code.
It may be the person willing to stop and ask:
What would have to be true before we should ship this?
That person can use AI aggressively and still distrust a neat answer. They can distinguish a proposed patch from a tested patch, a green test from a secure system and a fast release from a recoverable one.
AI makes building easier. It does not make responsibility lighter.
That is the bit that keeps me awake.
If you are building an AI-assisted product with a tiny team, The 50x Founder Space is where we work through leverage without pretending the fragile parts have disappeared.