I Keep Asking Why: The Mindset I Want to Keep in the AI Era

Answer Snapshot

A conversation with my lovely wife made me wonder what it actually takes to become an engineer or an architect.

We started with skills and experience. Within 10 minutes, we were talking about mindset. That made me look at a learning loop I had never named:

• Observe: Notice how people and systems behave, especially when someone handles a situation better than I did.
• Ask why: Look past the visible action to the purpose, constraint, assumption, or trade-off underneath it.
• Test and reflect: Try a better response, return later, and keep what actually worked.

I use this loop to improve how I work with people and how I design systems. AI makes it more important, not because AI is unable to answer why, but because a plausible answer is still not a grounded decision. Someone has to test it against reality and own what happens next.

The Question My Wife Asked Me

My wife and I were talking about what makes someone an engineer and what eventually makes someone an architect.

The first answers were obvious: coding experience, system knowledge, communication, design patterns, technical depth, business understanding, and time. All of those matter. None of them felt complete.

After about 10 minutes, we were no longer building a list of skills. We were talking about a way of thinking. That turned the question back toward me: what, if anything, do I do differently from other people doing similar work?

People I have worked with often describe me as extremely self-motivated and passionate. I have never been completely sure how to explain that. It does not feel like a source of energy I deliberately switch on every morning.

Logical thinking and coding have also been part of my life for long enough that they now feel natural. I rarely stop to separate what came from experience, what I practiced intentionally, and what I learned from the people around me.

When I tried to answer honestly, the first thing that came to mind was not code. It was how much attention I pay to other people.

The Habit I Had Never Named

I often see a quality in someone and mentally save it.

One person stays patient when a meeting becomes tense. Another can explain a complicated system without making the listener feel small. Someone else knows when to stop discussing and make a decision. A careful engineer catches an assumption everyone else accepted. A good manager removes friction without making a show of it.

I find myself replaying those moments:

• Why did their response make the conversation smoother?
• What did they notice that I missed?
• How would they have handled the situation I just handled?
• Which part of their behavior could I practice next time?

This is not useful when I reduce it to "they are better than me." That turns learning into ranking. The more useful question is specific: what did they do well here, why did it work, and can I practice the principle without copying their whole personality?

What people call self-motivation may be this loop repeating:

1. I notice something I respect.
2. I compare it with how I currently behave.
3. I ask what created the difference.
4. I try a small change in a real situation.
5. I return and see whether it worked.

Learning leaves evidence that I can improve. That evidence makes me more curious, and curiosity sends me through the loop again.

Passion may look like constant energy from the outside. It does not always feel that way from the inside. Sometimes it begins with frustration, a failed attempt, or the uncomfortable realization that someone handled a situation better than I did. What keeps me moving is the belief that the gap contains something I can learn.

The same thing happened with engineering. I was not born knowing how to inspect a production failure, separate a symptom from a cause, or decide where responsibility should live in a system. I learned through code, mistakes, reviews, arguments, incidents, books, experiments, and people who thought differently from me.

The result eventually felt like instinct, but the instinct was trained.

That was the connection I had not seen before. Learning from people and asking why in engineering are not two separate habits. They are the same loop. I notice a difference, look for the reason behind it, try a better response, and return later to see whether it worked. I do that with my behavior, and I do the same thing with systems.

AI made this connection more visible because generated output can skip parts of the training loop. A person can reach working code without seeing the decisions underneath it. The implementation may be correct, but fewer of the reasons become part of that person's own judgment.

Why AI Made This Habit Visible

The aggregate labor-market evidence is still mixed, but AI is already automating some tasks and changing some roles. I do not think denying that pressure helps anyone.

I am also not convinced by the easy promise that every job removed will be balanced by a new and equally accessible AI job. New work will appear, but transitions are uneven. The person whose role changes today cannot pay a bill with a position that may exist for someone else in three years.

So the fear is real. Some work that people spent years learning can now be produced in seconds. I do not have a prediction that makes that fact comfortable.

My response has been to move toward the change. In my previous reflection, I wrote that I am aggressively trying to replace myself with AI. I still mean it.

I want AI to take repeated questions, routine messages, mechanical implementation work, and the interruptions that break my focus. If a task can be described clearly, checked reliably, and repeated without my judgment, I want to ask why I am still doing it manually.

What I am trying to preserve is not a pile of tasks. It is the ability to understand a situation, decide what matters, and take responsibility for a direction.

When implementation becomes cheaper, the important question is no longer only whether something can be built. It is whether it should be built, which constraints deserve to shape it, and which consequences we are willing to accept.

That is why I keep returning to the difference between what, how, and why.

AI Can Help Decide, but It Cannot Own the Consequences

Question	What it usually seeks	Engineering example
What?	An output, requirement, state, or object	What needs to change in this feature or ticket?
How?	A method, sequence, implementation, or tool	How should we build, test, and release it?
Why?	A purpose, constraint, trade-off, or reason to act	Why does this need to exist, and why is this trade-off acceptable here?

Engineering needs all three.

A team that only asks why can discuss purpose forever and ship nothing. A team that only asks what can produce a backlog with no coherent direction. A team that only asks how can build an elegant solution to the wrong problem.

