Using AI to Develop a Software Product
An Experience Report
For more than a year, we’ve been continuously working on our forecasting and Flow Metrics tool, Lighthouse. Recently, we’ve made a bigger update, reworking the UI. This would not have been possible without the use of AI tools.
In this post, I’d like to share my perspective on the usage of AI for developing a software product. I’ll share my actual experience with it, rather than making bold claims.
Who is this for?
If you check out LinkedIn (among other places), it’s nearly impossible to not read about all the things AI will change, who it will be putting out of a job, and more…
It feels like suddenly everyone is an AI expert, Vibe Code Coach, or Prompt specialist.
Agile is dead! Buy my AI course!
I’m not opposed to embracing new technologies. It’s what agility is also about. The integration of AI will certainly change how we work (hopefully for the better). With this post, I want to give an insight into how AI can be used for developing a software product.
If you are not developing yourself, this may give you a good idea of what’s possible nowadays. If you do develop, maybe it will encourage you to give it a try as well.
There may be better tools and better approaches to what I did. I don’t claim you should do the same. My goal is to share my experience, not to sell you a specific method.
My Background
While I’ve studied Software Engineering, and was working the first years of my career very closely in this domain, I’ve been focused more on the people and processes in the last years. Writing code was not part of my daily professional life anymore.
While I know some things about a Frontend, I’ve always liked the Backend and automation work way more. Frontends were a “necessary evil” more than something I liked to do.
Needless to say, this showed in the first version of Lighthouse:
A Backend Developer in a React World
It was clear to me that this was not something we should leave as is. So, after having it on my to-do list for years, I finally had enough motivation to dive into learning React.
As much of a culture shock as New York was for Sting, React felt very strange to me initially.
I started out learning the “old school” way:
Watching Tutorial
Doing online courses
Browsing the web for specific help
I’d like to think that it was very useful for me to learn the basics like this:
What is a component?
How should I structure my app?
How can I write tests?
What’s a state, and what are props again?
But I also realized that with such an established technology, Large Language Models (LLMs) such as ChatGPT are very helpful.
The following is a preview of how Lighthouse looked in one of the first iterations where we switched to the new React-based frontend:
At this point, I was mainly using ChatGPT to help me with specific problems or errors. This was way faster than having to sift through 20 search results from Google or asking a question on Stack Overflow (with the added benefit that ChatGPT was not complaining about how I wrote my question…).
And while it was helpful, it didn’t feel so nice yet. You always had to context-switch between a browser window and the Integrated Development Environment (IDE).
IDE Integration
That’s when I realized that there is a quite nice integration into VS Code for GitHub Copilot. This extension would allow you to chat and ask questions, where it’s directly having the context of your current file (or other files you’re referencing). And not only can you ask questions, but it is also possible that the LLM would directly make changes in your files.
This integration felt much more natural, removing context-switching, making it as easy to use as, for example, built-in refactoring tools your IDE is offering.
This was not just speeding up general development; it also allowed me to apply AI for more specific tasks where I needed more context. I used this extensively to improve the testability of my components, refactoring them and increasing the test coverage. This was hard to do without having the context, as it potentially affects many files in the project.
It also helped build up end-to-end testing using Playwright. I’ve never used Playwright before, but similar to React, the LLMs helped me get up to speed very quick, and it was one of the smoothest experiences I've had learning a new technology.
Curious in how we test Lighthouse? Read the dedicated Post about this!
How Do We Test Lighthouse?
When I started Lighthouse, it was a personal project. Yet, one of the first things I did was to add a CI Pipeline and write tests. Most of the backend was created using TDD, so it’s safe to say that tests were on our minds from the get-go.
This was nice, and I was happy. Things were working smoothly. I didn’t think there was much to improve. And then Agent Mode happened…
Agent Mode
In early 2025, Microsoft released an update to GitHub Copilot and its VS Code integration, so that now “Agent Mode” is supported. Instead of “just” asking questions or doing “simple edits”, Copilot was able to act as an agent, figuring stuff out on its own, looking for more context, and iterating on its own changes (for example, if tests are failing).
The demos were impressive, and my first testing also revealed that it seems to hold up on its promise. Far from perfect, but very capable, and it sped up development even more. It felt like it was supercharging my development efforts.
It’s been a year since I got my hands dirty with React, and I was doing ok. That said, I don’t see how I ever spend lots of time to make something really “nice”. It’s just not that interesting to me. But I thought, why not let the Agent mode of Copilot have a go at it? Out of curiosity, I threw the following prompt at it and let it work:
Copilot was at it for about 60-90 minutes. While some things weren’t working yet, it managed to change the full application and implement my requests. The new UI looked like this:
It took me about a day to clean everything up, make sure all tests were working again, and have everything deployed. One day, to fully rework the UI. For me, the person who does not really care about UIs. We could try to estimate how long this would have taken me to implement without the agent mode, but realistically, it would simply never have happened.
While ChatGPT and the “regular” Ask and Edit modes of Copilot helped me speed up, Agent mode made things possible that I would not have thought I could do:
I got 99 problems, the UI ain’t one of them!
Vibe Coding?
You may wonder, so is using this Agent mode what people call Vibe Coding? In my understanding, it’s a clear no.
I still try to look at the code, understand what’s going on, and sometimes manually adjust it. I don’t trust the output, and it’s my responsibility as a developer to make sure whatever I commit into version control is of good quality.
Following is the “definition” of vibe coding from Andrej Karpathy, who first mentioned the term on Twitter beginning of 2025:
So as long as you still inspect the code, you’re not “vibing”. AI-assisted coding, even if it’s doing the bulk of writing the code, is not vibe coding, if you’re still checking it out yourself, and potentially fixing some problems based on the resulting code.
Why do I care about that? I’ve seen the term being used extensively online (especially LinkedIn), where I had the feeling that many people don’t fully understand what it means. So I thought it’s good to clarify this.
This doesn’t mean that you can’t build something in a “Vibe Coding” mode. But for now, at least personally, I wouldn’t trust this enough to build a product, unless it’s something quite simple.
Conclusion
Is AI extremely helpful in building software? Yes! Can I build my software faster than before? Yes! Is it allowing me to build things that would not have been possible without it? Also yes!
You can see, I’m quite a big fan. Looking at Lighthouse as a case study, you can see how this can change a product. All of it could have been possible without AI, but realistically, I needed help from outside. Using LLMs and agents integrated with your IDE is upgrading your skill as an individual developer, allowing you to go faster and further!
I’m convinced the role of software engineers is going to change (if it hasn’t already). For me, embracing those new tools has been a game-changer. And while it’s not producing results that are always up to my quality standards, it has allowed me to become a “one-person development team”, covering all skills needed to develop a product. That’s pretty cool!