DEV Community: John OK.

Why Is 'Thinking' Being Attached to Everything?

John OK. — Fri, 17 Jul 2026 08:28:05 +0000

I Noticed That Every Profession Now Has a "Thinking." I Went Looking for Why.

It started as a low-grade irritation.

Systems thinking on a job listing. Design thinking in a workshop invitation. Product thinking in a strategy meeting. Computational thinking on a university course banner. These terms kept appearing, and each time they did, I felt a small, specific unease. The kind you get when you suspect everyone else in the room understands something you do not.

Eventually I stopped treating that unease as a sign of my own ignorance and started treating it as a question worth answering. Why is "thinking" being attached to everything? What does it actually mean when you pair it with another word? And what do all these terms have in common, underneath the branding?

I went looking for answers. What I found surprised me.

Before the pairing makes sense, the word "thinking" itself needs to. And it turns out thinking is not one thing. It is a whole family of mental activities, from recalling a memory to constructing an argument to making a split-second call. The most useful insight I came across was a distinction that psychologist Daniel Kahneman made famous: our brains operate in two distinct modes.

System 1 is fast, automatic, and effortless. It reads the emotion on a face before you consciously decide to look. It finishes the sentence before you hear the end of it. For most of our waking hours, this is what is running the show.

System 2 is slow, deliberate, and genuinely hard. It is what you use to follow a complex argument, to notice that your first reaction might be wrong, to work through something you have never encountered before. The brain avoids it when it can, not out of laziness, exactly, but out of efficiency. System 2 is metabolically expensive. The brain would rather not.

I filed that away, not yet sure what to do with it. It came back to me later, in a different form.

When you place a modifier in front of "thinking," something interesting happens on both sides of the pairing.

The modifier shapes the thinking. Left alone, thinking is unfocused. It wanders, it confirms what you already believe, it reaches for the nearest comfortable conclusion. Adding a modifier gives it a track to run on. The word "critical" in critical thinking does not simply describe a topic; it issues an instruction to the brain. Look for flaws. Question assumptions. Do not accept the first answer that arrives. Without that word, you might still be thinking, but your brain is probably just agreeing with itself.

And thinking reshapes the modifier. This is the less obvious half of the relationship. Take the word "design." On its own, it is a noun — an artifact, a layout, an outcome. Add "thinking" and the entire emphasis shifts. You are no longer focused on the thing being made. You are focused on the cognitive process of making it: the empathy, the iteration, the willingness to be wrong and start again. A noun becomes a methodology.

This is the pattern underneath all of these terms. When you see "X thinking," you are not being pointed toward a subject. You are being handed a cognitive lens. A structured way of seeing and moving through a particular class of problem.

Three examples make this concrete, and they work best when set against each other.

Critical thinking instructs the brain to be suspicious. If a headline claims that coffee drinkers live longer, the instinct is to believe or dismiss it based on how it feels. Critical thinking intercepts that instinct and routes you somewhere harder: Who funded the study? How large was the sample? Is correlation being reported as causation? What do other studies say? The goal is not skepticism for its own sake. It is the suspension of judgment until you have actually earned a position.

Design thinking starts somewhere different, with a person rather than a problem. A bank that wants to improve its mobile app might survey customers and build what they ask for. A team practicing design thinking observes customers using the app in real conditions, notices that what users are actually experiencing is anxiety, not knowing whether a transaction went through — and prototypes a small confirmation animation before writing a single line of production code. The solution that emerges is not the one anyone would have asked for on a survey. That is the point.

Systems thinking instructs you to look at how parts affect each other rather than the parts in isolation. A hospital hires more doctors to reduce wait times. Wait times increase. More doctors means more patients seen, which means more follow-up appointments, which means the scheduling system clogs further downstream. A systems thinker would have mapped that feedback loop before the hiring decision. The intervention was obvious; the consequences were not, until you looked at the whole.

These three frameworks feel different from each other and they are. But they share something underneath. Each one is a deliberate System 2 override. Each was built to intercept the comfortable, energy-efficient shortcuts that System 1 wants to take and route the brain into the slow, uncomfortable processing the problem actually requires. All of these frameworks, at their core, are structured workarounds for the brain's preference for the easy answer.

Why is this pattern everywhere right now? Three things, I think.

The most durable reason is that specific knowledge goes stale but mental models do not. Teaching someone the steps for a particular tool has a shelf life. Teaching them design thinking , a repeatable approach to any human-centered problem like travels across roles, industries, and decades. Organizations are increasingly reaching for that durability.

The second reason is that these terms dissolve gatekeeping. "Design" used to belong to designers. "Data" used to belong to analysts. Re-framing them as types of thinking signals that anyone (engineers, marketers, executives) can and should adopt that perspective. Whether that is always earned in practice is a separate debate. The intent is democratizing.

