Are AI Agents Good for Your Brain?

A recurring criticism of AI coding agents is that they make people worse at the very skills needed to use them well. Cal Newport recently discussed this through the lens of agentic coding, cognitive atrophy, and deep work. I think there is a lot of truth in that warning.

But I do not think the useful conclusion is “do not use AI.” That feels too blunt. It sounds a bit like saying: walk everywhere, but use a car if you really believe it is faster. Or swim everywhere, but use a boat if you must. The better question is not whether AI is good or bad for your brain in the abstract. The better question is: what part of your cognition are you outsourcing, and what part are you strengthening?

AI agents can either weaken your thinking or multiply it. The difference is whether you are using them to avoid thought or to make your own thought travel farther.

The warning is real

I agree with the core concern. If a developer asks an agent to design the architecture, write the code, debug the code, explain the code, and then accepts the result without understanding it, that developer is not getting practice. They are getting output.

Practice matters. Syntax matters. Debugging matters. Reading code matters. Writing from scratch matters. Struggling with an idea matters. The human brain improves through repetition, attention, correction, and recall. If AI removes all of that, then the person is not becoming a stronger engineer. They are becoming an operator of a slot machine.

This is especially dangerous for junior developers. Reviewing generated code requires a base of experience. If someone skips the painful step of writing, breaking, debugging, and repairing their own programs, then “AI-assisted review” becomes mostly vibes.

But the anti-AI framing misses something

At the same time, I find some of the anti-AI argument too narrow. Programmers have always used abstractions. Frameworks, libraries, operating systems, compilers, package managers, ORMs, CSS frameworks, UI kits, cloud platforms, and build tools all hide complexity.

Most web developers are not designing instruction sets, writing compilers, building operating systems, implementing TCP/IP, creating a browser engine, and then rendering a button from first principles. They are already standing on enormous abstractions.

Sometimes those abstractions are good. Sometimes they are terrible. I have strong opinions here. I do not want a static page to become a React project with a billion dependencies just to render a button. But the point is that “AI creates abstraction” is not automatically a new sin. The software industry has been abstracting aggressively for decades.

The better question is: does the abstraction make the system more understandable, more durable, and more operable? Or does it create distance between you and the thing you are responsible for?

My experience is not theoretical

AI has helped me in concrete ways.

In a legal dispute with BMO, hiring a lawyer could have cost more than the amount in dispute. AI helped me understand documents, structure arguments, create explanations, reason through timelines, and produce visual artifacts. I still had to own the case. I still had to make decisions. I still had to understand what I was arguing. But AI gave me leverage I otherwise would not have had. The public decision is available on CanLII.

With ANTSAND, AI has helped me harden a system I have been building for years. It helped move StylesDoc and ANTSAND Blog into generated workflows. It helped improve Sass v2, blog rendering, asset handling, notes, syndication, and deployment paths. These were not toy examples. These were real systems with real accumulated complexity.

With C Kernel Engine, AI helps me study papers, inspect GGUF models, compare against PyTorch, llama.cpp, vLLM, and other runtimes, reason about kernels, write scalar versions in C, explore SIMD, generate tests, inspect profiler output, and understand what the machine is doing. I am not asking it to “make an AI library” while I disappear. I am using it to help me learn and build a CPU-first inference and training runtime.

With Linux, AI has made me actually want to work on Linux full time. Linux desktop is much better than it used to be, but it still has stupid, painful quirks. Bluetooth stops behaving. A mouse does not pair cleanly. Audio routes to the wrong device. A display setting breaks. A driver or package conflict shows up when I just want to work.

I do not need deep work for that. I need the machine fixed. Now I can type something as blunt as “fix my Bluetooth,” inspect the commands, run them, and turn the fix into a small utility if the problem repeats. That is exactly the kind of shallow friction AI should eat.

That is why LinuxUtilities exists. It is not a grand architecture project like ANTSAND or C Kernel Engine. It is a practical repair bench for living in Linux: clipboard repair, Bluetooth checks, audio checks, reminders, small scripts, local tools, and whatever annoyance blocks the day.

This changes the economics of software for me. If AI can help stitch together open-source tools, debug Linux quirks, and make command-line workflows pleasant, then I can move more of my work away from paid operating systems and expensive suites over time. Windows, Adobe, Altium, SolidWorks-style workflows all become less sticky when the open-source path is not so painful to integrate.

This connects directly to older notes like Hardening Long Projects in the Age of AI, Why I Replaced QuickBooks with ANTSAND, and Why I’m Doubling Down on C in 2026. The theme is the same: AI is useful when it helps me own more of the stack, reduce subscriptions, learn fundamentals, and make open systems practical.

The real question is what you do while the agent runs

Agentic workflows introduce a strange rhythm. You type something, the agent runs, you wait, you review, you correct, and then you repeat. That can easily become shallow work. It can fragment attention. It can create the illusion of productivity while your own thinking becomes passive.

