A key challenge Urban’s data science team often faces is determining the right technical approach for a product, especially when it calls for an unfamiliar combination of tools or deliverables. When multiple plausible paths, each with its own trade-offs and unknowns, are available, picking the wrong one can waste project funding and delay schedules. But evaluating multiple paths thoroughly enough to confidently pick the right one also takes time and money.

Over the past several months, we’ve found that agentic programming tools like Claude Code and GitHub Copilot CLI fundamentally change this calculus. These tools enable us to stand up working prototypes in minutes, test competing approaches, and surface limitations. As a result, we can make informed decisions earlier and confidently say yes to more-ambitious work. Two recent projects show how these tools have improved our work.

Choosing the right approach for iterated reports

A common request for our team is iterated reports, where we use code to programmatically generate a custom fact sheet for a specific unit of analysis (such as states, counties, cities, or schools). But a recent project complicated the usual request.

It required an unfamiliar combination of constraints: The deliverables needed to be Word documents with complex, highly formatted tables, and the partner requested we use Python so they could maintain the codebase. We’ve built plenty of iterated reports in R but hadn’t done so in Python or rendered to .docx. That combination meant the right technical approach wasn’t obvious.

Two paths seemed plausible. Quarto supports Python and can render to Word, but its .docx output loses the rich table formatting available in HTML outputs, where libraries like great-tables and gt offer fine-grained control over table styling. An alternative library, python-docx, offered more flexibility but requires a fundamentally different architecture than we had used before. Rather than commit without evidence, we used Claude Code to rapidly test both options.

With a “vanilla” Claude Code setup (Opus 4.5 with no subagents or custom skills), we pushed the Quarto/Markdown-based tables as far as they could go. Neither our own code nor code written by Claude Code could create tables with the degree of stylization the client requested. Within minutes, rather than days, we had confidence that this path couldn’t meet the partner’s needs.

In parallel, we used Claude Code to generate a proof-of-concept table with python-docx, testing whether it could match the partner’s tables with custom background colors, text formatting, and cell borders. On the first attempt, it produced nearly identical tables. The process also surfaced a limitation we might not have found for weeks: The python-docx prototype couldn’t correctly incorporate footnotes. Further investigation confirmed this was a known gap in the library.

With both approaches tested, we could make an informed decision. The pros of python-docx (the ability to closely replicate the partner’s vision and reliance on well-established software) outweighed the cons (no native footnotes and a different technology than we’d planned). Critically, we made this decision with prototypes in hand rather than educated guesses.

Validating a new workflow in 10 minutes

A few weeks later, a project team asked whether producing state-level one-pagers as printable PDFs would be feasible within a tight budget and timeline. The target audience, policymakers and legislative staff, wanted a printable document summarizing their state’s data, so our HTML-based state factsheets wouldn’t work.

Urban’s communications team had designed a polished .docx template with a multicolumn layout, branded headers and footers, and styled tables—a difficult document to reproduce programmatically. Usually, we would reverse engineer the template’s styling in Quarto and render to PDF (either directly or through a reference document and Pandoc). But that process becomes increasingly time-consuming as templates grow more sophisticated, and the project’s budget and deadline wouldn’t allow it.

Based on our previous experience, we had a hunch that a simpler path could work. Instead of relying on Quarto, we could use an R package like officer to programmatically populate the state template directly, then convert to PDF. This would enable the communications team to retain full control over the document’s visual design while we handled the data and code.

Yet this approach was still full of unknowns. We weren’t sure if it could handle a template this complex, and even if it could, we would be switching to an unfamiliar workflow, which often surfaces unexpected issues. That kind of hands-on testing would have meant days of iterating.

Instead, we turned to Claude Code to test it. After less than 10 minutes of prototyping (using Opus 4.7), we produced a working proof of concept that confirmed the approach was viable. officer could handle the template’s complexity, and the full pipeline from data to iterated PDFs held together.

Claude Code’s rapid validation meant we could scope the project with confidence: We knew the exact steps required and that the approach would deliver. Rather than falling back to a safer but less ideal option, we could deliver exactly what the project needed, within their budget and timeline.

Better decisions, more ambitious products

In both examples, our team started with the expertise that made the agentic tools useful: deep experience with iterated reports, knowledge of the R and Python ecosystems, and an understanding of what our partners and audience needed. We directed the exploration, reviewed the generated code and outputs, weighed the trade-offs, and made the final calls.

The agentic tools allowed us to compress the exploration phase and quickly assess whether an idea could work. Instead of discovering the limitations of an approach weeks later, we could evaluate multiple paths up front and move more quickly from “I think this might work” to “I know this works, and here’s what it can’t do.”

This workflow has practical implications beyond any single project. When we can cheaply validate or rule out a technical approach, we’re more willing to consider newer or less familiar tools and more confident taking on ambitious, customized work. That shift matters for how we fulfill Urban’s mission: It means we can bring data and evidence to the people who need it most in the formats that work best for them.