AI Development

Modern Software Development with AI: What's Changed and What Hasn't

An honest assessment of how AI has changed software development in practice — the fundamentals that remain constant and the workflows that have genuinely shifted.

J

Justin Hamilton

Founder & Principal Engineer

ai software development rails modern development productivity

I’ve been writing code professionally since the early 2000s. I’ve seen a lot of things get called “revolutionary” and watched most of them become incrementally useful rather than transformative. AI coding tools are different. They’ve changed how I work more meaningfully than anything since the transition to cloud infrastructure.

But the nature of the change matters. Here’s what’s actually different and what’s stayed the same.

What’s Genuinely Changed

The cost of getting to a first draft is near zero. The blank page problem — staring at an empty file trying to figure out where to start — is essentially solved. I describe what I need and I have a starting point in seconds. This is more significant than it sounds, because starting is often the hardest part.

Pattern-heavy work is dramatically faster. Custom software has a lot of repetition — multiple features that work the same structural way, multiple models that follow the same pattern, multiple API endpoints with the same shape. AI handles this repetition quickly and correctly, freeing developer attention for the non-repetitive parts.

Documentation has gone from ignored to routine. Writing documentation used to feel like the thing I did when everything else was done (which meant it often didn’t happen). With AI, I generate docs as part of the flow. The barrier is low enough that it actually happens.

Code explanation is instant. Working with inherited code — trying to understand what a complex query or a long method actually does — used to require careful reading and often consultation. Now I can ask “what does this do?” and get a clear explanation in 15 seconds.

What Hasn’t Changed

Understanding the business domain is still the hard part. Software is valuable when it accurately models and supports real business processes. Getting that model right requires understanding the business deeply — which requires time, conversation, and experience. AI doesn’t help with this.

Architecture decisions still require judgment. The choices that set the direction for a system — how data is structured, how services communicate, where the boundaries are — have consequences that play out over years. AI can analyze options, but the judgment call still requires experience and context that AI doesn’t have.

Testing the right things is still a skill. AI generates test cases quickly. Knowing which cases actually matter — which edge cases will surface in production, which business rules are subtle enough to need explicit testing — comes from understanding the domain and from production experience.

Production debugging is still methodical work. When something breaks in production in a way that doesn’t have an obvious cause, the investigation process is systematic and slow. AI can help organize hypotheses, but the investigation itself is still painstaking.

Security is still a discipline. AI tools will generate authentication and authorization code, but the security posture of your application is the developer’s responsibility. Understanding threat models, applying security best practices, reviewing for vulnerabilities — these require expertise that can’t be delegated to AI.

The New Failure Mode

With AI tools come new ways to fail that didn’t exist before.

Moving faster than your quality standards allow. AI makes it tempting to ship code that was generated quickly and reviewed lightly. The code looks right. It passes the tests (that were also generated quickly). It gets merged. And then you discover in six months that the generated code had subtle bugs that accumulated into a real problem.

The discipline required is moving faster on the parts AI handles well while maintaining rigor on the parts that require human judgment. This is harder than it sounds.

Letting AI make decisions that shouldn’t be automated. Architectural choices, business rule implementation, security design — these should be deliberate human decisions. AI can inform them, but it shouldn’t make them by default because you didn’t think to question the generated output.

The Compounding Effect for Experienced Developers

Here’s what I’ve noticed after extended use: AI tools compound with experience. The more you know, the better you can use AI.

An experienced developer:

  • Asks better questions (gets better output)
  • Evaluates AI output critically (catches the bugs)
  • Knows where not to use AI (avoids the failure modes)
  • Understands the context AI needs to be useful (provides better prompts)

This means the productivity advantage of AI tools is larger for experienced developers than for newer ones. The tools amplify existing capability.

For clients, this is relevant: you want an experienced developer using AI tools, not just anyone with access to AI tools.


I’ve been building software for 20+ years and I use modern AI tooling seriously. If you need software built by someone who can do both, let’s talk.

Let's Build Something Together

Hamilton Development Company builds custom software for businesses ready to stop fitting themselves into someone else's box. $500/mo retainer or $125/hr — no surprises.

Schedule a Consultation