How to experiment and scale AI safely | Trust in the time of AI

Portable moved from ChatGPT to Claude. That decision is already old news. By the time you read this, there has been another model release, another set of features, another round of "the thing you were using yesterday is no longer the best thing." The more interesting question is what's worth carrying with you when the tools change.

To answer it, we talked to three Portable practitioners who work with AI across very different contexts. Ian Hogers is a senior developer who builds at the technical frontier of what Claude can do. Ruth Taylor is a Technology Lead who both uses AI in her own work and oversees a team that does. Elly Beard is Portable's CFO, who came from a non-technical background and rebuilt her operational workflows around AI anyway. Their answers, taken together, say more about what actually matters than any individual tool could.

Before anyone can use AI well, they have to understand what it is.

Ian's version is blunt: "At the end of the day, it's still a super fancy autocomplete." Ruth's is more precise: "It's always predicting the next most likely word." Both of them are grounding themselves in something real, something that shapes every decision they make about how to prompt, what to delegate, and when to step back in.

The practitioners who struggle most with AI tend to treat it like a colleague who can read between the lines. They assume it understands context it hasn't been given, that it will flag its own uncertainty, that a confident-sounding output is a correct one. The practitioners who get the most out of AI operate from the opposite assumption. They know exactly what they're working with.

Understanding that AI is fundamentally a pattern-matching system predicting probable next outputs is the first principle that survives every tool change. It tells you why clarity matters, why examples work, why a poorly scoped prompt produces a confident, plausible, wrong answer, and why the quality of your input is the ceiling on your output.

Every practitioner we spoke to, regardless of how differently they use AI, named some version of the same habit: slow down before you start.

Ian's workflow starts before he changes anything: "The first thing I do is open Claude and ask it to analyse how that section works at the moment. Then while it's doing that, I'm reading my ticket and going through what needs to happen." The analyse-first step matters, but Ian attributes it to the knowledge sharing that happens across the team. This one in particular is a credit to Rohan Richards, a senior developer at Portable, and his willingness to share and explore these approaches openly, so they spread rather than staying locked in one person's head.

Ruth traces this back to the internal workshop sessions that helped her team navigate the shift from GitHub Copilot (essentially inline code suggestions) to agentic coding (a full back-and-forth with an AI that writes code for you). The core lesson Rohan brought to those sessions: "If you don't understand the problem, you're never going to be able to tell an AI to do it properly. You're going to end up going around and around in circles with code that gets worse. It tends to spiral." Once you're in that loop, the only real fix is to close the window and start again.

Elly's version comes from a different vantage point but lands in the same place. For her, using AI thoughtfully means running through a checklist before starting: what outcome do you want? What's going in, and what shouldn't (personal data, confidential information, anything that needs de-identifying)? What will this cost in tokens? Is AI even the right tool? "You really should not be doing anything with AI until you've considered all of those pillars."

Ian has moved across ChatGPT, Gemini, and Claude multiple times, and switching, by his own account, is not particularly hard: "Any documentation you have on how you use AI, it's all written in text. If you've got a specific project you've been working on with another model, and you've got all these notes about how you want your AI to operate, you just say: rewrite it in words that make sense for you, keep it concise. And it'll basically transfer the context for how it needs to operate without any extra effort."

Having that documentation in the first place is the prerequisite.

Ruth describes the fundamentals that apply regardless of tool: "It's always around clarity, being specific and direct, providing good context and scene setting, and giving examples. If you want it to produce something in a certain way, you need to show it what that looks like first. How does it know otherwise?"

Elly's version is more structural. Her AI setup lives in a project folder on her hard drive, a set of markdown files she spent a week building with Claude, covering her working instructions, context about the business, notes on how she works with different people, and her operating principles as a CFO. The investment of that week has compounded across everything she does since. When she moves to a new context, it moves with her.

Written-down frameworks are what carry this kind of knowledge across tool changes, and the institutional knowledge about how to work with AI effectively is at risk of living only in the heads of the people who've figured it out. Ian commits his memory files and configuration to GitHub, so when he moves to a new machine he pulls his existing setup and picks up where he left off: "You don't have to build that up again."

One of the clearest patterns across all three interviews: the AI implementations that held up were team decisions, not individual ones.

Ian calls this "team-based adoption" and lists it as one of his core principles: "Any work you're doing, if you're doing risk assessment or documentation, these decisions need to be made as a team. Otherwise you'll put standards in a document for some code quality and other people go, 'Why would we even need this?'"

In practice, on a recent project, that meant Ian and his colleague Tam sitting down before using AI on the project and talking through where it could help and where it might hinder. The client's initial blanket “no” on AI wasn't an obstacle; it was useful information, prompting a conversation about what the tool was and how the team planned to use it.

