How the htmx creator uses an LLM as a junior developer

A breakdown of the four-part framework for delegating coding tasks to an AI, including the specific prompts used to add a new feature to the htmx library.

The creator of htmx, a popular front-end library, used GPT-4 to add a new keyboard shortcut feature. The process, detailed in an essay on the project's website, treats the Large Language Model not as an oracle but as an eager, slightly incompetent junior developer. This method of delegation required a specific, iterative framework of prompting and refinement to produce functional code.

The entire interaction, from initial prompt to final, working code, serves as a concrete model for technical founders looking to integrate AI into their development workflow without ceding architectural control. The core skill demonstrated is not coding, but effective management of an artificial programmer.

Scoping the 'Zone of Ignorance'

The process began by defining a task the author understood conceptually but had not implemented before: adding support for the aria-keyshortcuts attribute. This targeted a specific “zone of ignorance,” a well-bounded problem perfect for delegation. The author knew what the final code should do and where it should fit within the existing codebase, but did not know the precise implementation details.

This initial scoping is critical. The author did not ask the AI to design a feature from scratch. Instead, they provided the strategic direction and architectural constraints, asking the AI to handle the tactical execution. The first prompt was a direct command: “I want to add support for the aria-keyshortcuts attribute to htmx.”

Iterating from a flawed first draft

The AI’s initial output was plausible but incorrect. It hallucinated an htmx event, htmx:keystroke, that did not exist. An inexperienced developer might have been blocked. The author, possessing deep context, immediately spotted the error.

Instead of discarding the output, the author corrected the AI with a follow-up prompt. The key was providing specific, corrective context: “you are hallucinating the htmx:keystroke event. There is no such event in htmx. I need to listen for a global key down event and then find the element that has the matching aria-keyshortcuts attribute and dispatch an event on it.” This is the central loop of the playbook: generate, verify, correct, and regenerate.

Providing context to refine code

Subsequent prompts continued this pattern of adding context. The author uploaded the entire htmx.js source code to give the AI full project awareness. With this context, the AI produced a much better second draft. It still contained a minor bug, which the author again identified and described in plain English.

The author then guided the AI to place the new code within the existing processNode function, ensuring it integrated cleanly with the library’s architecture. The final working code was the result of four or five iterative cycles of this conversational refinement. The author frames the interaction not as a one-shot command, but as a dialogue with a junior developer.

Using the AI for documentation

Once the code was functional, the author used a final prompt to pivot the AI from code generation to explanation. They asked it to “explain this code.” The AI generated a clear, concise summary of the feature it had just written. This turns the tool into a documentation assistant, ensuring the human developer fully understands the code before committing it. This step is a forcing function for comprehension, preventing the integration of black-box code into a project.

The investor read

This essay demonstrates that the primary leverage from current LLMs for software development is not autonomous code generation, but a dramatic increase in the productivity of senior developers. The playbook requires deep domain expertise to spot AI errors and guide the output. This suggests the defensible moat is not access to AI, but the skill to manage it effectively. For investors, this signals opportunity in devtools that structure and streamline this iterative human-AI workflow. It also recalibrates the threat to SaaS incumbents; AI is less likely to create a drop-in replacement and more likely to act as a force multiplier for well-managed, experienced teams. For bootstrapped founders, this workflow represents a significant reduction in the need for junior engineering hires, lowering operational expenses and enabling smaller teams to build more complex products.

Pull quote: “The author frames the interaction not as a one-shot command, but as a dialogue with a junior developer.”