One thing I’ve noticed in how I work with AI is that I do A LOT of iterations. And while I do give detailed prompts and ask Claude to interview me to develop an even clearer idea, I know AI is going to hallucinate extra crap regardless. And so iteration is just part of the process for me. The level of taste, specificity, and critique you bring to the output is what will decide the ultimate quality.
I’ve heard people claim that this process of iteration is essentially no different than if they had done it all themselves instead of using AI. I strongly disagree with that. In my experience, the work shifts from an act of generation to one of review. Perhaps it’s just how I use AI, but I find I get a lot done with it in a lot less time. I know how much time it would take me to do things by hand, and it’s probably 10X to 20X slower if I did, with a lot more discovery, learning, and refinement along the way. While I do care about the code, I care more about what the code enables. I don’t need to be the one writing it, but I do need to be the one specifying it.
Where I’ve seen people go wrong in their usage of AI, where what they produce is mediocre or needlessly embellished or complex, is that they stop after a first pass. I stop after maybe the hundredth, or thousandth. I keep going until it’s polished, and I bring a critical eye to everything it’s generated.
I don’t do much code writing anymore, and I do very little reading as well. But I do a lot more architecture, design, and QA. There are lots of things I don’t know, that I don’t need to or want to have to know: like how to integrate with a specific API, or performance improvements for a specific browser rendering. While I could dig into those specifics, I’ve been there/done that so many times in my career as a developer that I’d rather not learn more super-specific things only to never use them again. I care about the results, not the way. I do find I have to still emphasize good practices, composability, and performance, as Claude does not natively do those things unprompted.
I’m building my first game with an OSS game engine and am using Claude to do it, after having worked a lot with Unity doing more “productive” projects (I do not miss Unity’s quirks, though I did learn a lot from it). Claude’s done a surprisingly good job of generating art and music assets that I would not be able to generate myself. Not on the first pass, of course, but with a lot of back and forth it’s able to build on its previous generation and, with my guidance, arrive at something I like.
Iteration, in all of its forms and frequency, is my best advice for generating great results with Claude or any other LLM. I’ll write another post sometime about what those forms of iteration are, because in using Claude on a daily basis I’ve come to appreciate the limits of its knowledge/training and how to extend or work around them.
This isn’t to say that with enough iteration you’ll be able to achieve absolutely anything, like generating the next Skyrim or Google all by yourself. I mean, you’ll surely get to something, and it might be something worthwhile, but it won’t be like that. You must work in a scope where the specificity is manageable, knowable, and can be communicated/delegated to the LLM, or at the very least built up in the right layers or components. And this assumes that the LLM has enough training or abstract skill to work in the given domain.
So the next time you get AI to generate something for you, be wary of the early output. Be critical, demanding, and opinionated on what needs to be improved. An amateur considers the 3rd iteration good enough; a pro takes it to the 30th or 300th and probably starts over a few times.
]]>I’ve been using coding agents like Claude Code to do most of my development these days, with overall great success. This is a stark contrast to even a year ago, when LLM output was still prone to hallucinations around formatting and typos that broke the code it generated. But I can’t remember the last time Claude Code output didn’t at least run.
One of the things I’ve come to appreciate about coding with LLMs is I have greater control over how I want the code to work and be designed. Before LLMs I would have to spend weeks or more implementing a design decision, and maybe weeks or months if I had to refactor one. Now I can just tell the LLM to develop using web components, or via a classless framework, and it will happily go off and build these out. And if it was too ambitious, or not ambitious enough, or I changed my mind about something, changing the code is generally just a prompt away. The mechanical cost of trying an idea has collapsed. The thinking behind which idea to try has not.
And while I think this greater control over the design of software is a good thing, I recognize it is not automatic. When you prompt an LLM to generate a codebase, it will produce something. But the thing it produces is often an amateur version. It may throw in features you didn’t ask for, make assumptions about your architecture, or solve problems you don’t have. These additions can occasionally be helpful, but more often they’re overkill or simply noise.
As the recent Claude Code system prompt leak showed, LLMs are happy to create functions that are hundreds or thousands of lines long. And without guidance, they will keep growing these functions to be larger and larger. No human would ever write a single function that long. A human would feel the weight of it, the unreadability, and break it apart. LLMs don’t have that instinct. They just keep going.
LLMs still work best when there is a skilled human in the loop who can evaluate, critique, and guide what the LLM is doing. The time and cost of code generation has been dramatically reduced, but the skill required to produce quality has not gone away. Even if you prompt an LLM for “good design” or have it roleplay as a senior engineer, the decisions it makes still require a large amount of taste to assess whether it is making reasonable propositions or over-engineering for what you are trying to do.
Maybe that won’t always be the case. Maybe a year from now models will be that much better and all the decisions and thinking that engineers do when producing code will be a more natural part of the LLM output.
But just because we all have cameras in our smartphones, it does not make everyone a photographer. It also means one does not need a photographer to take a photo. Photography didn’t kill painting. It changed what painting was for. I suspect coding agents will do the same thing to software engineering.
]]>A similar thing happens on social media with transcription. The people in the video will say one thing, but the text you read on the screen will omit it or say something else. Or worse, they go the extra step of editing the audio as well, replacing or omitting the word they don’t agree with. And this isn’t just for profanity. Words like “Covid” and “Tiananmen Square” have a way of getting censored too.
This is AI-powered censorship, plain and simple. AI (and by extension the companies that leverage the models) is deciding what is and is not allowed to be expressed. Instead of faithfully transcribing what a person authentically said, it gets sanitized. In some instances, this sanitization may be warranted or welcome by the creator. But in so many others I’ve experienced, it totally changes the meaning of what someone is trying to communicate.
Given the nature of product development and technology, it’s not far-fetched to see this censorship as an attack on expression and free speech. Something that will only get worse over time. In the future, AI will take videos of people expressing thoughts or feelings and rewrite what they said. It’ll put words in their mouth, change upset faces to neutral ones, all to match how companies want people expressing themselves on their platforms. Truth itself will be controlled. There will be no ability to share reality, only the reality that companies decide to permit.
The tools for this already exist. It’s only a matter of time before companies incorporate this more deeply into their platforms. Users will adopt it because they either lack the control to say otherwise, or because it piggybacks on some other feature they actually want.
While I still have the opportunity to say it: fuck this shit.
]]>This is not to say there’s no role for using a library or framework; but it’s remarkable what you can accomplish with plain HTML, CSS, and JS these days—especially with Web Components available.
The benefit of building with simple technologies is that they are generally low in complexity, highly maintainable, and easy to manipulate. This lets you focus on what you are building, rather than how you are building it.
Of course, at a certain scale or level of complexity, you’ll eventually run into limits or frustrations and might wish you had leveraged something more modern. That’s fine—but wait until you reach that point, if you reach it at all. This is especially true when prototyping.
The truth is, many frontend frameworks and libraries are cumbersome and poorly designed or implemented. This is largely a function of the frontend ecosystem, where new “hot” tools appear almost weekly—but it’s also influenced by factors like resumes, branding, and the widespread adoption of flashy frameworks and libraries.
Don’t get me wrong: some libraries are focused and a delight to use. They do what they promise—and they do it well. They take hard or frustrating problems and make them easier to manage, removing a lot of manual labor. They have well-defined boundaries, are stable, well-documented, and battle-tested across the web. For certain problems, you’d be a fool not to use them. (This blog, for example, uses Jekyll, which compiles into a static HTML site.)
But there’s something to be said for having few-or no—dependencies to track or manage when building something. A splash of tasteful HTML and CSS, augmented with a sprinkle of JavaScript, can do a lot on its own.
Much of my career has been spent removing complexity and overengineering: converting specific technical decisions to generic ones, removing build steps, and optimizing the development experience for juniors.
If you can achieve your goals with the basics, there are many wins to be had. Knowing when to lean into simplicity and when to reach for something more powerful takes a pragmatic balance that can’t simply be conveyed—but embracing and celebrating simplicity wherever possible is an evergreen value worth upholding.
]]>Cost is not just money. It is time, effort, attention, willpower, and energy. Any finite resource must be spent deliberately. Every choice redistributes these resources, and the question is whether the cost is going where you want it to go.
The temptation is to pursue what looks cheap or easy. A feature can be built in a day. A tool can be integrated in an afternoon. A budget can be trimmed be reducing hiring. But building is only the beginning. Rollout, training, adoption, support, and long-term maintenance are never free. Costs are simply moved elsewhere, often where they are harder to see. In that sense, capital is sometimes the cheapest way to pay for things.
People often prefer the path of least resistance. It feels like progress without effort. It is seductive, but short sighted. The real costs, the meaningful costs, are rarely easy. They are slow, unglamorous, and require attention to detail and discipline to recognize and pay.
To lead well is to see costs clearly and make them intentional. Every action and inaction should be understood in terms of what is being spent and where it is going. Free lunches do not exist. The price is always paid. The question is whether you decide how it is paid or let circumstances decide for you.
Good strategy is about paying the right costs at the right time, deliberately, with clarity. Everything else is a gamble in ignorance.
]]>