DEV Community

Alexandra
Alexandra

Posted on

The Curiosity Gap: Why We've Stopped Asking Questions

Over-automation kills engineering curiosity

In a comment some weeks ago (link) i wrote about how it doesn't matter if you are using AI or not, or if you call yourself a vibe coder or a SWE. Over my years of working with code, I have seen passionate people who are excited and want the product to succeed, and people who have no interest in improving anything and promote enshittification. In my unpopular opinion, it all comes down to how much you care about the outcome and the quality of your work, and how curious you are to learn the whys.

In this post I want to dig into that second part: curiosity, or rather, the lack of it. Last year I felt so stuck, I didn't feel that I was learning anything or producing the results I want to. Even though I was shipping code (a lot of it), everything was feeling pointless. Everyone around me was so obsessed of automating everything, that learning and progressing as an engineer was an afterthought. Even though they were pushing us to use AI in a ridiculous degree, and our performance was almost certainly evaluated by token usage, they didn't offer any material, courses on how these systems really work, what are the optimal ways of using them and why we should care. Their thought process sounded more like "use-this-produce-money" and the magical answer to everything was "ask claude".

Buuuut...What it took me a long time to realise was that the only person that is responsible for my learning and the quality of my work, is me. I had slowly and steadily gave up trying, because everyone was telling me that I will be replaced. But nobody will come and save me, or implant knowledge in my head. It's on me whether I offload all my thought process to AI and don't care anymore, quote very confidently what claude answers me back or whether I doubt on the quality of my work and push for the best. Somehow this is how I started writing here again. My mantra is that if you can't explain it simple, you don't know it, so writing helped me identify my gaps and what really really interests me.

I see lately both in my friends, my professional circle and even on linkedin, that many people have mentally given up (generally, not only in SWE). The state of the world isn’t the best. We’re constantly hearing about AI replacing jobs, industries changing overnight, economic uncertainty, climate anxiety, wars, and about 147 other reasons to wonder what the hell we’re doing here and what is the point of anything.

When you’re constantly being told that whatever you’re learning might be automated tomorrow, I can understand why people stop investing to their skills or even to themselves. Why bother getting good at something if it might not matter in a few years (or months/weeks?). Why even bother look at the code when AI generates it, AI reviews it and AI documents it? Why even invest on learning how to code? And somewhere along these lines we lost everything that made this job interesting.

My question to you dear reader: Does it really matter if AI can do the skill/task/programming? The promise of these fancy tools was to automate the boring tasks and us the humans we will continue doing the interesting or difficult parts. Is that what we are really doing? Somewhere in this trip we started offloading the interesting or the difficult and kept the worst part of this job for us - managing a tool. I like solving problems, find where this little bug comes from, create a new feature. It's like little puzzles to me, that you play the detective and you need to find the culprit. I really enjoy solving these by myself. So who cares if they can be automated? The world won't stop about the half hour more I will take to do something without Claude whispering "Yes, you are right, i underestimated the scope".

 Not everything should be done in the name of automation and efficiency, sometimes we do stuff for the sake of enjoyment and curiosity.

So maybe it's a good time to re-invest to ourselves and start be curious again. Care about what we are doing, even if we don’t know whether that thing will still exist in a year. The time that we invest to ourselves and our skills are never wasted. You can learn a new programming language, try a non-tech hobby, learn how the electronics world works, try a new library, revisit old projects, or build something completely unrelated to our job. Maybe we get the inspiration or motivation we need from somewhere we weren’t expecting.



I don’t think the answer to uncertainty is to stop being curious because AI can do it anyway. Sometimes we learn because we want to expand our mind or simply because it's just fun.

So, thank you, for coming to my Ted talk and the optimistic message of the day for you is: Stay curious! ✌️

--
This post was written by human(me!) and might have grammar errors.

Top comments (24)

Collapse
 
learn2027 profile image
meow.hair •

Thank you so much for this insightful and inspiring article! Your reminder to stay curious and take ownership of our own learning really resonated with me. I truly appreciate the effort you put into writing this. Keep up the great work!
🧊🗻😁

Collapse
 
ikrame-ih profile image
Ikrame Ibn Hayoun •

