My LinkedIn says “Senior Software Engineer.” My screen time says I spent 14 hours this week talking an AI coding assistant out of various wrong turns, or not catching it in time and just having it redo the work.
Twenty years into this career, I’ve debugged production systems at 2 AM, untangled spaghetti code left by developers who apparently hated whoever came after them, and survived multiple rewrites of the same application. None of that prepared me for becoming an “AI psychologist.”
The pitch was “AI handles the grunt work and you focus on the interesting problems.” What actually happened is more interesting than that, and better than the cynical version too. AI does handle a lot of grunt work. It also creates new grunt work. And the actual job, the part nobody put in the description, is learning how to think before you prompt instead of just typing what you want and hoping. It’s like working with an intern who graduated top of their class, has read every book, and will confidently tell you the database should be stored in a spreadsheet. Unless you prepare ahead of time.
The LeadDev piece on the “just one more prompt” era called the loop “uniquely rewarding, and exhausting.” A cognitive slot machine. But here’s what took me embarrassingly long to figure out: most of the time I was pulling the lever was on prompts I should never have written that way in the first place.
- The Diagnosis: How Did We Get Here?
- The Patient Files: Tool-by-Tool Therapy Notes
- What I’ve Learned About AI Psychology
- I’m Also the Patient
- The Rubber Duck That Talks Back
- The Prognosis: Am I Better Off?
- The Therapist Is In
The Diagnosis: How Did We Get Here?
I’ve been writing code since the late 90s. I’ve seen client-server, I’ve seen web 1.0, I’ve seen web 2.0, and I’ve seen the mobile revolution. Each shift changed what developers do. None of them changed what developers are.
This one might.
Not because AI writes code better than me, but because the cognitive overhead of working with AI tools created a new layer of professional skill that nobody put in the job description. The McKinsey State of AI report (November 2025) found that companies are still largely “experimental” with AI adoption. Which sounds measured and responsible. What it actually means is that every developer on the ground is both guinea pig and architect, figuring out in real time how to integrate tools that weren’t built for how software actually gets made.
I didn’t sign up to be a therapist. I signed up to build things. But here I am, maintaining relationships with seven different AI assistants, each with its own personality, its own particular flavor of wrongness, and its own emotional needs.
And here’s the thing: once I stopped fighting that and started working with it, my output went up. Not “marketing-deck up.” Actually up. I ship more in a week than I did two years ago. I just had to give up the fantasy that I could type a vague request and get a clean result.
The Patient Files: Tool-by-Tool Therapy Notes
I’ve spent serious time with most of the major AI coding tools. Each one has a personality. The trick is learning to talk to that personality on purpose instead of getting mad at it for being itself.
Claude Code: The Eager Intern
Claude Code is the overconfident new hire who graduated top of their class and has read every design pattern book ever written. It will absolutely take on your task and complete it thoroughly, thoughtfully, and sometimes in a completely different direction than you intended.
Tell it to add validation to a form field and it will:
- Add validation to the form field
- Notice that your component structure “could be improved”
- Refactor the component
- Update all 14 imports
- Create a new utility file for “reusable validation logic”
- Rename your API endpoints because they were “semantically inconsistent”
- Present you with 847 changed lines for what was supposed to be a 3-line fix
For months I’d push back after the fact: “no, just the validation, undo the rest.” That worked, sort of, in the same way bailing out a leaking boat works.
The fix wasn’t a better correction. It was a better opening. Now I tell it the scope before it touches a file: “Add email validation to this component. Don’t refactor anything. Don’t touch any other file. If you see something else worth changing, list it at the end and I’ll decide.” That single sentence cut my “wait, why did you change that” moments by something like 80%. The intern is still an intern. I just stopped letting it freelance.
GitHub Copilot: The Golden Retriever
Copilot is enthusiastic. Copilot is always helpful. Copilot will auto-complete you into a corner and wag its tail while you figure out how you got there.
It’s the tool equivalent of a golden retriever fetching the wrong stick. You asked for a stick, you got a stick, it’s technically a stick, the dog is very happy about this. The stick is on fire and has three undocumented dependencies.
Copilot auto-completes based on pattern recognition, which means it will confidently suggest code that looks right and is subtly wrong. The lesson I had to internalize: Copilot is amazing at the second half of a line and dangerous at the second half of a function. So I let it finish what I started typing and I stop trusting it the moment it tries to finish what I was going to type. The energy I was burning fixing its longer suggestions is gone now. I just don’t accept them.
GPT-4: The Know-It-All Who Never Reads the Room
I have a specific GPT-4 interaction that lives in my head rent-free.
Me: “What’s the ternary syntax for: if x > 0 return ‘positive’ else return ‘negative’?”
GPT-4: “Great question! The ternary operator is a concise conditional expression available in many programming languages. Before diving into the syntax, it’s worth understanding why ternary operators exist and how they differ from traditional if-else statements. The ternary operator was first introduced in C and has since been adopted…”
Four paragraphs of history later: x > 0 ? 'positive' : 'negative'
GPT-4 knows a tremendous amount and has zero ability to calibrate how much of that knowledge you need at any given moment. It’s the smartest person at the party who cannot tell when you’re making small talk versus when you actually want a lecture. The fix is in the prompt, not the response. “One line of code, no explanation” stopped feeling rude the second I realized it saved me ninety seconds per question. Multiply that by a workday.
What I’ve Learned About AI Psychology
This is where the article shifts from venting to the part that actually changed how I work. Almost every problem I had with these tools turned out to be a problem with how I was opening my mouth.
Framing Beats Specificity
I used to think the answer was being more technically specific. Add more constraints. Spell out more requirements. That helps, but it’s not the lever. The lever is framing. The gocodeo.com breakdown of prompt psychology calls this cognitive programming through language: framing effects that change what the model pays attention to before it generates a single token.
“Add validation to the email field” gets one result. “You’re a senior backend developer who hates form bugs. Add minimal, focused validation to the email field. Don’t touch anything else.” gets a different result. The technical ask is identical. The framing changes what shows up.
Contextual Anchoring Actually Works (Embarrassingly Well)
Seeding prompts with identity (“you’re a senior React developer who hates class components”) works. This bothered me philosophically for a while. But it works. There’s actual research behind it: schema activation, attention focus, cognitive priming applied to LLM behavior.
But I still don’t do it every time. It still rubs me the wrong way. “You’re a developer who prefers minimal changes. We’re using React hooks only. This codebase has fragile integration tests. Don’t change anything not directly related to the task.” The context window is not your friend, and the AI has the memory of a goldfish. Re-establishing ground rules at the top of a session takes thirty seconds and saves an hour of cleanup.
When Iterating Doesn’t Work, Give It an Algorithm
This is the one that took me the longest to learn, and it’s probably the most useful thing in this article.
For months, I experimented with getting AI to write articles to a target word count for another site I am building. The conversation was always the same:
Me: This is 1,400 words. I asked for 2,000.
AI: You’re right, I’ll expand it.
Me: Now it’s 2,300.
AI: My apologies, let me trim.
Me: 1,650.
AI: Sorry, expanding now.
Me: …
I cycled through that for months. Yelling at it. Trying different ways to phrase “actually count the words.” It would confidently agree, recount, and miss again. I was treating it like a person who wasn’t listening, when the actual problem was that it had no reliable way to do the thing I was asking.
Eventually, I stopped asking it to count and started giving it an algorithm:
When you write the outline, assign a target word count to each H2. The targets must sum to the total. As you write each section, stay within ±10% of its target. Tally section counts as you go.
From then on, perfect. Every time. The AI didn’t get smarter. I stopped asking it to do something it couldn’t do reliably and gave it a procedure that turned the task into something it could do reliably.
That moment reframed the whole job for me. The pattern is: try a thing once or twice. If it keeps going wrong, the question isn’t “how do I correct it harder,” it’s “what algorithm or scaffold turns this into something the AI can do without me babysitting?” And if it’s something I’m going to do over and over, that scaffold becomes a skill, something I write once and stop re-explaining.
The mental shift: stop arguing with the model. Build the rails the model needs.
The Trust Paradox
The actual skill isn’t prompt engineering. It’s knowing how much rope to give the agent before it hangs your codebase.
Too little rope: you’re basically typing the code yourself and having the AI format it.
Too much rope: you come back to 847 changed files, a refactored architecture, and the sinking feeling that you need to review all of it before you know if your feature even works.
The right amount of rope is context-dependent, tool-dependent, and something you only develop by making expensive mistakes. The good news is the mistakes are educational. The first time you let the AI invent your architecture and then have to ask it how its own code works, you start designing the architecture yourself again.
I’m Also the Patient
Here’s the part I don’t see written about enough: a lot of the time, the AI isn’t the one derailing the session. I am.
I’ll be deep in a clean refactor, the AI is on track, the diff is small and tight. And then I’ll think of something tangentially related and just… ask. “Oh, while we’re here, what do you think about how we’re handling auth in this other module?”
Twenty minutes later we’re three modules away from where we started, the context window is full of auth opinions, and the original refactor has been quietly forgotten by both of us. The AI is happy to follow me anywhere, which is exactly the problem.
I learned to recognize the moment now. The second I notice I’ve yanked the conversation onto a new track, I stop, close the session, and start fresh. The original task gets a clean room. The new question gets its own room. Trying to do both in one session is how I end up with garbage in both.
This is the part of “thinking before you prompt” that’s least about the AI and most about me. The model has no scope discipline. So I have to bring my own and notice when I’m the one breaking it.
The Rubber Duck That Talks Back
Rubber duck debugging is a real technique. You explain your code to an inanimate object and in the process of explaining, you find the bug yourself. The object doesn’t help. The explanation does.
AI pair programming is rubber duck debugging if the rubber duck argued with you, gave you bad advice confidently, and you had to diplomatically respond “that’s an interesting perspective, but I’m going to go with my original approach.”
That sounds bad. It actually isn’t. The argument is the value. Forcing me to say “no, we’re not using Redux for this, here’s why” surfaces my actual reasoning in a way that staring at the screen doesn’t. The AI isn’t right. I’m not even trying to convince it. But explaining why it’s wrong is doing the same thing the rubber duck does, with more friction and more upside.
And sometimes the AI is right. Helpfully right in a way that saves you an hour. That’s the slot machine moment people warn about. Just one more prompt. It’s almost there. The developer frustration data from programming-helper.com shows the pattern: hallucinations and “almost correct” output keep developers engaged because the occasional win pays for the losses.
The way out of the slot machine isn’t quitting the casino. It’s noticing the loop and breaking it on purpose. After two iterations that don’t land, I stop. Either I write the thing myself, or I step back and figure out what algorithm or scaffold the AI was missing. Pulling the lever a third time, hoping this prompt is the one: that’s where the day disappears.
The Prognosis: Am I Better Off?
Yes. Honestly, yes.
When it works : starting projects from scratch, generating documentation and boilerplate, the “army of interns with PhDs” feeling. When I’m building a new service and need structure, tests, config, and scaffolding: AI tools are genuinely useful. I build faster. I cover edge cases I’d have missed while moving quickly. The ceiling on what one developer can ship in a sprint has gone up in measurable ways.
When it doesn’t : legacy code with context that doesn’t fit in a context window. Anything where “almost correct” compounds across multiple sessions. When the AI “improves” working code because it can see a better pattern. Any problem where the truth lives in production state rather than the codebase. And anything where I haven’t done the thinking work up front about what I actually want and how to frame it.
That last category is the one I have control over, which is why this article isn’t a complaint. The first time I had to sit and plan a prompt like I’d plan a meeting, I felt ridiculous. Now it’s just the job. Think about what I want. Think about what the AI is likely to do with each phrasing. Think about what scope I’m authorizing. Think about whether this is a one-off or whether I should encode it as a skill so I never have to think about it again.
Any developer can learn the tools in an afternoon. The actual skill is the thinking that happens before you type the first character: anticipating how the model will react to your framing, your scope, your context. That’s not a technical skill. It’s a human skill applied to machines. And it’s the part nobody handed me a manual for.
That’s what I mean by therapy. Not “the AI is broken and needs my emotional support.” More like: the relationship has its own dynamics, and learning to work inside those dynamics on purpose is the difference between a week of cleanup and a week of shipping.
The Therapist Is In
Twenty years ago, I worked with a coding language, a laptop, and a manual. Today I sit down with seven different AI assistants and a mental playbook for each one.
Some days I miss the simplicity. Most days I don’t. I ship more, I cover more ground, and the failure modes are at least new failure modes instead of the same legacy spaghetti I’ve been untangling for two decades.
The lesson isn’t “AI is hard.” It’s “I had to stop typing what I wanted and start thinking about how to say it.” Once that clicked, the slot machine quieted down. The intern stopped freelancing. The golden retriever stopped lighting sticks on fire. The know-it-all gave me one-line answers.
If you’re reading this and thinking “yeah, that’s my Tuesday,” welcome to the profession. We’re all AI psychologists now. The good news is, you can get good at it. The job is mostly thinking before you prompt, and that’s a skill, not a personality trait.
Top comments (0)