Where the Thinking Happens

Rethinking how we work with AI

Intro

Lately I’ve been running into the same situation over and over again.

Someone mentions that ChatGPT or similar tools have gotten worse. Less useful. Too vague. Too watered down.

At the same time, my experience has been different.

Not because the models are flawless, but because I seem to be getting something else out of them than what many people expect.
That discrepancy caught my attention.

Same tool, different experience. Not just slightly. Fundamentally.
I started noticing it everywhere. In conversations, comments, day-to-day work.

People approaching these systems with a clear idea of what they want, expecting straightforward execution… and then running into friction. Frustration. The sense that something is off.

Meanwhile, for others, that same friction seems to be exactly what makes the system valuable.

That made me wonder if the difference isn’t in the tool at all.

But in how we approach it.

The Observation

The pattern shows up in different places.

In casual conversations, it often starts the same way. Someone describes trying to use ChatGPT more seriously, maybe for work, maybe for coding, maybe just to explore ideas. And then at some point, the frustration kicks in.

It qualifies. It asks for clarification where none seems necessary. What felt like a straightforward request suddenly turns into a back-and-forth.

The same thing shows up in professional contexts as well. Developers trying to use it to speed things up. Generate code, move faster, reduce effort.

At first, it delivers. You get output quickly. It looks plausible. It feels like progress.

But that progress often doesn’t hold. Edge cases appear. Assumptions break. Pieces don’t quite fit together. What started as acceleration shifts into debugging, patching, and reworking.

That’s where the perception starts to change. The system no longer feels like a straightforward tool. It becomes unpredictable. Sometimes helpful, sometimes obstructive.

What stood out to me is that this pattern repeats, even when the context changes.

Different people. Different use cases. Same arc.

Fast output, followed by friction.
Expectation of execution, followed by resistance.

The Mismatch

At some point, I started to look at this less as a problem with the tool, and more as a mismatch between expectation and behavior.

Not in the sense that people are using it “wrong”, but that the expectations brought into the interaction don’t quite align with how these systems actually behave.

Most of the time, the interaction starts with a clear intent. A task to be completed. The expectation is straightforward: provide input, get output.

That mental model works well for many tools. You give a command, the system executes it. The better the tool, the more directly it follows through.

But that doesn’t seem to fully apply here.

Instead of simply executing, the system often pauses. It asks for clarification. It qualifies. It reframes the problem before attempting to solve it.

From the outside, that can feel like unnecessary complexity. Especially when the original request already felt precise enough.

But seen differently, it looks less like a failure to execute, and more like a system that doesn’t assume the input is complete.

It creates tension.

The user expects execution.
The system behaves as if further refinement is needed.

And that gap is exactly where the friction seems to emerge.

The Hidden Variable

At that point, another way of looking at it started to take shape.

If the same system can produce such different experiences, then the system itself isn’t the only variable.

Maybe the interaction is.

What if the outcome is not just a function of the model, but of how it is approached?

Seen from that perspective, the earlier mismatch starts to make more sense.

If you approach the system as something that should execute a well-defined input, then any request for clarification feels unnecessary. Any qualification feels like noise.

But if you approach it as something that operates on incomplete information by default, those same behaviors start to look different.

Asking questions is not hesitation.
Qualifying is not avoidance.
Reframing the problem is not resistance.

It is part of how the system arrives at an answer.

That shift in perspective changes the entire interaction.

The system stops being a passive tool that executes, and starts behaving more like an interface that reflects, challenges, and refines what is put into it.

Which means the quality of the output is no longer just tied to the capability of the model.

It is tied to the quality of the interaction.

The Shift in Skill

If the outcome depends on the interaction, then the question naturally shifts.

What matters is no longer just what the system can do, but what kind of input it is given.

And that, in turn, changes what it means to be effective when working with it.

For a long time, a significant part of software development was shaped by friction.

You had to remember syntax.
You had to write everything yourself.
You had to make things compile, fix errors, debug step by step.

A lot of skill lived in navigating that friction efficiently.

Writing clean code. Moving fast. Knowing your tools in detail.

That hasn’t disappeared. But it no longer seems to be the main constraint.

The bottleneck has shifted.

What matters more now is how clearly a problem is understood before any code is written. How well constraints are defined. How early edge cases are anticipated.

In other words, the focus moves from implementation to formulation.

