So You Want to Build AI-Generated Apps And You Know Absolutely Jack about Computer Science? (vol. 5)
3 Simple Pro Strats for Software (and Life)
Today I’ve got 3 big-picture strategies for you that the best software pros use to solve hard problems and build software that’s actually manageable to understand and maintain, rather than chaotic and unmaintainable (as you are likely to build with no CS experience).
These CS concepts apply to much more than building software, they can be used for problem-solving and optimization in life generally. They are:
Divide and Conquer
DRY
KISS
Divide & Conquer
Much of what makes a good developer is that they simply have more patience than most people. When faced with an Everest-scale challenge like “build this really cool app idea,” there might be several thousand micro sub-steps required to achieve a goal that large.
Its too overwhelming to think about projects of that size all at once, so people tend to give up before they even try.
Even if AI is building the software for you, you need to overcome that feeling and embrace trying and failing continuously. One of the best ways to trick yourself into undertaking and overcoming huge complex problems is to divide and conquer.
mergesort is a common one of many algorithms based on “divide & conquer”
Is your app composed of 5 main pages? Sure, try to one-shot all 5 pages at once with lovable or bolt or cursor, but at the time of writing June 2025, that’s most likely going to fail1. That doesn’t mean AI can’t get your app built for you.
Divide and conquer: pick one page, block the other 4 pages from your mind entirely. Using all of your PRD docs (discussed in previous posts in this series), see if AI can in fact one-shot just one entire single page alone of your app or website for you. If it gets it right, great! On to the next. If it fails, divide that one page further. Ask AI to generate JUST the first element on the page only, the navigation section for example. Don’t worry about the rest of the elements on the page until that first element is right.
When you conquer the first page or just the first element, be sure you commit your progress as a checkpoint before attempting the next piece.
DRY
Don’t Repeat Yourself. It’s not a hard and strict rule for software dev, but more of a guiding concept.
Scenario:
You have AI create an element on the page of your app, let’s say it’s a button in your react native app. You have AI add some custom styles to make the button have custom rounded corners, custom font and colors. On your next app page, you want to add another button with the same font and styles, and you notice the styles get reimplemented.
Before you know it, you have the same code for that same button style implemented in 10 places where you are using those buttons 10 times, and when you decide to try out a new font on those buttons, you are left to hunt down and update those 10 implementations one by one. This is not dae wae.
To make your code DRY, your font style should be defined in one and only one place, with all instances of that button making use of that singular font style. 2
prompt:
”I noticed you wrote nearly the same exact db connection lines of code in several different places. do you think it’s worth it to make this code more DRY?”
KISS
KISS is “Keep It Simple, Stupid!”, a hundred year old folk saying adopted and made popular throughout STEM. KISS can apply not just to your code, but your UX design, or even your app’s overall goals and scope.
A lot of people are trying to AI generate app ideas that can sprint before they’ve even learned how to crawl. “generate for me the uber of vacation planning app!”
Keep it simple. Focus on your app’s number one value proposition and only once that’s rock solid expand the scope from there.
It may take some level of experience and discernment before you can tell over-engineered code from ‘clean’ and simple code at a glance, but if the complexity seems to be spiraling out of control, ask for the AI to explain whats going on simply. Ask it if there is a way to make the engineering simpler (following the tips i’ve given in previous posts in this series, using your documentation, separation of concerns, and modularity) .
prompt:
”I only asked you to generate a signup form on my existing page. Why did you generate 20 new files and all this complicated code i can’t understand? can’t we start with a much simple version and follow KISS principles?”
That’s all for today. Thanks for stopping by, and good luck building! Come back for more parts of the series.
If you are just joining us, catch up with the series here:
Vol 1: Day 1 Ground Floor Basics To Help You Out
Vol 2: You're building a building without a blueprint
Vol 3: Untangle failed codebases with this one weird trick
Vol 4: Two Foundational CS Concepts for Anyone
It’s just a matter of time tbh until software is “solved”, in which case maybe nothing in this series will be relevant anymore.
There are cases where an over-endeavor to keep code DRY can lead to more abstract more complex code, so you need to balance KISS and DRY principles. A good approach is to just implement things the first naive way that comes to mind, and once you (your AI) find yourself repeating nearly the same code blocks 2-3 times that should be a signal to you to start think about making it more modular and DRY.