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 off 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.
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 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 engineers Thinking in the Age of AI — Team Edition
Don’t let AI break your collective thinking: a practical guide for engineering teams Thinking in the Age of AI — Builder Edition
From vibe coding to clear thinking: what non-technical builders need in the age of AI AI Thinking Balance Tracker
The 4 cognitive archetypes of developers using AI Prompt System Guide
The missing layer in prompt engineering: thinking quality System 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.
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?
The Toolkit brings together 6 resources:
A guide for individual engineers who want to use AI without weakening their own reasoning, learning, and technical intuition.
A guide for engineering teams that want to preserve shared understanding while adopting AI-assisted workflows.
A guide for builders, founders, and non-technical creators using AI to build software without losing sight of the systems they are creating.
A spreadsheet to help developers notice how they use AI across different cognitive modes: learning, generating, debugging, reflecting, and executing.
A spreadsheet to help teams identify where system understanding is strong, fragile, or dangerously concentrated.
A practical guide to using prompts not just to get better AI outputs, but to improve thinking quality.
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:
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.
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.
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:
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.
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. I would love to hear how you are approaching this in your own workflow: