How AI Helped Me Rethink How Software Gets Built

 

Six years ago, I wrote a small Swift framework to fetch content from an API.

In 2026, I rewrote it from scratch.

Not because it was broken—but because the way we build software has changed.

The framework is Gathr, an iOS SDK designed to give developers a clean interface for fetching content like articles, photos, audio, video, and events through a simple API.

What began as a quick helper library eventually became something more interesting: a long-running experiment in how engineering evolves.

And the biggest shift didn’t come from Swift.

It came from AI-assisted development.

The First Version (2016)

Like most frameworks, the first version was simple.

It had:

• A few model objects

• A basic networking layer

• A CocoaPods podspec

The API design was opinionated but practical:

• Singleton access

• Public properties

• Closure-based async callbacks

It wasn’t elegant, but it worked.

And like most early projects, the commit history tells the real story:

• Fixing API endpoints

• Migrating Swift versions (3 → 4 → 4.2 → 5)

• Improving the README

• Refining model structures

Nothing revolutionary.

Just steady iteration.

When a Utility Becomes a Real SDK

The turning point came when real use cases appeared.

As more projects started relying on the framework, the feature set expanded:

• Category-based filtering across content types

• Apple TV support

• Expanded video models with producers and episodes

• YouTube integration

• Notification hooks for async updates

• Swift Package Manager support

The framework stopped being a convenience layer and started behaving like a real SDK.

But the biggest improvements came years later.

The Six-Year Refactor

Between September and November 2025, the framework went through its most focused development sprint.

The codebase gained:

• A dedicated GathrCategory model

• Category filtering across every content type

• Safer optional handling throughout the SDK

• Codable support across the model layer

• Computed properties for episode metadata

• A full unit testing suite using MockURLProtocol

This was the moment the project stopped being “something that works” and became something reliable.

But the next change was even bigger.

AI Became Part of My Engineering Workflow

In 2026, I started using AI as an active collaborator, not just a code assistant.

Instead of asking a single chatbot for help, I built specialized AI agents responsible for different phases of development.

Think of it like an engineering pipeline:

Requirements → Architecture → Implementation → Review → Testing → Documentation

Each stage has its own AI partner.

Requirements Planner

Defines scope and constraints before writing code.

SwiftUI Architect

Designs clean SwiftUI implementations based on requirements.

SwiftUI Code Reviewer

Reviews code for MVVM patterns, dependency injection, and Swift best practices.

Swift Test Writer

Generates comprehensive unit tests using the Swift Testing framework.

DocC Documentation Writer

Produces DocC documentation and polished README files.

This structure mirrors how engineering teams work in practice.

But instead of context switching between roles, I move through a guided workflow supported by AI collaborators.

The result isn’t just faster code.

It’s more consistent engineering.

The Rewrite That Changed the Framework

In March 2026, I made the biggest architectural decision in the project’s history.

I removed every external dependency.

Libraries like Alamofire and SwiftyJSON were replaced with a lightweight internal networking layer built entirely on native Apple frameworks:

• URLSession

• JSONSerialization

• Native Codable models

The result was significant:

• Zero external dependencies

• Smaller binary size

• Fewer breaking updates

• A clearer architecture

This rewrite would normally take weeks.

Instead, it moved quickly because the process was structured.

1. Requirements were scoped first

2. Architecture was designed before implementation

3. Code review happened before commit

4. Tests were written alongside the code

AI didn’t write the project for me.

It helped enforce engineering discipline.

What Six Years of Iteration Taught Me

Building the same framework over six years changes how you think about software.

A few lessons stand out.

Dependencies Are a Loan, Not a Gift

Every dependency eventually has to be repaid—through upgrades, rewrites, or technical debt.

Tests Make Refactoring Safe

Without tests, refactoring becomes guesswork.

AI Doesn’t Replace Engineers

It amplifies engineers who already know what good looks like.

Specialized Tools Beat General Ones

An AI designed for one task consistently performs better than one designed for everything.

Your Commit History Is Documentation

Future you will thank present you.

The Bigger Shift

AI didn’t replace my development process.

It made the process explicit.

Instead of jumping randomly between coding, testing, and documentation, I now move through a clear pipeline:

Design → Architecture → Implementation → Review → Testing → Documentation

Each step has support.

Each step has structure.

And that structure is why the rewrite happened faster and with more confidence than any previous version.

The Future of Engineering Workflows

The most interesting impact of AI in software development isn’t faster coding.

It’s better workflows.

The next generation of engineering tools won’t just generate code.

They’ll help us design systems for building software.

And once you experience that shift, it’s hard to go back.

If you’re building SDKs or experimenting/using AI-assisted development workflows, I’d love to connect.