Once I had decided that the website should have user accounts, I had to answer a fairly important question. Where should authentication live? The obvious answer, if I was thinking about the individual applications, would have been to put it in each application. After all, an application needs to know whether someone is logged in. But that immediately brought me back to the problem that had started the whole framework project in the first place. Duplication. If Publications had its own authentication system, and Marketplace had another, and another application had another, I would once again have several versions of essentially the same functionality. That wasn't what I wanted. If a user account belonged to the website rather than to an individual application, then authentication needed to belong to the platform as well. That was an important distinction. The applications shouldn't each have to work out how to authenticate a user. They should simply be able to ...

When I started building the Auspice Darer Framework, I wasn't trying to create a framework. I was trying to solve problems as they appeared. The original problem was duplication. I had a number of PHP applications, and each one had developed its own header, footer, navigation and supporting code. Making a change to one application was easy enough. Making the same change consistently across all of them was where the time went. So the first stage was fairly straightforward. I began bringing the applications together under a common structure, sharing things that didn't need to be independently maintained. That was already making life easier. Then, at some point, I had another idea. Why not have user accounts? It sounds like a fairly ordinary feature. Most websites have them. But in the context of what I was building, it changed the nature of the project. Until then, the applications could largely be thought of as separate programs that happened to live on the sam...

One of the biggest lessons I learned while working with AI wasn't about prompting. It wasn't about context windows. It wasn't about choosing the right model. It was about recognising when neither the AI nor I were solving the right problem. Software development has a habit of encouraging incremental fixes. A bug appears. You fix it. Another edge case appears. You patch that too. Eventually the code works—but it becomes increasingly difficult to understand why. AI can unintentionally reinforce this pattern. If you ask it to solve today's problem, it will usually do exactly that. If another problem appears tomorrow, it will solve that one too. Before long you've accumulated a series of perfectly reasonable fixes that, taken together, have become an increasingly awkward design. I saw this happen more than once while building the Auspice Darer Framework. We would spend time refining an approach, improving it a little with each iteration, only to realise that the underly...

One of the biggest misconceptions about AI-assisted software development is that the AI is somehow "in charge" of the project. It isn't. No matter how capable AI becomes, the responsibility for the overall architecture still belongs to the human developer. I learned this repeatedly while building the Auspice Darer Framework. Most of the time, the AI produced excellent ideas, spotted bugs I had overlooked and suggested cleaner implementations than I might have written myself. But occasionally it would head in the wrong direction. Sometimes it would forget an important design decision we'd made earlier. Sometimes it would suggest a solution that ignored one of the framework's architectural principles. Sometimes it would continue reasoning from an assumption that was no longer true. When that happened, I discovered something important. The AI doesn't know it's gone wrong. It simply continues reasoning from the information it believes to be correct. That's...

One of the first habits I had to change when working with AI on software projects was how I shared my code. Initially, I'd upload one file, ask a question and wait for the AI to request the next file. Then another. Then another. If you've ever done this with a large application, you'll know how quickly it becomes a game of "Can I see the next file?" The problem isn't that the AI is asking the wrong questions. The problem is that it can only reason about the information it has available. If the bug appears in a controller but is actually caused by a service, configuration file or bootstrap process, the AI has no way of knowing that until it sees those files as well. Before long, you've spent more time uploading files than discussing the solution. Eventually I started taking a different approach. Whenever I was working on something that involved architecture, debugging or major refactoring, I'd simply upload a ZIP archive of the entire project. That chan...