The code came faster than ever. The harder question was whether I was becoming a better engineer in the process.
AI assisted post: I’ve spent years treating a mobile app as my personal learning playground. I never published it, but it was where I explored architectural styles like MVVM and MVU, experimented with dependency injection, and practiced keeping clean service-oriented boundaries. I also used it to test API patterns, performance, and to watch the .NET ecosystem evolve over time.
At work, AI tools like Claude and Gemini are now everyday instruments for writing, analysis, coding, and prototyping. That inspired me to try Cursor for my own project. With its flexible models and capacity, I essentially rewrote the app. It’s a book-series tracker—simple in concept, but tricky in practice because reliable series data and ordering are hard to source. In a few weeks, working only a couple of hours a day, I rebuilt it into a cleaner, more functional app with a modern iOS-style feel.
But that raised a deeper question: what am I actually learning? When most of the work becomes writing prompts and requirements, it’s easy to worry that we’re outsourcing real engineering judgment.
The question I asked my self, Am I learning anything new anymore? While I am learning a great deal about how to work with AI and produce some amazing tools, apps, and analysis. But what about true engineering, am I learning anything there, am I am challenging my self to think deeper, figure things out and understand how things work under the cover.
Not as much as I used too, now It’s like doing a code review with a very fast engineer: produces real results and I can skip understanding whats inside the black box with the pressure of speed and doing more with less. Something I am not all that comfortable with as I self reflect.
And it raises a bigger concern: as teams and individuals build internal apps and dashboards without deep engineering backgrounds: how do we make sure the code is reliable, efficient, and not quietly increasing cost? Or just down right produces the wrong results.
So maybe the real shift is this: AI changes what being “smart” in software means. Less time on boilerplate, more on judgment, design, and asking sharper questions. The fundamentals still matter, especially for maintainability and long-term quality, but our craft is evolving. The challenge is keeping our engineering muscle strong while we learn to collaborate with these new tools.
Add comment
Comments