The Evening Étienne Asked for Numbers
Tuesday evening, the open space had cleared except for Étienne. Étienne, who holds sixty percent of the company and spends his week scrutinizing ERPs for software acquisitions, sat on the edge of my desk. He asked, as he always does when he senses a narrative taking hold, "What's that based on?"
I was ready to launch into a story: sixty days of solo production on Rembrandt with Claude Code, detailing the doctrine, the in-flight retractions, and the incidents that shaped the rules. The declarative form was prepared. But Étienne doesn't ask for narrative; he asks for the material inventory. So, I opened a terminal and let wc -l speak. This article is what I should have presented him immediately – the dry, numbered balance of what worked, what didn't, and what the real impact was.
Setting the Stage: Claude Code and Rembrandt ERP
The experiment involved integrating Claude Code, an AI coding assistant, into the development workflow for Rembrandt, our in-house Enterprise Resource Planning (ERP) system. This wasn't a greenfield project; Rembrandt is a mature, complex system with years of development history. The goal was to assess Claude Code’s utility not in a sandbox, but in the trenches of production code maintenance and incremental feature development. Over 60 days, I worked with Claude Code as my primary coding partner, aiming for a realistic, unvarnished assessment.
The core question was: can an AI assistant genuinely accelerate development and improve code quality in a high-stakes, legacy environment, or does it merely generate boilerplate and require constant correction? My hypothesis was that it would offer benefits, but the extent and nature of those benefits, especially concerning error reduction and complex logic, remained to be seen. The true test lay in its ability to handle the nuances of an established, intricate system like Rembrandt.
The Metrics: Lines of Code, Files Touched, and Time Saved
To provide the quantitative evidence Étienne demanded, I tracked several key metrics. The primary metric was the number of lines of code (LOC) generated by Claude Code that were ultimately committed to the repository, versus the LOC I wrote myself. I also tracked the number of files modified, the number of Git commits where Claude Code played a significant role, and an estimation of time saved through code generation, debugging assistance, and refactoring.
During the 60-day period, Claude Code generated approximately 15,000 lines of code that were committed. This represents about 40% of the total code written during that timeframe. The remaining 60% was my own direct input. This figure is significant because it wasn't just random code generation; much of it involved creating boilerplate, writing unit tests, implementing small utility functions, and translating requirements into initial code structures. The 15,000 lines represent a tangible output directly attributable to the AI assistant.
Beyond raw LOC, Claude Code was instrumental in modifying over 200 files. This doesn't mean it rewrote entire modules, but rather that it contributed to the changes within these files, whether by adding new functions, refactoring existing ones, or writing tests. My Git history shows approximately 70 commits where Claude Code was actively involved, either as the primary author of a change or a significant contributor. This indicates its utility spanned a broad range of tasks within the codebase.
Where Claude Code Shined: Boilerplate, Tests, and Documentation
Claude Code excelled in areas that are often time-consuming but less intellectually stimulating for developers. Generating repetitive boilerplate code, such as data access objects (DAOs), DTOs, and basic CRUD operations, was a significant win. Instead of manually typing out similar structures repeatedly, I could provide a prompt describing the entity, and Claude Code would generate the necessary code with remarkable accuracy. This alone saved hours each week.
Unit test generation was another strong suit. Given a function or a class, Claude Code could produce a comprehensive suite of unit tests, covering various edge cases and scenarios. While these tests often required minor adjustments for specific business logic or assertions, the foundational structure and common test patterns were consistently well-implemented. This dramatically reduced the burden of test writing, a critical but often neglected aspect of software development.
Documentation also saw an improvement. Claude Code was adept at generating docstrings for functions and classes, explaining their purpose, parameters, and return values. This not only improved the immediate readability of the code but also contributed to a more robust knowledge base for the entire team, even though I was the sole user during this period.
The Rough Edges: Complex Logic and Nuanced Requirements
However, the AI assistant was not a silver bullet. Its performance diminished significantly when dealing with complex, nuanced business logic or intricate algorithms. While it could generate code based on explicit instructions, it struggled to infer implicit requirements or understand the deeper context of Rembrandt's business rules. When I provided vague or underspecified prompts, the generated code was often incorrect, incomplete, or simply missed the point.
Debugging complex issues also proved challenging. Claude Code could help identify syntax errors or suggest potential fixes for common problems. But when it came to tracing subtle logical flaws within the ERP's interconnected modules, its assistance was limited. It lacked the deep understanding of the entire system's state and the historical context that a human developer possesses. It was like asking a brilliant but inexperienced junior developer to debug a mission-critical system without full context; they can spot obvious errors but miss the systemic issues.
The process of refining Claude Code's output was also a significant factor. While it generated 15,000 lines of committed code, the time spent reviewing, debugging, and correcting that code was substantial. My estimation is that for every 10 lines generated, I spent approximately 3-5 minutes reviewing and potentially correcting. This means that for the 15,000 lines, I spent roughly 45-75 hours in direct oversight and refinement. This is not a criticism, but a realistic assessment of the human-in-the-loop requirement for AI coding assistants.
The Honest Balance: Time Saved vs. Time Invested
So, what is the net balance? Étienne's question was valid. If we consider the 15,000 lines generated, it might seem like a massive productivity boost. But the hours spent prompting, reviewing, and correcting are critical. My conservative estimate for time saved, factoring in the review overhead, is around 10-15% of my total development time over the 60 days. This translates to roughly 40-60 hours saved in total.
This might not sound like a revolutionary leap, but for a solo developer on a complex legacy system, it's meaningful. It meant more time for architectural thinking, for tackling the truly difficult problems, and for refining existing code rather than just churning out new features. It's less about writing more code and more about writing *better* code and having a bit more breathing room.
The surprising detail here is not that Claude Code isn't perfect, but that its current utility is so precisely defined. It’s a powerful assistant for well-defined, repetitive tasks, but it doesn’t replace the need for deep domain expertise and critical thinking for complex problem-solving. It's a highly capable intern, not a senior architect.
Looking Ahead: The Future of AI in ERP Development
After 60 days, Claude Code has earned its place in my workflow. It’s not the magical solution that eliminates the need for developer skill, but it is a valuable tool that augments it. For developers working on large, established codebases like Rembrandt, the ability to offload repetitive tasks and accelerate the creation of standard components is a significant advantage.
The key takeaway is that AI coding assistants require skillful prompting and diligent review. They are most effective when used for specific, well-defined tasks. As these tools evolve, their ability to understand context and complex logic will undoubtedly improve, further transforming the development landscape. But for now, the honest balance is one of augmentation, not automation, and requires a developer's hand to guide it.