Random thoughts
Short, unfiled notes
Things worth writing down that don't need a full essay.
The AI paradox in software craftsmanship
Generative AI promises real speed in software engineering, but the way most people use it works against their own skill. Guess-and-check prompting hands the actual thinking to the model: the architectural decisions, and the edge cases nobody thought to ask about. The code that comes out often looks finished. It can also be the version that falls apart the moment it meets real load.
Prompting deserves to be treated as a discipline, not a chat. A one-shot result, a prompt that produces a complete, working solution first time, means holding the whole system in your head before you write a word. The constraints go in up front (type safety, failure modes) instead of being left for the model to guess. You map the inputs and edge cases before you hit generate, and you write clearly enough that none of it gets lost. Get that right and prompting looks less like magic and more like seniority. The AI becomes a fast way to carry out intent you already understood.
The risk is teams drifting into passive consumption, where nobody holds that understanding anymore. One practical guard is asking a few pointed competency questions once a story’s spec is drafted, before anyone starts building. Left to answer alone, people will happily let an AI do it for them. Answered in pairs, the same questions turn into something closer to an architectural review, because you can’t fake explaining your reasoning out loud to another person the way you can paste a response. The conversation naturally drifts from what was decided to why it was decided that way. It’s also one of the few places left where a junior engineer gets to watch a senior one simulate failure modes in real time, rather than just reading the result.
Tight upfront prompting and paired validation, used together, let a team get the speed AI promises without trading away the judgement that makes the speed worth having.
Prompt precision as a design skill
A prompt that works on the first try isn’t luck. It usually means you already had a precise mental model of the thing you were building before you typed a word, and you folded that model into one instruction that holds together.
Software craftsmanship has always rewarded people who can state a problem clearly before touching a keyboard. Prompting just makes that skill visible in real time. When an AI returns a subtly wrong answer, the fault is often in the prompt rather than the model. The prompt is reflecting a gap in your own specification, one you would have hit anyway a few commits later.
A prompt that lands cleanly on the first pass also has to carry the constraints a careless implementation would skip, like type safety and proper error handling. Writing those down before generation is system design, not a shortcut around it. Vague prompts produce vague code. So you cut the fluff and say exactly what you mean, which is the same habit that makes code readable in the first place.
None of this replaces the underlying skill. Knowing what to ask for, and knowing whether what came back is actually right, still depends on how well you understand the problem. What a well-scoped prompt buys you is an AI acting as an extension of that understanding rather than a chat partner you keep having to correct.