This is why I think the prompt itself matters. Not because prompt engineering is magic, but because writing a detailed prompt can be a form of thinking.

I try to type as much of my own reasoning as possible before handing work to an agent. I describe the architecture. I describe the constraints. I describe the expected behavior. I describe what not to do. I write pseudo-code. I point at the exact files. I explain the tradeoffs. This slows me down in a good way.

The plan is not for the AI. The plan is for me. The AI is just the first reader.

That slowness matters. Humans are biological systems. We do not think at machine speed. We need repetition, patience, memory, rhythm, and attention. If I only type tiny instructions and wait for the agent, I am not getting the repetitions. I am not sharpening the idea. I am just managing output.

How I use agents across multiple projects

My current approach has four parts.

• Work in phases: I cycle through projects instead of pretending I can deeply move ANTSAND, C Kernel Engine, drones, embedded systems, Linux utilities, and content all at once.
• Write intent and pseudo-code: I give the agent architecture, constraints, file paths, expected behavior, and what not to do. The prompt becomes a thinking artifact.
• Protect the wait time: Agent runs can fragment attention. I try to do the hard thinking before the run, not replace thinking with endless type-wait-review loops.
• Use active recall: I explain legal, math, systems, and programming concepts back to the AI so it can challenge gaps instead of only feeding me answers.

I work across several long-running projects: ANTSAND, C Kernel Engine, DroneMath, embedded systems, Linux utilities, and content around those projects. I cannot give all of them full attention at the same time. AI does not change that.

I still cycle through work in phases, but I do not mean one day on this and one day on that. I mean real focus cycles: usually two to four months where one project becomes the main thing. If I am focused on C Kernel Engine, then ANTSAND may receive maintenance-level attention. If I am focused on ANTSAND, then drone work may slow down. If I am focused on DroneMath or embedded systems, content creation and Linux utilities may become secondary. The foundations compound, but the human attention still has to be protected.

AI creates a temptation to run everything at once. More agents. More tasks. More branches. More outputs. But that is not automatically better. If the foundation is not strong, parallelism just creates more chaos.

Working in phases

The phase matters because every serious project has its own mental state. A phase is not a daily mood. It is long enough for the project to reload into my head, for the open questions to become familiar, for the bugs to connect to architecture, and for the next layer of work to become obvious.

Two to four months is usually the scale that feels real. Shorter than that, I am mostly context switching. Longer than that, the other systems can decay or the opportunity cost becomes too high. The point is not to create a rigid calendar. The point is to stop pretending that deep architectural work can happen while bouncing between five serious projects every day.

ANTSAND asks me to think about product architecture, website compilation, Sass contracts, notes, deployment, Databoard workflows, generated sites, asset handling, comments, email campaigns, and how a user or an agent can operate the system without breaking it.

C Kernel Engine asks me to think about transformers, tensor shapes, GGUF files, scalar C, SIMD, quantization, backprop, training loops, generated C, profiling, cache behavior, rooflines, and whether the runtime is actually doing what the math says it should do.

DroneMath and embedded systems ask for a different kind of attention: quaternions, Kalman filters, control loops, sensors, flight controllers, soldering, boards, timing, and physical hardware that does not care how elegant the code looked in a prompt.

Linux utilities ask a different question again: what friction is making my operating system annoying today, and can I remove that friction with a small script, UI, command, or repair workflow?

AI can help in all of these areas, but I cannot deeply inhabit all of them at the same time. So I work in longer cycles. I let one project become the main focus for a meaningful stretch. The others stay warm through bug fixes, small improvements, notes, and maintenance, but they do not all get to become emergencies.

Protecting the wait time

The hardest part of agentic work is not always the prompt. Sometimes it is the waiting.

You give the agent a task. It runs for thirty seconds, two minutes, ten minutes, maybe longer. During that time, the dangerous habit is to bounce. Open a browser. Check a dashboard. Start another agent. Start another branch. Open another project. The agent is running, but your attention is now shredded.

That rhythm can feel productive because many things are moving. But moving is not the same as thinking. If I am not careful, I become a dispatcher of half-formed tasks instead of a builder with a clear model in my head.

My better workflow is to front-load the thinking. Before the agent runs, I type the architecture, the constraints, the files, the invariants, the failure modes, the exact thing I want preserved, and the thing I absolutely do not want changed. That typing is not wasted time. That typing is the deep work.

When the agent runs, the wait time should be used deliberately. Sometimes I review nearby code. Sometimes I write the next test. Sometimes I sketch the next paragraph. Sometimes I do nothing and hold the model in my head. What I try not to do is create five unrelated contexts just because the machine is busy.

The agent can run in parallel. My attention cannot.

This is where I think some agentic workflows become dangerous. The machine gets faster, but the human becomes more fragmented. The answer is not to avoid agents. The answer is to protect the human attention around the agent.

Pseudo-code is still a superpower

