Key Takeaways
- Vibe coding and AI-assisted development produce working code fast, and architectural mistakes just as fast. The speed is real. The consistency is not.
- A prompt carries only what its author understands. AI raises the output of someone who knows the domain and multiplies the mistakes of someone who does not.
- Most of any business software is plumbing every application needs: accounts, roles, permissions, audit trail, validation, import, export, background jobs, an API. Generating that from prompts is where technical debt collects.
- A data platform like AtroCore ships that plumbing as configuration, which leaves AI-generated code responsible only for the part specific to your business.
- Starbucks is replacing the software its own engineers were already rewriting. That test travels to any size. The capacity to build a foundation from scratch does not.
Companies Are Building Custom Business Software Again
For decades, the build versus buy question had a settled answer. You bought off-the-shelf software and bent the process to fit it, because building was slower and carried a total cost of ownership nobody wanted to defend.
Starbucks is the clearest sign that the calculation moved. The company spends roughly $400 million a year on software, and chief technology officer Anand Varadarajan told an internal forum there were clear opportunities to reduce that, according to reporting on a leaked internal presentation. Engineers are using AI-assisted coding to build replacements for a Microsoft inventory monitoring system and an IBM maintenance management tool.
The detail worth copying is which software Starbucks picked: tools its engineers were already heavily modifying. That test has nothing to do with company size. A building materials manufacturer whose pricing depends on index clauses buried in supplier agreements faces the same question. Contract management products handle the clause. Joining it to the plants and material groups already sitting in that manufacturer's master data is where the ones we have evaluated stop.
The behavior is spreading. Retool's 2026 survey of more than 800 professionals found 35% of enterprises had already replaced at least one SaaS tool with something built in-house, and 78% expected to build more.
The story cuts both ways. In-house software moves cost from subscriptions into maintenance and headcount rather than removing it, and the point-of-sale replacement for Oracle Simphony has been in progress for several years, predating the AI tooling. AI compresses some of this work and has not compressed that. Starbucks also absorbs what most companies cannot: an engineering organization big enough to build a foundation and maintain it for a decade. A 200-person manufacturer faces the same decision without that capacity. For them, the useful question is what to build on, and a data platform they did not have to write is the cheapest answer available. Vibe coding names the end of this, where someone prompts an application into existence and ships whatever comes back.
What follows applies to the wider case too: professional developers using AI assistance on code they review. We build custom business software with manufacturers and distributors, so the arguments come from projects rather than a whiteboard.
What AI Writes Well, And What It Writes Badly
Veracode has run the same test against AI models since 2023: 80 coding tasks, four languages, four vulnerability classes, no security instructions in the prompt. In its Spring 2026 update, syntax correctness passed 95% while the security pass rate held near 55%. Java scored worst at 29%.
The reason behind those numbers is more useful than the numbers. Models are strong at local patterns and weak at tracking data across files. Parameterized SQL is a pattern the model has seen flagged a thousand times. Sanitizing input that passes through four functions into a template is a dataflow question, and dataflow needs context the model does not hold.
For a professional team, the interesting failures are the ones that survive review. A reviewer catches a missing null check or a wrong variable name. Review is far weaker on anything visible only across files and across weeks, because each change looked reasonable alone. Undocumented logic passes too, since generated code that works is hard to argue against in a pull request. What accumulates is comprehension debt: code that runs correctly and nobody on the team can now explain.
Maintainability shows the same weakness. GitClear analyzed 211 million changed lines of code from 2020 to 2024 and, as reported by LeadDev, found duplicated blocks of five or more lines appearing eight times more often in 2024. Copy-pasted lines overtook moved lines for the first time in the dataset. Moved lines are the fingerprint of refactoring, the work of consolidating something into one reusable place.
In the 2025 Stack Overflow survey, the top frustration, named by 66% of respondents, was AI output close to correct without being correct. The same survey sizes the practices: 84% use or plan to use AI tools and 51% of professional developers use them daily, while only about 15% call vibe coding part of their professional work. AI-assisted coding is the default case. Shipping unread output is still rare.
A Prompt Carries Only What Its Author Knows
AI answers the prompt it was given, so the ceiling on generated code is the domain understanding of whoever wrote the prompt. On B2B data problems, that understanding rarely sits with the developer. A purchasing manager who has negotiated supplier agreements for fifteen years knows what an index-linked price clause has to survive. A developer prompting without that knowledge gets code that satisfies the example and nothing past it, and the gap stays invisible until a real contract arrives.
For professional teams, this moves the bottleneck. Typing speed stopped being the constraint a while ago, and syntax went with it. What limits output now is how well somebody extracted the domain knowledge first.
A related assumption deserves naming. Software companies that have spent ten years on the same product have rarely been wasting those years. That time holds the edge cases nobody anticipated, the permission model that survived an audit, the import that copes with the spreadsheet a supplier actually sends rather than the one the specification described. None of it reaches a prompt, because nobody writes it down until it breaks once in production.
An experienced developer with good AI tooling can reproduce the shape of a mature product in weeks. Reproducing what it learned takes about as long as it took the first time. We sell software, so weigh that accordingly, then test it: take a product you know well and count how many of its behaviors you could have specified up front.
The Technical Debt Sits In The Plumbing
Picture a supplier management application. Before it manages a single supplier, it needs a long list of things that have nothing to do with suppliers.
Accounts, groups and roles, plus field-level permissions so purchasing sees commercial terms and the plant manager does not. An audit trail recording who changed which field and when. Validation on every field. Search, saved filters and bulk edit. Import from the spreadsheet a supplier emailed, export to the ERP. Background jobs that survive a 40,000-row update. A REST API for the mobile view someone will request later.
None of that is your business problem. All of it has to work.
Prompt an agent for it, and you get role checking implemented one way in the supplier module and another way in the contracts module three weeks later. Two permission mechanisms that disagree on edge cases. Overcoupled components, because the model optimized each prompt locally and never saw the whole. Change history on four entities and not the fifth. Each piece works when demoed. Together they are the maintenance bill, and it arrives whether or not anyone called the process vibe coding.
Across the implementations we have run, the split between plumbing and business-specific logic is lopsided in a consistent way.
The part specific to a customer's business is rarely more than a tenth of what gets built. The rest is the same in every business application ever written, and it is exactly the part AI writes inconsistently.
That ratio decides the economics. Vibe coding is cheap where the work is small and expensive where the work repeats.
What A Data Platform Hands You Before The First Prompt
The AtroCore data platform is open source software under GPLv3, in active development since 2018, built for master data management and system integration. Its documented use cases include serving as an open source low-code platform for custom business software.
Available through configuration, before anyone writes a line of code:
- Data model.
Configurable entities and relations, over 20 field types with automatic validation, configurable layouts, multi-level hierarchies with inheritance, classification and taxonomies. - Access and history.
Unlimited users and groups, role management, field-level access control, configurable access queries, action logs, change history, comments, record ownership, dashboards, storable filters. - Data movement.
Import and export feeds, configurable API requests and database queries, transformations applied before import or export, XLSX, CSV, JSON and XML, connections over REST, GraphQL, SOAP and OData. - Processing.
A job manager where you set worker count against server capacity, scheduled jobs, event-based actions, configurable workflows, and data quality checks. Custom action buttons placed into the interface by configuration, each running against a single record or a whole selection. - Output.
PDF, Office document and email templates, plus a REST API covering everything, including your own configuration.
What remains for vibe coding is the part that is actually yours. The index-linked price adjustment formula. The tender comparison logic. The connector to that one ERP module nobody has integrated before.
That code has defined places to live. AtroCore is extended through modules you write yourself, and lighter logic fits into configurable actions, scripts and conditions attached to existing entities. The trigger is usually a configured button, which means a bulk operation over 300 selected records needs no screen, no route, and no permission logic of its own.
The Veracode findings still apply to whatever the model writes there. What changes is the blast radius. A pricing formula inside a system that already handles authentication, field-level permissions, and input validation has fewer ways to hurt you than one in a hand-rolled endpoint that also invented its own session handling.
The API Contract Does The Guardrail Work
One detail in AtroCore's architecture matters more for AI-assisted work than it appears to. The HTTP layer follows PSR-7 and PSR-15 strictly. Handlers register through PHP attributes and are documented automatically as OpenAPI 3.0. Per the project documentation, a route that is not fully documented is not registered, and every request and response is validated against the schema at runtime.
Consider what that does to a coding agent. It writes a client, invents a plausible field name, and the request fails immediately with a schema error. Same session, context still open, fix costs thirty seconds. Errors caught inside the session never turn into technical debt. Without a contract at the boundary, that invented field writes nowhere silently and resurfaces four months later as a data quality investigation. Fast, unforgiving feedback is what makes AI-generated code cheap to fix, and the platform supplies it without anyone building it.
That schema is also what you hand the agent. Because the documentation is generated from the handlers rather than maintained beside them, the OpenAPI description of your own configured entities is current by construction, which is rarely true of a specification kept by hand. Give a model that schema plus your naming and access conventions, and it writes against the real contract. Extend the data model by configuration later, and the schema moves with it, so the agent's context stays accurate without anyone updating a document.
Research Points At The Foundation, Not The Tool
Google's 2025 DORA report found that AI acts as an amplifier, magnifying existing strengths and existing dysfunction, with the largest returns coming from the underlying system rather than the tools. Google Cloud's companion capabilities model is more specific: AI's positive influence on organizational performance is amplified where quality internal platforms exist. A second capability covers healthy data ecosystems: internal data that is high quality, accessible, and unified. A configurable data platform under your custom business software addresses both.
Speed claims keep moving. METR's early-2025 trial found experienced developers took 19% longer in mature repositories when allowed AI tools, while its February 2026 update points toward a speedup and flags selection effects strong enough to warrant a redesign. Treat productivity numbers as unsettled. Maintainability findings have not moved since 2023.
A Supplier Contract Example From Our Projects
Our customers turn to us with a recognizable version of the same problem. A manufacturer keeps supplier agreements as PDFs on a shared drive, key terms in a spreadsheet, renewal dates in one purchaser's calendar. Nobody can say which agreements contain a price adjustment clause tied to a raw material index, because that clause is a sentence inside a document.
Standard contract management tools exist, and they assume a legal department workflow ending at signature. This company needed contracts joined to material groups, plants, and supplier records already in their master data, with obligations that keep producing work for years after signing.
On the data platform, contract, clause, renewal, and obligation became configured entities related to supplier and material records that already existed. Field-level access separated commercial terms from delivery obligations. Change history came with the platform, which mattered the first time two people disagreed about a rebate. A scheduled job flagged renewal windows.
Custom code covered two things: the index-based price adjustment calculation, and a connector feeding the invoice check in their ERP. Both were narrow enough to specify precisely and test properly. The platform constrains what generated code may touch, and vibe coding covers what it was never going to know about a specific business.
Where To Draw The Line Between Configuring And Vibe Coding
Most vibe coding best practices reduce to two questions. What gets configured, and what gets generated. AI has a part to play on both sides of that line, and the two parts are not the same job.
Configure anything that is a record with fields, relations, permissions, and a lifecycle. That covers more than most teams expect, including approval flows, escalations, and scheduled checks. Teams new to this consistently under-configure, then write code to do what a configured action already does.
AI helps here in a way that gets overlooked. Ask it how to model a contract renewal with inheritance, or which field type suits a tolerance range, and a capable model walks you through the configuration. Point it at the REST API, and it can apply that configuration itself. Suggesting and applying configuration is a different job from building the system, and it carries the better return, because a wrong configuration shows up in the interface within minutes while a wrong architecture shows up in month six.
Generate the transformations and calculations. A formula, a mapping, a parser, a report query. Small surface, clear expected output, easy to test.
Verification has a concrete shape here. Configure the validation rules and data quality checks before generating anything, then run the generated logic against records whose answers you already know, including awkward ones like the contract with no end date. The platform rejects what breaks its own rules, so the calculation fails loudly on the record that would otherwise have failed silently in production. Keep that record set as the regression test for the next model you try.
One category belongs to neither. Where a wrong answer is expensive and silent, write it yourself. Money, tax, safety documentation, anything a regulator reads. AI can produce that code perfectly well. The reason to write it by hand is that you need to have understood it first.
If you can describe it as data plus a state change, configure it. If getting it wrong costs more than writing it slowly, write it slowly.
What This Approach Costs You
You adopt someone else's conventions for how records, relations, permissions, and processes work. Where your mental model differs, time goes into fighting the platform instead of using it. Read the developer documentation before committing.
AtroCore runs on PHP and needs a Linux server with root access plus PostgreSQL or MySQL. Ordinary shared hosting will not run it. In our projects, once someone knows the system, a first working data model of four or five entities with relations, layouts, roles and history takes days. Reaching that familiarity takes longer, which is why payback arrives in month three.
Fit is bounded. A platform organized around records, relations and business processes makes a poor foundation for real-time control or signal processing. Start from a framework for those. Over-configuration is its own trap: twenty entities where five would do is technical debt too, quieter than duplicated code and harder to unwind once real data lives in it.
How To Judge A Foundation Before You Start Prompting
Two alternatives compete with a data platform, and each fails a different test. A bare framework leaves you owning every piece of the plumbing. A low-code builder solves that and charges in a different currency: the vendor owns your data model, hosting and runtime, and pricing follows user count. That trade works for an internal dashboard, badly for software holding supplier contracts for the next decade.
Hold any candidate against this list, including both alternatives above.
- One entity, one field and one relation, added without a deployment.
- A single permission mechanism covering the whole system, rather than several that drift apart.
- An API generated from the code and validated at runtime, rather than documented by hand and wrong within a month.
- A change history nobody on your team had to build.
- Background work that runs without a new cron entry per job.
- A clear exit: your data, your database, and your right to keep running the system if the vendor disappears.
Most foundations fail several of these. Knowing which ones, before the first prompt, is the difference between technical debt you chose and technical debt you inherited.