Every developer has one.

A side project that scratched a personal itch, taught you something new, or accumulated a small but loyal user base. It was exciting to build, fun to ship, and then life happened. Eventually it became one of those projects you always intended to revisit. But every passing year meant more obsolete APIs, more technical debt, and more reasons not to start.

Sun & Moon was one of mine, and it's an app I still use. I originally wrote it in late 2015 to learn Swift. It performs its own astronomical calculations to determine sunrise, sunset, moonrise, moonset, and related information without relying on a third-party library or API. The app isn't particularly large, but beneath the screen lies a surprising amount of complexity.

Ten years of platform evolution. The astronomical calculations held up surprisingly well; the UI and codebase did not.

After updating Xcode and opening that project back up in 2026, the math still worked. Almost everything else around it didn't.

Over the last decade, Swift evolved dramatically, UIKit conventions changed, device sizes changed, and design expectations changed. Seeing that project again felt like opening a time capsule back to an era of apps before microtransactions and subscriptions had infested everything.

I wanted to modernize it, but the reason for taking ten years to get to it is that I never wanted to spend weeks doing it. That kind of work isn’t exactly exciting.

The Part of Software Development I Don't Enjoy

I genuinely enjoy building software.

I enjoy designing features, solving interesting problems, creating and refining user interfaces, and chasing down obscure edge cases. Seeing an idea through as it gradually becomes something tangible and polished is immensely gratifying.

I don't enjoy spending evenings rewriting perfectly functional code because APIs changed.

There has been no shortage of discussion around AI replacing developers, eliminating jobs, and so on. My experience has been far less dramatic. For me it has become an indispensable tool for both accelerating my work and handling the pieces I dislike.

AI isn’t replacing me — it’s giving me a team. Not a team of senior engineers who can independently architect a system, but a team of capable junior developers who can implement well-defined specifications remarkably quickly while I review, guide, and occasionally send them back to try again. They work quickly, occasionally misunderstand the assignment, sometimes need course corrections, yet routinely surprise me with how much they can accomplish once given clear direction.

This new tool has completely changed how I approach side projects.

One of the best analogies isn't in software or even computing at all; it's an executive chef in a restaurant. The executive chef could chop every onion or plate every dish, but that's not the highest-value use of his time. Instead, he's coordinating multiple stations, tasting the food, adjusting seasoning, deciding what leaves the kitchen, and keeping the entire operation moving. The line cooks handle much of the repetitive execution while the chef focuses on quality, timing, and direction.

That's how these side projects feel now. While one model is modernizing Swift code, another might be helping refine an interface or generate marketing assets. I'm regularly switching between reviewing completed work, answering questions, refining direction, and tackling the parts that still benefit most from human judgment.

The bottleneck has shifted. Writing code is no longer the scarce resource. Good decisions are. I'm spending the bulk of my time on the unique technical problems and the overall design and experience of the software.

That's a much more enjoyable role than spending an evening manually translating deprecated APIs one compiler warning at a time.

Resurrecting Sun & Moon

Rather than starting a brand-new application, I wanted to explore the answer to a question: How well could AI resurrect an abandoned project?

Surprisingly well.

One of the first prompts I gave Codex wasn't "fix this bug." It was simply to modernize the project.

That turned into far more than updating syntax: it audited third-party dependencies, removed obsolete frameworks like Crashlytics, generated a README and repository documentation, updated Xcode project settings, replaced deprecated APIs, added an initial suite of unit tests, and narrated the entire process as it worked through the codebase.

Individually, none of those tasks are difficult, but they're also not the reason anyone starts a side project. Those bits of routine, repetitive, mundane work are the boring part of software development, and AI's ability to handle them all with alacrity is what convinced me to dust off a decade-old codebase. Collectively they represented weeks of work I no longer had to dread.

Within a couple of hours, the application had been migrated from early Swift syntax to modern Swift, a task in the past that would easily take weeks.

Next, a completely redesigned interface came together in roughly a day through rapid iteration. It wasn't because AI nailed it on the first attempt but because it let me iterate far faster than I could have manually.

Longstanding display bugs that had lingered for years were finally tracked down and fixed.

One specific example involved an edge case where, at certain times of year and at certain locations, the moon can rise, set, and rise again within the same calendar day. Handling these events correctly while presenting them in the user's local time zone required coordination between the astronomical calculations and the UI. AI wasn't particularly good at deriving the underlying mathematics, but it was more than capable at using the existing calculations to correctly present the results.

That distinction became a recurring pattern.

Where AI Excelled and Where It Didn't