The "if you can't explain it simply, you don't know it" bit is exactly why I write things down now. I really got obsessed with documenting everything I do or develop rn. AI can make my output look finished way before my understanding is. The dangerous part isn't using it, it's losing the discomfort that makes you ask one more why. My rule lately: if I can't re-explain an answer in my own words, it's not done. AI should makes us smarter, not lazier

Collapse
 
ale3oula profile image
Alexandra •

Same here! I was writing things in an actual paper way before, nowadays is a must when my memory and attention gets more and more divided

Collapse
 
unitbuilds profile image
UnitBuilds •

I actually found that I ask more questions with AI, than without it. I research more, I learn more and I still get more done. Not cuz I let AI do it all, but because when it finishes a round, if there's anything I dont understand, I ask it to elaborate, if I still dont understand, I send the AI on for it's next round, then research it manually. Something I find quite useful though, is key-word queries. Eg. Write a function in rust, then ask it 'how would we optimize this for zero-alloc', it'll then check allocations and give you a theory on how to reduce it and whether true zero-alloc is possible. Yes, it's not perfect, but it helps you find the small things that can be the difference between a server hitting 1gb of ram usage under 1000 concurrent users, or stay stable at 50mb. It makes a difference, because it compounds and I would have never asked that question if I was stuck figuring out getting it working, let alone optimizing.

In that sense, AI really has given us the opportunity to look broader and dig deeper, because often we dont have the right question to research it ourselves, vs AI gives us the keywords we need to learn specifics.

Collapse
 
ale3oula profile image
Alexandra •

Hmm, yes, techinical questions are easy to answer by an agent. But there are some that needs collaboration, like "why we are building this in the first place" or finding a limitation before writing a single line of code, that i see people just give up to ask. I see more and more that design and user requirements are moving after the development, which make the pipeline WAY slower.

Collapse
 
unitbuilds profile image
UnitBuilds •

In many ways, yes. But in others they make the end task more deliberate, depending on how you use it. Eg. When investigating a concept, I ask alot of questions, regarding common use-cases, edge-cases, industry equivalents, what's users' biggest complaints, what makes it maintainable, where do these systems generally fail, how can we optimize it without sacrificing compatibility, etc. All questions that get answered immediately, whereas they'd take a decent while to research manually. It's that instant nature that makes me more willing to ask them, rather than weigh the tradeoffs and ignore them, because it would take too long.

It's like that old saying about chopping a tree, you spend more time sharpening your axe than chopping. Do the things that are low-effort first, so they can make the high-effort task more deliberate and easy to manage. Like sketching out a roadmap, architectural diagram, Red-teaming, etc. All things you can just prompt your way through, before writing a single line of code, because with those files in place, you have a solid design to ground the implementation with and it simplifies it enough that you'd understand the concept, before you ever code. It makes the process slower, but lets remember, 10 minutes of planning beats 10 hours of debugging.

Thread Thread
 
ale3oula profile image
Alexandra •

Yes, i agree 100%, try to convince a manager though 😂 Some things will take time, no matter what

Thread Thread
 
unitbuilds profile image
UnitBuilds •

That's why I tend to lean towards higher autonomy and ownership roles. Give me a task, let me do it my way... Dont micro-manage. You hire for experience, so that experience can be applied right? But seems to me that the more people get into AI in their companies, the more paranoid they get, despite proven results.

Thread Thread
 
ale3oula profile image
Alexandra •

The last couple years i worked in more corporate environments, and ownership even though advertised was never an option. Autonomy not a chance. Especially after the introduction of AI, we had this impossible requirement to do things in a ridiculous short amount of time, and most of these things were not even thought a bit. At that point i also lean to roles with more ownership and autonomy, I am a bit "scared" to go back to this insanity that bigger companies are

Thread Thread
 
unitbuilds profile image
UnitBuilds •

Agreed on that. My last job was full autonomy, then that degraded to micro-management. That's half the reason why I left, because quality of work got degraded as a result, I was constantly checking in to get feedback which slowed me down and the solutions I got told to implement were always flawed and then it circles back to what I originally proposed. A massive waste of time and patience, for what?

Thread Thread
 
ale3oula profile image
Alexandra •

