Every few weeks, we have a new start of the art AI model release, promising better coding abilities. I get tempted, and undertake a review of my code and its architecture. AI presents me with a list of errors and recommendations, which made me wonder: is it really this bad?

On every new commit, a small worry keeps building momentum within me: is my code stable for the long run? I am dependent on AI for every line of code in my app. In my initial days, I asked AI to explain every line of my code. I stopped doing it in my quest for speed. 

Learning how to code is a laborious task. Hence, I invested my energy towards learning how to think like a software developer. Two weeks ago I came across two new videos that helped in improving my workflow:

  1. Simple Made Easy
  2. Writing Good Code

Simple Made Easy

Two weeks back, I was updating my attendance rules. The tool was built in March’26. AI had hardcoded most rules within the code. I asked AI to dig deeper, ensuring there are no loose ends. AI identified four functions, which depended on the rules. 

The audit recommended storing the rules in DB. It listed an additional three more functions dependent on my attendance rules. I resolved many such similar issues already but a few still persisted in my code.  

The audit’s suggestion required me to scrap the existing PRD. It recommended a new function that would provide values from DB to all the functions. It was a simple solution, not the easy one that AI usually recommends. 


AI prefers easy over simple solutions

In my earlier logs, I wrote about two challenges that I often face with AI: (a) AI works better if you know the right vocabulary, and (b) Context Rot. The simplicity-audit skill helps me to overcome these issues. 

AI writes PRD as explained in Log 26. Once a PRD is generated, I invoke the simplicity-audit skill in another session to suggest further improvements. The simplicity-audit skill recommends me to proceed or modify or rework my plan.

In the past two weeks, I audited 25 PRD’s. It recommended modifying 5 PRD’s, suggested minor fixes in 12 PRD’s, and cleared 5 PRD’s. It asked me to rework 3 PRD’s again due to major issues. 

Once everything is built and reviewed, I run a fallow skill before I commit the code. Fallow scans my changes to identify: duplicated code, unused files, unused dependencies, and unused exports. 

Initially, when I ran fallow to scan my entire codebase, it identified 4000+ lines of dead code, 10 unused dependencies, 40 stale type exports, and flagged more than 50 functions. The fallow skill provided clear instructions on what was no longer needed in my app and which functions were too complex. I removed the 15 files and 10 dependencies it flagged, and the report helped me shed over 2,500+ lines of code in total (currently my project has over 167,000 lines of code across 901 files)

The code-review skill I use just answers two questions: does the function work and is code built as per specs. I never asked it to review what can be removed, so AI never did the same. The fallow skill suggests what can be removed. AI reviews the suggestions, then removes dead code and reduces complexity of new functions. 


Reverse Hedonic Treadmill

O9X has been live for over 3 months. However, the worry that something might break never pauses within my head. The worry encourages me to learn more, and audit my codebase with what I learnt. With every new SOTA model, the worry shifts into an overdrive. 

I did one when Fable 5 was released, and another after GPT5.6 release. Every review unearths issues that it recommends fixing on priority basis. 

The loop to improve my app never pauses. The review treadmill slows down once in a while. However, the pace picks up after release of a new model or when I add a new feature. Today’s simple solution can easily be labelled as an easy fix by a more capable model. 

“If it ain’t broke, don’t fix it” adage recommends to leave a functioning system, process, or object alone to avoid making things worse.I adopted the advice for a few days before my worry took over. I find it more peaceful to search for flaws than waiting for something to break in production. 


Will AI ever get good enough to let me worry less? I don’t know. One day, a new SOTA model might identify, and fix issues even before being asked to do so. Until then, I need to keep asking AI: is this simple or an easy fix.