And then there is the honest third reason: this is a good brand. "Design thinking" sounds like a fundamental upgrade to how your mind works. "Design workflow" sounds like a checklist. Packaging methodology as cognition makes it easier to sell as workshops, certifications, consulting engagements. The frameworks are often genuinely valuable. But their proliferation is not purely intellectual. The brand is doing real work, and it would be naive to pretend otherwise.

Now when I encounter a new "X thinking" term I have never heard, I reach for five questions.

What domain does this framework operate in? What specific failure mode was it invented to fix ? What does it exist to prevent? What does it tell you to pay attention to that your default thinking ignores? What does it tell you to resist or question? And what are the actual practices , not the concept, but the things you would do differently on a Tuesday morning?

The answers will not come from knowing what "thinking" means. That word tells you a structured method exists. It does not tell you what the method is. For that, you have to go learn the specific framework , its history, its steps, its blind spots. But at least now you know exactly what you are looking for.

When I see those job listings and workshop banners now, I do not feel the old unease. I feel something closer to recognition. Each term marks a place where someone looked at a class of problem, noticed that human beings approach it badly by default, and spent real effort designing a path through. That is not jargon. That is worth learning.

Coding Assistant CLI Tools vs. AI-Powered Terminals: Which Should You Use?

John OK. — Wed, 25 Jun 2025 21:18:38 +0000

Picture this: You're knee-deep in code, stuck in the terminal, hunting for that one elusive command to save your sanity. Frustrating, right? Luckily, there's two kinds of help, in fact: coding assistant CLI tools(codex cli, gemini cli,claude code) and AI-powered terminals(warp). One helps you write and debug code faster, the other transforms how you interact with your terminal altogether.

But which one deserves a spot in your dev toolkit? Let’s break them down.

What Are They?
🔧 Coding Assistant CLI Tools:
These are command-line utilities that assist with tasks like writing functions, fixing bugs, or explaining code. Think of tools like GitHub Copilot CLI or Codex CLI—they’re like pair programmers that live in your terminal.

⚡ AI-Powered Terminals:
These are full-fledged terminal environments enhanced with built-in AI. They can interpret natural language, automate multi-step workflows, and even understand context. A prime example? Warp, a reimagined terminal that acts more like a collaborator than a command-line.

Functionality: What Can They Actually Do?
CLI tools excel at targeted, task-based help. Need to refactor a function or understand a tricky snippet? Just ask. In fact, surveys show developers using tools like Copilot CLI reduce time spent on repetitive code by up to 30%.

AI-powered terminals, on the other hand, go beyond just code. They can automate whole workflows. Think, “set up my dev environment,” and boom, it’s done. Warp reports that 75% of users experience a noticeable productivity boost after switching.

Ease of Use: How Hard Is It to Get Started?
CLI tools require a bit of setup. Installing dependencies, managing tokens or API keys. It’s not difficult, but it adds friction. Once configured, though, they’re efficient and predictable.

AI-powered terminals tend to be plug-and-play. Tools like Warp let you interact using plain language. You don’t need to memorize commands, you just type what you mean. It feels less like coding and more like a conversation.

Integration: Do They Fit Seamlessly Into Your Workflow?
Here’s where AI terminals shine. They can replace your current terminal, letting you switch between traditional and AI-enhanced commands effortlessly.

CLI tools, while powerful, often operate alongside your terminal rather than within it. For example, with Codex CLI, you’ll prefix commands like codex explain. Useful, but slightly interrupts the flow.

Performance: Are They Fast Enough?
CLI tools are purpose-built and lean. They handle quick, single-task operations like code generation or debugging with near-instant results.

AI terminals offer more features, which can introduce minor latency. Still, tools like Warp report AI interactions add just 50ms to command time—imperceptible to most.

Cost: How Much Do They Cost?
Most CLI tools start free. GitHub Copilot CLI, for example, offers a free tier with limited usage and a full plan at around $10/month. Open-source options like Codex CLI are entirely free.

AI terminals follow a similar model. Warp’s basic features are free, with unlimited AI access available at $15/month. It depends on your budget—and how much you value time saved.

Customization: Can You Make Them Yours?
CLI tools tend to be highly customizable, especially if they’re open source. You can write plugins, chain commands, or even tweak the internals.

AI terminals, by contrast, offer limited customization. You can personalize workflows or themes, but the AI layer is more of a black box—you get what the platform gives you.

*So… Which One’s Right for You?
*Here’s the quick takeaway:

Go for CLI tools if you want a lightweight, coding-specific assistant. They’re fast, efficient, and let you stay hands-on.

Choose an AI-powered terminal if you’re looking to rethink your entire workflow. These tools can streamline everything from writing code to deploying apps with a single command.

There’s no wrong choice,just the one that fits your style.

Tried either of these? What’s your experience been like? Drop your thoughts in the comments, I’d love to hear your take.