The agent wrote the feature before lunch and never added a log line. Everything after the code is priced the way it was in 2019.
The feature was done before lunch. I described what I wanted, the agent wrote it, I read the diff, pushed back on two things, and it was done. That part of the job has genuinely collapsed.
Here is what it did not do. It did not add a log line. It did not emit a metric. It did not open a span. Why would it? I asked for a feature, the feature works, and every test I asked for passes.
Then I went to give it to people, and that is where the cost showed up.
Because turning code into a product somebody pays for takes a lot more than code. Instrumentation. Alerting. Capacity. Distribution. The demo call you end up doing yourself. Writing the code is one job out of many, it is now the cheapest one, and every other job on that list costs what it always did.
When coding was most of the work, being good at coding put you most of the way to a product. Now it puts you a small part of the way, very fast, and then drops you at the start of a stack of jobs you have never practiced.
the part your agent silently skipped
Start with the job the agent actively made worse, because it is the one nobody sees coming.
You ship the feature. Some external API starts timing out, or an edge case fires, and you go to find out what happened, and there is nothing there. No logs. No traces. No metric that went sideways before the thing fell over. You are debugging a system that has no opinion about its own behavior, at the exact moment you need it to have one.
This is where experience shows up, and it is the clearest example I know of something AI has not compressed even slightly. A good engineer designs the app to be operable before it needs to be. Structured logs, metrics on the paths that matter, traces across the boundaries between services. Not because it is satisfying work. Because at 2am the only thing between you and a guess is whether a past version of you decided to instrument the code.
The agent will do every bit of this, happily and well, and to a standard most people would not bother with by hand. It will never do it unprompted.
That gap is the whole job now.
something has to be on the other end
Having the data is not the same as being told. Nobody watches a dashboard at 3am, so the metrics have to be wired to something that wakes you up. iLert, Sentry, whichever tool you like the shape of.
It costs money. Tens of dollars a month if you are small and careful, hundreds as you grow. Observability is the line item people leave out of the napkin math on a solo SaaS, and it arrives right after the moment you start feeling clever about how little the hosting costs.
Worth saying plainly: something has to be on the other end of that alert. For most people reading this, that something is you, holding a phone, on a Saturday.
when instrumenting first is the wrong call
I should argue against myself here, because „instrument everything from the first commit“ is the kind of advice that sounds free and is not.
Plenty of what I build does not deserve it. A script that runs once, a prototype whose entire purpose is to tell me whether an idea is stupid, an internal tool with two users who sit near me. Instrumenting those is a cost with no payoff, and the honest move is to skip it and know you skipped it.
There is a second failure worth naming, and it is specific to working this way. Tell an agent to instrument thoroughly and it will, everywhere, at a volume no human would have produced. Now every function logs its entry and exit, the signal is somewhere inside a firehose, and you are paying per gigabyte to store noise that makes the 2am search harder rather than easier. The agent has no taste about which paths matter, because taste is the thing it is missing.
So the instruction is not „instrument everything.“ It is that you have to decide which paths matter, which is judgment, which is yours. The agent is very fast at the part after the decision.
capacity stopped being about CPU
Two parts of this got better, and I am not going to pretend otherwise. Cloudflare, AWS and Vercel sell compute per request now, so you stop answering „how much machine do I need,“ which used to mean guessing your traffic a year out and paying for the guess whether or not it came true. Analytics is a solved purchase too.
But capacity planning does not disappear, it relocates. It stops being about CPU and becomes about data. How much can one user create? What happens the day somebody decides to upload their entire Google Drive? Where is the ceiling, and what does the app do when it reaches it? Nobody is charging you per request to think about that, and the agent will not raise it, because you did not ask.
nobody knows it exists
Everything up to here has documentation and right answers, which is exactly why engineers like it. Then you have a working, observable, alertable product and you hit the wall: nobody knows it exists.
This is where SaaS founders are stuck right now. Go read any founder subreddit and count the „how do I get users“ threads against the „how do I build this“ threads. It is not close. The building questions got answered by the tooling. The distribution questions did not get answered by anything.
Organic posting is what everyone tries first, and it works, but not the way people want it to. You do not get to show up on Reddit and advertise. Do it repeatedly and you will get banned, and you will deserve it, because that is what you are doing to everyone else in that subreddit. What works is slower: be where your users already are, be useful about the problem, mention you have been building in this direction without turning it into a pitch, and when somebody asks, tell them. That is a real strategy with the worst throughput per hour of anything here.
The thing I keep coming back to is a story I read a while ago. A founder got a genuinely good result from one LinkedIn influencer, not a huge one, but one whose audience was precisely the people with the problem. One channel, tightly matched, beating a wide net. I have no number attached to it, so treat it as a direction. Audience match beats reach.
This is also the job that resists the agent most completely. It will write you a hundred posts. It has no idea which subreddit tolerates them, and that is the entire problem.
the demo is a listening exercise
Say it works and somebody is interested. Now you are on a call doing the demo yourself, because you cannot afford to hire the person whose job this is.
The trap is symmetrical. Oversell and you have burned it, because the product will not do the thing you implied and they find out in week two. Undersell and they never learn it solves their problem. Engineers reliably do the second one. We hedge, we caveat, we lead with the limitations, and we leave the room having accurately described something nobody wants to buy.
What works is closer to listening than presenting. Their problem has a shape, and that shape is almost never the shape of your feature list. The job on that call is to find out what actually hurts and then show the part of the product that touches it. The rest of the demo is noise you are adding to somebody’s afternoon.
None of this is engineering. It is a separate skill you now own, because the alternative is paying somebody and you cannot.
engineering got cheap. the rest did not.
The missing log line was never really about logging. It is the same absence you hit on the pager at 2am, on the demo call, in the subreddit where nobody knows your product exists. Every one of those asks you to decide what matters before anyone can help you do it, and deciding is the one thing you cannot hand off at any price.
Your ten years of deliberate practice now compound on the cheapest job in the line.
Go find out which one you are worst at. It is probably not the one you have spent a decade practicing.
Peace, nerds.