More Than Faster
When people ask about AI in software development, the conversation usually lands on speed. How much faster does it let you write code? The numbers from our work at Rhodium Systems are real: sustaining 3,000 to 4,000 non-comment lines of code per week became a normal pace for a senior engineer working with AI assistance. During the most intensive periods of early development, that figure peaked higher. Before AI tools, those numbers were not achievable for a single engineer working at a maintainable pace.
But speed, while useful, is not the most significant thing that changed.
The more important shift was in what became practical to attempt. When the cost of execution drops, the constraint moves upstream — to design and judgment — and you find yourself taking on more of the problem than you would have otherwise. Features that would have been deferred for schedule reasons get built. Work that would have required a larger team becomes feasible for a small one. This is harder to quantify than lines of code per week, but it matters more to what you can actually ship.
At Rhodium, this showed up in scope. We are a small company building a platform with a lot of surface area: agent-based infrastructure management, DNS and IP management, identity and access management, monitoring, provisioning. The AI tooling did not just help us write code faster. It changed what we could reasonably commit to building at our current team size.
The Spec Discipline Problem
Early in the development of ResorsIT, some AI-generated design recommendations went in directions we did not want. The code was functional — it compiled, it ran, it did something — but the approach did not match what we were building toward. The architecture was heading somewhere we would have had to undo.
The solution was not to use AI less. It was to write better specifications before asking for implementation.
This is counterintuitive. The common assumption is that AI tools reduce the need to specify things precisely — that you can sketch an idea and get working code. Our experience was the opposite: AI executes on what you give it, faithfully. Vague inputs produce technically-correct-but-wrong outputs. The discipline required is being precise about the design before you ask for the implementation. When we tightened our specifications — more detail on the architecture, clearer constraints, explicit statements about what the code should not do — the results improved substantially.
Understanding this going in saves significant rework. AI does not replace design work. It accelerates the translation from a well-formed design into running code. The quality of that translation depends almost entirely on the quality of what you put in front of it.
Why the CLI Matters
The primary tool we use is Claude Code. One observation worth sharing: the CLI interface is meaningfully different from a web-based chat interface, and the difference matters operationally.
A web conversation with an LLM is detached from the codebase. It does not have the project in front of it, cannot read the actual files, and cannot act directly on them. You are describing your code to it rather than working with it. The CLI runs inside the codebase. It reads, modifies, and reasons about the actual code and project structure — the same files the compiler sees — rather than a description of them.
That operational context is what makes the difference between a conversational assistant and a capable development tool. Most of the friction people experience with AI coding tools is a symptom of using the wrong interface. The CLI is where the leverage is.
What This Adds Up To
The honest picture is not that AI writes your software. It is that AI changes the ratio between design work and execution work. Execution — translating a well-specified design into code — accelerates significantly. Design, judgment, and architectural thinking remain fully human work, and arguably require more discipline than before: because the cost of a poorly-considered design decision is paid faster, and at higher volume.
For a small team building complex software, that is a favorable trade. You take on more ambitious scope. You ship things that would otherwise have been cut. You keep pace with a product roadmap that the team size would not have supported without it. The catch is that you have to do the specification work well. The tool rewards precision and punishes vagueness, and there is no shortcut around that.
ResorsIT was built with AI-assisted development throughout. See the platform overview to see what that produced, or contact us if you want to talk about how we built it.