Ruth's team's approach was more structured. When Portable's development team made the shift to agentic coding, Rohan Richards led a series of internal workshop sessions that took the whole team through the capabilities, the limitations, and the things to watch out for. "Without those sessions, the uptake would have been harder and slower. We use AI because it's supposed to create efficiencies. But if people don't know what it can't do, they spend more time than they save."

Without shared understanding of a tool's limitations, each team member discovers those limitations independently, spending effort on the same mistakes and developing different expectations about what the tool can do.

Perhaps the most unexpected thing any practitioner flagged was the human cost of AI without constraints.

Ruth describes watching a developer run multiple agentic coding sessions simultaneously, across four or five windows at once. "There becomes a point where the mental load of managing multiple AI agents at the same time becomes impossible, or mentally exhausting, or it starts to create a burnout-type scenario in the person managing those agents. We end up with a human problem, because this person can't do their job anymore." Her observation cuts further: "I think this is the first time that any tool we use to do our job has the potential to cause harm in a human."

The advice she gave was counterintuitive: slow down to speed up. One task at a time. The efficiencies you think you're gaining by running four sessions aren't real if the person managing them starts to fail.

Elly's version of the same failure mode looked different but had the same structure. She spent three days deep in an AI loop trying to reconstruct a grant methodology, going back and forth, getting increasingly specific, unable to step back and see that she had become the only person who could solve the problem. "I got really siloed in doing that. And it took Andrew coming in and saying, 'Step away from the AI for a second, talk me through it.'"

In both cases, AI amplified speed, and speed without oversight creates conditions where the human starts to fail. Human oversight is what keeps the whole system working.

Ian's final principle speaks to the longer game.

After a particularly difficult piece of work, his habit is to run a mini retro with Claude: ask questions on the struggle points, get it to produce a document with a clear title, commit it to the repository or store it somewhere retrievable. "That ritual has been very useful, because if something related comes up again, Claude reads that document first. You can get it to automatically gather learning from past problems." He has been developing this approach for Portable's internal Librarian project, a system designed to hold and surface the company's institutional knowledge.

The infrastructure question most AI users don't reach is this: how do you build a working relationship with AI that accumulates over time, rather than resetting with every session? For most people the learning evaporates the moment they close the tab. The struggle you just worked through is gone, and you'll pay for it again next time. Ian's answer is literal: commit it to Git, but also build skill documents that evolve as you use them, so new learnings fold back in rather than getting lost. The principle applies more broadly, because the value is in the pattern of working, not just the output it produces.

Elly is building toward the same thing from a different direction. Her operating system in Claude has become, over time, something close to a recreation of her former business mentor: it prompts her with the kinds of questions she'd expect from someone who knows the business and her role inside it. "Sometimes it comes back with something and I think, 'Keren would have asked me that.'" She knows the test for whether it's working: can someone else pick this up without her explaining it? "If I have to explain it, I may as well have done it myself."Ian's final principle speaks to the longer game.

After a particularly difficult piece of work, his habit is to run a mini retro with Claude: ask questions on the struggle points, get it to produce a document with a clear title, commit it to the repository or store it somewhere retrievable. "That ritual has been very useful, because if something related comes up again, Claude reads that document first. You can get it to automatically gather learning from past problems." He has been developing this approach for Portable's internal Librarian project, a system designed to hold and surface the company's institutional knowledge.

The infrastructure question most AI users don't reach is this: how do you build a working relationship with AI that accumulates over time, rather than resetting with every session? For most people the learning evaporates the moment they close the tab. The struggle you just worked through is gone, and you'll pay for it again next time. Ian's answer is literal: commit it to Git, but also build skill documents that evolve as you use them, so new learnings fold back in rather than getting lost. The principle applies more broadly, because the value is in the pattern of working, not just the output it produces.

Elly is building toward the same thing from a different direction. Her operating system in Claude has become, over time, something close to a recreation of her former business mentor: it prompts her with the kinds of questions she'd expect from someone who knows the business and her role inside it. "Sometimes it comes back with something and I think, 'Karen would have asked me that.'" She knows the test for whether it's working: can someone else pick this up without her explaining it? "If I have to explain it, I may as well have done it myself."

AI can hold and retrieve an enormous amount of information, but the knowledge, the genuine understanding of what it means and why it matters, still sits with people.

Elly put it plainly: there's a real risk that as AI gets better at retrieving and synthesising information, organisations stop building the genuine understanding that makes that information useful. "Where are we if we hoard that knowledge in a database and no one truly thinks about it anymore and just goes, 'I'll just ask the bot what our policy is on this'?" Mass information, with loss of knowledge.

The tools will keep changing, and the next version is already in development. What Ian, Ruth, and Elly each described, across very different contexts, is a practice that doesn't depend on which tool you're using: know what AI actually is, do the thinking before you reach for it, document how you work (not just what you produce), make adoption a team decision, keep humans in the loop because the system breaks without them, and build the infrastructure to carry knowledge forward.

None of this is a quick fix, but it's the kind of thinking that compounds and holds up regardless of which model you're using next week.