AI isn't equally good at every aspect of software development.

That's okay, and that's the basis of my view of AI being a tooling upgrade rather than replacing developers. The parts of development it falls short on happen to be the parts I enjoy doing anyway.

Generating artwork has been one of the most useful applications of these tools for me. Generating dozens of icon concepts in an afternoon was incredibly valuable, and collectively they explored more design space than I probably would have covered manually in several weekends. Choosing which one actually represented the application well and looked good on screen was still my job, and after a number of revisions, I settled on a strong improvement.

The same was true for the interface. AI could produce layout after layout based on my feedback, but I was still steering the process. It wasn't designing the experience but rather rapidly exploring possibilities under my direction.

I didn’t blindly accept every suggestion. Much like reviewing a pull request from another developer, I read the code, sometimes isolated and tested the behavior, and rejected changes that didn’t meet the standard I wanted. AI sped up implementation, but it never eliminated verification.

Looking back, the pattern is fairly obvious. AI excelled wherever there was existing context to build upon. Modernizing Swift, wiring together interfaces, refactoring code, and generating tests all began with an existing implementation or a clearly defined objective. Asking it to invent a mathematically correct astronomical algorithm from scratch was an entirely different kind of problem.

Expertise Still Matters

A common fear among the software industry is that AI makes software development "too easy" and that it will replace developers. That misunderstands where the hard part of software development has always been.

Writing code has never been the entire job. Experienced developers spend easily as much time planning and making decisions as they do typing. Is this the right architecture? Does this edge case matter? Is the interface intuitive? Does this implementation fit the rest of the project? Those questions don't disappear simply because an LLM can produce code quickly.

I saw that repeatedly while modernizing Sun & Moon.

The model could modernize decade-old Swift code with remarkable accuracy, and it could do it far faster than I could manually. But when asked to do anything around the astronomical calculations that underpin the application, it struggled. Those algorithms required actual domain expertise rather than recognizing patterns from existing code. That's exactly where I found AI to be weakest.

Likewise, it couldn't tell me whether the new icon would still be recognizable at 60×60 pixels, or even reliably apply my desired changes in many requests. It also couldn't decide whether the interface "felt right." It couldn't determine on its own how to adjust the UI to handle that rare triple-event day. Those all required domain knowledge, experience, and judgment.

AI proved exceptionally good at implementation once the problem had been clearly defined. Defining the right problem, and knowing whether the solution was actually correct, remained exclusively my responsibility.

I've become dramatically more productive, and my role has become more focused on the parts of software development that benefit most from experience. Instead of spending evenings translating obsolete APIs or writing boilerplate code, I could spend that time reviewing implementations, refining the design, validating correctness, and making the kinds of decisions that drew me to software development in the first place.

Power Tools for Developers

Framers still know how to frame a house. Modern framers just don't insist on doing it with only hand saws and hammers because that's how it was once done. Pneumatic nailers, laser levels, forklifts, prefab components, and other developments didn't eliminate craftsmanship. They amplified it by removing repetitive, cumbersome labor.

AI is much the same. It's another tool. A remarkably capable one, but still a tool.

The developer remains responsible for architecture, correctness, user experience, quality, and ultimately what ships. The tool ultimately lets that developer accomplish more.

Looking Forward

Every developer has that side project they keep meaning to revive. For years, mine sat untouched because the cost of modernizing it always outweighed the excitement of building on it.

For years, the question wasn't whether I still cared about the project. I did. I still used it. The question was whether I cared enough to spend several weeks modernizing code in lieu of spending that time elsewhere. The answer was always no.

AI didn’t remove the work. It changed the economics of the work.

Suddenly, revisiting a decade-old project wasn’t something I needed to carve weeks out of my schedule to accomplish. It became something I could make meaningful progress on in an evening.

That’s why I think these tools matter. The biggest revelation of this project isn't that AI wrote some Swift code but that projects I had quietly written off as "maybe someday" suddenly feel achievable again.

Sun & Moon is only the first of several side projects I've been wanting to revisit. It started as a way to learn Swift, so it was fitting for it to be the subject once again when pursuing a new purpose with the AI tooling.

I'm still making the architectural decisions, reviewing every line of code, and obsessing over visual details until they feel right. But instead of spending weeks translating deprecated APIs or writing boilerplate, I get to spend that time building, refining, and creating.

The biggest shift isn't that AI has started writing code; rather, it was that implementation stopped being the bottleneck. Decision-making became the scarce resource.

For me, that's where the real promise of AI lies. Not replacing developers but helping developers spend more of their time doing the parts of software development they actually love.