Introduction

AI is changing not just how we code, but how we think while coding. When tools can autocomplete functions or spin up prototypes in minutes, it raises an important question: what happens to our own engagement, creativity, and memory when we let AI do the heavy lifting? To explore this, researchers at MIT’s Media Lab ran a study called “Your Brain on ChatGPT.” Their findings were striking: people who wrote essays with AI assistance showed weaker brain connectivity, less originality, and lower memory retention compared to those who wrote without it. Participants even struggled to recall sentences they themselves had “written” with ChatGPT.

MIT ChatGPT Research

In short: when we let AI do the heavy lifting, our brains disengage.

AI killed my coding brain? 😔

This got me thinking about how AI affects software engineering - particularly the tension between prototyping with AI and building production-ready systems.

⚡ Prototyping with AI: A Superpower

Andrej says "New Programming Language" is English

There’s no denying it: AI has transformed how we code with English.

• Need to test an idea? AI can spin up a proof-of-concept in minutes.
• Stuck on boilerplate? AI generates the scaffolding instantly.
• Want to explore a library? AI gives you usable examples faster than documentation.

In the prototyping phase, speed matters more than polish. The goal is to move ideas into code as quickly as possible, and AI excels here. It reduces friction and lets us validate feasibility before investing serious time.

🏗️ Production Code: Where Humans Must Lead

But production software is a different story. It’s not just about writing code that works - it’s about writing code that other humans can understand, extend, and maintain years later.

Finding Your Way In Code

Here’s where AI shows its cracks:

• Undigestible code → AI often produces solutions that “work,” but don’t align with human intuition, naming conventions, or architecture.
• Hidden complexity → Snippets stitched together without a clear design rationale.
• Low readability = low ownership → Just as MIT’s participants felt detached from AI-written essays, developers struggle to feel ownership of AI-generated code.

In the long run, this erodes team confidence. Developers spend most of their time reading code, not writing it - so code that humans can’t easily reason about is a liability.

🤖 Why AI Struggles with Maintainability

Andrew says "Move fast & be responsible"

Humans and AI “think” differently when it comes to code:

• Humans write with intent, guided by mental models, tradeoffs, and design patterns.
• AI writes by predicting likely sequences of tokens.

That’s why AI-written code often lacks:

• Clear design rationale (“why” this approach, not just “what” works).
• Consistency in style, abstractions, and patterns.
• Documentation or context for future maintainers.

It’s production engineering without the storytelling that makes code understandable.

🌱 The Path Forward: How AI Can Improve

AI doesn’t have to remain a black-box code generator. Imagine tools that:

• Prioritize readability and naming clarity over terse correctness.
• Generate not just code, but explanations of design choices.
• Adapt to a team’s style guide and architecture conventions.
• Collaborate like a pair programmer, asking clarifying questions instead of dumping code.

That’s the direction we need AI to evolve - toward systems that augment human reasoning rather than replace it.

🚀 The Future of AI in Software Engineering

If we zoom out, the trajectory looks something like this:

• Today → Prototype Assistant
  Great for exploration, boilerplate, and quick demos.

• Near-term → Pair Programmer
  Assists with testing, style, and incremental improvements - without eroding human ownership.

• Future → Cognitive Collaborator
  Acts as a true partner, helping humans reason more deeply while handling complexity in the background.

But until we reach that future, the MIT study offers a warning: when we let AI do all the thinking, we disengage. For software, that disengagement means fragile systems nobody truly understands.

Conclusion

AI is not “bad for coding”. In fact, it’s a powerful tool - when used wisely. But we need to draw the line between:

• Use AI for speed → prototypes, boilerplate, experimentation.
• Use our brains for depth → architecture, design, long-term maintainability.

Because at the end of the day, code isn’t just what machines execute - it’s what humans need to reason about, debug, and build upon. Until AI can write code that’s as digestible to humans as it is executable by machines, we’ll need to keep our brains firmly in the loop.

REFERENCES

PS: A big thanks to Greg Tanaka for his insights on the topics covered in this article.