AI has enabled lots. Or at least, it appears that way. I’m under the firm belief that technical ability is still required to perform technical tasks. However, the world is changing, and technical ability might not equal “knowing how to code”. But then, what does it equal? Certainly, you can’t graduate with a major in computer science without learning how to code. You can’t get a job without knowing how to code. But allegedly, you can code without knowing how to code. This makes sense.

In this article, I hope to educate all of you (especially my dad) with my 6 year software engineering career on coding without knowing how to code. And no I don’t think you’re a dummy, my dad thought of the name. You won’t be a pro software engineer by the end of this article, but maybe you can have a better idea of how to use code generation tools we have now to make something besides AI slop.

Lesson 0. How is Engineering Even Hard?

If you know that software engineering is hard, feel free to skip this.

I always thought coding was easy. And it is, I haven’t changed my opinion on that. But software engineering is legitimately difficult – almost like a craft. It takes a massive amount of work, collaboration, and perseverance to roll out any quality piece of software. Shitty software? Be my guest, it’s probably easy.

To further explain how something like “computer science” can possibly be difficult, take physical labor as an analogous example. You don’t look at the pyramids and say “I could probably do that in a day without any slave labor”. That would be silly. Because it’s so massive in size and made of such heavy material, you recognize as a human with limbs who takes up space in this world how hard that must be, and how much time it would take. But most people are not software engineers, and see websites as things that are just pixels on the screen. It’s more than pixels on the screen! This can be hard to conceptualize because the medium in which it’s expressed (a computer screen, a phone screen, some other combination of blue pixels) is generally, unimpressive and boring.

You see the creation of the bridge as the hard part, why is creating the bridge hard? If you think about it for a bit, perhaps it starts to make sense. Well, I don’t want the bridge to break, right? And, I don’t want it to wobble, that certainly would not be good. You can map as a person who crosses bridges how the physical world interacts with the bridge, and can probably recognize that engineering a bridge is not easy. Similarly, if you understand what makes a piece of software work and see the whole thing, you’ll realize it’s a lot to put together, despite literally just being pixels on the screen.

Software engineering always used to be both the engineering and construction of the product. I would argue now, we are past that. It’s always been about not only designing how the thing is made, but about making it yourself. Coding is simply the syntax for how the thing gets made. And, with the AI tools available to us now, it’s not very hard. What is still very hard though is the engineering. Talk to anyone in tech and the opinions around AI coding are all the same – useful, but I still have a job. Companies who did mass layoffs are actually hiring people back in masses. There’s reason for that – just because AI can do the heavy lifting does not mean that it can engineer the solution.

Lesson 1. Code is Easy

Probably an unpopular opinion. I’m not saying software engineering is easy, I’m saying code itself is not what you think. Do you think people who know a different language than you are on some vastly different plane of intelligence because they speak an unintelligible language? No it’s just because, that’s how they learned to communicate. That’s how they learned to talk to their friends, to get stuff done – just like you.

By the way, code is made up. It’s not real, it’s made by us. New coding languages are made constantly. All code does is tell a computer to do something. All code is, is just organized instructions. That’s it – you really thought it was harder than that? Alright here’s some examples:

• When one thing happens, do this other thing
• Do this until you should stop
• Do lots of things in a specific order to get the desired result
• Save this information for later
• Get the information you saved from before
• Hi I’m a button when I’m clicked do this
• When something breaks make a note of it so we can fix what breaks
• When something loads slow make a note of it so we can make it faster

Congrats! You’ve just learned the primitives of my entire job! It is genuinely not much harder than these concepts (all of which are real by the way in my code) – the daunting part is all the scary letters in the monotype font – I say genuinely because I thought the same thing for years!

It’s telling a computer to do things in a certain way. I can give an example – React is what I code in. It’s a Javascript framework that says, “treat the parts of the website you see as lego blocks”. Treat the header as a block, an icon as a block – the entire website is just blocks inside of one another. I played with a lot of lego as a kid, so this comes naturally to me! And makes sense I think – websites are, at their core just a bunch of blocks I guess. So yeah, React was made to give software engineers a quicker way to make websites. Because once you think of a website like building blocks, you can code in React! Same goes for other languages – Python has a lot of cool stuff with computer vision – 1 line in python might be able to detect a moving object from a camera which is pretty sick. Different languages just allow you to interact with different technological mediums, there’s no one better language than the other unless you’re coding web apps then you must be coding in React or you’re crazy!

Oh yeah – because coding is pattern recognition at its core (it has to be a pattern, how else would we learn it as humans), AI is really really good at it. Expressing a medium in a language that requires high barrier for entry? AI literally does not care it will just spit out other people’s code.

Lesson 2. Engineering as a Fractal

