Producing Became Cheap, Knowing Became Expensive: What Proud Tech Summit 2026 Reveals About the Frontier Between Prototype and Production

I followed the online stream of Proud Tech Summit 2026, an event hosted by Starian and Softplan. It was roughly eight hours of presentations focused on software engineering, legacy systems, production AI agents, and data architecture.

The event bypassed the superficial AI chatter that dominates the internet. Instead of canned chat demos, the sessions addressed real problems: legacy relational databases, brittle integrations, fiscal constraints, and the work required to run models with actual customers.

The sessions I followed throughout the day:

• Carla Souza, Guilherme Brasil, and Luis Fausto (Starian and Softplan): opening and enterprise AI maturity.
• Lucas Leung (Oracle Brazil): Formula 1 simulations with Oracle RedBull Racing.
• Jean Roloff (Checklist Fácil / Starian): building Orbit with Working Backwards and SDD.
• Pedro Escobar (Softplan): agent governance and the Softflow framework.
• Rafael Gomides and Amanda Aragão (1Doc / Softplan): public municipal service via WhatsApp.
• Diogo Noschang (Starian): corporate data governance and security with MCP servers.
• Alexandre Messina (Lovable / VibeLabs): fast prototyping and Vibe Coding.

The three-prompt test and the 77% stalled in pilots

In the opening remarks, Carla Souza pointed out a clear mismatch: the speed of tooling development has accelerated drastically, but the time it takes to grasp business logic and validate systems remains thoroughly human.

Guilherme Brasil demonstrated this with a test using the exact same LLM model. He asked for a 32-word opening statement containing the numbers 5, 10, 15, 25, and 50. Given the bare request, the model produced empty corporate buzzwords about milestones and future impact. When he supplied the actual context - the 5th edition of the summit, 10 years at the company, his daughter’s 15th birthday, 25 years of marriage, and turning 50 -, the output became direct and humorous. The model was identical. The difference was solely the context provided in the input.

Luis Fausto presented market research from Gartner and McKinsey on adoption: roughly 77% of companies remain trapped in early pilots and proofs of concept, while only 23% have managed to deploy agentic systems into actual production.

The reason for this bottleneck is operational. For an agent to run in actual production, it requires an accountable owner, explicit Service Level Agreements (SLAs), and a dependable rollback mechanism to recover from errors.

Orbit: three weeks, PR/FAQ, and SDD

Jean Roloff detailed the development of Orbit, Starian’s agent platform, built during an intensive three-week sprint.

Before writing code, the team applied Amazon’s Working Backwards approach: they wrote the launch press release and internal FAQs (PR/FAQ) as if the product were already finished. The goal was to align customer needs and expected business outcomes before opening the editor.

Jean Muller Roloff (Starian) detailing the Working Backwards approach and PR/FAQ in Orbit.

For development with agents, the team enforced Specification-Driven Development (SDD). Instead of open-ended prompts, they defined data contracts, interfaces, and unit tests before prompting the AI to generate code. The project totaled over 200,000 lines of code with automated test coverage exceeding 90%.

The team also avoided attempting to deploy all fifteen microservices from the planned architecture at once. They isolated a single vertical slice within the Contato Seguro product, focusing purely on report triage, deployed that piece to production to gather live data, and only then expanded to other modules.

Softflow: 220 engineers and four manual gates

At Softplan, the challenge was not a lack of AI adoption, but the uncontrolled spread of custom scripts and prompts across more than 220 engineers, making collaborative codebase maintenance difficult.

Pedro Escobar introduced Softflow, a framework based on the Orchestrator-Workers pattern with eleven distinct stages. The core of the pipeline is its mandatory checkpoints (gates), where execution pauses until a developer validates what was generated.

Pedro Escobar (Softplan) presenting contextual subagent specialization starting from code review.

The pipeline organizes validation across four primary stages:

1. Gate 1 (Specification): The agent reads the work item and writes the formal technical specification (SDD). No code is written before this specification is approved.
2. Gate 2 (Review Findings): Dedicated subagents scan the diff for security flaws, performance regressions, and architectural inconsistencies. The developer reviews each finding and decides what to fix or dismiss.
3. Gate 3 (Merge Request): The agent creates the branch and runs the test suite, but merging into the main repository remains a manual approval.
4. Gate 4 (Closure): A human verifies whether the business demand was actually resolved before closing the work item.

