Proud Tech Summit 2026: Code Generation Is Cheap, So Why Is Knowledge Expensive?

Proud Tech Summit 2026, co-hosted by Starian and Softplan, packed eight hours of agenda that steered clear of the AI chat demos flooding the internet and instead pointed the lens at legacy relational databases, fragile integrations, budget constraints, and the foundational work required to make models genuinely serve customers. According to livestream coverage compiled by attendees, the event's core thesis can be distilled into a single sentence: generating code has become fast and cheap, while understanding business rules, writing technical contracts, and designing regression tests remain expensive human labor.

Tools Are Accelerating, Understanding Is Not

Starian's Carla Souza opened by pointing out a glaring mismatch: tooling iteration speed has surged, but the time needed to fully grasp business logic and validate systems remains stubbornly human time. Softplan's Guilherme Brasil made this point vividly with a controlled experiment—given the same LLM model, he first asked it to write a 32-word opening line containing the numbers 5, 10, 15, 25, and 50. The model spat out hollow platitudes about milestones and future impact. When he supplied real context (the summit's fifth edition, the company's tenth anniversary, his daughter's fifteenth birthday, twenty-five years of marriage, his own fiftieth birthday), the output immediately became direct and humorous. The model didn't change—only the context carried in the input did.

Luis Fausto cited Gartner and McKinsey market research that quantified this: roughly 77% of enterprises remain stuck in early pilots and proof-of-concept stages, with only 23% actually deploying agentic systems into production. The bottleneck isn't model capability but operational conditions—for an agent to run in production, it needs a clearly accountable owner, explicit service level agreements (SLAs), and reliable rollback mechanisms that can recover from errors.

Orbit's Three-Week Sprint: Write the Press Release First, Then the Code

Jean Roloff described the development of Starian's agent platform Orbit, completed in an intense three-week sprint. Before writing a single line of code, the team applied Amazon's Working Backwards method: assume the product has already launched, write the press release and internal FAQ (PR/FAQ) first to align customer needs with expected business outcomes, and only then open the editor.

The development phase enforced Spec-Driven Development (SDD). Rather than writing open-ended prompts, the team first defined data contracts, interfaces, and unit tests, then let AI generate code. The final project accumulated over 200,000 lines of code with over 90% automated test coverage. Another key decision was restraint: they didn't try to launch all fifteen microservices planned in the architecture at once. Instead, they carved out a vertical slice in the Contato Seguro product responsible only for whistleblower triage, deployed it to production to collect real data, and then expanded to other modules.

Working Backwards is a new-product definition method widely used inside Amazon: rather than starting from a feature list, you assume the product has already launched successfully and write a customer-facing press release plus a companion internal FAQ, answering questions like "who is the customer, what's the pain point, why should anyone be excited." Only once this narrative can be written clearly does the team move into technical design. Its value lies in pulling the discussion from "what can we build" back to "what does the customer need," and in exposing requirement ambiguities before the first line of code is written. The Orbit team used it to align customer needs with business outcomes, extending this methodology from consumer products into the context of agent platform development.

Spec-Driven Development (SDD) means defining data contracts, interface signatures, and expected tests in a machine-readable, structured form before letting AI generate code, then feeding these specs to the model as input constraints. The key difference from open-ended prompting is that the spec itself is a verifiable artifact—generated results must satisfy the declared interfaces and tests, rather than a human repeatedly reading prose-style prompts to judge. The benefit is that the generation process becomes auditable and reproducible, and when failures occur you can pinpoint whether it's a spec defect or an implementation deviation, instead of assigning blame within uncontrollable natural language input.

Vertical Slice is a slicing strategy in agile delivery: rather than advancing horizontally by architecture layer (database, service, frontend), you cut a thin strip vertically along one complete business flow, wiring everything from entry UI to data persistence and deploying it to production. Orbit launched only the whistleblower triage path instead of rolling out fifteen microservices simultaneously, precisely to obtain real traffic and real failures as early as possible, calibrating subsequent design with production data and avoiding the accumulation of assumptions in isolated environments.

Softflow: 220 Engineers and Four Human Gates

Softplan's problem wasn't insufficient AI adoption but the chaotic proliferation of custom scripts and prompts across 220+ engineers, making the codebase difficult to maintain collaboratively. Pedro Escobar's Softflow framework is based on the Orchestrator-Workers pattern, spans eleven stages, and centers on four mandatory checkpoints—execution pauses until a developer confirms the generated result.

Gate	Agent Automated Actions	Human Verification
Gate 1	Read work item and write formal technical spec (SDD)	No code written until spec is approved
Gate 2	Sub-agents scan diff for security, performance, and architecture issues	Developer evaluates each item and decides to fix or reject
Gate 3	Create branch and run automated integration tests	Human approval required to merge into main repo
Gate 4	Prepare wrap-up and verify business criteria	Human confirms business requirements are truly resolved

In a live demo, Escobar showed a bug fix for an IBM Jazz RTC legacy integration: the API returned an empty owner field, and the agent used the MCP protocol to check the work item and implement a patch. Before opening the merge request, a review sub-agent flagged a log line missing its corresponding unit test; the team added the adjustment on the spot, and all tests passed and merged. Such details show that the gates aren't formalism—they place human judgment precisely where the cost of error is highest.

Orchestrator-Workers pattern is a classic topology for multi-agent systems: an orchestrator agent handles task decomposition, subtask assignment, result aggregation, and deciding the next step, while multiple worker agents each execute specific actions within constrained responsibilities. Its engineering significance is making complex workflows explicit—the orchestration layer can record state, insert checkpoints, and restrict which tools workers can access, without relying on a single model to remember all constraints across one long conversation. Softflow's eleven stages and four gates essentially move orchestration logic out of the model and into the process layer, so humans can review from fixed positions.

MCP (Model Context Protocol) is an open protocol that lets language models access external tools and data sources in a standardized way, typically consisting of a client side (model) and a server side (data/tools). The server declares its available tool list and parameter structures to the model, which initiates calls through the protocol and receives structured results. Compared to handing database addresses and credentials directly to the model, MCP confines the permission boundary within the server implementation, enabling parameter validation, access auditing, and capability trimming at the protocol layer—the very premise that makes the two-layer security model discussed later viable.

Scoped diff review is an often-underrated engineering practice in AI-assisted development: sub-agents read only the diff of the current change rather than the entire codebase, focusing on security, performance, and architecture risks within a limited context window. Its limitation is that humans must judge which issues were introduced by this change versus pre-existing debt—which is why Softflow keeps "evaluate each item and decide to fix or reject" as a human action: automation handles discovery, humans handle attribution and trade-offs.

1Doc: Engineering Constraints of Bringing Municipal Services into WhatsApp

Rafael Gomides and Amanda Aragão shared the case of 1Doc delivering municipal services via WhatsApp (Limeira's LIA and Florianópolis's TIA). WhatsApp was chosen for its ubiquity, but this brought a set of concrete architectural constraints.

In everyday chat, people send fragmented messages, voice notes, and switch topics at will—which doesn't naturally match administrative workflows. The solution was to embed structured forms in the conversation and have the agent route complex edge cases directly to an offline service desk. On the security side, a phone number doesn't constitute legal identity, so 1Doc decoupled authentication: citizens click a temporary link to log into the official web platform, and passwords and personal data never flow through chat history. Municipal ticket creation also doesn't depend on the availability of a third-party messaging app—records are first written transactionally to the central database, and notifications are sent to users afterward.

Budget and risk controls were also productized: administrators can disable specific services on demand, the system automatically alerts at 50%, 70%, 90%, and 100% of contract quotas, and once the limit is hit, AI processing stops cleanly and requests fall back to the standard human support queue.

MCP Server: Let AI Query the Database but Never Write to It

Diogo Noschang tackled another high-frequency challenge: how to let models query enterprise databases without exposing sensitive records or triggering unintended changes. Legacy databases carry decades of implicit rules and abbreviated table names; exposing raw schemas directly to language models makes misinterpretation almost inevitable.

Starian's approach places a Python-built Model Context Protocol (MCP) server between the model and the company database, with security enforced at two layers. The logic layer handles parameter sanitization, blocks SQL injection, and rejects overly broad queries (such as prompts attempting to dump an entire table without filters); the physical layer's database connection user is strictly limited to SELECT, with no INSERT, UPDATE, or DELETE grants, so even a malfunctioning model cannot alter data. The server also manages context on demand: rather than loading the full schema every time, it provides only the tools needed to answer specific metrics. In the Starian Performance 360 framework for Projuris Empresa, this setup unified queries across Jira, SonarQube, GitLab, and Windsurf, recording a 27.3% improvement in qualified delivery throughput with a 17.6% rework rate.

Oracle Red Bull Racing and Lovable: Two Extreme Speed Samples

Lucas Leung's talk showcased the other end of the compute spectrum. On race weekends, Oracle RedBull Racing spins up Kubernetes clusters running over 500 ARM CPUs on Oracle Cloud Infrastructure (OCI). When yellow flags or safety cars change race conditions, the system executes up to a million Monte Carlo simulations per second at peak, evaluating roughly six million scenarios to determine pit-stop feasibility. This system underpinned Max Verstappen's performance at the Miami Grand Prix: starting ninth, beginning on hard tires, extending the first stint in clean air, switching to mediums later, and winning—pit wall decisions directly guided by these real-time probabilistic simulations.

Alexandre Messina showed the other pole with Lovable and Vibe Coding. Amicci's Amosview is a sample management tool built by a single operations specialist in two days, bypassing the bottleneck of filing tickets with central IT. For validating product concepts, building proofs of concept, and assembling department-level tools, the speed advantage is obvious. But the boundaries are equally clear: prompt-generated interfaces can handle initial interactions but can't solve legacy databases carrying a decade of implicit business rules, async queues, auditing, and strict session control. You can spin up a SaaS with Supabase plus Stripe in an afternoon in Lovable, whereas in Softplan and 1Doc's daily engineering, the hard problem is making automation coexist with legacy systems—where the risk of data corruption directly touches legal and tax compliance.

Monte Carlo simulation in racing strategy works like this: for each remaining segment of the race (laps, tire wear, possible yellow flags or safety cars), you repeatedly sample random events, running thousands to millions of iterations, and tally the distribution of finishing positions for each pit timing. A single simulation gives only one possible world; only massive repetition yields the optimal decision in probabilistic terms. This explains why race weekends require Kubernetes clusters with over 500 ARM CPUs—the compute isn't training models but stabilizing probability distributions within the available decision window (often just tens of seconds).

Vibe Coding refers to a development style where intent is described in natural language and the model directly generates runnable interfaces and logic, emphasizing rapid iteration and low barriers rather than strict specs and test-first practices. Its advantage is compressing the interval from "having an idea" to "seeing something" down to hours, letting business-side people bypass IT ticket processes to validate concepts. But its output typically lacks transaction boundaries, concurrency control, audit trails, and permission models, making it suitable for prototypes, demos, and department-level tools—not for core systems bearing legal and tax compliance requirements. This is precisely why the article presents it in contrast with the engineering practices of Softplan and 1Doc.

What Remains

Cross-referencing the various talks at this summit, the consensus is remarkably stable: code generation has become the fast and cheap link in the chain, and what continues to consume time are the things that have always consumed time—understanding business rules, drafting technical contracts before implementation, and writing tests that catch regressions. The MCP protocol deserves deeper study, and specs should be written before asking for code. The rest is mostly noise.

One-line Summary

Code generation is cheap; understanding business rules, writing contracts, and designing regression tests remain expensive human labor.

Paragraph Summary

Proud Tech Summit 2026 brought together practices from Starian, Softplan, 1Doc, and others, with a core thesis: generating code has become fast and cheap, but understanding business rules, writing technical contracts, and designing regression tests remain expensive human labor. Carla Souza and Guilherme Brasil noted that tooling iteration far outpaces organizational absorption, while Gartner and McKinsey data show about 77% of enterprises remain stuck in pilot stages, with bottlenecks in operational conditions like ownership, SLAs, and rollback mechanisms. Orbit used Working Backwards plus Spec-Driven Development to produce over 200,000 lines of code with over 90% test coverage in three weeks, launching only one vertical slice first; Softflow set up four human gates at a scale of 220 engineers; 1Doc brought municipal services into WhatsApp and decoupled identity authentication; and the MCP Server achieved two-layer security through logic-layer sanitization and physical-layer read-only access. Oracle Red Bull Racing and Lovable represented the two extremes of compute and speed.