I recently stumbled upon Thomas Ptacek’s blog post against so-called “AI skeptics”, in which he argues against developers who (as he puts it) think that AI is “just a fad”, and asserts that opponents of AI are “doing work that LLMs already do better, out of spite.” He addresses some of the common critiques of AI-assisted coding (unreliable code, removal of human authorship, threat to job security, plagiarism), and exhorts all engineers to start “sipping rocket fuel” and get over the “affectation” of critiquing AI.
I will grant that Ptacek makes an important distinction between chat-based AI coding (copy-pasting bad code from your ChatGPT window into your repo) and agent-based coding (using advanced configuration of LLMs to read, run, test, and commit code in a project). While lots of the criticism of AI software is directed at the former, he argues, the real progress is being made with the latter, as “serious LLM-coders” are integrating AI into their projects in ways that allow agents to absorb context and create close-to-passable code at breakneck speeds.
However, there are some things about Ptacek's argument (and about the bigger picture with AI) that still don't sit quite right with me. I may not have been shipping software since the 90s like Ptacek, but my experience as both an engineer and a scholar gives me some perspective about all this stuff. Plus, I can't help but think that I’m not alone in my objections. This post is my effort to get them out in the world.
First off, I should clarify that I am not an “AI skeptic”–at least, not in the sense that Ptacek describes. While there are still legitimate questions over the degree to which LLMs can help software engineers, I think it's fair to say now that they can, in the right settings, produce some useful code. I don't think AI is a fad. We've opened Pandora's box, and there's no going back. But given that we as an industry now seem to be past the point of no return on our attachment to the AI world, I think my concerns are all the more important to voice.
We’re Stunting Our Ability to Learn
One of Ptacek’s primary points in favor of AI-assisted development is that it allows engineers to bypass the time spent getting a project off the ground and go straight to “real” work:
I can feel my blood pressure rising thinking of all the bookkeeping and Googling and dependency drama of a new project. An LLM can be instructed to just figure all that shit out. Often, it will drop you precisely at that golden moment where shit almost works, and development means tweaking code and immediately seeing things work better. That dopamine hit is why I code.
To be sure, part of our job is working smarter, not harder, automating repetitive tasks and boilerplate so we can focus on core business problems. And as Ptacek rightly insists, working with AI doesn’t absolve engineers from understanding their codebases: you’re responsible for reading and understanding what an LLM outputs. No engineer should blindly accept what an LLM tells them, any more than they should blindly copy-paste from Stack Overflow.
Still, I can’t help but wonder: do I gain the same level of understanding through reviewing code that I do through writing it? The more I work with agents, am I going to be more tempted to “skip ahead” over the painful head-scratching parts of app development just to get to that “golden moment where shit almost works”? If I go too far down the LLM path, will I be less equipped to handle the situations where AI comes up short? My dopamine comes not only from seeing things work better, but also from deepening my understanding of the tools I’m using and how they work.
I spent most of my college years outside of tech, reading Latin and Greek. Learning these languages requires an understanding of how their fundamental building blocks (words) form relationships with each other to create larger structures of meaning (sentences, paragraphs, texts, etc). To build their skills, students memorize tables of noun declensions and verb conjugations, as well as lists of vocabulary words. Armed with an understanding of the different forms that words can take, the knowledge of a good number of word definitions—plus the ability to make educated guesses on unfamiliar words and phrases—and a basic understanding of the historical context in which texts were written, they read and analyze texts thousands of years old. These are difficult languages that require persistence and discipline to absorb. My fellow students and I would often complain about the amount of effort it takes just to read a single sentence written by a Roman author like Cicero or Tacitus.
This was the 2000s, and the digital revolution had made it to classical language study. We had access to online sites like the Perseus project and Whitaker's words that offered side-by-side Latin-English texts and quick lookup of vocabulary. They were great resources to frazzled students trying to get their homework done, but instructors typically frowned upon them as crutches that would hinder learning progress. I'd be lying if I said I never used Perseus or Whitaker’s, but I tried my best to limit their usage to when I was really stuck. And when I did use them, I made a point to internalize what I was looking up. For translations, I would map each Latin word or phrase to its English equivalent in the translation to make sure I could see how nouns declined, verbs conjugated, and different sentence clauses were constructed. For new vocabulary words, I would make a point of writing down a new word with its translation in a notebook, so that the act of writing it down would help me internalize it.
Since translation is never 1:1, tools like Perseus and Whitaker’s words can only provide a Latin/Greek student so much help. It is always necessary to piece together the bigger picture and understand wider contexts of the individual words and/or phrases that Latin/Greek students capture quick translations for. Moreover, access to those quick translations can easily present an impediment because they give the illusion of easy answers at the click of a mouse. In reality, there is value to more laborious processes such as looking up words in a paper dictionary, cross-referencing grammar tables, and drilling flashcards. Repetition breeds familiarity, and especially when you’re learning something new, this is essential. In my experience, the exercise of writing in itself provides knowledge that will help you improve the next time around. If you hand that first writing off to an LLM, are you going to be able to iterate on it as efficiently as you would have if you had written it yourself the first time around?
My concern is that even if AI coding agents—when adequately configured, monitored, and fine-tuned—can provide a useful tool for those who already know what they’re doing, they will leave significant gaps in the education of those who are still learning. (I count myself in both camps.) Those gaps will not necessarily be immediately evident, as tacit assumptions, blind spots, and shortcuts can easily contribute to boiling frog problems that don’t become necessary until they pile up. Sure, this already happens with human-written code. But it will likely happen a hell of a lot more with AI-written code.
Believe me, I’m no fan of all the hassle of initializing a new project. I don’t want to spend my day setting up a new git repository, scaffolding the folder structure, pulling in dependencies, setting up databases, then screaming as my app fails to build even though I did everything right according to the documentation. But I also can’t help but think that, well, that’s part of the job. So much of the message around AI is that you can skip the more “tedious” parts of software development—or the parts that you just don’t want to do—and jump straight to the “important” things. And I totally agree, up to a point. But part of the process of what we do involves going through the work to determine what is important and what can be automated. Without some familiarity with setting up all those pieces, you’re always going to be at a disadvantage. Like memorizing grammar tables and vocabulary lists, there is value in experiencing some of the tedium of app development. Once again, those who already have that experience will find benefit in AI handling the tedium for them, but newer learners are going to be forever reliant on agents to do all the heavy lifting for them.
I know that this probably sounds a bit like a grizzled old man’s “when I was in school, I had to walk fifteen miles uphill in the snow” argument. I’m not trying to trumpet my toils as a badge of honor, but rather to comment on what sorts of practices tend to be more helpful for deep learning. AI is already eroding those practices among students today, and possibly also limiting our brains’ cognitive abilities.
You might also think that if AI stunts learning, then maybe we should just not use it when we’re learning something new, and take full advantage of agents for our day-to-day work where customers and stakeholders are asking for quick returns. I am currently working through a side project in Rust, and turning off AI-assisted coding so that I can experience building on my own and getting some level of muscle memory writing in the language. But I’ve never found it easy to separate the processes of learning and executing in my day-to-day work. I am learning new things and sharpening my skills and building my knowledge every day, even when I’m working in a language that I have years of experience in. How can I know what to foist off on AI when I am continuously developing my own knowledge of the tools I work with? Frankly, the process of learning is why I love this profession. I do worry that AI will take this away from me.
We neglect the “boring” parts of our work at our own peril. When I work through a project and develop an understanding of what can and can’t be automated away, I not only improve the project I work on, but I also gain skills and experience that will help me in future work. Without gaining personal growth, how is delivering a faster-shipped product actually helping me? Boosters tend to dismiss concerns over AI taking jobs as stick-in-the-mud Luddites—or, in Ptacek’s case, the angry redneck from South Park—but I see over-reliance as a more likely path for engineers to be replaced by AI. When engineers, particularly newer ones, hand more of the learning process off to AI agents, it makes it easier for people like Ptacek to equate them with a cursor.ai subscription. As our leaders constantly preach AI as a vessel for company and industry growth, we as engineers must continue to emphasize that human growth has value in and of itself.
I'm well aware that, in spite of all their problems, LLMs are not going away any time soon. But I'm sick of pretending like this is entirely a good thing. Honestly, if the price of AI is a workforce unable to think critically, I’d be alright with writing a little more tedious boilerplate. I'd probably even find ways to optimize the tedium without LLM assistance. If we do have to live with these tools, let's stop raving about how much more productive we'll be and start talking about ways they can help us truly grow.