From writing code to shaping the problem that the code is supposed to solve.

This also changes the role of speed.

It becomes less about how quickly something is produced, and more about how much rework is avoided.

In my own work, that shows up in a simple way.

I’m not necessarily faster.

But I’m more precise.

And that precision compounds.

A clearer design means fewer surprises.
Fewer surprises mean less debugging.
Less debugging means fewer iterations that lead nowhere.

The time isn’t saved at the beginning. It’s saved by not having to redo things later.

Which makes the initial slowdown deceptive.

From the outside, it can look like unnecessary overhead.

But it’s actually front-loading the thinking that used to happen after things broke.

Why This Feels Off

If this shift is real, then the next question is why it doesn’t feel natural.

Because for many people, it clearly doesn’t.

One possible explanation is that a lot of existing skill and confidence is tied to implementation.

Knowing how to write code quickly.
Being fluent in a specific language or framework.
Solving problems by directly translating intent into code.

These are not trivial skills. They take time to build, and they shape how developers understand their own competence.

A workflow that shifts the focus away from implementation can therefore feel like it devalues that competence.

Not explicitly, but implicitly.

Another factor might be habit.

For years, the dominant loop has been straightforward: think, write, run, fix.

The thinking happens, but a lot of it happens while writing code, not before.

Moving that thinking earlier in the process changes the rhythm.

It can feel slower. Less direct. Less productive, at least initially.

There is also a question of control.

Traditional tools execute. You give a command, they follow it. The system stays in the background.

These systems behave differently. They respond, question, reinterpret. They don’t just execute, they interact.

That can feel like loss of control, even if it isn’t.

And finally, there is expectation.

If the goal is speed, then anything that slows down the first step feels like a regression.

If the goal is precision, the same behavior starts to look like a feature.

That helps explain why the experience can feel so different.

Personal Working Model

At this point, the question becomes practical.

If the interaction matters, then how does that interaction actually look in practice?

For me, it rarely starts with a fully formed instruction.

More often, it starts with something incomplete. A rough idea. A direction that isn’t fully thought through yet.

Instead of trying to turn that into a precise request immediately, I use the interaction to refine it.

I describe the idea. I push on it. I see where it holds and where it breaks. I let the system reflect it back, sometimes in ways that expose gaps or assumptions I hadn’t noticed.

That process is not about getting an answer as quickly as possible.

It’s about arriving at a clearer question.

Once that question is clear, the actual implementation becomes much more straightforward.

In that sense, the system is less of a tool that executes, and more of something that helps shape the problem before execution even starts.

That doesn’t mean every interaction is perfect. Sometimes it drifts. Sometimes it needs to be corrected or redirected.

But that’s part of the process.

The goal is not to remove thinking from the workflow.

It’s to externalize it, so it can be inspected, challenged, and refined before it turns into code.

Reframing the Narrative

Looking at it this way, some of the common narratives around these systems start to feel incomplete.

The discussion often centers around whether the models are getting better or worse. More capable or more restricted. More useful or more limited.

Those questions are not irrelevant. But they miss something important.

If the interaction itself is a defining factor, then the experience cannot be explained by the model alone.

The same system can feel fast or slow, helpful or obstructive, precise or vague, depending on how it is used.

Which shifts the question.

It becomes less about what the system does in isolation, and more about what happens in the interaction.

In that sense, these systems don’t just produce output.

They shape how problems are approached.

They influence where thinking happens and how it is structured.

That also changes how we interpret friction.

What looks like resistance from one perspective can be part of the process from another.

What feels like overhead can turn out to be investment.

And what seems like a lack of speed can actually be a different distribution of effort, depending on how the interaction is shaped.

Closing

Stepping back, this feels less like a problem to be solved and more like a transition to be understood.

The tools are new, but the reactions to them are not. Every shift in how we work tends to surface the same patterns. Habit, expectation, identity.

It takes time for those to adjust.

And maybe that’s part of what’s showing up here.

Not a system that got worse, but a change in how it needs to be approached.

Something that doesn’t quite fit how we’re used to thinking about tools.

For now, we’re still figuring out what this interaction actually is.

Somewhere between tool and interface. Between execution and reflection.

And maybe the most useful thing, at this stage, is not to settle on a final answer too quickly, but to stay aware of how differently the same system can behave, depending on how the interaction is shaped.