What you will find in this article:
- What the market calls "vibe coding" and why the term confuses decision-makers.
- Where exactly does the AI-generated app break down when it enters real-world operation?
- The data that reveals the hidden cost of unreviewed code.
- How to recognize an orphan system before it becomes a costly problem.
- The seven questions that either block or allow the approval of an internal app.
- The role of Base44 and the relationship of Bytebio with the platform
In February 2025, AI researcher Andrej Karpathy described a new way to write software: you tell it in natural language what you want, and the AI generates the code. The market dubbed it vibe coding, and the name stuck.
A year and a half later, this has already happened within your company. Someone from operations, marketing, or sales opened an AI tool, described an internal control that had always existed in spreadsheets, and showed up at Monday's meeting with a functional screen. A beautiful screen, with a form, a list, and an export button.
The screen works. That was never the problem.
The problem arises in the third month, when permissions per profile are added, along with five hundred records per day and the need to communicate with the CRM. And it reappears in the sixth month, when the person who created it resigns and nobody knows where the code is.
What has really changed?
It's important to separate the fact from the noise.
The fact is that the time between an idea and the first usable version of internal software has dropped from months to days. This isn't a vendor promise; it's observable behavior. According to TechCrunch , about 25% of the startups in Y Combinator's Winter 2025 cohort had codebases almost entirely generated by AI.
This trend helps explain the adoption. There is pent-up demand for internal software and few people available to write that software in the traditional way.
The noise is the interpretation that this concludes engineering. It doesn't. It changes things where engineering is needed.
The screen design is no longer the bottleneck. The bottleneck has become everything that comes after it: data model, access control, integration, traceability, and continuity. This is precisely the part that no demo shows, because in a demo there is only one user, one record, and no audit.
Where the prototype breaks
In practice, an app generated in an afternoon usually breaks down at three predictable points.
Permission by profile. While three people are using it, everyone sees everything and no one complains. When the app reaches thirty users, the inevitable question arises: can the coordinator see the cost? Can the salesperson edit a colleague's record? Can the intern export the entire database? Access control isn't just another screen; it's a modeling decision that needs to exist before the data is even entered.
Volume. A query that responds in milliseconds with two hundred records might crash with two hundred thousand. The prototype doesn't err out of malice; it errs because nobody told it what the volume would be in year two.
Integration. The app is born isolated and becomes an island. The team then does what it has always done: exports spreadsheets from one side, imports from the other, and pays for the integration in person-hours. The gain in speed of construction returns as a recurring operational cost.
These three points have something in common. None of them are problems with the AI that generated the code. They are all architectural decisions that someone needed to have made beforehand.
The fact that nobody puts on the slide.
There's an uncomfortable aspect to this conversation, and it deserves to be in the article instead of being mentioned in the incident.
A CodeRabbit report published in December 2025, based on pull requests from open-source projects, indicates that code co-authored by AI exhibited approximately 1,7 times more serious problems than code written by humans. The concentration is in security flaws and logic errors.
The most common patterns are well-known: an exposed API key on the client side, an unprotected endpoint, and overly permissive database rules. These are flaws that go unnoticed because the app works. It responds, saves, and exports. But it also responds to those it shouldn't.
This doesn't invalidate the approach. It invalidates the idea that it eliminates the need for review. AI-generated code needs the same type of checking as code written by humans, with the added problem that those who generated it often don't know how to read the result to check it.
The orphan system
The second failure is organizational, and it usually costs more than the technical one.
The app was built by someone who is not part of the technology team. It's not in a repository, it has no documentation, no version control, and no formal technical lead. It only exists in the creator's personal account.
When that person changes departments or leaves the company, operations discover that they've become dependent on a system that no one can maintain. And by that point, the system is no longer optional: thirty people are using it every day, and going back to spreadsheets means losing the historical data.
This is the same risk we already addressed in documentation and key person dependencies , but with a worse detail. In the spreadsheet case, the knowledge was in someone's head. Here, it's in code that nobody has read.
Who is responsible for governance?
The third flaw is what prevents the director's approval, and it is almost always brought up too late.
The questions are simple and legitimate. Where is the data stored? Is there a log of who accessed what? Is there a backup and restore test? If the platform goes down, what is the plan? Who is the technical lead if sensitive data is leaked?
When an app is generated by AI without a supporting structure, there are no answers to any of these questions. And without answers, the project remains on the desk of whoever signs it.
It's worth noting the honest limitation here: structure and control are engineering deliverables, and the Bytebio It is your responsibility to ensure compliance with the LGPD (Brazilian General Data Protection Law). Compliance also depends on your company's data policy, the legal bases you adopt, and what your legal department defines. No one provides a compliance certificate along with software.
What separates a prototype from a system?
The difference between the two isn't in the tool. It's in five decisions made before the first screen appears.
- Data model. What entities exist, how are they related, and what happens when one of them changes?
- Access control. Who sees, who edits, who approves, and who exports—defined by profile, not by trust.
- Integration. Which systems are the truth source for each piece of information, and in which direction does the data travel?
- Traceability. What needs to be recorded for auditing purposes, and for how long?
- Continuity. Where the code resides, who versions it, and who provides support when it breaks.
None of these five are accelerated by generating code faster. They all remain engineering work.
Where does Base44 come in?
Business relationship: a Bytebio [Company Name] is a partner of Base44, and the links to the platform in this article are affiliate links. A subscription made through them may generate a commission for [Company Name]. Bytebio.
Base44 is a business application platform from Wix. It's not just a website builder: it serves as an operational dashboard, portal, approval workflow, and internal tool. That's the category of problem it was designed to address.
What the platform does well is address the layer that typically consumes the largest portion of an internal software budget without delivering any added value: authentication, isolation of environment variables, database, deployment, and hosting. Having this ready and handled in the infrastructure significantly reduces the error surface we mentioned above, because most common AI-generated app failures lie precisely there.
Regarding reliability, consider the manufacturer: Base44 was acquired by Wix in June 2025. You're not betting on a weekend tool.
And the point, mentioned before and not after: Base44 is an architectural choice, with the advantages and limitations of any architectural choice. There are scenarios where it is the right decision and there are scenarios where it is not. Replacing an ERP, accounting, or tax system is not its suitability. Migrating critical legacy systems as a standalone project is also not an option.
A Bytebio and Base44
Saulo Amui, CEO of Bytebio, is an ambassador for Base44 in Brazil, and Bytebio is a partner of the platform through it. In practice, this means a direct channel with the manufacturer. It does not mean a license discount, and it does not transform the Bytebio at a reseller.
The distinction matters to those who hire. The platform accelerates construction. Architecture remains an engineering decision, and that's where... Bytebio It comes in with what it has been doing since 2009: data modeling, integration with CRM and ERP, access control, version control in repositories, documentation, and support after the system goes into production.
The time between the idea and the first usable version drops from months to days. The time between the first version and the system that can handle the operation depends on the architecture.
Seven questions to ask before putting an internal app into production.
Use this list the next time someone on your team presents a pre-built screen in a meeting. It works for any AI-powered app, on any platform.
- Who can view, edit, approve, and export each type of record?
- What is the expected data volume in year two, and was the app tested on that volume?
- Which systems does this application need to communicate with, and which one is the true source?
- Where is the code versioned, and who besides the creator has access to it?
- Is there sufficient access and change log for an audit?
- There's a backup, and has anyone tried restoring it?
- When the store breaks at 8 AM on a Monday, who answers the door?
If three of these questions remain unanswered, what you have is a valuable prototype. It deserves to become a system, and it isn't one yet.
The conclusion that matters to the decision-maker.
Describing software in natural language works, and it works well for getting to the first version quickly. That part of the promise has been fulfilled.
What hasn't changed is that real operations require permits, volume, integration, auditing, and continuity. Those who address these five things beforehand save on rework. Those who address them afterward pay twice: they pay to build and they pay to rebuild.
Structure first. Automation later. Base44 solves for speed. THE Bytebio It is responsible for the structure.
How Bytebio can help
A Bytebio It is a technology and data consultancy focused on operations. system integrations and business intelligence, with software engineering since 2009. We work with process automation, operational data and indicators e AI applied with governance.
As a partner of Base44, Bytebio We implement and maintain business applications on the platform: operational dashboard, customer or supplier portal, approval workflow, and internal tools. We handle the data model, profile-based access control, integration with your existing CRM and ERP systems, version control in repositories, and support after the system goes live.
If your company already has an internal AI-generated app running without a technical lead, or has a request stuck in the IT queue for months, talk to the BytebioWe begin with a brief diagnosis of the application and the process, and we frankly state what can be salvaged and what needs to be redone.
