The Complexity We Choose | Frazik<br>The current premise of software development is token maximization. More tokens mean more code, more generated output, and more features shipped in less time. The assumption is that if an AI system can produce ten times as much code, we will be ten times as productive.<br>That assumption ignores the bill that arrives later.<br>Code is not valuable because it exists. It is valuable because people can understand it, change it, operate it, and trust it. When code becomes harder to read than the problem it solves, every future change becomes more expensive. The team spends its time reconstructing intent instead of delivering value.<br>We have spent decades treating this complexity as an unavoidable cost of software development. It is not always unavoidable. Often, it is simply the accumulated result of choices nobody had time to revisit.<br>The token ceiling is not the real ceiling<br>Large language models have made the cost of producing code extremely low. A developer can describe a feature and receive a plausible implementation in seconds. An agent can inspect a repository, modify several files, and propose a pull request before a human has finished opening the editor.<br>This is powerful, but it changes the shape of the problem. The scarce resource is no longer only typing. It is comprehension.<br>Generated code still has to be read. Its assumptions have to be checked. Its failure modes have to be understood. Someone has to know whether a change belongs in the domain layer, the adapter layer, or nowhere at all. Someone has to debug it at two in the morning.<br>If we use AI only to generate more code, we are optimizing the cheap part of the work while making the expensive part larger. The repository gets bigger, the dependency graph gets denser, and the number of possible interactions grows. A system can compile and pass a narrow test suite while becoming progressively less intelligible.<br>More tokens are not the same as more understanding.<br>Who owns software written by a model?<br>There is another question hiding beneath the productivity story: ownership.<br>If an AI system writes a company’s internal software, who owns that software? The practical answer is usually determined by employment agreements, vendor contracts, applicable copyright law, and the amount of human authorship involved. A model provider does not automatically become the owner of every program generated by its model.<br>But legal ownership is only one part of the question. A company can own the repository and still lose effective ownership of the system if nobody inside the company can explain it. If the organization cannot safely modify, replace, or operate an internal tool without depending on a particular model or vendor, it has control on paper but not in practice.<br>This is the more important form of ownership: the ability to understand and change what you depend on.<br>Model providers may influence the software indirectly. They control the model, its updates, its availability, its usage terms, and sometimes the surrounding tools that make an agent effective. A team that accepts generated code without preserving its rationale, tests, and architectural boundaries can become dependent on a system it does not own.<br>The answer is not to reject AI. It is to make the output comprehensible and portable. A company should be able to explain its software without referring to the private reasoning of a model. It should be able to change models without rewriting the system. It should own the decisions, the tests, the operational knowledge, and the constraints that make the code safe.<br>Complexity is an AI problem too<br>The most under-discussed opportunity in generative AI is not generating software. It is reducing software complexity.<br>An AI system performs better when it has less irrelevant context to process. A small module with explicit boundaries is easier for a model to reason about than a huge service where business rules, persistence, networking, and formatting are mixed together. Clear names are better prompts than comments that describe accidental behavior. A narrow interface is a better contract than a convention spread across twenty files.<br>Software that reads like a book helps both humans and machines. It has a beginning, a clear sequence of decisions, and an understandable conclusion. Its abstractions earn their existence. Its data flow can be followed without holding the whole repository in working memory.<br>This is not an argument for simplistic software. Complex domains will remain complex. The goal is not to pretend that a difficult business rule is easy. The goal is to keep accidental complexity from obscuring essential complexity.<br>AI can help with this work:<br>identify duplicated logic and conflicting rules;<br>map dependencies and reveal unnecessary coupling;<br>find dead code, obsolete abstractions, and unused configuration;<br>propose smaller modules and safer boundaries;<br>summarize behavior before a refactor;<br>generate characterization tests for legacy...