Earlier this spring, I launched a tool I had been building since last fall. It is aimed at non-profit sports associations where members help out by taking shifts, for example in the kiosk during games. Administrators create work shifts, and members book themselves onto them. The product is currently built for the Swedish market, and you can take a look at arbetspass.se.
This article is not really about the product itself. It is about how AI helped me build it, how my way of using AI changed during the project, and what I think developers still get wrong when they talk about AI-assisted development.
My main tool for this project was GitHub Copilot, which I used in GitHub Web, VS Code, and Visual Studio. The biggest lesson was not that AI made me faster. It was that AI became dramatically more useful once the project had clear structure, consistent patterns, and sensible boundaries. In other words: AI did not replace engineering discipline. It rewarded it.
Structure first, then speed
One of the best decisions I made in the frontend was to build a component library for this project. Not a general-purpose design system, but a set of reusable components that made the site consistent. I use a lot of isolated CSS, and I built components such as my own TextBox so that text input looked and behaved the same across the whole application. It was not just an input field. It also included a label, styling, and a predictable structure that I could reuse everywhere.
The same pattern applied to other components as well. Some of them also handled responsive behavior. For example, my Grid component behaves like a table on desktop and more like a list on mobile. That kind of consistency matters for users, but it also matters for AI.
Once those patterns existed, building new pages became much easier. Copilot did not have to invent structure or guess the visual language of the application. It could follow the patterns that were already there. That is an important distinction. AI is far more useful when it can continue a system than when it has to design one.
That changed the way I worked. Early in the project, I mostly used Copilot for isolated problems. Later, I could give it broader prompts such as: "Build a date input component in the same style as the other input components in the project." That only worked because the project already had a recognizable style and architecture. The better my structure became, the more leverage I got from AI.
AI worked best when the problem was clear
The backend is hosted in Azure. I originally built the API as a Web API project and planned to host it in Container Apps. But this is a side project, and I did not know whether anyone would use it. For that kind of workload, cost matters a lot. I realized that Container Apps could become expensive, especially if I wanted to avoid long startup times, so I decided to move the backend to Azure Functions instead.
By that point, I had already built many of the endpoints. Rather than rewriting everything manually, I used Copilot to help convert the API to Azure Functions. It worked well, but there was a catch: the task was too large to hand over in one go. At that time, Copilot was noticeably weaker when a task was broad, ambiguous, or touched too many files at once. I had to split the migration into smaller pieces and convert a few endpoints at a time.
That experience changed how I think about AI-generated code. The problem is usually not that the model cannot write code. The problem is that developers often ask it to solve a task that is underspecified or too large. When I gave Copilot a clear, bounded task, it was productive. When I expected it to reason through a large migration all at once, it struggled.
That is still the pattern I see most often: AI performs well when the work is structured well enough that another engineer could reasonably pick it up and complete it.
Infrastructure is where AI saved me the most time
I also use Bicep for infrastructure. I have worked with Bicep for years, so I know it well, but even then, infrastructure work often means spending a lot of time in documentation, checking resource properties, and fixing deployment issues one iteration at a time.
This was actually where Copilot saved me the most time early in the project. I used it heavily when setting up the cloud environment. The suggestions were not always correct on the first try, but they were often close enough that I could deploy, see what failed, feed the error back into Copilot, and iterate quickly.
That workflow matters. AI did not eliminate the need to understand Azure or Bicep. It made the feedback loop shorter. I still had to judge whether the proposed solution made sense. I still had to validate the deployment. But instead of spending that time translating documentation into code from scratch, I could spend more of it evaluating and refining.
For experienced developers, that is one of the most useful roles for AI: not as an autopilot, but as a fast first draft generator that helps you move through technical friction faster.
The most important lesson: AI follows your standards
What I learned from this project is that project structure matters more in the age of AI, not less.
If your project has clear patterns, reusable components, sensible naming, and a consistent way of organizing code, AI will usually reinforce that. If your project is messy, inconsistent, and full of special cases, AI will reinforce that too. It is very good at continuing patterns, including bad ones.
That is why I think a lot of the discussion around AI in software development misses the point. People often ask whether AI can write code. Of course it can. The more important question is: what kind of codebase are you asking it to write into?
A well-structured project gives AI guardrails. A poorly structured project gives it noise.
This also means you need to work differently depending on the stage and age of the project. Early on, I used smaller prompts with more explicit instructions. As the architecture became clearer, I could split work into larger functional slices such as frontend and backend. Now I often work from functional requirements and let Copilot generate most of the implementation, from backend functions to frontend pages, often in a cloud session.
But there is a second lesson here: broader delegation only works after the project earns it. You do not get there by accident. You get there by building conventions, reviewing code carefully, and making sure the codebase has a shape that both humans and AI can follow.
AI did not remove the need for judgment
One reason this approach works for me is that I do not treat AI output as finished work. I treat it as proposed work.
When Copilot generates something substantial, I review the code first, often in the web UI. Then I pull the branch, test it, and make changes where necessary. That review step is not optional. AI is good at producing plausible code, and plausible is not the same thing as correct. In infrastructure, that means deployments still need validation. In backend code, it means checking behavior and boundaries. In frontend code, it means verifying that the result actually fits the component model and behaves properly across screen sizes.
That is another reason I think the "AI replaces developers" narrative is shallow. The real shift is not that developers become unnecessary. It is that the value of strong technical judgment increases. If AI can generate more code more quickly, then reviewing architecture, correctness, consistency, and tradeoffs becomes even more important.
My takeaway for developers
The sharpest lesson from this project is simple: AI is an amplifier.
If you have a well-structured project, it amplifies that structure. If you have clear patterns, it amplifies those patterns. If you are disciplined about review and validation, it amplifies your productivity.
But if your project is inconsistent, if your boundaries are unclear, or if you expect AI to compensate for weak engineering habits, it will amplify that too.
That is why I do not think the main competitive advantage is "using AI." More and more developers will use AI. The advantage is having a codebase and a way of working that let AI be effective.
For me, that meant reusable frontend components, clear architectural slices, iterative infrastructure work, and a review process that treats AI output as a draft rather than a verdict.
So yes, AI helped me build this product faster. But the more important lesson is why it helped: not because it was magical, but because the project gradually became structured enough for it to be genuinely useful.
That is the part more developers should pay attention to.