Beyond Autocomplete

The default way most developers encounter AI is autocomplete — gray text appears, you hit Tab, code shows up. It’s useful in the way that any shortcut is useful. But it’s also the thinnest possible version of what AI can do, and it creates a misleading mental model of the relationship.

Autocomplete frames AI as a faster typist. The real value is closer to a collaborator who’s read every Stack Overflow answer, never gets tired of explaining things, and has no ego about being wrong.

Code generation is the least interesting thing

When you ask an AI to generate code, you get code. Sometimes it’s good. Sometimes it’s confident nonsense. Either way, you’ve positioned yourself as a consumer of output — evaluating what you got, accepting or rejecting it.

When you have a conversation with AI — about what you’re trying to do, why, what the constraints are, what you’ve already tried — you position yourself as a thinker who happens to have a very knowledgeable partner.

The difference isn’t subtle:

Generation mode: “Write me a function that validates email addresses.” You get a function. Maybe it’s fine. You don’t learn anything.

Conversation mode: “I need to validate email input. What are the tradeoffs between regex validation, a library, and just checking for an @ symbol and sending a confirmation email?” Now you’re in a design conversation. The AI might point out that RFC 5322-compliant email regex is famously unreliable, that most serious systems just send a confirmation, and that the “right” answer depends on whether you’re protecting a database or protecting a user experience. You come out with a decision you understand, not just code you have.

Software doesn’t have to be a pure function anymore

Here’s something that takes a while to internalize: before AI, the tools in your development environment were deterministic. The compiler did the same thing every time. The linter checked the same rules. The test runner ran the same tests. You could treat your tools as pure functions — same input, same output.

AI isn’t like that. You can ask the same question twice and get different answers. You can rephrase your question slightly and get a significantly better result. The output depends on context, phrasing, what came before in the conversation.

This bothers some developers. It feels unreliable. But the fuzziness is the feature, not the bug. It means you can work with intent rather than specification. You can say “this doesn’t feel right” and the AI will engage with that. You can say “explain it differently” and it will. You can describe what you want in imprecise, human terms and get something useful back.

The skill isn’t learning the right prompt syntax. It’s learning to think out loud.

Naming and metaphor

One of the most underappreciated uses of AI is as a naming partner.

Naming is design. When you name a class DataManager, you haven’t just described what it does — you’ve created a gravity well. Every developer who touches that class will think “well, it manages data, so my data thing goes here too.” The name gives permission for the class to grow in every direction. Six months later it’s 400 lines and does twelve things.

AI is surprisingly good at the naming conversation. Not because it generates better names (sometimes it does, sometimes it doesn’t), but because it can hold the context of what a thing does while you talk through what it is. You can describe the behavior, the constraints, the domain language, and iterate on names together. The dialogue is the value — it forces you to articulate what the thing actually is, which is the hard part. The name falls out of that.

One technique that works well: give the thing a placeholder name that’s obviously a placeholder. Use a food, an animal, whatever. “Tacos” is clearly not the real name. “DataManager” sounds real and lives forever. Then tell the AI: “When you think we have a better idea of what Tacos actually is, suggest a name.” The AI can track how Tacos is being used across the conversation and pattern-match against it as the design clarifies.

The conversation as the artifact

When you use AI well, the conversation itself becomes valuable — not just the code that comes out of it. The back-and-forth about tradeoffs, the rejected approaches, the moment where rephrasing the question revealed the actual problem — that’s the thinking that produced the design.

This is also why AI is better than documentation for certain kinds of knowledge transfer. Documentation is a monologue written for an imagined reader. A conversation is a dialogue shaped by what you actually need to know. The best explanation of your codebase isn’t a wiki page someone wrote six months ago — it’s an AI that can read the code right now and answer the specific question you actually have.