Technology executives shouldn't give up control | Kimchi Blog

← All postsPerspectiveAugust 3, 2026·11 min read<br>By Leon Kuperman, Founder of Cast AI<br>Technology executives shouldn't give up control<br>AI coding is becoming the software factory. Enterprises need to own the enforcement path, the economics, and the definition of done.<br>In July 2026, security researchers reported that Grok Build had been uploading entire code repositories to SpaceXAI-controlled cloud storage. The uploads reportedly included files the tool had not been asked to inspect, repository history, and potentially sensitive credentials. A privacy command existed, but researchers found that it governed retention rather than the network path that allowed repository uploads.<br>The incident will be fixed. The affected product will change. Other vendors will point to their privacy policies and explain why their systems behave differently. We are missing the larger issue however.<br>A zero-data-retention policy is still a policy. A privacy setting is still a setting. Both depend on software behaving exactly as intended across every code path, feature release, operational process, and future architectural decision. Policies can be violated by bugs, misconfigurations, undocumented behavior, internal tools, or deliberate backdoors. The only durable way to prevent data from crossing a boundary is to enforce that boundary at the infrastructure level.<br>Privacy by policy asks the enterprise to trust. Privacy by architecture removes the need.<br>The Experimentation Era is Ending<br>Over the past year, learning to code with AI has been an intensely personal experience. Every engineer has developed a different way of working. Some use one coding assistant. Others combine several tools. Some delegate entire features. Others use models as more capable autocomplete. The most advanced users have assembled their own prompts, skills, agents, model preferences, review loops, and mental models.<br>That experimentation was necessary. AI coding represents the largest change in the mechanics of software engineering in decades. The industry could not have standardized its practices before engineers understood what these systems were capable of. We are now, however, approaching the next stage of adoption.<br>The time for learning is not over but the time for every engineer independently inventing an operating model should be.<br>When I talk to CIOs and CTOs, many are overwhelmed by the number of choices. Should they provide Claude Code, Codex, Cursor, or several tools? Should engineers be allowed to experiment freely? Which models are permitted? What data can leave the company? How should usage be budgeted? How should generated code be verified? Who is responsible when an agent runs for hours and produces the wrong result?<br>These are no longer individual productivity questions rather they are questions about how an engineering organization operates. AI coding is crossing from early adoption into the messy middle before mainstream use. The early adopters have generated enough evidence for us to see both the opportunity and the recurring failure modes.<br>We failed on cost governance.<br>We failed on intellectual-property protection.<br>We failed on data sovereignty.<br>We have allowed token consumption to grow much faster than our ability to measure verified delivery.<br>The next phase requires systems, governance, and repeatable engineering practices. These are all required to get to adoption at scale.<br>Stop treating one model like an engineering organization<br>Most discussion about AI coding still revolves around model selection. Which model writes the best code? Which one reasons most effectively? Which one leads a benchmark this week?<br>Model quality matters, but the quality framing is becoming less useful.<br>You would not hire a senior architect and ask that person to plan every feature, write every implementation, generate every test, perform every security review, and approve every deployment. It would be economically irrational, operationally fragile, and unlikely to produce the best result.<br>The same applies to models.<br>A planning task may require a highly capable reasoning model. A narrow implementation task may not. Test generation, documentation, code review, failure analysis, and adversarial verification may each be better served by different models, tools, or evaluation techniques.<br>The objective is not to avoid frontier models. The objective is to use them where their marginal capability justifies their marginal cost.<br>Recent open-weight models have become capable enough that I now use expensive frontier models far less frequently in my own coding workflow than I did even a month ago. That is a time-bound observation, and the specific models will change. The structural point is more durable: as baseline model capability improves, a growing share of system value moves into the harness.<br>The harness determines how work is planned, how context is assembled, which model handles each stage, when the system...