First-person reflection

Finding where my ideas were supposed to go

When I first started working with AI WorkBook, I was apprehensive. I had ideas, questions, and instincts about what might be useful. What I did not understand yet was where those ideas were supposed to go.

I'm not someone who knew how to build software. I'd never even tried vibe coding, partly because I was unsure about the safety and trust behind it, but also because I felt that having an idea was only the beginning. What mattered to me was whether an idea could be developed thoughtfully into something genuinely useful, rather than rushed into existence simply because the technology made it possible.

At first, almost everything felt unfamiliar and, honestly, a little intimidating. I'd only ever heard people talk about software development in terms of repositories, workflows, records, validation, and product decisions. There was language around approvals, permissions, assistant behaviour, source records, and governance that felt completely outside my experience.

I found myself looking at concepts that seemed designed for software developers and wondering where someone like me fit into the process, or whether I fit into it at all.

Trust mattered from the beginning

Aside from the technology, part of my hesitation also stemmed from a lack of trust.

One of the things that has always concerned me about AI is that it can generate an almost unlimited number of outputs. It's part of what makes it powerful, but it also raises difficult questions. How do you know why something happened? How do you review decisions after the fact? How do you maintain appropriate oversight when the technology itself is capable of producing so much, so quickly?

Those questions mattered to me because of my background in psychology. I spend a lot of time thinking about evidence, accountability, decision-making, and the potential consequences of getting things wrong.

What surprised me about AI WorkBook was that these questions were not treated as an afterthought. The platform had been designed around records, evidence, permissions, review points, approvals, and documented decisions. Rather than asking users to trust AI blindly, it created structures that made activity visible and reviewable.

That changed how I thought about building with AI.

Ideas had somewhere to live

Instead of expecting me to become a developer overnight, AI WorkBook gave me a framework for understanding how ideas move from concept to product. Even without a technical background, I could engage with the process because there was a clear structure around how decisions were made and tracked.

Ideas that would normally disappear into conversations suddenly had somewhere to live. A passing thought could become a note. A note could become a task. A task could become a record. A record could become a decision. And a decision could eventually become part of a working product.

For the first time, I could see the path between "I have an idea" and "this could become a working product I can trust."

AI WorkBook gave structure to the messy middle in between. The part where ideas are tested, refined, challenged, documented, and slowly turned into something real.

What changed was not that I suddenly learned how to code. It was that it made my judgement matter.

Human decisions mattered

I found myself making decisions about what felt useful and what felt unnecessary. What felt trustworthy and what felt confusing. What language sounded helpful and what language sounded too confident. Where an assistant should support a user and where it should stop and ask for approval.

Those decisions were not technical decisions. They were human decisions.

With my psychology background, I naturally found myself thinking about how people experience systems. What would make someone trust this? What information would they need before taking action? Where could misunderstandings occur? What should be transparent and visible rather than hidden behind automation?

Those questions turned out to be just as important as the technical ones.

One thing that helped enormously was Codex. Rather than acting as a replacement for thinking, it acted more like a guide to the platform. It helped explain unfamiliar concepts, break ideas into smaller decisions, and translate vague requirements into records, workflows, assistants, and review processes that AI WorkBook could work with.

Instead of losing decisions in chat history, they could become records, workflows, tasks, and documented product choices. Progress felt visible. Ideas no longer disappeared once the conversation ended.

Designing for trust

I noticed that I kept coming back to the same kinds of questions: would a real person understand this, trust this, and know when they were still in control?

I saw this most clearly while working on different product concepts.

One example was a task management tool. On the surface, it seemed straightforward: create tasks, organise work, and track progress. But the more we explored it, the more interesting questions emerged. How should priorities be presented? When should an assistant suggest actions? When should it ask for confirmation before making changes? How much control should remain with the user?

Those questions were ultimately about trust and autonomy rather than technology.

Another example was a knitting companion application. What started as a simple project tracker evolved into thinking about guided workflows. How should patterns be introduced? What setup information should be reviewed before a project becomes active? How can source material remain connected to the project while still creating a clear user experience?

Again, the challenge was not simply building functionality. It was designing something that felt understandable and reliable.

The most complex example was a concept around relationship intelligence. This required thinking carefully about the difference between evidence and interpretation. Information about people is inherently sensitive, and it quickly became clear that not every judgement should be automated.

Some things require human review. Some conclusions should remain suggestions rather than decisions. Some information needs to be presented with appropriate uncertainty.

Working through those questions reinforced something important for me: building software responsibly is not only about what a system can do. It is also about deciding what it should do.

The first screen is not the system

Before AI WorkBook, I associated AI-generated software with speed. The promise often seemed to be that anyone could build anything instantly.

What I worried about was whether that speed came at the cost of quality, safety, or understanding.

My experience with AI WorkBook felt different.

Instead of asking me to trust AI blindly, it gave me ways to understand, question, and review what was happening. That meant I could focus less on worrying about governance and more on thinking about the problems I was trying to solve.

The point was not just building quickly. It was building in a way that I could understand, question, review, and trust.

Looking back, one of the biggest things AI WorkBook taught me was that the first screen is not the system.

Software is often judged by what appears on the screen. But the more important work is usually everything behind it: the evidence, review points, permissions, records, decisions, assumptions, safeguards, and human judgement that shape how the system behaves.

I still don't think of myself as a software developer, and I'm not sure I ever will. But I do think of myself as someone who can help build useful software.

AI WorkBook did not remove the need for human judgement. It gave that judgement a place to live.