---
title: "The Return to Performance-Optimized Software"
description: "As AI makes code cheaper to generate, developers are reconsidering the cost of running, verifying, and maintaining it. From Rust rewrites and memory safety to lightweight AI agents and local-first applications, this essay explores why software efficiency may be becoming a competitive advantage again."
canonical: "https://amananu.me/writing/the-return-to-performance-optimized-software"
last_updated: "2026-10-17"
---

# The Return to Performance-Optimized Software

As AI makes code cheaper to generate, developers are reconsidering the cost of running, verifying, and maintaining it. From Rust rewrites and memory safety to lightweight AI agents and local-first applications, this essay explores why software efficiency may be becoming a competitive advantage again.

An engineering essay about Rust rewrites, AI-assisted coding, memory safety, verification, and resource-efficient software. · 12 min read · 1792269468092

Some of the software we are rebuilding today has been working perfectly well for years. Its users know it. Its developers understand its quirks. Its edge cases have been explored, and its place in the ecosystem is established. Yet developers are building alternatives in Rust, rethinking database engines, rewriting command-line utilities, and questioning implementation choices that once seemed settled. The interesting question is not simply why they think they can make these tools faster. It is why the trade-offs are becoming attractive again.

For years, software development has rewarded the ability to ship. Better abstractions, managed runtimes, extensive libraries, and powerful frameworks made it possible to build increasingly sophisticated products without managing every detail of the machine underneath. Hardware became more capable, development cycles accelerated, and many costs that once demanded careful attention became easier to absorb.

But the cost of an abstraction does not disappear because hardware gets faster. It moves somewhere else: into memory consumption, startup time, latency, background processes, infrastructure bills, or maintenance complexity. For many applications, those costs are entirely reasonable. For others, they are beginning to look like opportunities.

## When working is no longer good enough

Consider a database engine, a command-line utility, or a developer tool that has been around for years. Replacing it is not trivial. Mature software accumulates compatibility guarantees, obscure edge cases, and practical knowledge that rarely appears in a clean implementation. A rewrite has to earn its existence against all that history.

Projects such as Turso's Rust-based, SQLite-compatible database engine, uutils, and gitoxide make this tension worth examining. They represent different efforts and goals, but they share an important characteristic: established software behavior is being approached through alternative implementations, often with different safety, architectural, or performance priorities.

These projects are not proof that rewriting software automatically improves it. A new implementation can be faster on one workload and slower on another. It can have a cleaner architecture while lacking years of compatibility testing. It can remove one class of bug and introduce another. The language alone cannot settle those questions.

What makes the movement interesting is the willingness to revisit decisions that were previously accepted as the price of building software. A rewrite creates an opportunity to reconsider not only the implementation language but also the architecture, concurrency model, data structures, interfaces, and assumptions inherited from an earlier generation of computing.

## Rust offers more than speed

Rust's appeal is often compressed into a familiar claim: it is fast and memory-safe. Both properties matter, but the combination is more interesting than either slogan suggests. Rust provides native compilation and substantial control over memory and resource usage, while its ownership system, borrowing rules, and type system allow the compiler to reject many invalid programs before they execute.

In ordinary safe Rust code, developers can avoid many memory-management errors without relying on a garbage collector. The compiler checks how references are used and enforces constraints around ownership and borrowing. Its concurrency guarantees also help prevent data races in safe shared-memory code.

These guarantees do not make software correct by default. Rust cannot establish that an algorithm implements the right business rule, that an API behaves as intended, or that a program is free of every security vulnerability. Unsafe code requires additional care, and a program can pass compilation while producing the wrong answer.

The real advantage is more specific: certain mistakes become harder to express, and some classes of failure can be prevented before runtime. That can matter in databases, infrastructure, developer tooling, and services that run continuously. It can also make development more demanding. Ownership and lifetime rules take time to learn, compilation can slow iteration, and a poorly designed Rust application can still be inefficient.

The language is not the optimization. It is a set of tools and constraints that may help developers build a particular kind of system. Whether those benefits justify the cost depends on the problem.

