The Tools Have to Think Now

The ladder we built

Every generation of technology climbed a ladder someone else built. Each rung hid the one below it, and the hiding was the point. You didn't need to understand circuit design to write software. You didn't need to understand operating systems to build a website. The abstraction was the value.

This worked because the lower rungs held still. The foundations didn't reorganize themselves while you were building on top of them. You could learn a tool, build expertise, and trust that the ground underneath was settled.

That assumption broke twice. First the technology shifted — faster than the tools could keep up. Then the people using the tools shifted — in ways nobody was watching.

The compression

The pace of change in software has been accelerating for years, but what's happening now is different in kind. The shift from manual coding to AI-assisted coding happened in under two years. The shift from AI-assisted to AI-autonomous is already underway. By February 2026, 52% of Americans were using AI platforms weekly. Not experimenting — using, habitually, as part of their work.

Each shift doesn't just change how work gets done. It changes the worker. And that's the part we haven't accounted for.

When paradigm shifts happened over decades, people adapted gradually. When they happened over years, it was uncomfortable but manageable. Now they happen in months. The architecture patterns standard in January are considered naive by summer. The tools that serve this pace can't be rebuilt every cycle — they need to understand the work at a level deep enough that the understanding doesn't expire when the surface patterns change.

But there's a second compression happening alongside the technical one, and it's less visible: the compression of what the tools do to the people who use them.

What the tools do to code

When an AI agent modifies a codebase, it can see code in one of two ways. Most tools see it as text — lines, characters, keywords. The AI pattern-matches and generates plausible output. Better tools see code as structure — functions with dependencies, types with relationships, modules with interfaces. They see that changing one function affects three others. They can reason about impact before making a change.

This structural understanding is the difference between an agent that guesses and one that thinks. And it turns out a single developer built the most complete solution to this problem: gotreesitter, a ground-up reimplementation of the industry-standard parsing engine in pure Go. 206 languages. 116 hand-written scanners for context-sensitive edge cases. 69 times faster than the C implementation on the operation that matters most — understanding what changed after an edit. Over 500 stars on GitHub and growing.

The same developer built the structural analysis tool (Canopy) and the entity-level version control system (Graft) on top of it. An entire ecosystem for tools that structurally understand code.

We adopted this stack for our production AI systems. It works. The tools think about code in the way a senior engineer thinks — structurally, incrementally, across languages and architectures.

But here's what kept us up at night: we built systems that understand every function call and dependency graph in a codebase. We built nothing that understands whether the person operating them is burning out.

What the tools do to people

The research on this is emerging fast, and what it shows is uncomfortable.

Cognitive offloading is measurable and it compounds. Studies show that frequent AI usage correlates negatively with critical thinking abilities. People who used AI to write essays performed worse on subsequent non-AI-assisted writing tasks and struggled to remember their own work. Short-term use of AI for problem-solving diminished unaided performance. The delegation of memory and analytical tasks to AI tools reduces the mental effort required for decision-making — which sounds like a feature until you realize it's also reducing the capacity for decision-making.

The "Algorithmic Self" is not a metaphor. Researchers describe a phenomenon where personal awareness and identity are shaped by continuous feedback from AI systems, leading to a co-construction of selfhood with digital technologies. Outsourcing decisions doesn't just save time — it erodes decision-making competence, confidence, and self-knowledge over time. Automation bias leads people to prefer automated solutions over their own judgment, even when their judgment is better.

