Chapter 2: Engineering Fundamentals for Non-Engineers

Imagine a restaurant.

There's a dining room where customers sit. A kitchen where food gets made. Waiters who carry orders in and plates out. A pantry where ingredients are stored.

Every piece has a job. The dining room doesn't cook. The kitchen doesn't seat guests. Each part does one thing well, and they communicate through clear handoffs.

Software works the same way. When you use an app, you're sitting in the dining room. You see a menu. You make choices. Things arrive. What you don't see is the kitchen: the servers running code, the databases storing information, the logic deciding what happens when you click a button.

The frontend is everything the user sees and touches. Buttons, forms, text, colors, layout. This is the dining room. It's designed for the customer, needs to look good, and makes it obvious what you can do.

The backend is everything the user doesn't see. Code running on a server somewhere, processing requests, enforcing rules, storing and retrieving data. This is the kitchen. The customer never sees it, but it's where the real work gets done.

When you're building with AI, you'll work on both. The Jetty Method treats them differently because they fail differently. A frontend bug means something looks wrong. Annoying, but visible. A backend bug means something is wrong. Data gets corrupted. Orders get lost. The kitchen is on fire and customers have no idea until their food never arrives.

The API is the waiter. The frontend and backend don't talk directly. The API defines what you can ask for and what you'll get back, just like a menu. The frontend says "Give me this user's profile." The API carries that request to the backend. The backend finds the profile, and the API carries the response back.

The database is the pantry. An organized collection of information your application can read from and write to. When a user creates an account, that goes into the database. When they log in, the backend checks the database. The backend doesn't remember anything on its own. Every request, it asks the database: "What do we know about this customer?"

Third-party APIs are other people's kitchens. You don't have to make everything from scratch. When you integrate with Stripe for payments, you're sending your waiter to Stripe's kitchen with a specific order. Stripe does the work and sends back the result. Email, payments, login, maps, AI: all available through APIs, all kitchens you can order from without building yourself.

Let's put it together. You click "View My Orders."

The dining room (frontend) notices you clicked

The waiter (API) carries your request to the kitchen

The kitchen (backend) asks the pantry (database) for your orders

The pantry responds with the data

The kitchen formats it for presentation

The waiter carries it back to the dining room

The dining room displays your order history

All of this happens in milliseconds. Every interaction follows some version of this pattern. When something goes wrong, it means one of these handoffs failed.

If the finished software is the restaurant during service, your development environment is the restaurant at 6am. Lights on. No customers. The chef testing a new recipe. Someone checking that the ovens work.

The IDE (Integrated Development Environment) is your prep station. A program where you view files, make edits, and see what's happening. Popular ones include VS Code, Cursor, and Zed. You don't need to master your IDE. You need to be comfortable opening files and navigating around.

File structure is the kitchen layout. Software projects have folders (called directories) organized in particular ways. Some common patterns:

my-project/

src/ ← where the actual code lives

tests/ ← where the tests live

public/ ← files users can access directly

package.json ← a manifest listing what the project needs

The AI knows these conventions and will put files where they belong. Your job is to understand the layout well enough to find things.

The terminal is your intercom. A text-based interface where you type commands and the computer responds. Most of your terminal work will be running commands the AI gives you, starting your application, and committing code. You don't need to memorize commands. The AI will tell you what to type.

Environment variables are recipe cards that change per location. Settings that differ depending on where the code is running. When developing locally, the app might connect to a test database. In production, it connects to the real database. Same code, different configuration. These live in files called .env. Never share these publicly; they contain secrets like passwords and API keys.

Imagine a chef developing a new dish. She tries rosemary. Then thyme. Adds lemon zest. But wait, too much salt. She wants to go back to the version before the salt mistake.

Without notes, she's guessing. With a detailed logbook, every change is traceable.

Git is that logbook for software. It tracks every change to every file. Not just what the code looks like now, but the complete history.

A commit is a snapshot. You're saving the current state with a note about what changed. Good commits are small and focused. "Added login button" is good. "Fixed a bunch of stuff" is not.

Branches are parallel experiments. The main version of your code lives on a branch called main. When you want to try something, you create a new branch. You work there. If it works, you merge it back into main. If it doesn't, you delete the branch and main is untouched.

This is your safety net. Experiments can't break what's already working. When the experiment succeeds, it joins the main recipe. When it fails, you haven't lost anything.

When you work with an AI assistant, things move fast. Git solves the "I want to go back to when it was working" problem. Every commit is a checkpoint. Every branch is a safe experiment.

Software that only runs on your laptop isn't useful to anyone. At some point, it needs to leave your kitchen and serve real customers.

This happens in stages. Think of it as three versions of your restaurant.

Local is your home kitchen. You're experimenting, tasting, adjusting. Nobody eats here but you. If you burn something, no one knows.

Staging is a dress rehearsal. A real kitchen, real equipment, fake customers. Everything looks and works like the real restaurant, but the stakes are low.

Production is the real restaurant, doors open, customers seated. Mistakes here have consequences.

You don't serve customers from your home kitchen. You don't skip the dress rehearsal. Each stage exists because the cost of failure increases as you move toward production.

CI/CD (Continuous Integration and Continuous Deployment) is the quality inspector. Before a dish leaves the kitchen, someone checks it. In software, this is automated. You push your code, and a system runs all your tests. If any test fails, the code doesn't move forward. If all tests pass, the code flows to the next environment. You don't need to set up CI/CD yourself, but when the system rejects your code, it's being protective. Something failed. The system caught it before users did.

You understand that software has a dining room (frontend) and a kitchen (backend), connected by waiters (APIs), with ingredients stored in a pantry (database).

You build in a prep station (IDE), organize your kitchen (file structure), and give instructions through an intercom (terminal). You keep secrets in recipe cards (environment variables).

You keep a logbook (Git) with snapshots (commits) and parallel experiments (branches).

And you know the journey from your home kitchen (local) through dress rehearsal (staging) to opening night (production), with quality inspectors (CI/CD) checking every dish before it leaves.

That's the foundation. You don't need to master any of this. You need to recognize it when you see it, understand why it matters, and have enough vocabulary to direct your AI assistant effectively.