I finally got around to updating a personal app I had neglected for years. I had a list of features in my head, but I kept putting it off because I knew it would take a few weekends of focused work.
With AI, I got most of it done in a weekend. Not perfectly. Not magically. But fast enough that the project went from “someday” to “working.”
AI is powerful, but it still needs engineering judgment.
The speed is real
In the past, I would have spent several weekends implementing these features. With AI, I was able to move significantly faster. It generated boilerplate, helped scaffold screens, suggested database changes, and accelerated many of the repetitive parts of development.
Instead of spending most of my time typing code, I spent more time reviewing, evaluating options, and making design decisions.
AI reduced the cost of implementation. It did not eliminate the need for engineering judgment.
Where AI was not always right
One thing I noticed was that AI tends to optimize for solving the requirement it sees at that moment. It is much less effective at understanding how a system evolves as requirements change over time.
In one example, it created both a deletedAt timestamp field and a separate
deleted boolean field. Technically the solution worked, but the boolean field
added no real value because the timestamp already told us whether a record had been
deleted.
Keeping both fields would have increased complexity and created more opportunities for bugs when the two values inevitably drifted out of sync.
The more interesting example involved budget history tracking.
Early in the project, we introduced a new database table to track and retain budget changes. At the time, the requirement justified having a separate structure because we anticipated managing and storing budget history differently from the primary budget records.
As the feature evolved, however, the requirements changed. Through discussions, feedback, and a better understanding of the actual business workflow, the distinction between the two datasets gradually disappeared.
What started as a specialized history table slowly evolved into a table that was tracking information very similar to what already existed in the original budget table.
By the end of the design process, there was little reason to maintain two separate structures. The new table was no longer serving a unique business purpose and much of the information could have been stored directly within the original budget history model.
The interesting part was that AI never recognized this shift. It continued building around the earlier architectural decision because that decision had once been valid.
From AI's perspective, the solution was consistent with the historical design. But software architecture is not just about consistency. It's about periodically stepping back and asking whether the original assumptions are still true.
Once I re-evaluated the final requirement instead of the original requirement, it became clear that maintaining two separate tables was introducing unnecessary complexity.
AI remembered the solution. Engineering required questioning whether the original problem still existed.
The difference between coding and engineering
That experience reminded me that software development is not just about generating code.
Requirements change. Assumptions become outdated. Features evolve as teams learn more about what users actually need.
AI is excellent at producing implementations. Engineers still need to recognize when yesterday's architecture no longer matches today's business problem.
The best engineers are not the ones who write the most code. They are often the ones who recognize when code, tables, services, or entire features are no longer necessary.
What changed for me
Before AI, a large portion of my time was spent implementing ideas. Today, implementation is often the fastest part.
The bottleneck has shifted toward architecture, product thinking, understanding user needs, and making good technical decisions.
The better AI becomes, the more valuable judgment becomes.
That's why I don't see AI replacing experienced engineers. I see it raising the importance of the parts of engineering that were already the hardest: understanding trade-offs, simplifying complexity, and deciding what should be built.
AI helped me ship more in a single weekend than I might have accomplished in several weekends on my own.
But I was still responsible for the architecture, the trade-offs, and the final decisions.
AI made me faster. Engineering made the result better.
← Back to writing