One of the biggest surprises in my journey toward becoming an AI engineer hasn’t been learning new frameworks or getting better at prompting AI. It’s been learning to think differently depending on who I’m building for. When I’m building an app for myself, success is simple: does it solve my problem? I don’t care if the UI is rough, the architecture is questionable, or I have to restart it once a week. If it saves me time around the house, it’s a win.
Building software for work is a completely different mental model. The question is no longer “Can I make this work?” It’s “Will someone else understand it? What happens when it breaks? How will Support troubleshoot it? What assumptions am I making that my users won’t?” I’ve realized that the hardest part of engineering often isn’t writing the code. It’s thinking through all the people and systems that interact with it after you’ve shipped it.
What’s been interesting is that my side projects have actually made me better at my day job. At home I can move fast, try bad ideas, throw things away, and learn without consequences. At work, those experiments give me better instincts for building software that’s reliable, maintainable, and designed for people other than myself. The code may look similar, but the mindset couldn’t be more different.
I’m starting to think that becoming an AI engineer isn’t just about learning new tools. It’s about learning when to think like a builder, when to think like a customer, and when to think like the person who has to support what you built six months from now.