Bottleneck Shifts When You Automate

There’s a thing that happens when you start automating infrastructure and pipeline code with AI tools that nobody warned me about: the bottleneck doesn’t disappear — it moves.

Before AI-assisted development, the slow part of building a data platform was what you’d expect. Writing Terraform modules. Scaffolding dbt models. Getting the SQL right. I could plan faster than I could build, and the backlog of “I know what to do but haven’t written it yet” was always growing.

That’s not the bottleneck anymore. Now I can scaffold a full dbt model layer in an afternoon. What doesn’t move fast is everything around the code: getting an SME to confirm a field mapping, aligning on what “real-time” means in context, waiting on a schema review before building on top of it.

Before:
  [Plan] --fast--> [Wait to build] --slow--> [Build] --fast--> [Validate]
                                    ^^^^ bottleneck

After:
  [Gather requirements] --slow--> [Align w/ SMEs] --slow--> [Build] --fast-->
        ^^^^ bottleneck                  ^^^^ bottleneck

The bottleneck shifted from building to knowing what to build.

When the constraint was my own throughput, I could manage it — work more hours, get faster at Terraform. But when the constraint is other people’s calendars and attention? That’s a fundamentally different problem. You can’t automate your way through a two-week wait for a domain expert to confirm whether your mapping is correct.

What I’ve started doing differently

Front-loading the ambiguity. If work depends on SME input, I surface those questions before building, not after. The building is now cheap enough that I’d rather wait and do it once than build-show-correct-rebuild.

Planning docs as a deliverable. A clear spec translates almost directly into working code through AI tooling. A vague spec generates vague code, fast. Speed without direction is just expensive wandering.

Treating human dependencies like technical ones. I track “waiting on SME” the same way I’d track “waiting on AWS support ticket.” They need the same follow-up discipline.

The life sciences angle

This shift hits harder in life sciences. The domain knowledge is deep and specialized — you can’t Google whether your SDTM mapping is correct. And faster code generation makes the gap between “technically possible” and “scientifically valid” more dangerous, because you can build a confidently wrong thing very quickly.

As the tools get better at the mechanical parts, the job becomes about orchestrating knowledge that only lives in people’s heads. That’s a communication job, not a coding job.