I like to call myself a PHP developer, but I keep hearing the same claim over and over that with agentic development. It's that the underlying programming language doesn't "matter" anymore. I prompt the LLM and the LLM writes some code that should match the prompt, so I shouldn't care if it's PHP, Python, or Rust. I've been thinking about that for a while, and I wanted to know if that was true or if it was the kind of thing people posting engagement bait say that falls apart the second you try to ship something.

So like most things with agentic development, I tested it. I built a real command-line tool in Python, a language I don't work in, using agentic development. It wasn't a toy or a weekend "hello world," but something I needed to support my content creation work. It turns out the language was truly a non-issue, but that's not the whole story.

What I Built

The tool is UnleashedPodcastsCli, a command-line interface for the API behind my UnleashedPodcasts.com product. I modeled it on the AWS CLI because that's a design I know and trust. You get noun-verb commands like unleashed episode list, credentials and profiles through unleashed configure, and output in JSON, table, or text so it plays nice with scripts (and LLM agents).

unleashed episode list --output llm

It also does JMESPath queries so you can filter the response, a --dry-run flag, and granular exit codes so you can chain it in a shell script and know what failed. It's a real tool driven by a real need, which was my whole point. I wanted to prove I could ship something I could hand to another developer or content creator and have them use it.

Part of why I picked Python is that I wanted to learn the language. It's what "the cool kids are doing", and I prefer to learn by building than by reading "Python for Middle Aged PHP Developers" (coming Winter 2026 by me?).

The Part That Was True

So I wasn't shocked, but generating the code was truly a non-issue. I took the same spec-based development approach I use with my PHP and agentic development projects. I never had to sit down and memorize Python syntax or fight with how it handles variables or whatever else I'd have spent a weekend on five years ago. I just said "I need X" or "Y is broken" and the LLM did what I asked.

The Part That Wasn't?

So I think I found out I can generate any kind of code that I want all day long without enough issues that it derails me (here that, hiring managers who want 10 years of Livewire experience?). But I still had to learn the parts I didn't feel comfortable handing over to an LLM.

The biggest question being how do I package this so someone can install it? I've been spoiled with the singular Composer ecosystem in PHP, but Python has multiple package managers with slightly different setups. In the end, I went with uv (which is the most modern), and if people want more, we'll add them on later.

I didn't know how a Python project should be laid out. Claude put my files in "src" and tests in "tests"; was that right? It seems like it, but I wasn't sure without some extra research and looking at other Python packages.

Ultimately, I can generate code in any language I don't know, but I'm struggling with steering the project and reviewing the code. That's the important piece that I don't see anyone talking about online. It's all "I vibe coded a million dollar app in a weekend".

How I Trusted Code I Couldn't Read on Instinct

Through experience, I can read a chunk of PHP and instinctively know if it's correct and follows modern development practices. I've written and reviewed so much PHP code that it's just part of my broken brain. I however, don't have those same paths for Python (yet).

To "get around this," I offloaded that gap into tooling that I trust (again after years of experience).

First, I forced the LLM to lean on test-driven development and implemented a 90% code coverage gate. This forces the LLM to write tests for the code it's generating, and I can more or less look at what I asked it to do, see the tests it generated, and "assume" the code is correct. I couldn't "trust" the code, but I trusted the tests because a test that says "given X, the configure command writes these credentials" is something I understand no matter what language it's written in.

Second, I set up a CI/CD pipeline to run the tests and checks for every test. "Works on my machine" isn't the bar, because the pipeline exists to enforce that bar. A green build meant the thing was shippable, and that let me, a PHP developer, merge Python without worrying about what I missed.

Coverage plus CI is how you replace the confidence that comes from language fluency. It's how I handle new teammates as well, so it's not surprising it works here as well with an "artificial" teammate.

Wrap it up already

To try and wrap this up. With this experiment, I'm finding that language choice is more of a design decision and less of a skills decision. This won't come as a shock to anyone who has been in this industry for even a little while. I picked Python for reasons that had nothing to do with my ability to write Python but instead for my desire to learn it. It might have been the wrong pick for this project, but now that I have a spec and process to test the code, switching might be as simple as pointing an LLM at the repo and saying Recreate this in Go or Rust.

Ultimately, the tool works, so I'm keeping it around, and I'll be adding features to it in the coming weeks.