Last year I read raf’s post, The Curse of Knowing, and it described a feeling I’ve had for most of my career. Once you understand how software works, you stop being able to ignore it when it doesn’t. Every clunky workflow and half-working tool starts to look like something you should fix.

raf lands on a line I keep coming back to:

“But the hardest thing you’ll ever learn is when to leave them broken.”

As I’ve started adopting AI development workflows, this has been a more difficult lesson to learn.

Timed decisions

The district I work in is growing rapidly, and our team is somewhat small for the size of the environment we support. For most of my time here, time decided what I could realistically accomplish. I’d notice a gap, sketch out what a tool should look like, and then add it to a list that never really got shorter.

Some things were left unfinished, and others never got the attention they deserved. Not because I didn’t care, but because the week didn’t have time.

Recently that’s changed. Ideas I’ve had that time wouldn’t allow for are now achievable in just a few days. A web app for managing DHCP. A better solution for staff creating Google groups, without handing out admin console access. A visual map of our network from district down to the closet. Even an agent that can answer “what port is that camera on?” These went from ideas to working solutions.

The curse, accelerated

AI is letting me build more, not just build the same things more thoroughly. With that change, raf’s post hits differently now.

When fixing something took weeks, the time cost made the decision. I couldn’t fix everything, so I didn’t have to decide whether I should. With AI, I can fix the things I know are broken, and build the solution I know should exist. But maybe I shouldn’t always.

My bar hasn’t moved. I still decide what to build based on where I see gaps, or where I believe the most positive impact is. What AI changed is the rate. I just get to clear that bar at a rate I wouldn’t have before.

That sounds like pure upside, and mostly it is. But raf makes the point that software decays, and that the work is never really done. Every tool I ship is one more thing that has to keep working. Being able to build something in a few days doesn’t make it free to own.

Engineer or architect?

This is where I go back and forth.

I have anxiety about skill entropy, and I often feel some amount of imposter syndrome. It’s not necessarily because I don’t believe I could build a thing. It’s because I feel as though I did less of the building.

Maybe I’m no longer an engineer, but an architect?

I’m still the one deciding what gets built, how it fits into our environment, and whether it’s right. I still review everything. But the hours I used to spend typing and debugging are shorter now, and perhaps something went with them.

What I miss most is probably just the feeling of “I wrote this. I made this do exactly what I intended.”

Diving deep

Here’s the counterweight. I also know the depth of my knowledge has increased by diving deeper into problems than I ever had without AI, or would have had the opportunity to due to time constraints.

Recently I built PortLens, an ESP32-based handheld network diagnostic tool, similar to a LinkSprinter. I’ve always been fascinated with hardware, but I hardly pushed into building the firmware to operate a thing. You plug PortLens into a port and it tells you what’s on the other end.

Building it, I learned more about hardware requirements than I imagined I would. I learned the difference between the hardware modules used for networking, and how each one allows data to be surfaced in different ways. Before, I wouldn’t have had the time to go get that knowledge.

So the honest answer to “am I still an engineer?” might be that I’m a different kind of one. I write less of the code by hand, but I understand more of the system.

Internal tooling

My focus has been on building internal tools to reduce friction in our environment, and I think that’s such a fun space for AI development. The risk is low, the reward is high, and with proper risk management your exposure is low when the product never sees the light of day (or the internet).

That doesn’t mean anything goes:

  • Review: I still review everything that ships.
  • Exposure: Apps built with AI assistance stay internal, keeping attack surfaces small.
  • Testing & audits: I test, test again, and run security audits.

Internal tools are also forgiving in a way public products aren’t. The users are my coworkers, the environment is one I know well, and if something breaks I’m the one who hears about it first.

Final thoughts

I haven’t learned when to leave things broken. If anything, AI has made it easier to avoid the question.

If you’re feeling the same pull, I don’t think the answer is to build less on principle. It’s to keep the bar where it was: build where the gaps are and where the impact is real, and let the rest stay broken a little longer.

And if you’re in K-12, working a list that grows faster than your team does, I hope this is a little encouraging. The tools we wished existed are within reach now. The ones worth building are still the ones that make life easier for the people we support.

raf is right that you can fix some things, not everything. That’s still true. It’s just that “some things” got a lot bigger.

˙ʞuı˥ ʎɐpɥʇɹıᗺ ʎddɐH