Being an engineer in the age of AI: code got cheap, structure didn't
The Ship AI Engineer team · Published 2026-10-05
Describing a feature and getting working code for it within minutes is ordinary now. The speed is real and it isn't going away. The conclusion people draw from it is usually wrong, though: "If the model writes the code, there's no need to understand engineering in depth anymore."
What's actually happening is the opposite. Writing code got cheap; deciding what to write, where, and within which boundaries did not. As production speeds up, those decisions get heavier, because every one of them is now multiplied by far more code.
Speed amplifies the structure you already have
A system's structure is how the data is modelled, where responsibilities are separated, where an error gets caught and who can access what. If that structure is right, every new piece produced quickly slots into place. If it's wrong, every new piece produced quickly buries the mistake a little deeper.
A bad structure used to hurt slowly because it grew slowly. A team shipping a few features a week would notice a flaw in the data model over months. Today the same team can stack far more code on the same flaw in a week. The flaw is the same; the load on top of it is much larger. Speed didn't reduce how much we depend on good structure. It increased it.
Judging generated code is harder than writing it
When a model hands you a function, it usually works. The question isn't whether it runs; it's whether it does the right thing within the right boundaries. Answering that takes questions the model doesn't ask on its own:
- Does this query put the user's value straight into the SQL, or send it as a parameter?
- Does this endpoint check that the caller owns this record, or only that they're signed in?
- This loop is fast on a hundred rows; on a hundred thousand, does it fire a separate database query for every row?
- Is this error handled, or silently swallowed so the code carries on with a wrong default?
- Is this key read from an environment variable, or written into the code?
None of those questions is "knowing how to write code". All of them are knowing how a system breaks. Someone who can write code can copy it; someone who knows how it will break can ship it. The model made the first cheap, not the second. You can follow real projects breaking on exactly these kinds of decisions, step by step, on the failure cases page.
Where exactly does engineering live?
Around the code that gets written. Most of the decisions that keep a system standing are made at the boundaries between parts, not inside any one function.
The data model. What information is stored where and in what shape, what must be unique, what happens to the things attached to a record when it's deleted. A badly built data model gets more expensive to change with every line of code written on top of it.
Trust boundaries. Which information the server trusts and which it doesn't. Everything that arrives from the browser is in the user's hands. A system that takes a score, a price or a permission from the client and accepts it as-is is broken, however quickly it was written.
Failure cases. What happens when an external service doesn't answer, when a request arrives twice, when an operation is cut off halfway. The happy path is a small part of the code; a system's quality is measured in the rest.
Measurement. How you know a change made things better. Tests, evaluation sets, monitoring. A team without measurement changes more things, knowing less, the faster it goes.
Operations. How the system is watched in production, who finds out how when something breaks, how cost is kept in check. In systems that call language models this means the bill: an endpoint left without limits is a budget someone else spends. You can try how architecture decisions change the cost in the cost game.
What does going deeper mean?
Knowing the layer underneath well enough to question what the tools produce.
Someone who knows how a database runs a query sees why the query the model suggested will be slow. Someone who knows how HTTP and the browser work notices why a cookie is set wrong. Someone who knows a language model rereads the whole conversation on every request can explain why long chats get expensive and why, at some point, they "forget" the instructions at the start.
That knowledge used to separate a good engineer from an average one. Today it's the minimum for anyone working alongside a tool that generates code. The tool is fast, confident and fallible; the only thing that checks it is your understanding.
How should you use AI tools?
Like a talented but inexperienced teammate. It writes fast, knows a lot, and everything it does needs reviewing.
In practice that's a few habits. Build the structure yourself first: the data model, the module boundaries, where each thing gets validated. Then use the tool to produce the pieces inside that structure. Accept generated code because you understand when it would break, not because it passed a test. And think about the tests separately from the code: having the same tool write the code and the test that checks it at the same time can mean writing the same assumption twice.
The upshot: more engineering, not less
Code generation getting cheap doesn't mean software got cheap. The expensive part of software was never pressing keys; it was deciding what to build, why, and within which boundaries. That part matters more than ever today, because every decision is now multiplied by far more code.
So for anyone entering this field now, the right question isn't "what will AI do instead of me?" It's "what do I need to understand in depth to judge what AI produces?" The answer is how a system is built and how it breaks. We cover the order to learn it in our roadmap post, and you can see every concept in the free knowledge map.
Sources
- OWASP: Top 10 for LLM Applications: where trust boundaries break in systems that call language models. (added 2026-10)
- Google SRE Book: Release engineering: the engineering discipline that fast, frequent releases rest on. (added 2026-10)
- Google SRE Book: Monitoring distributed systems: what to watch in a running system. (added 2026-10)
- The Twelve-Factor App: the structural principles of a deployable app. (added 2026-10)
- Anthropic: Building effective agents: why simple, inspectable structures should come before complex ones. (added 2026-10)
Keep reading
2026-10-06
Resources worth following as an AI engineer: what to read, and when
A new post, model or tool appears in this field every day, and trying to follow all of it is the fastest way to learn none of it. A handful of resources that genuinely help, and the stage of learning at which each one is worth reading.
2026-10-02
Shipping an AI application: spending caps, caching, monitoring and model changes
In an ordinary web app every request costs roughly the same. In an app with a language model inside, it doesn't. Capping cost when you ship, using caching safely, watching the right things, and being ready when the provider retires a model.
2026-09-30
An AI engineer portfolio: what a project that gets you hired looks like
A chatbot demo impresses nobody anymore. Six signs that make an AI project credible, five project ideas that each show a different skill, and a README someone can read in two minutes.
2026-09-27
Prompt injection and abuse: why the server has to be the single source of truth in an AI app
An application with a language model inside carries every security problem of an ordinary web app and adds new ones. Why prompt injection can't be fully prevented, how to limit the damage, protecting the endpoint, and why the model's output can't be trusted.
2026-09-23
Building your first test set for an LLM application: a guide to evaluation
You changed the prompt and the answers look better. Do they? Building a first test set, taking a baseline, seeing what the average hides, the limits of one model grading another, and watching the system once it's live.
2026-09-19
When should you fine-tune, and when is it a waste of time?
Training a model on your own data is an attractive idea. Most of the time it's the wrong tool. What fine-tuning teaches and what it doesn't, how it compares with prompting and RAG, data quality, leakage, LoRA, and licences on open models.
2026-09-14
7 questions to ask before you pick an AI engineering course
Seven questions worth asking before you spend money and months on an AI engineering course. A short answer to each, and the concrete sign you can check in the syllabus before you buy.
2026-09-09
AI with image and audio input: the costs and failures your tests don't show
Handing a model a photo or a recording isn't the same as sending text. Request size, unreadable images, sentences invented in silence, generation that takes seconds, and an image paid for again on every turn.
2026-09-04
When don't you need an agent? Building and stopping a tool-using system safely
"Agent" is today's most requested and most easily misbuilt thing. The difference between a fixed workflow and an agent, why tool descriptions are critical, how to stop the loop, and how to protect irreversible actions.
2026-08-31
Why does RAG give wrong answers? Most failures are in retrieval, not the model
When a system that answers from your documents says something wrong, the model is the first suspect. Most of the time the culprit is the chunk it was given. Finding where the failure is, containing invention, citing sources and measuring properly.
2026-08-26
How to become an AI engineer: a roadmap that builds products, not models
Most roadmaps in the search results describe a different job. What the AI engineers being hired today actually know, the order to learn it in, and what makes each stage "done".
2026-08-21
When do you actually need a vector database? A practical guide to embeddings
The first step people take after deciding to build semantic search is usually picking a vector database. Most of the time it's an early step. What an embedding is, what a similarity score doesn't tell you, and the real reasons to move to a database.
2026-08-17
Managing prompts like code: versions, templates, schemas and tests
A prompt that works in a chat window quietly breaks inside an application. Keeping prompts in the repository, separating user input from instructions, validating the answer against a schema, and shipping a change only after measuring it.
2026-08-12
Why LLM APIs break under real traffic: rate limits, retries and timeouts
Three errors you never saw in development arrive together in the first busy hour. Telling 429 from 5xx, retrying properly, setting timeouts, and keeping the product up when the provider goes down.
2026-08-07
Do you need maths to become an AI engineer?
The honest answers to the six questions that stop people before they start: maths, degrees, machine learning, Python, hardware and money. Short answers first, reasons after.
2026-08-07
An AI engineer is not a machine learning engineer
Search "how to become an AI engineer" and the first page teaches linear algebra, CNNs and training loops. That is a different job. Here is what the work actually is, and what you can skip.