A developer told me he writes code from his phone in the grocery store. He was not joking.
Inside an honest conversation about AI, where it shines, and where it still fakes it.
Last week I asked a room of .NET developers a simple question.
Does anyone still write code by hand anymore?
The answers were honest, a little uncomfortable, and more interesting than any benchmark chart.
This was one of the live sessions I run twice a month inside the .NET Web Academy.
No slides, no agenda. Just working developers talking about what is actually happening in their day-to-day.
People building industrial systems in Sweden, migrating decades-old ERP systems in Italy, shipping iPhone apps, and analyzing financial data.
Different problems, different stacks, one shared and slightly disorienting realization.
The way we work has changed, and it changed fast.
“I live in the terminal now. Four terminals at once.”
I will be honest about my own state, because I was honest with the group.
Since Opus 4.8 landed, I have barely looked up a line of code. I do not mean that as a brag.
I mean it as something closer to a confession. I described living in four terminals at the same time, context switching between five different applications, prompting one while another builds.
One developer, Jeff, put words to the part that is genuinely useful.
You can walk away. You can start a task, set it running, and go read your kids a bedtime story or stand in line at the grocery store and write the next prompt from your phone while you wait.
That is the part that still feels strange to say out loud. The most-used app on my phone right now is not a social network.
It is Claude.
Instead of doom scrolling, I am building things from my pocket.
Earlier that day, I had it take one of my long-form videos, transcribe it, find the best clips, reframe them vertically, bake in highlighted subtitles, and prepare them as YouTube Shorts.
From my phone.
While I was away from my machine.
Is that healthy? Probably not.
Jeff said it plainly, and he was right. The whole promise was supposed to be that we sleep more, not less.
I am not there yet.
But the capability is real in a way that it simply was not a few months ago.
Where the skeptics were right
Here is what I appreciate most about these sessions.
Nobody in the room is a hype machine. The pushback is real, and it is the most valuable part.
Jeff is building a financial analysis app. The kind of thing that decides whether to buy, hold, or sell a stock. And he said something that has stuck with me since.
The results look correct. They look great.
Clean analysis, credit risk, year-over-year numbers, a confident recommendation.
But they might be wrong.
The data was scraped from the web, and it could be last quarter’s report, or a bond rating for a different company that happened to share a page.
His point was not that AI is bad.
His point was sharper than that.
Anybody can build an app now.
But “it runs” is not the same as “it is correct.”
If your iPhone app works, great, the definition of done is that it works.
But if your app fakes being right when it is actually wrong, that is a real problem, and no amount of looping over it fixes a flawed foundation.
Per, who builds industrial systems where a mistake costs real money, made the quieter version of the same point. You have to be able to quantify what better and worse actually mean before you can ask AI to optimize toward them.
Asking AI to analyze a stock is, in his words, a bit like asking it who will win the Stanley Cup. It will give you a confident answer. It is still a probability, and the best goalie might get injured tomorrow.
This is the part that does not make it into the breathless takes.
AI is astonishing at the problems where the answer already exists somewhere, and you can recognize a good result when you see it.
It is far shakier where correctness is genuinely hard to define.
Knowing the difference is the job now.
The skill did not disappear. It moved.
There is a fear underneath all of this, especially for newer developers, and we talked about it directly.
We have a 22-year-old junior on my team, and he asked the honest question.
If I do not really write the code anymore, what does that mean for me?
I have been writing code for about 30 years, since I got my first machine as a kid and poked at QuickBasic and Turbo Pascal.
I love writing code.
So I understand the grief in that question. But here is what I told him, and what I believe.
The art was never really in typing the syntax.
The art is in deciding what to build, choosing the architecture, knowing which tradeoffs matter, and recognizing when something is off.
Arnold, who built and shipped an iPhone app, said the thing every experienced consultant eventually learns.
Clients tell you what they want.
Your job is to understand what they actually need, which is usually something they cannot articulate.
That skill has not been automated. If anything, it matters more now.
Jeff said it best. In the last four months, he has broadened his architecture skills and incorporated patterns he would never have had the time to learn before.
Does he understand them as deeply as he would have with, in his words, bloody fingertips from debugging them by hand?
No.
But he is using them, and shipping with them, and he thinks that tradeoff is worth it.
The artistry, he said, is at the higher level now. Not in checking whether something was null for the hundredth time.
The honest, practical takeaways
A few concrete things came out of the conversation that are worth passing along.
The newer models genuinely changed the experience, not just the benchmarks. I used to hit a build error two or three times a day and had to feed it back.
Since 4.8, I struggle to remember the last one, across five projects running at once.
Others in the room who were still on older models through their work tools described it as living a couple of decades in the past by comparison.
The gap between what you can use at home and what your company allows is becoming a real source of friction.
The tool wrapper matters as much as the model.
We got into why the same underlying model can give better results in one tool than another.
The answer is the shell around it, the system prompt, the way the tool feeds context and handles permissions. It is not only about which model number you are on.
MCP servers finally clicked for me, and it was Jeff who explained it.
You put an MCP server on top of an existing API so that AI agents can call it easily, because agents have a hard time calling a raw API directly, but a much easier time using the tools an MCP exposes.
My own use case made it concrete. I am building my own community platform to replace an expensive tool we were unhappy with, and I want my wife to manage it, creating spaces and assigning roles, by talking to Claude through an MCP server I built for the app.
That is the moment MCP stopped being an abstract acronym for me and became a thing I actually want to build.
Why I am sharing all of this
These conversations are the most valuable thing I do, and they are members-only for a reason.
They are not lectures.
They are a room of working developers being honest with each other about what is exciting, what is overhyped, and what is genuinely hard.
The skeptics make the optimists sharper.
The optimists pull the skeptics forward. Nobody is selling anything.
If you want to be in the room for the next one, that is what the All Access Pass is for.
Twice a month, live, plus every course I build and the recordings of every past session.
We go deep on exactly this kind of thing, with real developers working on real problems.
Use the code SUBSTACK for an exclusive discount.
And if there is one thing to take away without joining anything, it is this.
The developers who are thriving right now are not the ones who prompt the fastest.
They are the ones who still understand the foundations well enough to know when the confident answer in front of them is actually wrong.
That skill is not going anywhere.
If anything, it just became the whole job.