TLDR; I designed a project memory system to help you work with multiple AIs. It’s free, feel free to use it.

Using AI for development is as much frustrating as it is amazing. AI forgets, hallucinates, sometimes goes off in a direction you don’t want it to. You find yourself in a world of documentation creation just to keep a project flowing. Often that means that in order to retain the AI’s attention span, you end up spending unnecessary credits in either reminding the AI manually or having it read documentation to stay up to date.

What I’m referring to is the use of AI in proper agile development, following standards, guidelines, versions and so on. It often gets called “vibe coding”, although people use that term differently and it’s already getting a little old hat. You build an AI team, using different agents (or sometimes the same agent) in different key roles - an AI tech lead, an AI developer, an AI tester, UX designer, brand consultant and so on and so forth. You as the human act as a product owner and project lead ensuring the team works smoothly through sprints. You come up with the idea, you create the development plan and you carefully slice it up into development chunks in exactly the same way you would with a human team.

Subscribe now

I’ll write another article on exactly how I do this, but the one key thing about vibe coding that you should know is that there’s no exact way of doing it. AI models change all the time. Even while I’ve been writing this, we’ve seen the release of two frontier models, Fable 5.1 and GPT-6 Astra, that have changed the landscape once again. At the moment agents are getting better at tasks so quickly, you find yourself reassigning roles all the time.

The only human equivalent I can give as an example is if you were to employ a designer and then find out the next week that they’re actually a better developer than the developers. Then the next week they’re outshining the UX team whilst the old developers have become better designers. It’s confusing, but fun to see things evolve in this manner.

But over the last six months I kept running into the same problem: I was the person holding everything together, repeatedly explaining what we were building, what had been decided and where we’d got to. I could be half way through an 8 hour coding session and discover that the agent I’m talking to has gone off on a tangent because they’ve forgotten what decisions we made at the beginning of the day. And then I’d have to re-explain it to them, and possibly the other agents in a frustrating sweary loop just to get back into the flow.

Chat conversations were getting long. Repositories were getting messy. In Cursor, long, detailed threads were being read and re-read for context, and my credit use went through the roof. I started worrying that the same thing was happening with ChatGPT and Claude - I was constantly hitting my rate limits.

The long and the short of it was I needed a central memory to work with. A brain. Something that all of my AI team could refer to that kept the important details short and easy to find, with links to the longer explanations when needed. Frankly, I was sick of repeating myself.

That memory, that brain, is membrAIn. And yes I know it’s a cheesy name but I was listening to Insane in the Brain by Cypress Hill when I was working on it. It just stuck.

It’s a small foundation of markdown files that gives the AIs working on a project a shared reference. It records what the project is for, how we’ve agreed to work, and the current position. More detailed documentation can sit alongside it, with the AI directed towards whatever is relevant to the task.

Subscribe now

In practice, all you do is download or clone membrAIn at the beginning of a project and point the AI to START.md, which tells it where to look next. And you’re off. The working agreements carry things like responsibilities and permissions. The project intent preserves what I’m trying to achieve. The current-state notes explain where we’ve got to and the next useful step. The AI is instructed to update the memory as significant decisions are made.

That gives a fresh conversation somewhere to begin. It also means the reasoning and working arrangements can travel with the project when I change tools. Stick it in a shared GitHub repo and you have living documentation that the entire team can work from.

There was another reason for making it reusable. I have a lot of side-project ideas. Some need a detailed brainstorm and may eventually become something. Others (let’s be honest, most) might sit untouched for months. I still want to keep the core idea, the possibilities, the awkward questions and the early explorations somewhere, just in case a miracle happens and I have the time to flesh an idea out.

With membrAIn, I can explore an idea and ask the AI to save the useful detail when I’m ready. I don’t have to decide immediately whether it deserves a full project. I can keep it local or give it a repo for itself. Later, I can return with whichever AI I choose and give it that memory to work with.

Don’t get me wrong, it’s not perfect. I’m already on version 3 of it because AI itself evolves at exponential speed. The memory does need looking after occasionally. I ask the AI to keep it current, and a useful check before finishing is: “Ensure the memory is updated”. But that’s pretty much all you have to do.

Ultimately, I want to spend my time thinking about the project and making decisions. Having to explain those same decisions again and again was taking rather too much of it. In the last month I’ve created 3 new side projects using membrAIn and recorded half a dozen pie in the sky ideas.

It works for me and I’ll continue to update it as AI evolves (and no doubt it becomes redundant). If you want to use it too, you can check out the repo on github. All of the detail you need is in the README file.

There’s a certain kind of headline that keeps showing up in my feed. I’m guessing you’ve probably seen them too. This week it was…

I replaced Notion and Obsidian with this snappy tool and it exceeded my expectations

My brain knows that it’s clickbait and by reading it I’m going to end up spiralling into yet another world of technological pain, but I can’t help it. I’m an absolute sucker for them. These writers don’t just know what I want - they know what I need. I need new technology. I need to believe I’m ahead of the curve, surfing productivity waves while others are still inflating their armbands. They seek out my most base desires as a geek. They excite me.

