AI Is Changing How I Think About Software Development

AI is Changing What Makes Sense to Build

I've spent much of my career deciding what software to build, how to build it, and whether the effort is justified. AI is starting to change how I make those decisions.

Projects that would have been difficult to justify a few years ago are becoming practical. Modernizing an aging application, replacing a problematic component library, or testing a new product idea doesn't necessarily require the development time it once did.

That's the part of AI-assisted development I find most interesting. It's not just about writing code faster. It's about reconsidering work that may previously have been too expensive or time-consuming to undertake.

This isn't unique to software development. Advances in

When Six Months Becomes Six Weeks

I recently worked on modernizing the frontend of an existing React application. The original estimate for the work was approximately six months, before AI coding tools became part of the development process.

Using AI-assisted development, I completed the project in under six weeks.

A large part of the work involved replacing components, adapting existing functionality, and dealing with differences between the old and new libraries. AI was particularly helpful with the repetitive implementation work.

There were still architectural decisions to make, particularly around how to separate application behavior from the UI components. That work ultimately made it possible to replace the component library without rewriting the business logic.

I wouldn't claim that AI makes every project ten times faster. The original estimate was made under different assumptions, and the outcome depended on the type of work involved. But the difference was substantial.

It made me reconsider how I would estimate similar projects today. An application modernization effort that once looked too expensive might now be worth doing, especially if it removes maintenance problems that have been accumulating for years.

Faster Code Can Still Mean a Worse System

One of my frustrations with AI-generated code is how readily it introduces unnecessary complexity. I've seen it add wrappers, helper functions, and compatibility layers to make two existing approaches work together, when the better solution would have been to simplify the underlying design.

The resulting code often works, which is part of the problem. A functional result doesn't necessarily tell you whether the architecture makes sense or whether someone will be able to maintain it in two years.

This is where I find that experience with the wider system matters. Sometimes I need to reject an implementation entirely, explain why the approach is wrong, and reconsider the design before continuing.

There's also a tendency to trust the output more as you become familiar with the tools. I've caught myself accepting an answer too quickly because the previous several changes worked well. That's something I have to be conscious of.

If AI makes it easier to produce more code, it becomes even more important to avoid accumulating code that shouldn't have been written in the first place.

The Most Capable Model Isn't Always the Right One

I've also spent time experimenting with AI beyond coding. Using Amazon Bedrock and other model providers, I've built prototypes for document analysis, image assessment, contract review, and customer-feedback classification.

One thing became clear fairly quickly: the best model depends on the problem you're trying to solve.

A more capable reasoning model can be worth paying for when the task is complex or mistakes are expensive. But if you're classifying large volumes of straightforward customer feedback, a smaller, cheaper model may be entirely adequate.

The difference matters when you move beyond a prototype. Processing a few test documents is inexpensive. Processing thousands of documents every day can change the economics considerably.

I prefer testing models against representative examples and comparing the quality of the results, cost, speed, and implementation complexity. There's little value in choosing the most expensive model if a cheaper one produces results that are good enough for the intended use.

What This Changes for Me

I haven't changed my basic approach to technology decisions. I still start with the problem, work through the available options, and consider what it will cost to build and maintain the solution.

What has changed is the range of options available. I can explore alternatives more quickly, test ideas before committing significant engineering time, and revisit projects that previously seemed too expensive.

There are limits, of course. AI-generated code still needs to work within a sensible architecture, and an AI feature still has to deliver enough value to justify its operating costs and maintenance.

I'm interested to see how much further these tools develop. They've already changed how I work, and they've made me reconsider some assumptions I've held about software development for years.