## Then AI changes the equation

AI coding tools introduce another variable into this discussion. Models can generate functions, modify unfamiliar codebases, translate between APIs, and attempt repairs after tests fail. They make some implementation work cheaper, sometimes dramatically so. But producing code and establishing that the code is correct remain different problems.

A generated implementation can look convincing and still contain a subtle error. It can compile while violating an unstated requirement. It can pass a small test suite while failing under concurrency or unexpected input. The speed of generation does not automatically reduce the work required to establish correctness.

Imagine an agent generating code, invoking the compiler, reading diagnostics, revising the implementation, and running tests before attempting another change. The compiler is not relying on the model to notice every mistake in its own output. It provides an independent mechanism for checking specific properties of the generated program.

That feedback loop is useful beyond Rust, and it is not a guarantee of correctness. Compilers, type checkers, static analyzers, and test suites already serve as feedback mechanisms in many languages. Rust's particular contribution is that its ownership model and type system make certain memory-safety and concurrency constraints part of the ordinary compilation process.

An AI agent can repair a borrow-checker error and still implement the wrong algorithm. It can produce code that compiles but mishandles permissions. It can pass unit tests while failing in production. Verification must extend beyond compilation to include tests, runtime checks, security review, and a clear understanding of what the software is supposed to do.

There is also a cost on the other side. Rust's constraints can make code generation harder, particularly when an agent has to reason about lifetimes, ownership, and complex type relationships. Repeated compilation and repair take time and compute. Whether Rust produces better outcomes for AI-assisted development is an empirical question, not something that follows automatically from its safety guarantees.

> As code becomes cheaper to generate, the ability to verify it may become more valuable.
> — The central question

This is the connection worth investigating. AI may lower the cost of producing alternative implementations while increasing the amount of generated code that needs to be checked, integrated, and maintained. Strong feedback mechanisms become more important when output is abundant. A language that prevents certain mistakes can help, but the larger principle is that generation needs verification.

## Efficiency was never just a language choice

It would be easy to turn this into an argument for rewriting everything in Rust. That would miss the more important point. Software efficiency is a property of the entire system, not a label attached to its programming language.

A badly chosen algorithm can overwhelm the benefits of a native implementation. Repeatedly fetching the same data can cost more than an inefficient local operation. An application that launches unnecessary background processes may consume more resources than its core functionality requires. An AI workflow that repeatedly sends the same context to a remote model may waste more time and money than any optimization to its orchestration language could recover.

The same principle applies to storage, compression, caching, network traffic, data movement, and inference. A better data representation can eliminate work rather than merely execute the same work faster. A local-first architecture can reduce network dependencies. Quantization can reduce the memory required by a model. Incremental computation can avoid repeating operations whose inputs have not changed.

These techniques have different trade-offs, but they share an underlying question: what work is the system doing, and does it need to do all of it? Sometimes the answer is a more efficient algorithm. Sometimes it is a better cache, a different storage format, or a native component. Sometimes it is removing an unnecessary layer entirely.

This is why performance optimization should begin with measurement rather than a language preference. Startup time, memory consumption, throughput, latency, binary size, and operating cost are distinct dimensions. Improving one can leave another unchanged or even make it worse. The relevant benchmark is the workload the software is actually expected to handle.

## The pressure to do more with less

AI makes this discussion more urgent without making it entirely new. Inference consumes compute and memory. Agents may remain active for long periods, invoke tools, manage state, and coordinate external services. Applications that seemed inexpensive at prototype scale can become costly when used continuously or by many people.

At the same time, AI-assisted development makes it easier to experiment with alternative implementations. A coding agent may help explore a codebase, generate tests, translate components, or attempt a migration. But a cheaper first draft does not make a rewrite cheap to complete. Compatibility, correctness, security, and long-term maintenance still require work.

The two developments create an interesting possibility. More software can be produced, and more software may run continuously, while the cost of operating every component remains real. The ability to generate another service or agent does not mean its memory usage, latency, failure modes, or infrastructure costs stop mattering.

