It’s the first night of DrupalCon Chicago, and I’m mingling. I’m not expecting to have a deep, meaningful conversation. But that’s exactly what I got.

I’m standing somewhat rudely in the middle of the aisle in the hotel bar, and I can feel the long-suffering glare of the server who has to maneuver around us. It’s crowded. And loud. We’ve just finished dinner, and after a long day of travel, I’m more than ready to sneak up to my room. But there’s a human traffic jam of wonderful people, including one of my faves, Randy Fay. We were on the same trivia team last year, and we commiserated our loss, as one does.

I’ve got my new “Developer Advocate hat” on, and I’m in earnest as I ask him if he’s experiencing any AI-induced bottlenecks in his open source project’s issue queue. Randy maintains DDEV, a popular tool for local development not limited to Drupal, but a popular choice amongst the attendees here at DrupalCon.

Randy tells me a story about one bottleneck that’s been weighing on his mind. A “PR That Gives Him Pause.” If you’re unfamiliar with the term, a PR is short for pull request, a GitHub term for a proposed code change that can be reviewed and discussed in isolation from the rest of the project’s issues. GitLab, which hosts Drupal’s codebase, uses the term merge request for the same concept.

The PR in question contains a refactor of an important component in DDEV, and the code was generated by AI, in large or in whole (the specifics don’t really matter here). It was opened from a contributor he doesn’t know — and this will become important as our conversation unfolds.

So what’s the bottleneck? He is. He’s stuck on how he should comment. This is huge, because it’s unlike Randy not to reply in a timely fashion, as anyone who has asked a question about DDEV knows.

So, why? What’s the hesitation? That’s what I want to know. I begin my gentle interrogation.

Is the problem technical in nature? Is the code of poor quality or full of AI slop? Knowing nothing about DDEV’s CI/CD pipeline or its automated testing checkpoints, I’m wondering whether this is a tool- or process-related problem. An automated quality checkpoint that could ease this maintainer’s burden a bit.

No. The code looks good at first glance. Impressive, even.

Is the feature on the roadmap? If it’s not planned, that’s an easy reply: “Closed as not planned.” Next! As I ask, I’m recalling hot takes about spec-driven development and past conversations about scope creep. I want to know whether encouraging Randy to gently but firmly set a scope boundary is the right next step.

No. The feature is on the roadmap and would improve the product. The plot thickens! The din of the crowd fades into the background. We’re locked in now.

Is it a huge PR? I’ve read tales of ginormous PRs and 800-line diffs burdening senior developers. Maybe it was just the one tale, and it’s been repeated so many times that I’ve lost any idea of how widespread this problem is. I want to know: Does just looking at this PR make you tired all over?

Well, no, that’s not quite it either. We’re certainly capable of reviewing this PR. It’s just that…

Well?

This would be a huge change, and I don’t know this contributor. Can I trust them to help maintain this code or offer support? Can I trust myself to maintain my expertise as more problems are handed off to AI and more AI-assisted solutions surface in my issue queue?

Turning FUD into food for thought

Now, a few months down the road from this conversation, what ended up happening? In reviewing a draft of this article, Randy told me more about this contributor. A couple of his PRs have landed, and he’s made contributions in another repo as well. While Randy still doesn’t know how to turn him into a maintainer, their team at DDEV has been influenced by his approach to producing these well-crafted AI-produced PRs, including using tools like spec-kitty, a project by Robert Douglas.

And Randy’s expertise? Is it waning as he feared? He told another story about this same contributor. They produced a “masterful AI-helped and well-organized set of improvements” to make a central piece of DDEV functionality more performant. But later, focused on the same problem and with a broader, fuller understanding of the situation, Randy produced 2 separate PRs that were 100x more impactful, each with tiny code improvements. His ability to do this was rooted in a deep familiarity with DDEV behavior, a context and expertise the AI tool just didn’t have.

The thrill of superpowers

I get excited when a coding LLM helps me contribute a solution to a project I care about. Especially when it’s a project I wouldn’t have normally felt comfortable contributing to. It’s exhilarating to watch AI-assisted solutions pass automated tests, sail through quality checks, look good in the preview, and pass the scrutiny of an expert reviewer. At the same time, I’m filled with doubt.

  • Was there adequate test coverage?
  • Was the reviewer too busy or fatigued to give a proper review?
  • Was the LLM missing critical context? How do I even know what context it used or didn’t use?
  • Did I increase my understanding of the product?
  • Did I just get lucky?
  • What expertise am I developing? Figuring out how to use superpowers or gaining a deep understanding of a product? Can it be both?

The shape of code contribution is changing. Contributors, energized by new forms of power tools, are drilling into backlogs and unearthing solutions like never before. And those power tools are getting swapped out with better models every other week, it seems. In all this disruption, we’re learning how to use our new superpowers. And we’re questioning everything. Even our own expertise, as we offload our problems to AI to solve, and sometimes struggle to stay engaged and rooted in the problem.

The power of pausing

Everyone talks about the deluge of AI-assisted code contributions, battering the issue queues and inboxes of open source project maintainers. Stress testing of CI/CD pipelines and ensuring the right checks are in place. The deployment of agents to manage the chaos (or be the chaos — probably both). But sometimes the hesitation, the pause, the bottleneck is our hearts. Sometimes we need a minute to mourn our craft, wonder about the future, and cope with the discomfort of becoming a learner all over again, no matter how long we’ve been in this business.

Heart-shaped bottlenecks

I think that’s the real takeaway. We were experts, and we had things figured out, or so we thought. We’re still experts, but we’re also learners again. Feelings of fear, uncertainty, and doubt are flooding into our hearts. They cause us to pause. To reflect. To be the bottleneck in the issue queues we maintain. And I think that’s ok. Good, even. As we contend with contributions submitted by people but produced by AI, as we engage in these practices ourselves, as we learn as much as we can to try and participate in a conversation that is re-shaping our world and livelihood, do we have the courage to become learners again? To be the heart-shaped bottleneck?

This article was not written by AI.