AI Accelerator: Stacey Nunez, Software Developer

In this installment, we speak to Stacey Nunez, a member of our software engineering team. Over four months, Stacey led the rebuild of an internal data tool for managing securities. She did this working solo alongside Anthropic’s Claude, demonstrating the leverage AI tools can offer. The result is a modern, fully tested solution that is in active use. Here is how she approached it.

The AI Accelerator series is an ongoing collection of conversations with people across Confluence who are at the forefront of how we build and use AI.

From the intelligent features embedded in our solutions to the tools colleagues increasingly leverage to get their work done, each installment hears directly from people across teams and disciplines. Find out what’s working, what isn’t, and what they’re still figuring out. Ground-level perspectives from the people living it every day.

Q: What was the case for rebuilding this solution, and what were you trying to achieve?

A: The primary driver was to improve speed of future development, improving scale. The previous version had no automated test coverage, no CI pipeline, and all deployments were handled manually. That created real constraints on how quickly we could move, and how confidently we could make changes.

We started with a clear goal: a minimum viable product delivered in a short timeframe, built on a modern, maintainable foundation. We focused on rebuilding everything sitting on top of the database: a REST API, a React front end, Redis caching, full test coverage, and deployment via Docker and Kubernetes.

Q: How did you approach using Claude for a project of this scope?

A: The core instruction I gave Claude was: rebuild it to be clean and modern but match the observable behavior of the existing application. Not to replicate it exactly but preserve the business logic and the outcomes that our teams rely on. Terminology and labelling stayed the same, because you do not want users to feel like they have to learn a new system.

I kept the old and new codebases in the same repository so Claude could reference both simultaneously. That made cross-file audits much more effective, particularly for verifying that logic carried across correctly. There are meaningful differences in how the two languages handle things like null checks and having everything in one workspace meant those inconsistencies could be caught early.

Over the four months, I ran more than 65 Claude sessions. I built a discipline around session starts: Claude would read a living memory file and any relevant documentation before we touched any code. That continuity was essential.

Q: You developed a structured system of commands and rules over time. How did that come about?

A: It came out of experience. In the early sessions, I found myself repeating the same instructions constantly: check this before you change that, apply this rule, verify before committing. That became unsustainable across a project of this length. So, I built a library of slash commands covering things like smoke tests, code review, new ticket setup, and verification steps. Having those in place meant I could stay focused on the work rather than on managing the tool.

I also learned that rules held more reliably when they lived in the repository itself rather than in the chat session. If a constraint was only stated in conversation, Claude would sometimes work around it when navigating a complex problem. If it was in the repo rules, it held consistently.

Everything Claude touched, it documented. That sounds like overhead, but across 65-plus sessions it was the only way to maintain a coherent picture of what had been built and what the constraints were.

Q: Where did Claude add the most value, and where did you keep the tightest control?

A: The repetitive, standardized code that every API call requires was where Claude made the biggest difference to throughput. Each of the hundreds of API calls in the new application needs the same surrounding structure: authentication, error handling, response formatting. The logic in the middle changes, but the wrapper around it is largely identical each time. Claude handled all of that consistently and quickly, freeing me to focus on the parts that actually required judgment.

Test coverage was another area: every feature I tested manually, I had Claude write a unit test for. Reaching 547 unit tests alongside everything else would not have been feasible without that.

For the UI, I gave Claude the Confluence brand colors and a clear brief to modernize the design. While this was an internal tool, it was a good experiment to be disciplined in the UI, to see how Claude could perform. I leaned on Claude to produce a first version and then iterated from there, directing changes until the result felt right. The reusable component approach was important to me throughout, and Claude applied that consistently.

I never allowed Claude to push, pull, or deploy anything. I reviewed every code change manually before it went in. In the early months I also committed everything myself. I came to allowing Claude to commit later in the project, and even then, I checked everything. That level of review is part of why the project took four months, but it is also why the application works

AI didn’t replace the developer on this project. It removed the grind. The judgment, the architecture, the decisions about when something needed to go a different way — that was still the developer’s job. AI gave me the capacity to do more of that work, not less.

Stacey Nunez, Software Developer

Q: What were the most challenging moments, and how did you work through them?

A: The most difficult stretches involved situations where fixing one thing would break another, and the cycle would repeat. There was a particular challenge around session and role management. A test user in the system had 230 roles assigned in the database, and getting Claude to handle that edge case consistently across sessions took real persistence.

What I learned from those situations was the value of the slash commands. Rather than trying to reason through the loop in conversation, having a structured verify or audit command would get things back on track without losing context. Screenshots also proved invaluable. When something was not behaving correctly, a screenshot communicated the problem far more precisely than a written description.

Q: What would you tell a developer considering using AI for a project of this kind?

A: Build your structure early. A living memory file, clear repo rules, and a set of commands for recurring tasks will save significant time across a long project. Put your constraints in the repository, not just in the chat. And take screenshots throughout: they are far more effective than written descriptions when something is not working as expected.

Be deliberate about what control you hand over and when. Reviewing every change manually took time, but it meant I always had a clear picture of what was in the codebase, and I trusted what was there.

And understand what AI is actually doing in this kind of project. It did not replace me as the developer. It removed the grind: the repetitive scaffolding, the test generation, the standardized code that has to be written the same way dozens or hundreds of times. The judgment, the architecture, the decisions about when something needed to go a different way, those were still mine. AI gave me the capacity to do more of that work, not less.