Over the past weeks, I’ve been sharing a series of posts that gravitate around one question:
How do we use AI without outsourcing our judgment?
The engagement from this community in response to this series has been genuinely strong.
This indicates that the issue of cognitive offloading associated with AI use is real. It is a problem space that resonates highly amongst developers.
The comments, feedback, and discussions sparked along the way helped me sharpen the ideas behind what has now become The Thinking Engineer Toolkit.
A moment of gratitude
It has been a wonderful and insightful journey to share this series with you here, to learn from other engineers and builders, and explore how AI-assisted work is changing the way we think, build, and understand software.
Thank you for your inputs.
And to those who have also reached out to me to express their support, encouragement and kind words, I thank you deeply.
I look forward to many more discussions with you all.
I wanted to originally tag the most engaged members directly here but there is a 10 tag limit per post (rightfully so!). Since I didn't want to make anybody feel left out I will avoid doing this since there are definitely much more than 10 people I wanted to tag!
The posts that led to the Thinking Engineer Toolkit
The Toolkit was influenced by a series of posts I shared here on DEV, feel free to check them out:
Thinking in the Age of AI
Don’t let AI do your thinking: a practical guide for engineersThinking in the Age of AI — Team Edition
Don’t let AI break your collective thinking: a practical guide for engineering teamsThinking in the Age of AI — Builder Edition
From vibe coding to clear thinking: what non-technical builders need in the age of AIAI Thinking Balance Tracker
The 4 cognitive archetypes of developers using AIPrompt System Guide
The missing layer in prompt engineering: thinking qualitySystem Comprehension Heatmap
Your Codebase Has Technical Debt. But Does Your Team Have Comprehension Debt?
Each post explored a different part of the same bigger problem:
AI is making us faster, but speed is not enough if understanding can't keep up.
Why I started The Thinking Engineer
I started The Thinking Engineer because I kept noticing a tension in my own workflow.
AI was helping me move faster.
It helped me brainstorm, debug, refactor, write, and build.
But I also noticed that if I used it passively, it could make my understanding thinner.
Sometimes I was thinking better with AI.
Other times, I was letting AI think too much for me.
I was confusing productivity with removing friction.
That distinction matters.
Because engineering is not just about producing code.
It is about judgment, tradeoffs, debugging, communication, system understanding, and knowing when something looks right but is actually shallow.
That is the problem I want to keep exploring:
How do we build effectively with AI while preserving the thinking skills that make engineering valuable?
What is inside the Thinking Engineer Toolkit?
The Toolkit brings together 6 resources:
1. Thinking in the Age of AI
A guide for individual engineers who want to use AI without weakening their own reasoning, learning, and technical intuition.
2. Thinking in the Age of AI - Team Edition
A guide for engineering teams that want to preserve shared understanding while adopting AI-assisted workflows.
3. Thinking in the Age of AI - Builder Edition
A guide for builders, founders, and non-technical creators using AI to build software without losing sight of the systems they are creating.
4. AI Thinking Balance Tracker
A spreadsheet to help developers notice how they use AI across different cognitive modes: learning, generating, debugging, reflecting, and executing.
5. System Comprehension Heatmap
A spreadsheet to help teams identify where system understanding is strong, fragile, or dangerously concentrated.
6. Prompt System Guide
A practical guide to using prompts not just to get better AI outputs, but to improve thinking quality.
Why bundle them together?
Each resource can be used on its own.
But together, they form a complete system.
The guides help you reflect.
The trackers help you observe patterns.
The heatmap helps teams surface comprehension debt.
The prompt guide helps improve the quality of your AI interactions.
Combined, they create a practical workflow for asking:
- Am I using AI intentionally?
- Do I understand what I am building?
- Is my team preserving shared understanding?
- Are we moving faster in a way that compounds learning?
- Or are we moving faster in a way that hides fragility?
Based on my experience, this is the Toolkit I wish I had from the beginning: a way to create better habits around the questions that matter.
The bigger picture
I think the next phase of software engineering will not only reward people who can use AI tools.
It will reward people who can use AI tools while preserving judgment.
The engineers and builders who stand out will be the ones who can ask better questions, validate outputs carefully, understand systems deeply, and keep learning instead of just delegating.
That is what I mean by being a Thinking Engineer.
What I’ve learned from sharing this work
One thing I’ve appreciated from the DEV community is that the general consensus is not simply whether AI is good or bad.
It is more nuanced:
- How do we use AI well?
- Where does it help?
- Where does it create dependency?
That is the conversation I want to keep having.
The nature of our roles is changing.
It is exciting and scary at the same time.
We are all figuring this out at the same time.
Get your Toolkit today
I want to share The Thinking Engineer Toolkit with you today free to help engineers and builders work effectively and sustainably with AI assistance. If you find it valuable, I would also appreciate any support so I can keep investing my time in creating such resources.
You can access the toolkit here.
Looking ahead
I would love to hear how you are approaching this in your own workflow:
- How do you avoid over-relying on AI?
- Do you have rules for when to use AI and when to think first?
- Are you seeing comprehension debt emerge in teams or codebases?
- What would make this Toolkit more useful in practice?
- What should I improve next?