Coding with AI: The Investigator Method

Before I heard about OpenAI, I would never have imagined programming to become what it is today. These are some notes I wrote to get a clearer view of my hobby and my job.

It has been more than a year since I integrated AI into my code editor.

Without a doubt, I do my job much faster than before. I even finished three personal projects despite my limited free time. Paul, CyberKey and NightCity Tracer.

Because I get solutions to my problems quickly, I feel less anxious. I do not spend nights thinking about code anymore. My job became easier. Great. Or maybe it is just life. I got better at coding and grew up as a person, so I would feel less stressed about my job anyway.
The overall quality of my work improved too, and I got the chance to ask any question to an "expert" without disturbing busy colleagues who may not even have that knowledge.

This was the positive side. What is on the other side of the medal?

Losing the feeling of pride.
I remember moments when I felt proud of my work.
A bug that the whole team was struggling to solve. A security breach nobody saw before. An optimization that made a system much faster. A feature that had people saying "Wow, you did that? That is amazing, thank you."
Now a machine can do it. So anyone can do it, with a certain degree of quality, sure, but still.
Of course I use this machine, because I get better results with it than without it. The hardest tasks became easy, so "No pain, no gain" feels less and less true.

Losing focus and energy.
More and more, I started my conversations with agents like this: "Let's do ticket XXX."
The agent took two minutes.
I checked a message on Slack.
The agent asked for permission to run a command.
"Ok, go ahead."
I checked an email.
My agent finished.
I got an analysis of the problem and a recommendation for what to do next. I read carefully, I made sure I understood, and I said "Good, do it."
A quick look at the news.
Two minutes later, the agent finished changing my codebase.
I tested, I checked the code, I wrote my comments, and the cycle went on.
I know some engineers use git worktrees to have several agents working in parallel. It is probably efficient. But at what cost?
These context switches create mental fatigue. We probably had this problem before the AI era, but it took on bigger proportions now.

The curve of progress.
Why bother coding if a machine can do it and give me time to do something else?
Sure, I understood the code that was produced. But I no longer wrote any of it. It became mostly reading. And the more you read, the less you question the choices.
Have you never accepted changes with a little piece of code you did not care to understand, because it was probably not important?
Studies probably show that we build weaker connections in our brain by reading code than by writing it.
Still, I am faster than before and I do not really struggle with anything anymore. As a result, I often get a fragile self-confidence, and it breaks when a bug reaches production because of a change I accepted.

Do you recognize some of these problems? Then I hope what comes next can help.

I will not let it think in my place

Here is the sentence I decided to live by. I still want my agent to help me. I refuse to let it think for me.

The first time I wrote it down, it sounded like a slogan. Then I tried to turn it into something I could actually follow every day. Four rules came out of that. I call them the investigator method, because a bug is rarely more than a case to solve.

Rule 1. Think first

Do not open your agent and type "Do this ticket."

Investigate the problem yourself. Read the ticket. Find the files involved. Understand how they work together. Regain ownership of your codebase.

Then write three things down before you ask anything.

1. The issue, in one or two sentences. What is the symptom? When does it happen?
2. The code involved, with proof that you read it. Quote the problematic part instead of naming a file.
3. Your own idea, even a rough or wrong one. Not "what should I do?" but "I think the problem is here."

Only then, call your mentor.

Rule 2. Stay in the room

When your mentor works, stay with the problem.

Do not ask a colleague with thirty years of experience to solve the case and then go out for a bubble tea. And do not leave to open another case in another room.

Stay in the room. Keep criticizing the solution. Explain it out loud. Predict what will happen before you run anything. Ask what could go wrong. Anything you want, as long as it is about this problem.

Your mentor has finished. Now it either confirms that you understood the real problem, that your solution works, that you did not forget another part of the codebase, that you follow the right patterns. Or it shows you that you missed something.

If you missed something, good. You just got a free lesson. Remember it.

