We used to have a meeting to give all developers an overview of what was happening. Every two weeks we gave quick updates on every major project in the company. This is no longer feasible. There are simply too many projects running at once. The meeting either runs for hours or turns into a list of names read out loud. So we are rebuilding how we keep everyone informed.
This is just one example. All throughout Rootline, AI changed the way we work. For most of Rootline's life, the limit on what we shipped was how fast people could write and review code. Today the queue forms in front of the decision about what to build.
Most of the strain lands on our product managers. We can build close to everything we want to build, which makes deciding what to build, and how it should behave, the slow step. Keeping the product coherent at three times the development output is the hard part, and it is where most of our attention goes today.
We got that 3x with the same team and this is only speeding up. Right now, getting this process right is worth more to us than hiring more engineers.
The numbers
We started investing in agentic coding at the beginning of this year. It took off organically from there. Between March and July this year we closed 2,499 issues (simple tasks) and 109 epics (larger projects). In the same five months last year we closed 912 issues and 34 epics. Same number of people.
Underneath that sit 7,744 commits against 3,057 a year earlier. Counting only source files, so Java, Python, Kotlin, TypeScript, Go and SQL, we added 951,000 lines of code against 152,000. The average commit grew from 50 lines to 123.
What had to be true first
We were ready for the extra output because of two investments: a test harness we trust, and the people already on the team. AI magnifies the qualities a team already has. Ours is strong, so more output arrived at the same quality and the bottleneck moved from implementation to design.
The testing harness is paramount to effective agents. If you give them a way to check, quickly, how well they are doing, agents become much more efficient. Our integration tests run in a single JVM, which means we can run them on every commit rather than overnight. We have one per domain, and we trust that a green CI is deployable.
These earlier investments meant we were ready for agentic coding.
To supercharge AI coding, we also doubled down on skills, specifically skills backed by scripts. We have 45 of them in the repository now, and a quarter call an executable. Anytime an agent can do something by calling a deterministic script, it should do so. It is faster, cheaper, and gives the same answer every time.
Bazel dependency management is the clearest example. Watching what agents actually did with their time, we kept seeing them get stuck resolving build dependencies. It is fiddly mechanical work, and it burned the context that should have gone into the actual task. We had a tool for it already, written back in 2023, and it needed one more push to be reliable. That push was cheap now that we had AI. Fixing it and then teaching agents to reach for it moved them from small tasks to large ones.
The best version of this is your agents writing the scripts that your other agents call.
Another factor that deserves a mention is the fact that we have a monorepo. We believe this makes AI agents more powerful because they have access to all the context they need in one place.
What is next
Everybody at Rootline is automating their own work with AI now, which means everybody is coding. This is now and essential part of the company and great for a proof of concept or a tool somebody runs on their own machine. The story is more nuanced when the code goes into the main repository and runs in production. Who owns code written by someone who is not a developer?
Right now we do it per item. A developer looks at the change, decides whether it is good enough to go in, and takes responsibility for it once it does. That is manageable at our current volume and it is settled by consensus rather than by policy. The open question is whether developers end up as a review queue for the whole company.
The harder question is about understanding. How well do you need to understand code an LLM wrote for you? Every line? The architecture? Do you need to know why it guarded against a race condition in a place where a race condition cannot occur? We ask everyone to be able to explain why the AI did what it did, and we have not agreed on the level at which that has to hold (but we decided for now that in the case of race conditions, yes; you should know).
This is most noticeable in reviews. If you are reviewing code an AI wrote, and your review comments are then picked up by an AI, what are you doing in the middle? If you request a review, you should be able to answer questions about the code without going back to your agent.
What it does to a working day
Context switching is the change everyone notices. You can have several things in flight at once, and your attention becomes the scarce resource instead of your typing speed. That is tiring in a different way than writing code all day. We are experimenting with spec driven development, where iterating on a spec is much faster and the switching goes down.
If you are running a team through the same shift: how did you settle ownership of production code written by people who are not developers?
