Coding Backwards

A new way to code for both Trads and Vibes.

8 min readMar 24, 2025

Internet juggernaut Amazon has an internal practice called “working backwards” where they write a press release before they start a project.

It takes effort. It requires difficult critical thinking, and yet it saves a huge amount of time by correcting missteps before they happen and ensures that what you get in the end is something you actually want.

What if we took this idea and applied it to coding?

As AI-Assisted coding becomes the norm for all types of software developers, how can we get the best results from our AI helpers and learn new systems as they appear? The answer is Coding Backwards.

Trads and Vibes unite! Seasoned programmers and AI-noobs can use this technique to get what you want faster. Your code will be cleaner, more elegant, more robust, easier to expand, and easier to debug.

You can learn a new language while coding in it (?!?!?!?!) and solve problems as you encounter them — but it takes discipline. And the technique requires flipping your mind inside-out. Here’s the recipe.

The Coding Backwards Technique

Write the Readme ← Start as if you’re already finished .
Make Skeleton files ← Start with empty files and empty functions
Progressive Build-n-Test ← Always have code that works
Explain it to Me ← this one is important, this is how you learn.

Step-by-step

Write the Readme

Don’t just jump into code. Start by writing your Readme. A Readme file is usually done at the end, to tell other people how your code works. Instead of waiting to the end, start with a Readme for your project and use AI to help you write it. Tell OpenAI or Claude or any other model what you are trying to do and ask it for structured assistance. Here’s a sample prompt for building your own Readme.

Prompt:

I'm planning to build a [your project here] app using [React, Python, etc], and I want to start by writing the README to clarify my thinking 
before writing any code. Please help me craft a detailed README that covers:- Project overview and purpose: what problem does this project solve?- Project outcomes: what does the final result look like? - Core features and functionality my app needs to have- Technical architecture - components, state management, routing- Technology stack recommendations (what software or services?)- Data structure and database- API design if needed- Deployment and hosting considerations- Performance optimizations for my content- Accessibility considerations- Future expansion possibilities- File structure For context, here is how I see the app working: 
 
- The user first [does this]
- Then the user [does this]
- The system checks to see [how to handle this]
- And then responds by [doing what I want]
- and then the user [does this]
- etc.And I need help to think through how to structure this app both 
technically and visually and experientially. Please ask me any questions you need to know as a part of your pre-planning. Once you feel like you've got all the info you need, then start writing the Readme. Let's begin!

A prompt like this will get you started. Answer all the questions the AI asks in the pre-planning stage and work with the AI to iterate until you’re happy with the Readme.

After you have a pretty good version, give it back to the AI a few more times and ask it to improve it. Ask it to figure out possible security problems, design flaws, usability flaws, etc. Ask it to double-check your file structure for the type of project you are building. Do this a few times to iterate and revise. Once you have a readme in hand, you’re ready to get started.

Make Skeleton Files

Once you have a readme, what’s next? The next step is to build out semi-blank files that follow the plan of the readme and the suggested file structure. Start by creating near-empty placeholder files that follow the file structure listed in the readme. Add a comment at the top that lists the name of the file and the structure. Save each file with the correct file extension.

Name all the files correctly, move them into the right folders, and then one-by-one ask the AI to help you set up empty placeholder functions inside the files.

With all your skeleton files and placeholder functions in place, you can then either start coding (if you’re old school) or ask the AI to help you code, or if you’re like most people, use both traditional and AI-assisted coding at the same time.

Progressive Build-n-Test

With your skeleton files in place, now start writing the actual files. Ask the AI (or yourself) to write the file in a way where you can progressively test it as you go. It’s easier to debug an isolated problem than to try to debug many interconnected, untested, interrelated possible problems.

Ask yourself (or the AI): What’s the simplest thing I can test to make sure everything is wired-up correctly? What the first step I can take? How can I know it’s working?

Once that first step is working, then take the next step. And the next.

Along the way, figure out how you can check yourself before you wreck your code.

Ask yourself (or the AI) how can I add in print statements or temporary output tests to prove that each next step is working? For instance, last night I was building a react app that assembled itself by reading a local json file. The whole thing was complicated, so I first had it just retrieve and display only one element to make sure the pipes were all connected. Once this was working, it was easier to add in everything else.

As you build, you can replace your skeleton functions and tests with more and more complicated and complete functions. Progressive build-n-test means you always know you are building on a base that actually works.

This is different than the yolo-coder’s approach of describing what you want, crossing your fingers, and hoping the AI will build everything for you. Honestly, prompt-n-pray yolo-coding sometimes works, and sometimes is fun, but almost always there’s something wrong or something that nearly works (but doesn’t actually work).

And even if your yolo-code does work perfectly, if you later want to expand or change it, you won’t know how.

Instead, code backwards with the progressive build-n-test approach, so that you’re never lost — because you’re always taking it one step at a time and scaffolding your knowledge as you go.

You can ask better questions, debug faster, and build in an expandable way from the beginning.

Also — and importantly — you get the satisfaction of many micro-victories along the way. We all need encouragement when we build. And progressive build-n-test offers the chance to feel a sense of accomplishment every few minutes, instead of every few days.

Explain it to me

As you work with an AI progressively writing one file at a time, ask it to explain each section of each file. Do this at every step so that you are learning while you are building, rather than just blindly prompting and hoping.

As the AI explains the code, rewrite the comments by hand in your own voice and style in your files to tell yourself what’s happening. Don’t just copy and paste the AI comments. Write them yourself, as a way to double-check yourself on whether you actually understand something. If you run across a line of code or a function you don’t understand, ask the AI what it does.

Asking the AI to explain it to you sounds like it will slow you down, and you’ll be tempted to skip this step, but the opposite is true. If you know what’s happening in your code (even if the AI originally wrote it for you), then you can change it, fix it, expanding it and build what you want. You’ll also have a better chance at debugging when the AI gets it wrong. You’ll build “error intuition” around what’s likely wrong.

Asking “Explain it to me” is the step that most people skip. Your code finally works, so you just want to move on. But this is the key moment that takes you from low-agency passivity to becoming a high-agency builder. This is the moment you learn, grow, and succeed.

The big idea is to take things one step at a time. Plan, execute, test, and learn. Them expand on what works. Save out versions every step of the way. And design projects that walk before they run so that you always have something that’s working, that you understand, and that is able to handle the next layer.

Does this work?

Yes. The process works. It requires a combination of imagination and analysis. It requires dreaming big and then breaking large projects into smaller tasks in a smart and humble way. It requires a love of learning.

And it’s a lot of fun.

Summary: The Coding Backwards Technique

Write the Readme ← Start as if you’re already finished .
Make Skeleton files ← Start with empty files and empty functions
Progressive Build-n-Test ← Always have code that works
Explain it to Me ← this one is important, this is how you learn.

You can do it!

If you’re a trad, then all you needed from this article was the idea of writing the readme first. If you are new to coding and trying to learn python, React, node, deno, html, css, js, etc for the first time and your only teacher is AI, then I hope this approach gives you a way to get started.

If you do make a project, let me know! I’d love to give you a digital high-five and shout “keep going!” 👋 “I believe in you” 👋 “you can do it!”

Going Further…

This idea of outline, skeleton, build-n-test, learn, and expand feels applicable to other topics outside of coding. How would you use it for learning a language, or learning a sport, or learning to be more kind, or a more thoughtful conversationalist? I’m interested in the idea that you could learn nearly anything if you find the right approach. For instance, I’m at work on a new painting. Here are three recent views. Looking at it, it feels a little like the Coding Backwards idea, these three images would be the skeleton files → build-n-test part of the process. Fascinating!