We Made AI Mandatory. Here's What Changed.

We made a decision at Data Driven earlier this year. AI tooling isn't optional. Every engineer on the team is required to integrate it into their daily workflow. Not as a suggestion, not as a quarterly initiative. As the way we work now. The results showed up faster than I expected.

I watched an engineer recently point Claude at an open JIRA ticket. It read the requirements, wrote the code, committed to GitHub, and created a pull request for review. No copy-pasting. No context-switching between four browser tabs. Ticket to PR, handled.

Before that, the same workflow was fully manual. Reading source dashboards, rebuilding them by hand, validating output, committing one file at a time. Once AI tooling was wired in, the throughput roughly tripled, and that was before any major refinements to the agents or the code. Mostly just the Claude CLI speeding up work that used to take an entire sprint.

This is happening across every engagement we touch, across industries, across team sizes. And the speed isn't what caught my attention. What caught my attention is what it does to everyone's role when this becomes the default.

The Production Line is Compressing

Most data teams still operate on an assembly line. A business user makes a request. It becomes a ticket. The ticket gets groomed, prioritized, assigned. A developer picks it up, builds it, submits a PR. Someone reviews. It merges. Maybe there's QA. The feature ships days or weeks after the original idea.

Each handoff in that chain exists because the work at each stage used to require dedicated, specialized labor. Designers mocked things up. Developers wrote the code. PMs kept the sequence moving. Every additional person in the chain meant more communication, and communication alone is one of the biggest things that slows delivery down.

I rebuilt our company website in my free time over a couple of weeks. The previous version required a UX designer, a content writer, and developers. Figma mockups went back and forth for a month. Content got drafted, revised, rerouted. Then developers built it, things broke, things came back for another round. Three people, weeks of coordination, all for a mostly static site. With AI handling the implementation, I went from concept to live pages directly. The bottleneck shifted from "can we build this?" to "do we know what we want?"

That shift is playing out everywhere. The constraint is no longer engineering capacity. It's product clarity.

Faster Execution Alone isn't the Answer

We've been noticing a pattern across the teams we work with. Organizations that adopted AI coding tools saw developers shipping features and fixes so quickly that their existing rituals started breaking down. Daily standups became counterproductive because by the time you met in the morning, half the sprint was already done. Teams that moved to weekly syncs found their output had multiplied, not because people worked harder, but because the friction between intent and implementation had mostly disappeared.

That sounds great. But think about what it means for the developer whose entire professional identity is built around completing tickets efficiently.

If AI makes you 10x faster at execution, your manager's first instinct is to give you 10x the workload. The second instinct, especially under margin pressure, is to realize they don't need the same headcount to clear the same backlog.

We see this in BI and analytics teams regularly. Some of our enterprise clients have large teams, 40 or 50 developers, spending most of their time building visualizations manually. Dashboard after dashboard. That work is pattern-heavy, well-documented, and doesn't require a lot of creative judgment. It's exactly the category of task AI handles well today. The teams that haven't started thinking about what their developers do after the dashboards build themselves are going to face hard conversations soon.

But this isn't all grim. In fact, for the developers who are paying attention, it's the opposite. The space that AI opens up isn't a vacuum. It's an opportunity to do work that actually matters.

The Developer's Role is Expanding, Not Disappearing

Here's what this looks like in practice. One of our engineers was using Claude to generate derived tables in Looker. Early on, the AI kept making wrong choices about table types, confusing native, persistent, and temporary derived tables. Instead of just correcting the output each time, the engineer built a decision framework that encoded our best practices: when to use which type, what the common failure modes look like, real examples from past projects.

That alone was valuable. The AI started reasoning through the right approach before writing any code. But what happened next is the part that matters.

Because the engineer wasn't spending all of his time on raw implementation, he had room to think about what came after the ticket. He started focusing on the user experience: how to organize views, dimensions, and measures in a way that made sense to the business users actually building reports. He built dashboards based on best practices instead of just fulfilling specs. He automated operational tasks using the API, things like scheduling dashboards and creating alerts, that would normally be a separate request entirely.

The work still went through QA. There was still a human validating every output. But the developer's role had expanded from "complete the ticket" to something closer to a technical product developer. Someone who ships the feature, thinks about how it gets used, and leaves a trail for the next person to build on.

That skills trail matters more than people realize. In most analytics teams, there's a huge disconnect between the developer who builds a data model and the analyst who builds reports on top of it. The developer knows the schema but not the business context. The analyst knows the questions but not the underlying structure. When our engineer encoded his decision-making into a reusable framework, he didn't just speed up his own work. He created guided context that a junior developer could use as a learning tool, compressing the ramp-up time for the next person on the project.

The timeline for shipping the feature compressed. There was a knowledge trail for onboarding. And the end users got what they needed faster because the developer had time to think about their experience instead of just closing the ticket.

This isn't limited to engineering roles, either. Our operations manager was drowning in meeting transcripts. Every week, she was sifting through hours of recorded calls across multiple projects to piece together status updates. It was time-consuming, manual, and by the time the updates went out, some of the information was already stale. So she took initiative and built her own connector. She combined and organized all the transcripts, configured it to generate detailed summaries, and now she can track sentiment across the timeline of each project. We know ahead of time when to loop in additional resources or check in on a project that's trending off-track. That's not an engineer's work. That's someone with deep operational knowledge using AI to close a gap that used to require a developer to fix.

This isn't about Replacing People

I want to be clear about something: I'm not arguing that AI replaces all of these roles automatically. You still need a human in the loop to validate, cross-check, and provide feedback. The derived tables still get reviewed. The dashboards still get tested against real data. The project summaries still get read by someone who knows the context well enough to catch what the model missed.

What we've done is compress communication to optimize the speed of delivery. Fewer handoffs, fewer misunderstandings between the person who knows what needs to be built and the person building it. In many cases, those are now the same person.

The biggest positive is that these tools are accessible. The barrier to entry isn't a computer science degree or months of training. It's mostly prompting. Writing clear instructions, building context files, wiring up the right APIs. The learning curve is days, not semesters. One of our engineers told a colleague who was nervous about falling behind: "You're not behind. You're one week away from where I am." That wasn't encouragement. It was accurate.

Where this Leaves Us

The organizations that treat AI as a headcount reduction tool will save money for a quarter and then get out-shipped by the ones that treated it as a capability multiplier. We're already seeing this divide form across the companies we work with.

The title "developer" is going to mean something different in two years. Not obsolete. Redefined. The people who thrive will be the ones who combined deep domain expertise with the judgment to decide what should be built, how it should work, and why it matters to the person using it. They'll be the ones who encoded their knowledge into systems, designed the guardrails, and expanded into the product and user experience work that AI freed them up to do.

The ones who kept their heads down and optimized for ticket velocity will find that velocity alone isn't enough when the machine next to them has no speed limit.