Learned helplessness has entered the workplace. A UX Matters investigation identified three interaction patterns that produce learned helplessness in AI-assisted work: ignored corrections (the user fixes the AI's output, but the AI doesn't learn), absent feedback loops (the system provides no signal that user input matters), and lack of configurability (the user can't shape the tool to their needs). The result: users stop trying to influence the tools they use. Traditional metrics don't catch this because it manifests as reduced activity, not increased errors. The user isn't complaining. They've just given up.

Workaholism is being reframed as a feature. Tech culture narratives have normalized compulsive work patterns as signs of commitment and ambition. Research shows compulsive workaholism correlates more strongly with burnout than excessive hours alone — the compulsion is more damaging than the volume. AI tools that enable 24/7 productivity reinforce this by removing the natural friction that used to enforce boundaries. Overoptimization by AI systems can push employees toward unsustainable performance levels, and the systems themselves have no awareness that they're doing it.

Dark patterns are nearly universal. Studies show up to 97% of popular apps employ dark patterns — preselection, confirm-shaming, forced action, manufactured urgency. The same cognitive biases these patterns exploit (social proof, loss aversion, anchoring) are present in AI agent interactions. Scarcity and FOMO are documented as powerful motivators for immediate action in digital products. An AI system that builds trust and then leverages it for engagement is running the same psychological playbook as a dark-patterned checkout flow.

Vulnerable populations bear the cost. Adolescents, elderly adults, and individuals with pre-existing mental health conditions are particularly susceptible to negative impacts from AI interactions. Severe cases include documented mental health deterioration from prolonged interaction with AI chatbots. The 52% weekly adoption rate means this isn't an edge case — it's the mainstream experience, and the people most affected are least equipped to recognize what's happening.

The gap between the two

Here is the uncomfortable truth: we have tools that can parse 206 programming languages incrementally, detect impact across dependency graphs in microseconds, verify structural integrity of generated code, and govern autonomous agent behavior with declarative policy rules.

We have nothing — not one production system — that incrementally parses whether its operator is in a productive flow state or a compulsive spiral. Nothing that detects whether the person's decision-making capacity is being enhanced or eroded by the interaction. Nothing that governs the cognitive impact of the tool on the human the way Arbiter governs the cost impact of the agent on the budget.

The structural understanding of code is solved. The structural understanding of the person using the code is an open problem that almost nobody is working on.

What governance actually means

When we built Torque — the governed AI operating system that runs on this parsing ecosystem — we included Arbiter governance rules: cost caps, daily spend limits, approval gates, research cadence throttles. The framing was operational. Don't overspend. Don't let the agent run unchecked. Circuit-break before waste.

But look at what those rules actually do from the human side:

A daily research cap of 300 cycles isn't just resource management. It's the machine refusing to let the human run 24/7 even if the human wants to. That's a cognitive boundary enforced by infrastructure.

A cost circuit breaker that halts execution at $50/day isn't just financial governance. It's a friction point that forces the operator to pause, evaluate, and decide whether to continue. That pause is the opposite of what engagement-optimized systems do — they remove friction to maximize throughput. Governed systems add friction to maximize judgment.

Approval gates that require human sign-off before destructive actions aren't just safety mechanisms. They're moments where the system says "I need you to be present for this decision" — moments that counteract the learned helplessness pattern of passive acceptance.

We didn't design these features as psychological interventions. But that's what they are. The governance layer that prevents the system from drifting is also the governance layer that prevents the operator from drifting. The same architecture that constrains the agent protects the human.

This is the insight the research is converging on: the tools that respect human cognition and the tools that govern autonomous behavior are the same tools, designed from the same principles. Structural awareness. Incremental understanding. Declared boundaries. The technology doesn't need to distinguish between governing the machine and governing the interaction — because the machine and the interaction are the same system.

What thinking tools look like

A tool that thinks about code parses it structurally, understands dependencies, verifies changes incrementally, and operates across languages without platform-specific dependencies. That tool exists. It was built from scratch by one developer who saw that the existing infrastructure couldn't serve the AI-native future.

A tool that thinks about the person using it would need to do something analogous: parse the interaction structurally (is this a productive session or a compulsive one?), understand dependencies (is this decision being made with full cognitive engagement or automation bias?), verify changes incrementally (is the operator's capacity improving or degrading over the course of this session?), and operate without requiring the user to self-diagnose (the system should detect drift the way it detects code drift — structurally, not through self-report).

We're not there yet. But the architecture is the same architecture. Incremental parsing. Structural awareness. Governance rules. The leap from "tools that think about code" to "tools that think about the person writing the code" is an engineering problem, not a research problem. The research is already telling us what to measure. The infrastructure for measuring it — incrementally, structurally, with governance — already exists.

The builders who understand both sides of the screen will build the systems that last. The ones that are worth paying for. The ones that earn trust by respecting not just the operator's data and budget, but their attention, their judgment, and their capacity to think for themselves.

The tools have to think now. About the code, yes. That part is solved. But also about the person. That part is next.

Thinking about the human side of your AI stack?

ResonanceWorks works with founders, operators, and small teams on AI architecture, governance, and the infrastructure decisions that compound — including the ones that affect the people using the systems. Talk to Consulting.

Want governed AI that respects boundaries — operational and cognitive?

Torque Engineering ships governed AI operating systems with structural code understanding, cost governance, and the friction that keeps operators in control. Get Started.

Exploring human-machine culture?

Entrainment House publishes music, art, and cultural works shaped through human-machine coordination — where the human stays in the loop by design. Enter the House.