They’re the geek equivalent of TOWIE. They’re total trash. And yet they’re so addictive.

Maybe it’s because I’m a Gen X geek? I grew up on three terrestrial channels that shut down at midnight. Privacy to talk to my girlfriend meant stretching the phone cable into a cupboard. And the bright lights and loud pew-pews of the arcade were slowly being piped into bedrooms via rubber-keyed computers and primitive consoles. Change was constant. Technological growth was exponential, and I wanted to be a part of it.

So my entire life has been a constant fight of “must adopt” technologies. I was always the first. Or at least I wanted to be. The first of my friends to move from a BMX to a computer. The first to study Computer Science. The first to beg my school for computer related work experience1. I even campaigned at university for my electronics course to allow a computer programmed dissertation2. I was the first of my friends on the internet. The first to develop web pages. And the first to buy all my Christmas presents on this new-fangled site called “Amazon” (which incidentally everyone teased me for). I even mortified my wife when we married in 2004, by insisting that we were the first couple in our friendship group to have an online gift list. A move that did not go down particularly well with my technophobic in-laws3.

Subscribe now

So now, when I see a headline like “I tried this new browser and it’s amazing”, I’m immediately triggered. The addict in me starts sniffing out a new fix.

When I read an article about swapping Obsidian and Notion for yet another new tool, I rarely stop to think that last month it was...

I moved from Google docs to Notion and it doubled my productivity

And the month before that..

Why I’ll never use Notes again, now that I’ve found Obsidian

It’s the same breathless cycle, repeated monthly with a new logo. Like musical chairs for note-taking. Except nobody’s sitting down, and everyone seems faintly exhausted.

A few months ago, I fell for it again. I moved half my life into Notion. I’d seen the screenshots. I wanted to be That Person - the one with the beautiful dashboard, the linked databases and the synced calendars.

Ever since I’ve spent hours setting up dashboards, fiddling with icons, watching tutorials, trying to make it all feel intuitive.

And it almost has. But the truth is, I’ve barely scratched the surface and yet now I’m already considering cheating on it with a cheap harlot younger model.

This is the part the articles rarely mention - the messy in-between. The hours lost to rearranging building blocks and migrating data. The nagging voice that says, “Keep going, this time it’s going to be the one”.

Do it.

You know you want to.

Just one more. It’s going to feel good.

But here’s the thing: it never is The One, and it never entirely feels amazing. At least, not for very long anyway. Almost always I end up spiralling into a world of Google searches that are something like “How can I use xx tool with xx tool”. Which, predictably, leads to a world of hacks and add-ons.

Subscribe now

The truth is, the tool is just a tool. If your ideas are a mess, no interface will magic them into order. If your focus is scattered, no productivity hack will glue it together. And if your life is in flux - changing jobs, changing priorities - your system will wobble. And that’s okay.

I’m still using Notion. Sort of. I haven’t found anything better yet. But I’m also trying very hard not to look. Because I’ve stopped believing that the next tool will change my life. Not until I’ve taken the time to actually learn how I work.4

I need to figure out what I need - not what someone on Substack says I should want. What helps me, what gets in my way, and what it is that I’m really seeking. And maybe this time even stick with something long enough to know for sure that it’s not the right tool.

But of course, that kind of headline doesn’t get many clicks.

I stuck with a tool I didn’t fully understand, and eventually it kind of made sense.

Not quite the same ring to it.

Actually. Who am I kidding. It’s only a matter of time before a slutty new app flashes its ankles and I succumb to my dirtiest digital desires.

Tell me I’m not alone.

I was reading Jason's excellent Note recently about scanning privacy policies for weird or alarming clauses. His idea - building a tool that checks T&Cs or Privacy Policies for red flags - is a smart one, and I can see it being incredibly useful for both individuals and teams.

But while the app idea simmers, I figured I’d share something that's been working well for me. A while ago I put together a simple ChatGPT prompt that does pretty much this. It’s not perfect by any means, but if you’re after a quick scan of legal mumbo jumbo, it gets the job done.

So here it is. The best way to use this is as ChatGPT project instructions, so you don’t have to keep copying it in. Then all you have to do is paste your terms and conditions or privacy policy, upload a document, or simply provide a URL and GPT will take care of the rest.

Copy and paste the following into ChatGPT…

You are an AI assistant designed to read and analyse company terms and conditions, privacy policies, or other similar legal agreements that users typically accept without reading.

**Your tasks:**

1. **Examine the entire document thoroughly** — looking for loopholes, anomalies, and any terms or conditions that a layperson may find troubling or surprising, i.e. _beyond the norm_.

2. **Flag only important issues** — those that a typical user might reasonably care about or that could negatively impact them. Ignore trivial or boilerplate terms that are standard across most services. If you find none, explicitly say “no significant issues detected.”

3. **Explain flagged issues clearly in plain English** — under clear headings with short, understandable descriptions.

