A different starting point
I built Fleet in Rust without knowing a lick of Rust when I started.
I had a product in mind. I understood the problem I wanted to solve and had a view of how the pieces should fit together. What I didn’t have was years of Rust experience. In the past, that gap would have defined the project: learn the language, get comfortable, then maybe start building the thing I actually wanted to build.
With AI, I could start with the thing itself. I could work through the structure, direct the implementation, and learn what I needed along the way. That experience made a shift I’d been feeling for a while much more concrete: knowing a particular language is losing its place as the gatekeeper to building software.
The abstraction moved
We’ve been moving up layers of abstraction for as long as we’ve been writing software. We use frameworks so we don’t have to rebuild every primitive. We use databases so we can reason about data without implementing storage from scratch. Each layer changes where we spend our attention.
AI is another one of those layers. I can describe a behavior, explain a constraint, or ask for an implementation in a language I haven’t used before. The distance between an idea and working code gets much shorter.
My take is that the era of treating language fluency as the primary measure of a builder is ending. Remembering syntax and knowing every nuance of a framework used to buy a lot of implementation speed. AI changes that equation. The harder question becomes: what are we asking it to build, and why should it be shaped that way?
Fleet made that real for me
Fleet brings Claude Code and Codex into one workspace. You can run work across repositories in separate worktrees, keep the context with the thread, and follow changes through verification and pull request feedback. You still make the merge decision.
Even that short description contains a set of architectural decisions. What belongs to a thread? What belongs to a repository contribution? Which work can happen independently? What needs to wait? When does an agent finishing actually mean the work is ready for a person to review?
Rust syntax doesn’t answer those questions. Product direction, system boundaries, and a clear model of the workflow do. Those were the decisions I needed to bring to the build. AI made it possible to turn those decisions into an implementation without first becoming a Rust specialist.
Take a look at FleetJudgment is the work
When producing code gets easier, it becomes easier to produce the wrong code, too. A feature can work in isolation and still make the product harder to understand. An abstraction can look elegant and still put the boundary in the wrong place. A passing test can tell you a behavior works without telling you whether it’s the behavior anyone needed.
The questions I want to spend more time on are the ones that shape the system: what problem are we actually solving? Where should state live? What happens when a dependency fails? Which decisions will be expensive to reverse? How will someone know what the system is doing?
You need enough understanding to challenge an implementation, recognize a bad assumption, and investigate when reality disagrees with the plan. If I can’t explain a critical part of the system, that’s a reason to stop and understand it. Asking AI to write code doesn’t transfer responsibility for that code.
Learn at the right layer
I’m not done learning languages. Building in Rust means learning about Rust, especially where its choices affect the behavior and reliability of the software. But I no longer think that learning has to happen entirely before the work begins.
I can learn in the context of a real decision. I can ask why an implementation is structured a certain way, compare alternatives, read the relevant documentation, and verify the result. There’s a big difference between not knowing the syntax yet and refusing to understand the system you’re building.
My background in support still shapes how I approach this. The person using the product doesn’t experience our code as a collection of languages. They experience a workflow that either helps them or gets in their way. That’s the level I want to keep coming back to.
What I’m taking forward
Fleet is one example from my own work, not proof that every project can skip deep domain expertise. But it changed what I’m willing to attempt. A language I don’t know no longer feels like a reason to put a good idea on hold.
The skills I want to keep sharpening are architecture, problem framing, product judgment, and the ability to evaluate what gets built. I want to get better at seeing the whole system, giving clear direction, and knowing when the result doesn’t meet the intent.
AI gives us more room to build. What we choose to build, and how thoughtfully we shape it, is still on us.