I feel that many people no matter how good engineers they are, are skipping this process. You got to find these edge cases, predict a bit of the future of the feature, asking the questions and even..read their (or claude's) code. I think before we could more comfortable say no to stupid requests, but now that "code is not the bottleneck" it seems the critical thinking is, and mainly they want to eliminate it. And that's horrible, i guess thats why we see many burnout engineers absolutely hating the state of tech in 2026.

Thread Thread
 
unitbuilds profile image
UnitBuilds •

It boils down to talk is cheap. People love talking, AI listens and implements. Hence implementing is cheap... Before, it was discuss before you implement, now it's bring a POC and see if it breaks. Not necessarily a bad thing, just people try and rush to the point, as opposed to properly architecting the solution. Not always a bad thing, you get some cool things from that approach. But it's generally speaking pretty bad...

Thread Thread
 
ale3oula profile image
Alexandra •

Yeah, i would even suggest that "People love talking, AI compliments their ideas, the ego gets high, everything is up for implementation".

I mean, bringing a PoC is not a bad thing, the contrary. But it is still a prototype not a production ready feature. Hopefully in some months they will understand that there is no point for this rush and anxiety and we start re-implementing products that make sense!

Thread Thread
 
unitbuilds profile image
UnitBuilds •

That's actually a philosophy I understood more precisely when I read the task Wasmer gave me as a 'take home assignment'. The scope is clean and clear, AI could implement it in it's entirety in 20 min, no doubt about that part... But the real task is hidden in the message and it boils down to 3 things. Ask, before you do. Implement a POC, not even a MVP, but know it's limitations and how we'd expand it. Use AI, but understand what it did. It's not about getting it done fast, or perfect, it's laying the groundwork to discuss the direction. The scope is essentially useless, if you actually go and implement it, or come back with a POC day 1, you fail. Because you rushed and in production, rushing costs money... Your 20 min of AI to implement it, cost more than 30 seconds to message about it. Because tokens are expensive... Research is practically free.

Collapse
 
beusebiu profile image
Eusebiu Balan •

The tell for me is whether I can explain why the thing I shipped works, not just that it does. When I cannot, I usually end up building it again six months later because I could not adapt it.

The other one is how long I go without reading someone else's code. When everything I touch is either mine or generated, the only ideas in the codebase are the ones I already had.

Collapse
 
ale3oula profile image
Alexandra •

True, but what happens when many many people ship to the codebase? Along with agents. That makes it increasingly harder to keep track!

Collapse
 
beusebiu profile image
Eusebiu Balan •

On a team you cannot hold it in your head, so the test has to move off the person and onto the pull request. If nobody wrote down why a thing exists, somebody deletes it by accident six months later and finds out in production. Agents just make the pile grow quicker.

Collapse
 
prasad-dev profile image
Prasad V •

The biggest thing I feel is, it is not about curious - as you mature in the industry, most of us just choose what is worth (few are exception).

Collapse
 
ale3oula profile image
Alexandra •

'What is worth' in what manner?

Collapse
 
prasad-dev profile image
Prasad V •

At least in my context: Even if I propose an approach or solution for a problem would that be supported by the team and company OR can I do it on my own - is it worth to pursue so the time/effort vs gain etc.., so many what if run in brain and will end up skipping most.

Thread Thread
 
ale3oula profile image
Alexandra •

I understand that this holds about the actual work, but learning is not necessarily about efficiency or gains.

Thread Thread
 
prasad-dev profile image
Prasad V •

True, but as you get older, that is what it will end up with (for the most people, not everyone - agree)

Thread Thread
 
pepapepa profile image
pepapepa •

If that was true... then Prasad and I would not be able to work, because Prasad V and I would not have all those simplified tools which were made by people who invested decades of their life into pursuing things that Prasad V and I cannot even comprehend still.
Humbleness is not a property of Prasad V and little old me, it seems.
We salarymen (like Prasad V and I) must be careful with our words, when we are talking about people like Naur, Knuth, Liskov and of course centuries of Eulers laying the foundations for us.
So in summary, I agree with you Prasad V on one point you made: We got older. We now have to buy more candles for our birthday cakes. Good on us.
Years did not make us more humble though.
How was it about respecting our elders?
We are not the good apples, Prasad V... we are not.

Thread Thread
 
prasad-dev profile image
Prasad V •

😀😀