Give AI a repository and a well-bounded Jira ticket, and it may tell me exactly what should change, how to implement the feature, and what status belongs in the ticket. That can save real time. The ticket still may not explain why the feature deserves capacity, why one acceptance criterion protects the user, or why the obvious implementation creates a cost somewhere else.

It would be convenient to say AI handles what and how while humans own why. I do not think that is true either.

An LLM can produce ten reasons for a feature, compare architectural options, identify business goals, and write a persuasive decision record. Sometimes it will do that better and faster than I can.

The problem is not whether AI can generate a reason. The problem is whether that reason should govern this decision.

The model sees the context I provide. It does not automatically know which stakeholder is leaving out an important concern, which operational burden the team can actually carry, which requirement is political rather than technical, which past failure still shapes trust, or which assumption will stop being true next quarter.

It can help me reason. It can challenge me. It can reveal an option I missed. But a plausible explanation is not the same as a grounded decision. Someone still has to test the explanation against reality and own what happens next.

That does not mean AI should never make a bounded decision inside a system. It means the builder still owns the boundary, validation, escalation path, and consequences.

The difference becomes clearer in architecture.

Suppose I ask whether I should choose pgvector or Neo4j.

AI can tell me what each technology does. It can show me how to install either one, generate schemas and queries, compare common trade-offs, and scaffold a proof of concept.

None of that answers the decision by itself.

I still need to ask what kind of problem I actually have. Is similarity search central to the workload? Are relationships first-class data that people need to traverse? Is PostgreSQL already an operational strength for the team? What query patterns need to stay fast? What consistency, maintenance, migration, and failure costs can we accept? Are we choosing for a measured requirement or for a future we have imagined?

The right answer could be pgvector. It could be Neo4j. It could be both, later. It could be neither.

An architect is not valuable because they remember a larger catalog of tools. The catalog helps, but the harder skill is connecting a decision to the problem, the people, the constraints, and the consequences over time.

I previously described my technical path from software developer to AI architect: skills, scripts, MCP tools, SDKs, and the realization that an LLM should not own the control plane for important workflows. Each step in that path started when I asked why the previous approach failed. The implementation gave me evidence. Asking why connected those failures into a direction.

To me, becoming an architect does not mean leaving code behind. Code is where many architectural assumptions are exposed. It means widening the frame: from whether a component works to why the system should have it, how it fails, who operates it, and what future choices it makes expensive.

The Loop I Use in Practice

This can sound abstract, but I do not have a formal self-improvement system. I use the same loop in ordinary work:

1. Observe. Look at what happened without rushing to defend my first response.
2. Ask why. Identify the purpose, assumption, constraint, or behavior that created the result.
3. Test. Make a small change in a real situation, preferably one that is reversible.
4. Return. See how the behavior or decision aged instead of judging it only at the moment it was made.

After a difficult conversation, I replay my part and ask what would have made it clearer or smoother. Before implementing a large change, I try to state the reason and the constraint in plain language. When AI gives me a solution, I ask which assumptions make it a good solution and what evidence would make it wrong.

The loop also has failure modes:

Failure mode	Correction I try to make
Asking why becomes analysis paralysis	Time-box the investigation, name the unknowns, and make the smallest reversible decision.
Asking why sounds like an interrogation	Challenge the assumption or system without making the person defend their worth.
A persuasive explanation is treated as evidence	Look for missing context and define a concrete way the explanation could be wrong.

Sometimes the reason is already known and the next useful action is execution. Asking why for the tenth time can become avoidance dressed as depth. Once the reason is clear enough, I need to return to what and how and finish the work.

A why that never changes a decision or behavior is not depth. It is only another explanation.

The Answer I Would Give My Wife Now

I think this is the answer I was trying to give my wife.

I did not become an engineer because I learned one tool, reached one title, or discovered a question that AI cannot answer. I became one by repeatedly noticing what I did not understand, asking why it mattered, trying a better response, and learning from the result.

That is one path, not a prescription. Different people become excellent engineers in different ways. Some learn by building. Some learn by teaching. Some see systems spatially. Some have extraordinary attention to detail. Some understand people and organizations better than any architecture diagram can show.

This is simply the behavior that seems to have shaped me: I look for good qualities in the people around me, inspect my own response, and keep asking why the difference matters.

I am not very worried that there will be no opportunities for me. That does not mean I think I am immune to the job market or uniquely impossible to replace. My confidence comes from the direction I am moving.

I know how much change I can bring to a company when I understand the problem, connect technical decisions to business reality, and keep improving how I work with people. I also know that today's useful skill can become tomorrow's generated output.

So I do not want my confidence attached to a tool, title, or task. I want it attached to my ability to learn, question my assumptions, and become useful in a new context.

Technical skill matters. Experience matters. Communication matters. Repetition matters. The ability to deliver matters.

Under all of those, I have found a loop that keeps pulling me forward.

What tells me the task.

How helps me execute it.

Why helps me decide whether it is worth doing, whether this is the right way, and whether I am willing to own the result.

AI can participate in every one of those questions.

I still need to become the person who can judge the answers, act on them, and learn when they are wrong.