It would be premature to claim that AI demand is the direct cause of the current Rust rewrite movement. Rust has a much longer history, and performance-oriented systems engineering never disappeared. The stronger argument is that AI workloads and AI-assisted development make the old questions about resource consumption and verification newly consequential in more contexts.

## Two unfinished projects, one recurring question

These questions also appear in my own experiments with software. I have explored Doxy, an unfinished author-driven novel-writing and story-intelligence workspace, and Flow Bot, an unfinished attempt to build a lightweight alternative to OpenClaw. Neither project should be presented as a completed product or as evidence of measured performance improvements. Their value here is in the engineering questions they raise.

Doxy is planned around Tauri 2, React, TypeScript, and SQLite, with ideas involving local data processing, AI workflows, story consistency, and document management. A desktop application built this way raises a practical question: which work belongs in the web-based interface, which operations need native capabilities, and which features should run locally? There is no automatic benefit in moving everything into a systems language. The useful task is to identify where the architecture creates measurable overhead and where a different implementation would genuinely help.

Flow Bot was intended as a lightweight OpenClaw alternative, but only its core service was implemented; the broader project was not completed. Even at that stage, the idea raises questions about how much infrastructure an agent needs, what must remain active, how tools should be executed, and how permissions and state should be managed. A small core service is not the same thing as a complete, dependable agent platform.

Neither project proves that Rust is the right choice. They are useful reminders that architecture decisions begin with constraints. A local writing application and an autonomous agent have different workloads, different failure modes, and different reasons to optimize. If Rust were considered for either, the decision would need to be based on the components involved, the guarantees required, and the cost of maintaining the resulting system.

That is the practical meaning of performance-conscious engineering: not choosing the most technically impressive stack, but understanding what the software needs to accomplish and avoiding complexity that does not serve that purpose.

## The price of rewriting

Rewrites are attractive partly because a new implementation begins with the freedom to correct old assumptions. They are dangerous for the same reason. Mature software has accumulated behavior that its creators may no longer remember, dependencies that users take for granted, and edge cases that only emerge under unusual conditions.

A rewrite can improve memory safety while breaking compatibility. It can improve a benchmark while making ordinary workloads slower. It can simplify the internal architecture while increasing the maintenance burden for a small team. And it can consume months of engineering time that might have produced more value through targeted optimization of the existing implementation.

The same caution applies to AI-generated rewrites. A model may translate code quickly, but translation is not proof of semantic equivalence. Tests must cover expected behavior, compatibility must be checked, and benchmarks must represent real use. The ability to generate a replacement changes the cost of experimentation; it does not remove the cost of proving that the replacement deserves to exist.

Sometimes a rewrite is justified by security, portability, architecture, or a clear performance bottleneck. Sometimes a smaller change is the better engineering decision. Sometimes the correct answer is to leave a mature component alone. Knowing which case applies requires evidence, not enthusiasm for a language.

## What should we optimize for now?

The return to performance-oriented software should not be interpreted as a rejection of abstraction or high-level languages. Those tools made software development more productive and remain essential. Nor should it be treated as a contest in which Rust must replace every other language.

A more useful direction is selective optimization. Keep the abstractions that make a system easier to build and maintain. Use native components where they solve a demonstrated problem. Choose architectures that avoid unnecessary work. Measure the costs that matter. Build verification into the development process, especially when AI is generating more of the implementation.

In this view, performance is not an isolated benchmark result. It is one part of a broader engineering responsibility that includes reliability, safety, maintainability, responsiveness, and operating cost. The best implementation is not necessarily the one with the lowest memory usage or the fastest execution time. It is the one that meets its requirements without imposing unnecessary costs or complexity.

Perhaps that is what makes the current moment interesting. We are gaining tools that can generate software faster than before, while rediscovering that generating software is only one part of building it. The system still has to run, remain correct, handle failure, and justify the resources it consumes.

If AI makes producing code abundant, the scarce skill may not be the ability to produce another implementation. It may be knowing what should be built, what can be verified, what needs to be optimized, and what should not be rewritten at all.