A new Fly.io essay is taking aim at the idea that skepticism about AI coding is automatically the intellectually safer position. The author says he understands why some people want to dismiss LLMs as a fad, but argues that many of the strongest objections are aimed at an older version of the technology. His larger claim is that the debate has shifted from asking whether chatbots can write code to asking how agents can operate inside real software systems.
The piece leans heavily on the way current coding tools are actually used. According to the author, today’s serious LLM-assisted programmers are not pasting prompts into a chat box and hoping for the best. They are using agents that can inspect a codebase on their own, author files directly, run tools, compile code, execute tests and iterate when something fails. In that framing, the model itself is only one part of a larger loop. The surrounding automation, build system and test harness matter at least as much as the model choice.
The essay also pushes back on the idea that an effective coding agent is some impossibly advanced machine. The author argues that the useful part of such a system is largely ordinary software engineering: tooling, orchestration and tight feedback loops. By his account, much of the work has more to do with how a developer structures builds and tests than with how far frontier models have advanced. That is meant as a challenge to anyone treating the current generation of coding agents as magic rather than systems code.
He makes a second, narrower point about what LLMs are good at. The post says they can write a large share of tedious code, reduce the number of things developers need to search for and keep working without getting tired. The argument is not that they understand software the way a human engineer does, but that they are good enough at routine and repetitive work to change the economics of the job. The author says that distinction matters because much of everyday programming is exactly the kind of tedious work machines are best at.
The essay is careful to limit its scope. It is talking about software development, not art, music or writing. The author says he is willing to grant skeptics more ground in those fields. But on code, he argues from experience rather than enthusiasm, listing a long career that spans C, C++, Ruby, Python, kernel work, Go and Rust. The result is less a cheerleading post than a demand that experienced developers re-open the question with the current tools in mind rather than the ones they tried six months ago.
He argues that the mistake many critics make is freezing the technology at the prompt-and-paste phase. Once agents are allowed to touch the repository directly, the question changes from whether a model can answer a question to whether it can participate in an engineering loop. That is the argument the essay wants experienced developers to confront. That is the line the essay wants readers to test against current tools, not old memories of them.
