What I've realized is this: AI is an amplifier of what you are. It's not a substitute - it just reflects and scales whatever you bring to the table.
When I was younger, I'd often just run at the wall and try to scale it fast. I'd throw a lot of code at the problem. Not out of carelessness - I was iterating quickly, looking for a working prototype that gave me feedback I could work with. Structure and architecture didn't matter to me as much - what I wanted was to hit the goal, the concept, the tangible result.
And that actually worked. I built a lot of stuff that way.
But I assumed AI would kind of "handle" the rest - that it would take care of the complexity, or clean things up. And what I've come to see is that AI just reflects your approach. If I'm in "throw code at the wall" mode, AI will just help me do that faster. Which can help. But it won't make the problem go away. It just accelerates whatever rhythm or method you're already in.
If you're designing systems, it can help you do that better. And if you're caught in a whirlpool of iteration, it can pull you in faster - unless you consciously step out and take a broader view.
That's the maturity I've been leaning into - stepping back, taking the time to think more expansively, seeing where the architecture needs to evolve to support the real model of what I'm trying to build. Because ultimately, building good software isn't just hitting the feature, it's about achieving a kind of mastery over the data and logic flow in the application.
There's something subtle there - like crossing the threshold between "everything technically works as a PoC" to "this is a robust, extensible system." The complexity isn't in the features themselves, it's in handling the state space, the transitions, the edges. It's in aligning the implementation with the model. When those are out of sync, you're constantly rubbing against invisible friction - and you know it, even if you can't immediately name it.
Today I had a moment that helped crystallize this. I was focused on this one feature - switching tabs and preserving focus state - and at first glance, it didn't seem like a big deal. But I just knew it was important. And in hindsight, it was a kind of genius intuition. Because solving that feature meant proving out a broader mastery of the data flow and internal consistency of the application. It forced the architecture to evolve in the right direction.
So this was the second kind of complexity - not about hitting a proof-of-concept, but about finessing the system into something real and usable, something that can hold together even as it grows. And being able to focus that amorphous challenge into a concrete goal - that's part of the craft. That's something I've learned, slowly, over time.
I think about people like Knuth - the legend of him sitting down and writing TeX or sendmail, and it just ... worked. Or people like Bellard who consistently produce numerous high-quality systems. I think what's cool about software is that it's a craft you can keep getting better at as you age. The ability to build clean, extensible systems isn't just raw talent - it's a process, and it deepens over time. Mastery.
So yeah, I've come a long way from the days of just hitting features as fast as possible. I want to take a less stressful approach, that's more thoughtful.
AI won't do that part for me. But it'll help me go faster once I've made the right decisions. It'll help me push further, once I've picked a good direction. It's a power tool. And like all power tools, it just makes you more of what you already are.
So that's my reflection. I'm curious about others' too - how has your approach to building systems changed over time? How do you think about AI now that the dust has settled a bit? What has your journey with software looked like?
OgsyedIE•3d ago
https://www.lesswrong.com/posts/apCnFyXJamoSkHcE4/cautions-a...