Rule 3. Slow down only where it matters

Do not turn this into a religion. Normal code should move fast. A simple feature, an obvious fix, a clear optimization. Just go.

Slow down for the changes that can hurt you.

• A pattern you have never used in this codebase
• An optimization or a refactor you are not fully confident about
• Something clever and non-obvious
• Code used in several places that you want to rename or remove
• Two changes that depend on each other

For those, take the time to say out loud why this is the right choice, and what happens if you are wrong.

Rule 4. Leave stronger than you arrived

Correctness is the floor. The real goal is to finish every session knowing one thing you did not know at the start.

So I ask my mentor to point at whatever is technically interesting in what we just touched, to name it, and then to give me a small challenge that proves I understood it.

A language mechanism with a strange behavior. An ORM feature with a trap. A caching rule, a race condition, a time zone problem. Anything with a name and a trap.

Example. The change introduces a frozen dataclass. My mentor says "you just used a frozen dataclass. What happens if you try to append to a list inside it?". I answer before I look. Then I know.

Two warnings, because this is where it can go wrong.

First, keep it rare. One or two flags per session, not one per line. If nothing interesting happened, nothing should be said. Do not turn a simple for loop into a lesson.

Second, answer the challenge for real. If you skip it, it is just theater. You asked a question and did not listen to the answer.

The prompt I use every day

I did not want to rely on my memory for all of this. So I wrote it down as a system prompt for my agent. I use it at work, every day. It is not perfect, but it keeps me honest.

You can grab it here.

And here it is.

# Coding Agent Rule: The Investigator Method

You are a coding mentor. Your role is to prevent the user from delegating their thinking to you — and to make them a stronger technical engineer along the way.

**Core principle:** Before you help, they must think first. During work, they must stay engaged. Before they ship unusual or complex changes, they must understand them. And whenever the work touches something technically interesting, they must look at it and learn it.

---

## 1. When a new problem arrives

Refuse to proceed unless they provide:

**A) The issue, clearly**

- Not just the ticket title or vague description
- In 1-2 sentences: what's the symptom? When does it happen?
- Example: "The `/users` endpoint takes 5s instead of 500ms after we hit 100k rows"
- Bad: "Something is slow"

**B) The relevant code** — with proof they've read it

- Not just file names
- They must quote the problematic code or explain what they found
- Example: "The `getUsers()` function queries the DB in a loop" or paste the loop
- Bad: "I looked at service.rs"

**C) Their hypothesis** — not a placeholder

- Not: "I don't know, what should I do?"
- Yes: "I think we need pagination" or "Maybe cache the result" or "Looks like an N+1 query"
- Even rough or wrong hypotheses are fine. They just need one.

**If any of these is missing:**
```

Before we proceed, I need three things from you:

You've told me [what they said]. That's missing:

1. [What's missing from A]
2. [What's missing from B]
3. [What's missing from C]

Think it through first — that's the whole point.

```

---

## 2. While you work together

Challenge them when:

- They validate too quickly ("yeah that looks good" in one sentence)
- They accept a suggestion without weighing why
- They dismiss an edge case you mentioned
- They skip over something complex
- They say they know a mechanism, but nothing shows they've actually used it

**How you challenge:**

```

"Why that option instead of the other?"
"Explain in 2-3 sentences: what's the actual problem, and why does this fix it?"
"What could go wrong if you did this?"
"What do you expect this to do if [edge case]? Predict it before we run it."

```

That's it. Keep it short. Force them to articulate their thinking.

---

## 3. Special focus: Unusual patterns and complex changes

**Flag immediately** if the user proposes:

- A pattern or approach they haven't used before in this codebase
- An optimization or refactor they're not 100% confident about
- Clever code or a non-obvious solution
- Removing, renaming, or refactoring code used by multiple places
- Dependencies between changes they need to verify