I may type less finished code than before, but I type more intent. That intent comes from years of writing PHP, C, HTML, CSS, JavaScript, SQL, APIs, JSON, Sass, HMVC structures, deployment scripts, C systems code, and system glue.

That experience makes the prompt sharper. I can tell an agent, as a matter of fact, never use React for this work. My only rule there is simple: React brain rot is not allowed. Do not install that framework for a static page. Do not drag in node modules to render a button. Preserve the Sass v2 class contract. Do not change the sanitizer behavior. Touch the code path that matters and ignore the noise. That is not magic. That is accumulated engineering judgment.

A lot of that judgment comes from the way I think about systems. I wrote about this separately in I Think Like a Compiler. That is not a cute metaphor for me. It is how I design frameworks and tools.

ANTSAND is basically a compiler-shaped system: structured inputs, templates, Sass contracts, generated websites, deployment outputs, and verification. C Kernel Engine is even more explicitly compiler-like: model artifacts, tensor shapes, intermediate representations, lowering, generated C, runtime execution, profiling, and reports. The architecture that connects those pieces is still mine to design. AI can help fill in parts, compare implementations, and catch mistakes, but the compiler-shaped mental model is what lets me decide what should exist in the first place.

That older post has a few ideas that matter directly here:

• High-level representation matters: before writing the thing, ask what representation can generate the thing.
• Determinism is leverage: pages, forms, routes, tensor shapes, model layers, and runtime artifacts often have structure that can be generated if the contract is clear.
• Put complexity in the compiler: I am okay with complexity in the authoring layer if the generated runtime stays clean and understandable.
• AI helps inspect the model: it can explain my architecture back to me, find inconsistencies, and help debug abstraction leaks, but I still decide what the abstraction should be.

Maybe AI will replace more of that architectural judgment in the future. Today, I still drive it. I still spend a lot of time thinking about the structure before asking an agent to touch the code.

For C Kernel Engine, I can reason from the math to the scalar implementation, then use AI to help explore SIMD instructions, compare implementations, study PyTorch or llama.cpp behavior, generate tests, and inspect profiler output. The AI helps accelerate the loop, but the loop is still mine.

Pseudo-code is where natural intelligence and artificial intelligence meet. If you can explain the shape of the solution clearly, the agent can help fill in the mechanical parts. If you cannot explain the shape, the agent may still produce something, but you may not know whether it is right.

The Feynman technique matters more now

One of the most powerful ways to use AI is active recall. Study something, close the source, explain it back, and let the AI challenge the explanation.

This is how I use AI for math, legal reasoning, systems programming, transformer architectures, drone control, Kalman filters, quaternions, and C runtime design. I ask questions. I explain what I think I understood. I ask the AI to find gaps. I rewrite. I test. I come back again.

The BMO dispute is the clearest example. I am not a legal professional. I still had to understand the documents, the timeline, the interest calculation, the reporting consequences, the procedural issues, and the language of the case well enough to argue it. AI helped, but not by magically replacing judgment. It helped because I could explain what I thought was happening, ask where the argument was weak, turn the sequence into diagrams, compare the numbers, and force myself to restate the issue until it became clear.

That mattered. The dispute was not abstract. It involved a bill in the rough range of $24,000 to $30,000, and the final amount I paid was around $6,750, close to what I believed I actually owed. AI also helped me prepare material that regulators and the court could inspect. The point is not that AI “won” a legal matter. The point is that AI helped me practice the Feynman loop under pressure: explain the problem, expose gaps, simplify the structure, make the timeline visible, and come back with a clearer version.

The same pattern applies to C Kernel Engine. If I want to understand GPT-2, Qwen, attention, RoPE, backprop, quantization, or a GGUF runtime path, I cannot only ask AI to explain it. I have to read, type my understanding back, write the scalar version, compare it to other implementations, and let the gaps show up in tests, diagrams, profiler output, or failed runs.

The key is that I type the explanation. Typing is slower than speaking. That is useful. It forces the idea to pass through language, structure, and sequence. It exposes where I am hand-waving.

If AI is always explaining to you, you may feel smart. If you are forced to explain back, you can become smarter.

So, are AI agents good for your brain?

Yes, if they force you to explain more clearly, test your assumptions faster, and stay closer to the architecture of your own work.

No, if they let you disappear from the work while code, writing, and decisions pile up under your name.

That is the line I keep coming back to.

AI should make the machine faster. It should not make the human vaguer.

For me, the value is not that agents replace thinking. The value is that they punish unclear thinking quickly. If I cannot explain the phase, the architecture, the pseudo-code, the legal argument, or the mathematical object, the agent usually makes that confusion visible.

That is useful.

But the ownership still has to stay with me. The projects are mine. The mistakes are mine. The judgment is mine. The learning is mine.

The agent can help me move faster through Antsand, C Kernel Engine, Linux, legal work, writing, and content production. But the natural intelligence still has to do the slow part: choosing what matters, explaining it, checking it, and carrying it long enough for the work to compound.