In the live demo, Escobar showed a bug fix in a legacy integration with IBM Jazz RTC, where the API returned empty owner fields. The agent used MCP protocol calls to inspect work items and implemented the patch. Before opening the MR, a review subagent flagged that a logging line lacked an associated unit test. The adjustment was made on the spot, and the merge proceeded with all tests passing.

1Doc: public services on WhatsApp and operational controls

The presentation by Rafael Gomides and Amanda Aragão addressed municipal service delivery via WhatsApp through 1Doc (cases LIA in Limeira and TIA in Florianópolis).

Placing public services on WhatsApp takes advantage of the application’s ubiquity, but introduces concrete architectural constraints:

Rafael Gomides (1Doc) explaining the read-contract architecture connecting AI to legacy backends.

In casual chat, people send fragmented messages, voice notes, and change subjects, which does not map cleanly to administrative workflows. The solution involved embedding structured forms within the conversation and programming the agent to route complex edge cases directly to in-person service desks.

Another factor is security: a phone number does not constitute legal identity. For issuing official certificates or reviewing tax debts, 1Doc decoupled authentication: the citizen clicks a temporary link to log into the official web platform, preventing passwords or personal data from circulating in chat history.

Additionally, municipal case creation does not depend on the uptime of a third-party messaging app. Records are saved transactionally to the central database before any notification is dispatched to the user.

For budget and risk control, municipal administrators have toggles to disable specific services on demand, paired with automated alerts at 50%, 70%, 90%, and 100% of contracted quota. If the cap is reached, AI processing shuts down cleanly and requests return to standard support queues.

MCP Server: connecting AI to databases without write permissions

Diogo Noschang addressed how to allow AI models to query enterprise databases without exposing sensitive records or risking accidental mutations.

Legacy databases carry decades of implicit rules and abbreviated table names that language models misinterpret when exposed to raw schemas.

At Starian, the decision was to place a Model Context Protocol (MCP) server written in Python between the model and company databases:

Security operates across two distinct tiers:

1. Logical tier (MCP Server): The Python microservice sanitizes incoming parameters, blocks SQL injection attempts, and rejects overly broad queries (such as prompts trying to dump entire tables without filters).
2. Physical tier (Database): The database connection user utilized by the MCP server is strictly limited to SELECT. There are no INSERT, UPDATE, or DELETE grants, preventing data mutations even in the event of model errors.

The server also manages context on demand: rather than loading entire database schemas on every prompt, the MCP layer provides only the specific tools needed to answer that particular metric. Inside the Starian Performance 360 framework at Projuris Empresa, the setup unified queries across Jira, SonarQube, GitLab, and Windsurf, logging a 27.3% increase in qualified delivery throughput and a 17.6% rework rate.

Red Bull Racing: OCI simulations

Lucas Leung’s presentation covered high-performance cloud computing used by Oracle RedBull Racing in Formula 1.

During race weekends, the team provisions Kubernetes clusters running more than 500 ARM CPUs on Oracle Cloud Infrastructure (OCI). When a yellow flag or safety car alters race conditions, the system runs peaks of one million Monte Carlo simulations per second, evaluating roughly six million scenarios to determine pit stop viability.

This setup backed Max Verstappen’s drive at the Miami GP, where he started from ninth on hard tires, stretched his initial stint in clean air, switched to mediums late in the race, and took the victory. The pit wall call was guided directly by these real-time probability simulations.

Lovable and Vibe Coding: rapid prototypes vs. legacy systems

Alexandre Messina discussed the growth of Lovable and the Vibe Coding approach, illustrating the generation of functional interfaces from natural language prompts.

Among the examples shared was Amosview at Amicci, a sample management tool built in two days by an operations specialist to solve an internal bottleneck without submitting tickets to central IT. For validating product concepts, creating proofs of concept, or assembling simple departmental tools, the speed of this workflow is evident.

Alexandre Messina (Lovable) presenting prototype acceleration with Vibe Coding.

The practical boundary appears when a prototype must turn into software maintained at enterprise scale. A prompt-generated interface handles initial interaction, but it does not resolve legacy databases carrying a decade of implicit business rules, asynchronous queues, auditing, or strict session control. In Lovable you can spin up a SaaS with Supabase and Stripe in an afternoon, while in scenarios like Softplan and 1Doc, the daily engineering challenge is making automation live alongside legacy systems where data corruption risks legal and tax compliance.

What remains

Generating code has become the fast and cheap part of the process. The work that continues to demand time is what it has always been: understanding business rules, drafting technical contracts before implementing, and writing tests that catch regressions.

I left the summit determined to study the MCP protocol in depth and write better specifications before asking for code. The rest is just talk.