I did not enter software through the clean front door.
I did not grow up as the kid who was building compilers in middle school, casually reading operating systems books for fun, and saying things like "I just love elegant abstractions" while everyone else was trying to survive algebra.
My path was messier than that.
I did not have a computer science undergraduate degree. I did not have the standard foundation. I did not arrive in software with the quiet confidence of someone who had been speaking the language since childhood.
I got into software by deciding I wanted a master's degree in software engineering, then realizing I had to piece together the prerequisite foundation first.
So that is what I did.
I took C. I took C++. I took data structures. I took some Java. I took web development. Not as part of some neat, coherent undergraduate computer science path, but as loose prerequisite work so I could qualify for the program I wanted to enter.
It was not glamorous.
It was a lot of grinding through unfamiliar concepts, staring at errors, re-reading examples, and slowly building the mental shelf space required to understand what software even is.
There was a lot of elbow grease involved.
Enough elbow grease that, if software had not worked out, I probably could have walked into a mechanic shop and started lubricating engine parts through sheer academic residue.
But it worked.
I got through the prerequisites. Then I went through the software engineering master's program at California State University, Fullerton. That program gave me a much broader view of software than just "write code until the computer stops yelling."
I studied software process, software architecture, software verification and validation, software measurement, maintenance, standards, management, and professional issues. The program ended with a capstone project where we had to build software and document the process like actual software engineers, not just people throwing code at a wall and hoping the wall had good taste.
That mattered.
Because one of the biggest mistakes beginners make with AI coding tools right now is thinking the code is the whole game.
It is not.
Code is part of the game. But software is also scope, architecture, data, user flows, testing, deployment, maintenance, tradeoffs, communication, and knowing what not to build yet.
That is the part beginners usually do not see.
And honestly, it is the part I did not fully see at first either.
After I graduated, I did not immediately stroll into a perfect software job. I graduated into the pandemic era and spent about a year unsuccessfully job searching. Then job searching moved to the back burner while I worked an unrelated customer service job.
That period was frustrating.
It is hard to explain the particular flavor of discouragement that comes from earning a software degree, doing the work, building the projects, learning the concepts, and then still feeling like the industry is standing behind a glass wall.
You can see the world you are trying to enter.
You just cannot seem to get through the door.
Eventually, a friend of a friend who worked at Uber helped mentor me through the job search process. Around that same period, ChatGPT showed up, and that changed the way I worked.
Before AI, my programming process looked like the standard developer scavenger hunt.
Search Google.
Open Stack Overflow.
Find a six-year-old answer.
Realize the library changed.
Open documentation.
Find a YouTube tutorial.
Hope the tutorial is not using a deprecated version.
Copy one piece.
Modify another piece.
Read a forum thread from 2014.
Stitch together five partial answers until the thing finally works.
That was normal.
Developers pretend this was noble, but a lot of it was just inefficient archaeology.
AI compressed that loop.
It did not magically make me good at everything. That is not how this works. But it gave me a way to ask better questions faster. It let me compare options, debug errors, explain unfamiliar concepts, rewrite plans, and move through confusion with less dead time.
So I used it.
I built my portfolio. I applied heavily. I started programming in public. I made a 90-video series of myself building a SpriteKit 2D iOS game.
That public work mattered because it turned me from a resume into a person with visible proof of effort.
Eventually, after a long stretch of pushing, I started getting interviews. Then something unexpected happened.
A couple of startup founders found me on LinkedIn. They liked what I had to say about how I would build their product. They hired me, and I built the first version of their event-based social media app.
That project became a serious step forward for me.
The first version was good enough that they gave me equity and brought in two junior iOS developers under me. I ended up managing the iOS side of the project for about five months.
That was the moment where software stopped being only academic for me.
It became product work.
Real scope. Real tradeoffs. Real people. Real ambiguity. Real pressure.
And later, freelancing made that even more obvious.
When you are the only person responsible for a client project, you learn very quickly that "I can write code" is not enough. You have to understand the app as a system. You have to manage the client relationship. You have to make architecture decisions. You have to use design tools. You have to manage backend assumptions. You have to test. You have to explain tradeoffs. You have to keep the whole thing moving even when the path is not perfectly clear.
That is where AI tools became more than a novelty for me.
I started using Cursor, Figma, Codex, backend tools, browser automation, and AI planning workflows as part of the actual work.
Not as toys.
As leverage.
And that is why I care so much about beginners using AI coding tools well.
Because I know what it feels like to start outside the software world and try to build your way in. I know what it feels like to lack the map. I know what it feels like to ask basic questions and worry that the basic question means you do not belong.
But I also know something else now.
Software is becoming more accessible.
Not easy. Accessible.
That distinction matters.
AI does not remove the need for judgment. It does not remove the need for taste, persistence, testing, product thinking, or architecture. If anything, it makes those things more important, because now beginners can generate much more software much faster.
That is powerful.
It is also dangerous if you have no idea what you are asking for.
A beginner with an AI coding tool should not start by saying, "Build me an app."
That is too vague.
Start by building the map.
What is the app for?
Who uses it?
What is the first workflow?
What should version one not include?
What data exists?
What tools are involved?
What does success look like?
What should your AI coding tool verify before it says the task is done?
That is the real work.
The beginner's job is not to become a senior engineer overnight. The beginner's job is to learn how to direct the tool without letting the tool shape the product by accident.
That is why I wrote AI App Builder From Zero.
I wrote it for people who never thought software was accessible to them. People with app ideas. People with small business problems. People who want to build something useful but do not know what a stack is, what a repo is, what a backend does, or what to type into the chatbox after opening an AI coding tool for the first time.
The internet has plenty of information.
Too much, honestly.
Reddit threads. YouTube tutorials. X posts. Documentation. Hot takes. Tool comparisons. Prompt lists. Arguments about frameworks. People confidently disagreeing with each other in public.
That can be useful once you have a map.
But if you are brand new, it can feel like trying to drink from a fire hose while someone keeps changing the hose into a different hose.
Beginners do not need more noise.
They need a first snowball.
Something small enough to pick up, concrete enough to push, and useful enough to gather momentum.
That is how I think about learning software with AI.
You do not need to know everything before you begin.
You do need a working model of what you are doing.
You need shared project knowledge. You need definitions. You need scope. You need rules. You need a way to ask Codex to plan, build, test, review, and stop.
That is the difference between using AI as a magic slot machine and using AI as a working partner.
My path into software was not clean.
That is probably why I am interested in teaching this.
I do not think the next generation of builders will all come from traditional computer science paths. Some will. Many will not.
Some will come from business.
Some will come from design.
Some will come from operations.
Some will come from customer service jobs, weird side projects, unfinished app ideas, freelance experiments, and late-night conversations with AI tools.
That is good.
Software should have more doors.
AI is opening some of them.
But walking through still requires discipline.
Learn the tool.
Build the map.
Control the scope.
Test the work.
Keep going.
That is the path.
It may not be the clean front door.
But it is a door.
And for a lot of people, that is enough to start.
If you want a practical place to start, I made AI App Builder Starter Prompts: 24 free prompts for turning a rough app idea into a scoped first build.
https://marcusykim.gumroad.com/l/ai-app-builder-starter-prompts
Top comments (0)