AI has changed the way software gets written.
A lot of teams are now using AI to generate first drafts of features, explore unfamiliar frameworks, scaffold systems, write tests, refactor code, and move faster through the boring parts of implementation. Some people call this “vibe coding.” The phrase is a little unserious, but the underlying shift is real: developers are increasingly steering, reviewing, correcting, and integrating code instead of typing every line by hand.
That creates a new question for engineering teams:
What languages and platforms work best when AI is part of the development process?
The answer is not just about which language an AI model can write most easily. The better question is which language helps generated code stay understandable after it lands. Agentic development works best when the system itself encourages clear boundaries, explicit contracts, narrow interfaces, and code that can be reviewed without reconstructing a pile of hidden assumptions.
For us, Rust has been one of the strongest answers so far.
Promising Results
At Dioko, we have been using Rust across native app development, cross-platform app development, and backend development. We did not come into this as long-time Rust experts. We had strong engineering fundamentals, but not a deep production Rust background. We have been learning it by building with it, reading, testing, refactoring, and using AI as a development accelerator.
So far, the results have been extremely encouraging.
Rust has given us a rare combination: high performance, strong correctness guarantees, great portability, a modern package ecosystem, and a type system that makes AI-generated code much easier to validate, constrain, and improve.
More importantly, Rust pushes both humans and AI agents toward stronger architectural boundaries. That may be the single most important thing for keeping agentic code manageable, readable, and clean.
Rust gives AI a better surface area to work with
One of the biggest problems with AI-generated code is not whether it can produce something plausible. It usually can.
The harder problem is knowing whether the generated code is actually right.
In dynamic languages, a lot of mistakes hide until runtime. Wrong shapes, missing fields, bad assumptions, nil errors, invalid states, forgotten edge cases, and weak boundaries can all survive the first generation pass. You may not find them until a test hits the exact case, or worse, until production does.
Rust changes that dynamic.
Rust’s type system, ownership model, exhaustive pattern matching, and compiler checks create a much tighter feedback loop. AI can generate code, but the compiler immediately acts as a rigorous reviewer. It does not care that the code looks reasonable. It cares whether lifetimes, ownership, borrowing, types, traits, match arms, and error handling are actually coherent.
That matters enormously when working with AI.
The compiler becomes part of the development workflow in a stronger way. You can ask AI to write or refactor something, run the compiler, feed the errors back into the loop, and converge toward code that is not merely syntactically valid, but structurally aligned with the program.
This does not replace human understanding. It raises the quality floor.
Rust makes boundaries harder to ignore
The most important thing Rust gives an AI-assisted workflow may not be speed, memory safety, or even compiler feedback in isolation.
It may be boundaries.
AI-generated code has a tendency to sprawl when the surrounding system lets it. Responsibilities blur. Data gets passed around too loosely. Optional states leak into places that should not know about them. Shared mutable state appears because it was the easiest path to a plausible answer. Interfaces grow wider than they need to be.
Rust fights that drift at the language level.
Ownership forces you to decide where data lives. Borrowing forces you to decide how access works. Traits force you to name capabilities. Enums force you to model states explicitly. Modules, visibility rules, and type boundaries make it harder to smear responsibility across the codebase without being noticed.
That does not mean Rust automatically produces good architecture. It means the path of least resistance is often closer to good architecture than it would be in a looser environment. The developer still has to make design decisions, but Rust keeps pulling those decisions into the open.
That is extremely valuable when agents are writing or modifying code. The system gives the agent less room to quietly improvise around unclear ownership, unclear state, and unclear module edges. Generated code has to fit through the boundaries that already exist, or the mismatch becomes visible quickly.
Strong types are self-documenting architecture
Rust’s type system is not just about catching bugs. It also makes code easier to reason about.
A well-modeled Rust system tells you a lot just by looking at the types. What is optional? What can fail? What state transitions are allowed? What data owns what? What can be shared across threads? What can cross an API boundary? What is impossible by construction?
That is valuable for humans. It is also valuable for AI.
When the codebase has strong types, clear enums, explicit error types, trait boundaries, and narrow data models, AI has more context embedded directly in the code. The code becomes less dependent on tribal knowledge, comments, or external documentation. The shape of the program carries more of its own meaning.
For an agency, that is a big deal.
We often need to move across projects quickly. We need to understand a system, extend it safely, and avoid creating fragile code that only works because one developer remembers every implicit assumption. Rust rewards making assumptions explicit. That makes it easier for both humans and AI agents to work inside the system without accidentally violating its invariants.
Runtime guarantees matter more when generation gets faster
AI lets teams produce code faster. That is useful, but it also increases the risk of producing more broken code faster.
This is where Rust’s runtime model is especially appealing.
Rust gives you memory safety without a garbage collector. It gives you strong concurrency guarantees. It makes many categories of bugs harder or impossible to express. It forces you to deal with failure paths instead of casually ignoring them. It makes shared mutable state something you have to justify, not something you accidentally create.
These are not academic benefits.
They matter when building native applications. They matter when building cross-platform libraries. They matter when building backends where performance, latency, resource usage, and reliability are all part of the product experience.
When AI is generating or modifying code, runtime guarantees become even more important. The faster the implementation loop gets, the more you want the language and compiler to constrain the possible damage.
Rust does that unusually well.
Rust is fast enough to change product decisions
Performance is not always the bottleneck. Plenty of products do not need maximum speed.
But performance still changes what you can comfortably build.
Rust is fast. Not “fast enough if you scale horizontally and cache aggressively.” Actually fast. It is suitable for native code, CLIs, servers, media processing, file processing, sync engines, local-first applications, embedded-adjacent work, and performance-sensitive backend systems.
That creates optionality.
You can write a core engine once and expose it to multiple platforms. You can move work client-side without dragging in a heavy runtime. You can build local-first features that feel instant. You can process data efficiently without defaulting to a large cloud bill. You can deploy small binaries with predictable resource usage.
For our work, this has been one of the most exciting parts.
Rust is not just a backend language. It can be the core of a product architecture. You can use it for native app internals, shared cross-platform business logic, backend services, workers, tools, and performance-critical modules. That flexibility is exactly the kind of leverage small senior teams need.
The ecosystem is mature enough now
A few years ago, the knock on Rust was that it was powerful but inconvenient. Great language, rough ecosystem.
That critique is less true now.
Rust now has a solid ecosystem for web services, command-line tools, serialization, async runtimes, database access, native integrations, cross-platform application logic, testing, observability, and deployment. Not every part of the ecosystem is as mature as the equivalent JavaScript, Python, Java, or Go world, but the foundation is strong enough for real production work.
You can build serious systems with Rust today.
The tooling is also refreshingly direct. Cargo is excellent. Dependency management is straightforward. Formatting and linting are standardized. Builds are reproducible enough to feel sane. Deployment can be as simple as shipping a binary or containerizing a small service.
There is less ceremony than many people expect.
That simplicity pairs well with AI-assisted development. The fewer custom build steps, hidden framework conventions, and fragile runtime assumptions a stack has, the easier it is to keep AI-generated work grounded.
Rust works well for cross-platform development
One of the more interesting uses of Rust is as a shared core across platforms.
Instead of rewriting the same logic for iOS, Android, desktop, and backend environments, Rust can often sit underneath the platform-specific UI layer. The UI can remain native or framework-specific, while Rust handles the logic that benefits from correctness, portability, and performance.
That can include things like:
- Local data models
- Sync engines
- File processing
- Licensing systems
- State machines
- Audio or media processing
- Cryptographic workflows
- Business logic shared across clients and servers
- Offline-first application logic
This is especially useful when building native or semi-native applications where the UI needs to feel platform-appropriate, but the core logic should be consistent everywhere.
AI makes this approach more accessible. It can help generate FFI bindings, scaffold platform interfaces, explain compiler errors, and translate architectural intent into Rust modules. But Rust keeps the boundaries strict enough that the generated code has to earn its way into the system.
Rust is not a substitute for understanding the code
This is the part that matters most.
We do not think the future of software is developers blindly accepting generated code.
That might work for prototypes. It might work for throwaway internal tools. It might even work for early experiments where the cost of being wrong is low. But for real products, someone still needs to understand the system.
AI can generate code. It can explain code. It can refactor code. It can propose architectures. It can write tests. But it does not own the consequences.
The engineering team does.
That is why Rust has been such a good fit for us. It supports an AI-accelerated workflow without encouraging a careless one. It lets us move faster while still forcing us to confront the structure of the program. If a boundary is unclear, Rust makes us sharpen it. If something is wrong, the compiler often tells us. If a state is invalid, we can model it out of existence. If an error can happen, the code has to decide what to do with it.
Rust does not remove the need for discipline. It rewards discipline.
The learning curve is real, but manageable
Rust has a reputation for being difficult. That reputation is not completely unfair.
The ownership model takes time. Lifetimes can be confusing. Async Rust has sharp edges. Some libraries are less mature than their equivalents in older ecosystems. You will occasionally fight the compiler, especially early on.
But our experience has been that the learning curve is more acceptable now than it used to be, especially with AI assistance.
AI is very useful for explaining compiler errors, suggesting more idiomatic patterns, comparing design options, and helping translate a concept from another language into Rust. The key is not to accept everything it writes. The key is to use it as an interactive tutor and implementation partner.
That has made Rust feel much more approachable.
We are still learning. We are still self-educating. We are still developing taste around what belongs in Rust, what should stay in a higher-level language, and where the complexity tradeoff is worth it.
But the direction is clear: Rust is giving us capabilities we want more of.
More teams should consider Rust
Rust is not the right tool for every project.
If you are building a simple CRUD app, a marketing site, or an admin dashboard, Rust may not be the highest-leverage choice. If your team is already extremely productive in another stack and performance or correctness constraints are modest, switching languages for trend reasons would be a mistake.
But for many modern products, Rust deserves more serious consideration.
Especially when the product involves native functionality, cross-platform logic, performance-sensitive systems, local-first architecture, reliability-critical workflows, or long-term maintainability, Rust can be an excellent foundation.
And in the AI-assisted development era, its advantages become even more relevant.
The type system documents intent. The compiler catches structural mistakes. The ownership model pushes stronger boundaries. The runtime model eliminates entire classes of bugs. The performance profile opens up product options. The deployment model stays relatively simple. The ecosystem is now broad enough for real work.
That combination is rare.
For us, Rust has become one of the most exciting tools in the current software landscape. Not because it lets us stop thinking, but because it helps us think more clearly. Not because AI can magically write perfect Rust, but because Rust gives AI-generated code a much stricter and better-bounded environment to operate within.
That is exactly what we want from a modern engineering stack.
Fast iteration is good. Fast iteration with guardrails is much better.
Rust gives us both.