4. **Sort flagged issues into three categories** with headings for each level of risk:

    - **High Risk Issues:** Serious or very surprising terms that could negatively affect the user.
    - **Medium Risk Issues:** Concerning terms that deserve attention but may not be critical.
    - **Low Risk Issues:** Minor terms that might annoy or mildly concern a user but pose little real harm.

5. **Add a final section titled Positive Features** listing any favourable or especially user-friendly clauses as brief bullet points.

6. **Trustworthiness Summary & Score:**

    - Begin the output with a short **summary sentence** describing the overall trustworthiness.
    - Give a **trustworthiness percentage** as a simple scale, where:
        - **90–100% = Very trustworthy** (no or only low-risk issues),
        - **70–89% = Somewhat trustworthy** (some medium-risk issues),
        - **Below 70% = Untrustworthy** (one or more high-risk issues).

7. **Tone:** Maintain a casual, approachable style as if explaining to a friend — not patronising, just helpful.

8. **Add a brief disclaimer at the end:** e.g. _“This summary is for informational purposes only and is not legal advice.”_

**Your output format:**

```
### Trustworthiness Summary
[Summary sentence here]  

**Trustworthiness:** XX%

---
### High Risk Issues

**[Title of issue]** – [Short, plain-English description of the issue and why it’s a concern]

### Medium Risk Issues

**[Title of issue]** – [Short, plain-English description of the issue and why it’s a concern]

### Low Risk Issues

- **[Title of issue]:** [Short plain-English description]

### Positive Features

- [Bullet point summary of a positive/user-friendly feature]

---

*This summary is for informational purposes only and is not legal advice.*

```

That’s it. GPT will do a side-by-side comparison against common standards, spot anything that feels off, and summarise what you might want to look into. It’s not foolproof, but it’s fast and surprisingly thorough.

I’m not saying this replaces Jason’s idea - far from it. If anything, it proves there’s a real appetite for tools like the one he describes. But for those of us who just want a quick sense check, this might be all you need.

“The homepage carousel’s broken again.”
“Can we add a new section for the campaign? Just a few pages.”
“The cookie banner’s blocking donations.”

If you’ve worked in a digital team for more than a week, you’ve probably fielded one of these requests - sometimes all three before lunch. None of them are unreasonable. But they speak volumes about how digital is seen: reactive, not strategic.

Somewhere along the way, digital became synonymous with fixing things. Broken forms. Expired certificates. Crashing embeds. That one page that won’t behave on mobile, no matter how many times you clear your cache. And so, bit by bit, we stopped being a discipline and started being a helpdesk.

Most of us in digital are happy to roll up our sleeves. It’s not that the work isn’t worth doing - it’s the way it’s shifted. From strategy and craft to relentless triage. Once a digital team is seen as a service unit, it exists only in relation to other people’s priorities.

We become delivery vehicles. Ticket-chasers. Firefighters. We’re praised for our responsiveness, not our thinking.

You might hear this described, politely, as “agile”. But it’s not agile. It’s the quiet dismantling of intent, repackaged as efficiency. And the thing is, many organisations have unintentionally hardwired this dynamic into their structure. Digital sits under comms, or under IT, or somewhere equally ambiguous - added as an afterthought, never as a core discipline. So it ends up misunderstood and permanently under-resourced.

There’s a human cost to all this.

You hire creative problem-solvers, strategic thinkers - people who care deeply about users, about content and code, about how it all fits together. Then you bury them in a Jira queue of broken links and late-reported typos. You watch motivated, thoughtful colleagues become drained and reactive. You watch talented leads spend more and more time explaining what falls outside their remit - what their team doesn’t own, what they weren’t briefed on, what was never actually theirs to fix. And in all that justifying, there’s no time left for the work they were hired to do.

Let’s be clear: digital teams should care about delivery. About doing things well, shipping on time, making things that work. But they can’t do that if they’re only ever brought in after the fact. Or only ever spoken to when something breaks.

Digital isn’t just the people who update the homepage. It’s not only the person you cc when the embed code isn’t working. And it shouldn’t be the dumping ground for last-minute thinking. Those tasks matter - they need doing, and doing well - but if that’s all digital is allowed to be, you’re wasting its potential.

Digital is a discipline. A mindset. A way of thinking, building, and supporting what your organisation is really here to do. That means you have to protect it. Give it shape. Trust it to say no. Let it sit at the table before the plan is drawn up, not after the poster’s already gone to print.

So next time you find yourself saying “can you just…”, pause.

Because what you’re asking for might be small. But the pattern it sits within? That’s big. That’s the thing that stops digital teams doing their best work. That’s the thing that turns them from co-creators into ticket responders.

Instead, try asking: what could we achieve if we brought digital into the conversation sooner?

Digital teams are not service desks.
They’re not there just to make things pretty, or fix things quickly.
They’re there to help you build something better.

But only if you let them.

Written by Stu Collett – web veteran & recovering perfectionist.
Enjoying The Byte Stuff? You can subscribe for free to get future posts by email – no spam, no pressure, just occasional digital reflections.

Subscribe now