# Building internal systems with AI: what changed > AI made writing code cheap, not the decisions that hold an internal system together. What that changes when you choose between building in-house and hiring. - Author: Marlon Trettin - Published: 2026-10-12 · Updated: 2026-10-12 - Language: en - Canonical: https://yowpi.com/en/blog/building-internal-systems-with-ai --- When your team builds a working screen on its own, the conclusion looks obvious: nobody needs to be hired. It holds, but the question moved. AI cut the cost of writing code, not the cost of the decisions that keep a system standing: who can change what, and who answers when a number comes out wrong. That is architecture. ## TL;DR - Producing a screen got cheap. The decisions that determine whether it still works a year from now cost the same as before. - In the 2025 Stack Overflow survey, 46% of developers distrust the accuracy of what AI returns and 33% trust it. The biggest frustration, cited by 66%, is the answer that is almost right. - The 2025 DORA report calls AI an amplifier: it magnifies what the organization already does well and what it already does badly. - The choice between building in-house and hiring is no longer about who writes the code. It is about who answers for the architecture once the system is part of the routine. ## Why is this question back on the table? Because the demo works now. An operations analyst opens an AI tool on Tuesday and shows a working order screen on Thursday. It saves, it lists, it filters. Not a mockup. It runs. The [2025 Stack Overflow survey](https://survey.stackoverflow.co/2025/ai) puts numbers on how normal this became: 84% of respondents use or plan to use AI at work, and 51% of professional developers use it daily. After the demo comes the same question every time. If the screen already exists, why pay for a project? ## What got cheap and what did not Producing code got cheap. Screens, forms, reports, import routines. That part of the work went from weeks to days. Deciding did not get cheap. A system the company uses every day depends on answers no tool writes on anyone's behalf: what the source of truth is for each piece of data, who can view and change what, what happens to history when a rule changes, who picks up the phone when the process jams at 6pm on a Friday. The [2025 DORA report](https://dora.dev/research/2025/dora-report/) sums the effect up in one word: amplifier. AI magnifies what the organization already does well and what it already does badly. Where the process is defined, the gain shows up. Where it was never defined, the company now produces more undefined work in less time. The report is published by Google Cloud, which sells AI, and the finding still cuts against the promise of automatic gains. ## Why "almost right" is worse than wrong in an operation In the same survey, 66% of developers name AI answers that are almost right as their biggest frustration, and 45% say debugging AI-generated code takes more time. Trust in accuracy sits at 33%, against 46% who distrust it. Only 3.1% say they highly trust it. What is wrong gets caught. The screen does not load, the calculation returns an absurd number, someone complains the same day. What is almost right goes through. In a marketing text that costs one round of edits. In a system that issues documents, calculates commissions or releases credit, the error lands in the database, spreads through the reports and resurfaces months later, when someone notices that [the dashboard never matched finance](/en/blog/management-dashboards-why-numbers-dont-match). The quality bar for a system in production is not the bar for a prototype. A prototype has to convince. A system has to be right when nobody is watching. ## The feeling of speed is not enough to approve a project METR, a nonprofit research organization, ran the experiment that was missing. Sixteen experienced developers, 246 real tasks in their own repositories, each task randomly assigned to allow or disallow AI. Before starting, they forecast a 24% speedup. After the work, they said they had gained 20%. [The measurement said otherwise: with AI they took 19% longer](https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/). The data is from early 2025 and METR itself treats it as out of date. In February 2026 it [published the follow-up](https://metr.org/blog/2026-02-24-uplift-update/), with 57 developers and more than 800 tasks, which points toward a speedup, and explained why it trusts its own number so little: many developers declined to take part rather than work without AI, and 30% to 50% of participants stopped submitting exactly the tasks where AI would help most. The useful conclusion is not that AI slows people down. It is that perceived speed is not evidence, not even from experienced professionals measuring themselves. If the decision to build in-house rests on the impression that things got fast, it rests on nothing. ## An example, and it is a hypothesis A distributor with thirty people and around $3M in annual revenue. The operations analyst builds an order screen with AI in a week. It works. The team adopts it, the spreadsheet disappears, everyone celebrates. By month three, three things happen at once. The price table is being edited in two places, because nobody decided which one wins. A customer disputes an order approved outside the sign-off limit and there is no record of who approved it. The ERP integration is a manual export the analyst runs every Friday, and he is on vacation. Nothing broke. The operation simply went back to depending on one person, which is the problem the system was supposed to solve. The scenario and the numbers above are a working hypothesis, not a measurement from a client. ## What changes in the build-or-hire decision The buy-or-build criterion is unchanged: commodity you buy, what differentiates the operation you build. What changed is what the company is contracting when it contracts. It used to contract the capacity to produce software. Today production is the most accessible part of the package. What you contract is responsibility for the decisions that have to survive the first month's enthusiasm, and for who answers when they fail. Before deciding, answer these in writing: 1. What is the source of truth for each piece of data this system touches, and who has authority to change it? 2. Who can view and change what, and what gets recorded when someone does? 3. When the business rule changes, and it will, who changes it, how fast, and against which test? 4. If the person who built it leaves next week, what stays in the company besides what is running? If your team answers all four, building in-house with AI support is a reasonable path. If it does not, AI is accelerating the part that was never the bottleneck. Worth remembering that [the bill does not end at delivery](/en/blog/what-it-costs-to-keep-a-system-running), and that choosing between an in-house team and a supplier carries other weights, from turnover to concentrated knowledge. ## Frequently asked questions **Without a technical team, can we maintain a system built with AI?** Yes, if the rules live outside the head of whoever built it. That means a documented data model, defined permissions, a test environment and a written change procedure. Without those, the company has a system in production with a single internal supplier, and that supplier takes vacations. **Is the system our team put together with AI secure?** Security is not a property of the tool, it is the result of decisions: [who gets in, what each role sees](/en/blog/access-control-who-sees-what), what gets logged and what happens when an employee leaves. A screen generated in two days rarely has those decisions made, because they stay invisible while everything works. Worth auditing before customer data goes in there. **Is architecture worth paying for if AI already delivers the screen?** The screen is the visible part and the cheapest to redo. What costs money is migrating badly modeled data, rebuilding history nobody kept and untangling an integration nobody designed. In the [Colo Saúde platform rescue](/en/cases/colo-saude), which we inherited running, the first project was a security audit and performance tuning, before any new feature; today the same platform is migrating to a different technical base. Architecture decides whether in two years you extend the system or start over. ## The next step If your team has already built something with AI and the question is what part of it deserves to become a system, the [Operational Architecture Diagnostic](/en/contact) is a 30-minute conversation about the operation, before any technical proposal.