Don’t let AI do your thinking: a practical guide for engineers
I built a reflection guide for developers to think better in the age of AI.
I’m testing if this is actually useful . Seeking honest feedback.
We’re entering a new era of software engineering.
Code can now be generated instantly. Entire functions, components, even systems can be scaffolded in seconds.
This is a massive opportunity.
But there’s a subtle tradeoff I’ve been thinking a lot about lately:
When execution becomes easier, thinking can quietly decrease.
Not because we’re less capable, but because many of the moments that used to force us to think - debugging, struggling, reasoning - are now compressed or skipped.
You can ship faster than ever.
But speed alone does not build understanding.
So I started building small reflection habits around my work.
Over time, this turned into a structured system.
This guide isn’t meant to be read once and forgotten.
It’s designed to be used in small moments during your workflow.
Most exercises take 2–5 minutes.
15 exercises in total.
You don’t need to use everything. Just start by picking one tool and applying it consistently.
The idea is not to reflect more.
But to reflect deliberately.
You can grab it for free (just set the price to 0)
If it ends up being useful, feel free to support so I can keep investing my time in creating resources to help engineers, totally optional of course.
https://javz.gumroad.com/l/thinking-in-the-age-of-ai
Looking to get feedback from other engineers.
Would especially appreciate feedback on:
- which exercises feel useful vs unnecessary
- what feels missing
- how this fits into your actual workflow
I’d also love to hear from other devs here:
How do you make sure your thinking keeps up with AI tools?
Do you have any habits or systems in place?
Your premise is spot on: AI makes execution too easy, causing shallow understanding. But asking developers to pause their flow state for manual reflection feels like homework. It won’t stick.
The way to keep your thinking sharp isn't to journal about the code. It’s to weaponize the AI against itself. Instead of manual reflection, I force the LLM to give me three reasons why the architecture it just generated will fail in production.
Have you considered turning your reflection exercises into system prompts that developers can feed directly back into their AI, rather than manual tasks?
That is an interesting approach. Thanks for the suggestion. However I would caution against just relying on the LLM itself. If it drifts then it won't output the right answer. Your suggestion could be interesting in the evaluation cases such as using another LLM as judge. What do you think?
This is a really insightful take on AI! I happen to know a couple of software engineers who actively use AI tools and are into structured reflection, and they'd probably be willing to answer some of your questions for free.
Thanks! That sounds great @Merc.
What would be the best way to get in contact with them? I really appreciate this.
Thanks for sharing. In the age of AI, developers really need to rethink their approach to avoid falling into the trap of chasing speed at the expense of quality.
At Seedium, we treat AI as an assisting tool rather than a replacement for engineering expertise. Before integrating AI into the workflow, we carefully audit project requirements and create custom setups for tasks that can be safely automated with minimal risk. At the same time, all decision-making, ownership, and final responsibility remain in the hands of senior engineers.
This approach has delivered strong results for us, helping speed up development by 2–3x depending on the project.
That makes a lot of sense and sounds like a healthy approach: setting clear boundaries and manual checks at critical points. Thanks for sharing.
Nice points. Nowadays people using AI they are not able to think by their own this is really serious matter. We should not totally depend on AI for any output. Nice written.
Thanks. I am glad this resonates with you as I am seeing this issue get worse over time.
This is a really thoughtful direction — especially the focus on “thinking as a skill” vs just shipping faster.
The 2–5 min exercises idea makes sense — that’s probably the only way this fits into real workflows.
One thing I’d be curious about:
→ when do people actually use it? (before coding, after shipping, during debugging?)
That might shape which exercises stick.
Also, I’m running a small project (Tokyo Lore) where we test ideas like this with a focused group of builders.
Since you’re exploring a pretty deep behavior shift (thinking vs speed), this could be a strong fit to validate how it actually lands.
Happy to share more if you’re interested 👍
Thanks for the validation!
This guide is to be used at all stages. There are exercises for each stage you mention: before coding, after shipping, during debugging.
If you want to share this with your group, feel free to test out this guide.
I would also be curious to know more about your initiative.
That’s great — covering all stages definitely makes it more practical 👍
I like that it’s not just theory but something people can actually plug into their workflow.
From what I’ve seen, the real test is which moments people naturally reach for it without forcing it — that usually shows what’s truly valuable.
On Tokyo Lore — it’s basically a small, focused group where we test ideas like this in real usage (not just feedback, but what people actually stick with over time).
Since your guide is behavior-driven, it could be interesting to see:
→ which exercises people come back to
→ where they drop off
Happy to share more if you’re open 👍