AI for Developers · Concept
Software Fundamentals That Still Matter
A short map of the software concepts needed to judge where an AI-generated change belongs.
On this page
A starting question
An assistant changes a database query to fix a page that shows 401 Unauthorized. Does that sound like the right boundary?
Maybe, but the status first points you toward a request and identity check. Without a model of the system, it is easy to accept a plausible change in the wrong place. You do not need to memorize every technology. You need to know what each part is responsible for.
Mental model
The compact map
- HTTP defines the request and response exchange between client and server. A method, path, headers, body, and status help locate a failure. The HTTP standard defines these semantics; the web-request path teaches them in context.A status is a clue, not a complete root-cause report.1
- An API is an agreed interface. Check its input and output contract before accepting a changed request. The APIs and JSON lesson goes deeper.
- A database stores and retrieves persistent data. Query shape, constraints, and transactions matter; an application error is not automatically a database fault. See How Databases Store and Retrieve Data.
- Git records changes so you can compare, discuss, and recover versions. Read the diff and keep changes small. A pull request makes that proposal reviewable; GitHub documents its diff and checks.AI output should enter the same review process as other proposed code.2
- The command line runs builds, tests, and scripts. Understand a command before approving it, especially if it writes, deletes, installs, or sends data. A successful exit code proves only that the command finished according to its own rules.
- Deployment moves a built change into a running environment. Local success does not guarantee production behavior. Automated workflows can build, test, and deploy changes, as described in GitHub Actions documentation.The deployment boundary deserves its own review.3
- System design asks how pieces behave together under load and failure. You need not design a giant service to ask whether a cache can be stale, a dependency can time out, or a retry could repeat a write.
Use the map on the example
For the 401, inspect the request and authentication path first. Was a credential sent? Did the server reject it? Only investigate a database query if evidence leads there—for example, a server log showing that the identity lookup failed. Changing a query because an assistant guessed at it may hide the real problem.
Recap and try it
Fundamentals are not a rival to AI assistance; they are the map you use to judge its suggestions. Learn the boundaries well enough to ask the next useful question.
Reflect, then reveal each answer.
An AI patch changes deployment configuration after a local API test fails. What should you check before accepting it?
Locate the failing boundary: request, application, data, or environment. Read the configuration diff and find evidence that deployment settings caused the local failure before changing them.
How this connects
- Reliable Software Workflows
Next: use review, tests, and deployment checks to turn individual judgment into a repeatable process.
- How a Web Application Actually Works
Study the core ten-lesson path for the full request journey.
References & further reading
References & further reading3 sourcesPrimary standards and official documentation used for this lesson.
- Pull requests (opens in a new tab)
GitHub Docs
Version-controlled diffs and review of proposed changes
- Understanding GitHub Actions (opens in a new tab)
GitHub Docs
Automated build, test, and deployment workflow as an operational boundary