When I first got into software, there were no libraries waiting for us. No package managers. No Stack Overflow. No copy-paste from GitHub.

If you wanted to build something, you built it. Top to bottom.

If I needed to talk to another system, I opened a socket. I connected via TCP. I handled the protocol. If something failed, I debugged it at the wire level. Applications were handcrafted end to end, and you were responsible for everything you shipped.

That experience shaped how I think about software to this day.

From Building Software to Assembling Software

As my career progressed and I started hiring engineers, I noticed something changing. We stopped teaching people how software works and started teaching them how to assemble it.

That’s not necessarily bad, but it does change the skill set.

When I built hiring assessments, one of the things I always tested was algorithms. Not because I expected everyone to be writing sorting routines every day, but because algorithms tell you how someone thinks. They reveal reasoning, tradeoffs, and how a person approaches a problem when there isn’t already a solution handed to them.

Over time, that kind of thinking became less emphasized. We got very good at wiring packages together. We got worse at understanding what was actually happening underneath.

That shift matters more than most people realize.

Automation Isn’t New, Context Is

Long before AI entered the conversation, I used to tell teams the same thing over and over. I can automate almost anything, but we need to start with people.

You let humans run the process first. You iron out the edge cases. You understand where things break. Then you automate the boring, repeatable parts and kick the exceptions back to humans.

That model has worked for me for decades.

What’s new now isn’t automation. What’s new is that software can finally understand a little bit of context. Not perfectly, but enough to participate instead of blindly executing instructions.

That distinction is everything.

The Real Cost of Babysitting Software

At one company, I had a peer who was incredibly good at keeping things running. Customers were happy. Issues were handled quickly. From the outside, everything looked fine.

When he eventually left, I dug into the system and realized how much time had been spent babysitting instead of fixing root problems. Not because he didn’t care, but because there simply weren’t enough hours in the day.

The company didn’t push for deeper fixes because the work was getting done. In reality, they were paying a premium for reactive support instead of investing in durable solutions.

That experience stuck with me.

Software that constantly needs human babysitting isn’t efficient. It’s expensive. And worse, it hides the real cost behind “everything is working.”

How My Thinking Has Changed

Today, I care less about features and more about intent.

Where does intent originate?
How is it preserved as work moves through systems?
What happens when that intent becomes unclear?
And when should software act versus pause and ask for help?

These questions matter more to me now than which framework is trending.

Some principles I won’t compromise on anymore:

• Tools should preserve intent, not just produce output.
• Automation without context just accelerates the wrong outcomes.
• Humans are not a failure mode, they are part of the design.
• Software should adapt to people, not force people to adapt to it.

Why This Is Finally Possible

For most of my career, software was deterministic because it had to be. That made context preservation incredibly hard.

Now we have systems that can reason, summarize, adapt, and operate with uncertainty. We can design workflows that branch. That pause. That escalate. That involve humans when confidence drops.

This doesn’t replace judgment. It finally gives judgment a place to live inside the system.

A Quiet Tease

I’m working on something that reflects all of this.

It’s shaped by decades of building software the hard way, watching teams struggle with invisible friction, and seeing how often people end up doing work that tools should have handled better.

I’m not ready to talk about it publicly yet.

But if modern dev tools feel powerful and exhausting at the same time, we’re probably thinking about the same problem.

More soon.