AI does not help you sleep better: every extra layer you pay for in production

AI does not help you sleep better. Every extra layer you pay for in production.

Putting a model in does not lighten the system. It moves it. Dependencies, output that does not repeat the same way, failure surfaces that were not there before. At Snowinch we say this when we look at an architecture: complexity you do not see at build time arrives later, when users are in and the data is theirs.

The comfortable misconception

A story goes around: AI simplifies. Less code, less hand-written logic. Describe it, the model does it.

That is true about the moment you assemble something. You get sooner to an object that answers. What it does not do is simplify the whole: components, states, vendors, behaviors the product has to manage while it is on.

Mixing those two up is what founders do when they measure progress by "you can see it". Then night comes, and so does the bill.

Where you pay

Generated code often "works in the cases you tried". It carries training assumptions, structures that are reasonable in general, not necessarily for your perimeter. The problem is not that it is always wrong. It is that nobody read it the way you read what you wrote. Generated, poked at, pasted. It holds, until it does not, for a reason that requires understanding a file nobody understood.

This is thin debt: not dirty code, unread code. The cost shows up when you have to change it under pressure, with someone waiting.

Every integration pulls in dependencies that look clean on a box diagram. Model version, response shape, latency you do not command. Context you feed in that shifts the output. In development volumes are low and you pick the conditions. In production they show up under load, on input you did not put in the tests. Debugging is slower than in a system that, given the same input, always does the same thing. Here it does not. Same prompt, different context, load on the vendor: different reply. In calm conditions it is noise. Under stress it is a wrong invoice, a permission granted, a text sent to a client.

For a product with real users, every crooked behavior has to be investigated. Investigating a system that does not reproduce the same way costs attention. That attention, at night, is sleep.

Or rather, we use AI for boilerplate too. The problem is when the layer becomes the architect: it decides how the pieces talk, it holds money or access logic, and nobody on the team has a map.

There is a precise moment when the debt stops being a retrospective worry. The system breaks in production. You have to understand why, fast. The question is not "how does AI work". It is: this input, this wrong output, how do I fix it without pulling down the rest.

If the layers are closed, with stated input and output, and the output is checked, that question has a path. If the model decided the shape of the system and the assumptions live in a chat from months ago, the path is long. Building only for the first "it works" is signing that night in advance.

I would rather have a boring, deterministic path on auth, payments, and data deletion. It costs in theater: you look less "AI-native". I take that. The path that moves money and identity is not where I want output that changes its mind.

A real aside, and a specific one: I have opened a generated auth module because "it is standard". Standard it was in style. In the assumptions about session and logout, no. On a screen, in an office, it passed. For the first real user who closed the browser and came back, no. It was not a language-model problem. It was a file nobody had read as if it had to hold someone else's data.

Tool, not architect

Using models on closed tasks (a draft you then read, a process with verifiable input and output, text that goes through a person) keeps the system understandable. Debt grows like it does in any product.

Handing shape decisions to the model (how the pieces connect, where the business rule lives, what happens if the vendor is down) raises initial speed and lowers understanding. Every later change is archaeology. Every extension starts with "wait, what did this place already decide".

Isolate the layer. The rest of the product should not need to know what is inside, only what it accepts and what it must reject. That does not remove non-determinism. It keeps it in a pen.

Verify the output, not the inner reasoning. You write the criteria. Outside the criteria is an error to handle, not a surprise to ignore.

Keep a fallback on the paths that, if they fail, wake you: money, access, data. Manual, fixed rule, a dumber system. Not as a forever plan. As a net for when the model does not do what you had in mind.

Write the assumptions. Why this model. What you expect in which cases. What you do when the output is crooked. That does not come out of the code. If it changes, update it. Otherwise the next night is spent reconstructing a chat.

Quiet nights

Validating an idea is not enough, and neither is a prototype that "uses AI". You need something in production that holds users, data, and lets you sleep. Every extra layer is either a pen with someone responsible, or debt that will call.

If the scope is "put a model on everything, then we see", we say no. If you need someone on a perimeter that has to stay on, we can talk. If you want to hear that AI simplified things and the problems are over, this is the wrong call.

Email hello@snowinch.com