This is perhaps my favorite way to view engineering, and one I’ve kinda stuck by my whole career. Engineering is not like a math problem, you can’t just code something and be done with it. Rather, it’s an endless rabbit hole in every direction of decisions you can make. The decisions you can make aren’t particularly hard, I think. There’s just a shit ton of them. When I start coding a project, I don’t have one insanely difficult problem, I have like maybe 300 easy problems, all with interconnecting dependencies.

The reason why engineering is hard is not because it’s like, one big engineering problem that takes months to solve. It’s because it’s a ton of super tiny problems that all interconnect and weave in unpredictable ways. As a project grows, its complexity can grow double that. I’ve found that the hardest projects are actually the biggest, the ones with so many moving parts that you need to align yourself with, rather than the empty slate.

The hard part is putting these things together to make a working app! Let’s take a save button, for example, Like you’re saving a document in Word or something. How do you think that works? Probably haven’t thought about it right – who would? Well, I don’t know how it works either, but I know it must be broken up into a few problems:

1. What exactly is being saved? like a docx or pdf or what?
2. How do you make the save popup thing that chooses the file browser?
3. How is it being saved on the computer? like, how does the file just appear there?

And that’s just for the feature itself! What about

• If you try to close an unsaved doc, it should stop you right? And say “do you want to save?” which should invoke the saving
• What happens when you try to save a file with the same name? Probably, “Do you want to replace this file” – right? Well how do you do that?
• What happens while it’s saving? Do they get Saving… or what?
• Is autosave a thing or what?

Not to mention – these things break down pretty fast. We haven’t even gotten to the coding part yet – these are just the initial questions you’re required to think about when engineering a quality product. Because, if you don’t think about these things now, someone will use your product, it will break, and they will say, “Why didn’t that guy think about me closing the window when I didn’t save? Now I lost all my data!”

So that’s the first thing you gotta know in engineering – the problems are infinitely deep. You have to start as wide as possible with features, then drill down recursively. Until you hit the point of, “this doesn’t actually matter”, then you can go back up the tree and drill down somewhere else!

Lesson 3. Prompting a Coding AI

This is a lesson that, I gotta say most software engineers don’t even have learned! Even myself, it’s a constant process of iterating my own process to make it as efficient as possible. But, I think we’ve gotten to a relatively stable point in models with Opus 4.7, so here is how I go about coding something with AI.

First, know what you want to make. Like, actually know what it is you want to make from front to back yourself. Write it down in a notepad, make bullets. You should be doing as much thinking as I did with the Word example from before except a lot more because you’re considering a lot more about how the software works. How much you zoom in depends on how much you care – if you’re making something like a personal website maybe you don’t have to care much. The length + detail of your plan will determine how successful the project is.

Second, give the AI all the highest level things you want to do, explicitly marking first-level deep implementations as “mocks”. Don’t worry about your 4th nested bullet point question – just fake it for the initial run. You want all of the top level things built out perfect your first run. Just the barebones look and feel of it, don’t stress too much if it looks like garbage. If it does what you want it to do like sorta, that’s good enough! If you’re releasing a shitty website or you don’t care, this is where you stop!

Third, one by one, tackle all the 1st level depth problems consecutively. This should be your “filler” – your, “how exactly do I save the document”? Even if you don’t know exactly how to do these things technically, detail the hell out of them, you will get much better results. This will take the second-longest, maybe an hour or two depending on your model/scope of the project, but is the most important part. Only until this step completes that you should regard it as an MVP – since you have completed the high level stuff, and got the implementation details figured out mostly. Common edge cases and other stuff isn’t there.

Last, fill in the rest but don’t spend too much time on each thing. This is a weird step because it’s different for every project – I oftentimes just attempt to ask it to solve bugs or do edge cases, and then when it fails I just take over since that’s fastest. If that’s not the case for you, either ask stackoverflow for your problems or use a different AI for just that question – fresh context gives fresh perspective! This should get you most of the way there to a production ready product. This is the longest part by far, especially as product specs and stuff change. And, you’ll inevitably run into errors that set you back a few days.

After that, I would highly recommend depending on your app that you prompt the AI to make test cases. You can test scenarios without actually running the app a bunch of times – that’s what software engineers do all the time – we automate these things! If you don’t know how to test for your specific language then the AI will always help you! This is definitely the thing the AI is the best at – just make sure you’re hand holding it on exactly what to test or else it will be garbage.

Conclusion

I hope this gave a solid intro to anyone who’s petrified or allergic to coding. I’m probably missing a lot because, there’s a lot, but this is a dump of the most important concepts I’ve learned throughout my career to get started. If you like problem solving and/or puzzles you will LOVE engineering.