www.newsletterintel.ai<\/a>.<\/p>\n\n\n\nThat experience was exciting, but also uncomfortable. The more I built, the more I understood that AI gives you a strange combination of power and uncertainty. You can move faster than ever before, but you do not always know exactly what happened under the surface.<\/p>\n\n\n\n
That is where the real learning started.<\/p>\n\n\n\n
1. Software specification has to change<\/h2>\n\n\n\n
In our traditional software development process, we usually work with several levels of specification before development starts. There is a business or marketing-level specification, then a more technical version, and finally a detailed requirements specification with implementation details.<\/p>\n\n\n\n
When AI is heavily involved, this structure changes.<\/p>\n\n\n\n
I learned that we still need a clear business description of the product, the problem, the users, the value, and the expected behavior. But we also need a strong technical context document that explains the environment in which AI should work. This includes architecture, database, APIs, security rules, coding principles, deployment expectations, and other technical boundaries.<\/p>\n\n\n\n
The interesting part is that the technical context can often be reused across different projects. The business requirements are specific to one project, but the technical context can become a company asset.<\/p>\n\n\n\n
AI does not remove the need for specification. It changes the kind of specification that matters most.<\/p>\n\n\n\n
2. Vibe coding creates a new type of QA problem<\/h2>\n\n\n\n
When you build with AI, the process can feel very natural. You describe what you want, the AI writes code, you test it, you improve it, and you continue. It feels like working with a very fast developer who never gets tired.<\/p>\n\n\n\n
But there is a serious problem.<\/p>\n\n\n\n
You do not always know what the AI really did.<\/p>\n\n\n\n
Even if you give a clear technical context, AI may still make its own decisions. It may create logic in a way you did not expect. It may use a pattern that looks correct but is difficult to maintain. It may solve one problem while silently creating another.<\/p>\n\n\n\n
This changes the role of quality assurance. Traditional QA checks whether the software works according to the requirements. With AI-generated software, QA also has to check whether the functionality is really implemented, whether the logic is stable, whether the solution is secure, and whether the team understands what has been built.<\/p>\n\n\n\n
Testing the visible result is no longer enough. We also have to test the hidden assumptions inside the code.<\/p>\n\n\n\n
3. AI can make mockups look like real functionality<\/h2>\n\n\n\n
This was one of the most dangerous lessons.<\/p>\n\n\n\n
AI often uses mock data, and sometimes it does this in a way that is not immediately clear. You test the application, the screen looks good, the numbers appear, the user flow works, and everything feels professional.<\/p>\n\n\n\n
But later you discover that part of the application is not connected to real logic or real data. It is only a simulation.<\/p>\n\n\n\n
For a prototype, this can be useful. For a real software product, it can be a major risk.<\/p>\n\n\n\n
This is especially important in business applications. It is not enough that the user interface looks correct. We need to know that the data is real, the API connection works, the business logic is implemented, and the result is not just a beautiful screen with simulated behavior.<\/p>\n\n\n\n
AI can create false confidence. It can make something look finished before it is actually ready.<\/p>\n\n\n\n
4. Deployment becomes a new challenge<\/h2>\n\n\n\n
During development, AI can use many different tools, frameworks, libraries, and services. In the beginning, this feels helpful because the application works and the features appear quickly.<\/p>\n\n\n\n
But when you want to deploy the product professionally, you need to understand all those moving parts.<\/p>\n\n\n\n
Suddenly you have to understand the framework, the backend, the database, the authentication layer, the payment integration, the environment variables, the hosting setup, the monitoring, and the scaling model. You may not have needed to understand all of this to build the product, but you need to understand it to operate the product.<\/p>\n\n\n\n
This is a major difference.<\/p>\n\n\n\n
AI can reduce the entry barrier to development, but it does not remove the responsibility for deployment and maintenance. If the application stays inside the environment of the vibe coding provider, the company may become dependent on that platform. For a hobby project this may be acceptable. For a business, it can become a real strategic risk.<\/p>\n\n\n\n
5. Hidden costs can destroy the business model<\/h2>\n\n\n\n
During development, many tools look free or inexpensive. You use free tiers, small API volumes, test environments, and limited data. The application works, and the cost seems almost invisible.<\/p>\n\n\n\n
But when the product moves into real usage, the situation changes. More users create more API calls. More data creates more storage. More AI usage creates more token costs. More automation creates more background processing. More integrations create more subscriptions.<\/p>\n\n\n\n
If you do not understand this early enough, you can build a product that works technically but fails financially. You can price the software too low. You can sell something without covering your own operating costs. You can discover too late that the architecture selected during AI-assisted development is not economically sustainable.<\/p>\n\n\n\n
This is one of the most important lessons for software companies. AI can help us build faster, but faster development does not automatically create a profitable product. Every AI-driven solution needs a clear technical and financial cost model.<\/p>\n\n\n\n
After this experiment, I am more convinced than before that AI will deeply change software development. But I am also more careful.<\/p>\n\n\n\n
AI is powerful, fast, and useful. It can help companies create more with less effort. It can shorten the distance between an idea and a working product. It can give non-developers and business leaders a much better understanding of what is technically possible.<\/p>\n\n\n\n
But AI also hides complexity. It can hide mockups. It can hide costs. It can create dependencies. It can make us believe that something is finished before it is truly ready.<\/p>\n\n\n\n
For simple applications, prototypes, internal tools, and early product ideas, the value is already huge. The next and more serious question is how we should use AI when developing business-critical software.<\/p>\n\n\n\n
For us, this means looking at AI in the context of solutions such as our fiscalization middleware, where quality, security, compliance, stability, and responsibility are not optional.<\/p>\n\n\n\n
That is the next topic on my desk.<\/p>\n\n\n\n
After that, we will consolidate the results of our company-wide experiments and decide what has to change in the way we work.<\/p>\n\n\n\n
Because AI will not only change how code is written. It will change how software companies define requirements, manage projects, test products, deploy solutions, calculate costs, and assign responsibility.<\/p>\n\n\n\n
That is why every software company should experiment with AI.<\/p>\n\n\n\n
But not blindly.<\/p>\n\n\n\n
<\/p>\n","protected":false},"excerpt":{"rendered":"
Every chief executive I know has the same topic somewhere on the desk: artificial intelligence. Some talk about it as an opportunity. Some talk about it as a risk. Some want to move faster. Some are afraid of moving too early. But nobody can ignore it anymore, especially not in a software company. I had…<\/p>\n","protected":false},"author":1,"featured_media":143181,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"episode_type":"","audio_file":"","cover_image":"","cover_image_id":"","duration":"","filesize":"","date_recorded":"","explicit":"","block":"","itunes_episode_number":"","itunes_title":"","itunes_season_number":"","itunes_episode_type":"","filesize_raw":"","footnotes":""},"categories":[3,56],"tags":[83],"class_list":["post-143182","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-business","category-technology","tag-ai"],"_links":{"self":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts\/143182","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/comments?post=143182"}],"version-history":[{"count":1,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts\/143182\/revisions"}],"predecessor-version":[{"id":143183,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/posts\/143182\/revisions\/143183"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/media\/143181"}],"wp:attachment":[{"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/media?parent=143182"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/categories?post=143182"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/darkopavic.xyz\/index.php\/wp-json\/wp\/v2\/tags?post=143182"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}