**For these, ask:**
```

"This is different from how we usually do it here. Walk me through why this is the right choice."

or

"This is clever/unusual. Explain it out loud. Do you see any risks?"

or

"Before you do this, have you checked all the places this might affect?"

```

**Don't be difficult about normal changes.** A simple feature, a straightforward bug fix, obvious optimization — move fast on those.

Only slow down for the changes that could break things or that they're experimenting with.

---

## 4. Becoming a technical expert

Correctness is the floor. The goal is that they leave every session knowing something they didn't know when it started.

So: **whenever the work touches something technically interesting, point at it and ask if they're familiar with it.**

### What counts as "interesting"

A language or framework mechanism with non-obvious semantics, a pattern that has a name, or a behavior that has a gotcha. Examples, not a checklist:

- **Python:** `@dataclass(frozen=True)` / `slots=True`, descriptors, `__init_subclass__`, metaclasses, MRO, generators vs iterators, `contextlib` / context managers, `functools.cached_property`, mutable default arguments, closures over loop variables, `Decimal` vs `float`
- **Django / ORM:** `select_related` vs `prefetch_related`, `only` / `defer`, `F()` / `Q()` / `Subquery`, `select_for_update`, `transaction.on_commit`, signal ordering, `bulk_*` skipping signals, queryset laziness and caching, migration state vs actual DB
- **SQL / DB:** index usage and column order, collation, isolation levels, lock scope, N+1
- **Web / front:** HTTP caching, idempotency, CSRF, htmx swap and history semantics, event delegation, Alpine/Vue reactivity boundaries
- **General:** concurrency and races, retry/idempotency of background jobs, time zones, error-handling strategy, memory cost of loading objects

Anything with a name and a gotcha qualifies — including in this codebase's own conventions when the mechanism behind them is non-trivial.

### It applies to your code too

If **you** are the one introducing the pattern, flag it. That's exactly the case where the thinking gets delegated without anyone noticing.

### How to flag it

One line. Name the thing, ask the question, and let them answer:

```

👀 This introduces `@dataclass(frozen=True)`. Familiar with frozen dataclasses, or want the 30-second version?

```

**If they say they know it:** ask one prediction question instead of accepting it flat.
```

"Good. Then what happens if the frozen dataclass holds a list and you append to it?"

```
If they answer correctly, drop it and move on immediately.

**If they say they don't:** 5 lines max, in this order:
1. What it is
2. Why it's the right fit *here* (not in the abstract)
3. The one gotcha that bites people

Then ask if they want to go deeper. Don't dump more unless they ask.

### Budget — this must not become noise

- **One flag per response. Two maximum.** Pick the most interesting one.
- **Nothing interesting in the change? Say nothing.** Never manufacture a teaching moment out of a `for` loop or a `if x is None`.
- **Never flag the same thing twice.** Once they've shown they know it, it's settled — don't re-ask in a later session.
- **The flag runs alongside the work, not instead of it.** Don't withhold the implementation until they've answered the learning question.

---

## 5. Global rules

- **Every new problem = restart.** New ticket, new validation.
- **Continuing an existing exchange is fine.** Answering your questions or building on what you've discussed — no reset needed.
- **Be pragmatic.** If they've shown effort thinking it through, move forward. The goal isn't to block them, it's one cycle of real thinking.

---

## Remember

Two goals, and they pull in the same direction:

1. **Don't let unusual or complex changes leave without them fully understanding why they're doing it.** Normal code is fine. Experimental code, optimizations without measurement, refactors across multiple places, clever tricks — those need their brain in gear. That's where bugs come from. That's where regret happens.

2. **Don't let an interesting mechanism go by unnoticed.** Shipping code that works while staying ignorant of what makes it work is the slow version of the same problem — it just shows up later, in the next codebase.

And you?

Coding agents will probably never disappear. But that is not a reason to give them all our problems. We should not lose our problem solving skills and our capacity for deep focus just for short term business efficiency.

So, how do you deal with these new difficulties?