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...

When people first start using AI for software development, they often treat it like a search engine. They open a single conversation and keep asking every question in the same place. I started that way too. For small projects, it works perfectly well. Large software projects are different. As my work on the Auspice Darer Framework grew, I realised that one conversation was trying to cover too many different topics at once. One moment I was discussing dependency injection, the next I was redesigning CSS, then debugging routing, before switching to documentation or database design. The conversation became cluttered, and the AI had to continually switch context. Eventually I tried something different. Instead of one conversation, I created a project and gave different chats different responsibilities. One chat focused entirely on framework architecture. Another concentrated on CSS and presentation. Others were dedicated to individual applications, documentation, testing or specific migrat...

When people hear the word architecture , they often imagine something complicated. Layers. Patterns. Dependency injection. Service containers. Routing. They're all useful tools, but they're not the reason architecture exists. For me, architecture serves a much simpler purpose. It makes change inexpensive. That lesson wasn't something I learned from a book. It was something I discovered by maintaining an increasing number of applications. Every time I found myself making the same change in multiple places, I asked the same question. "Why isn't there just one place to change this?" Over time those questions shaped the Auspice Darer Framework. There became one shared configuration. One common layout. One routing system. One authentication service. One way of rendering pages. One location for reusable components. Instead of every application deciding how to solve these problems, they all relied on the same shared platform. The result wasn't simply less code. I...