With that said, when I read this blog post. I feel the author’s pain. And it’s the first time that I emotionally get what the other side of the programming spectrum feels what it has lost. I feel sad about it. And because of it, I will also wonder about ways of bringing it back.

[1] not fully though. Something I can love coding by hand for months.

Some people are just born something (engineers, in this case), and they're that something for life.

I always have a hard time explaining to "normal people" that such life is not boring at all, in fact, I can't remember a single time in my life where I was actually "bored".

Full agent coding however is the complete opposite, you’re in constant damage control of a junior who moves fast and breaks everything. They’ve got better but still do dumb mistakes.

lot of engineers are discovering firsthand what it’s like to manage a team of eager but useless employees. Not fun at all

But when I think about it from the author’s position, I may actually have been lucky. For this person, writing code may have been a way of life. In my case, I only started doing field work and using AI relatively recently, so I was able to adapt faster than I expected.

If your whole way of life changes, the shock must be much greater.

In contrast, I had no real status or social position to protect, so perhaps it was easier for me to let go. If I had tried to compete fairly and directly, I could not have beaten the experience and accumulated skill of veteran programmers.

Of course, my ability to write code was something I was somewhat proud of. Giving it up was painful, and it brought regret and a sense of inferiority. But at the same time, I also find myself thinking: “Was I really supposed to fight against veterans like this?”

Recently, this feels very similar to Durkheim’s concept of anomie. While reading this, I kept thinking about categories such as conformity, innovation, ritualism, retreatism, and rebellion. There are many points here that make me think.

If, in the future, coding changes again from today’s agent-based coding into some other form, what will happen to me then? By observing how senior programmers are reacting now, perhaps I can draw my own conclusions and prepare for that moment.

Right now, agent-based coding that depends on specific companies is dominant. But I think the current price of agentic coding is too cheap. At some point, when it becomes more expensive, local LLMs may become mainstream. If that happens, damaged or weakened code-writing ability may become necessary again.

So the question is: how should I prepare for that?

This was an interesting post.

I’ve given up trying to get that feeling back at work.

We were lucky for 20 years, now if we want to do it for craft it’s time to contribute to OpenBSD or something — with phish on, not for money.

When I started to get this feeling recently (the sadness around the flow state being knocked off-axis), I started asking myself "what are you rushing toward? Do you really need to be working like this? Is this truly rational or just socially congruent?" YMMV but may be helpful for some.

Here I am still coding (mostly) by hand.

While I also sometimes do chat with qwen or use an agent to save some time writting tests or yaml, or "implementing" a draft version of a change, I can't really understand this "the job is changed".

Do some companies in some countries force you to use these agents? Are they going to fire you because Jack or Jill push changes two (or more) times faster than you?

In the past we were forced to pour the concrete ourselves. I understand how many of us enjoyed the sound and the smell of the concrete being poured. Myself, I’m happy to never get my hands dirty again, and focus on the actual engineering.

That loop (open a session, ask a question, redirect, switch) happens before the spec discipline is tight enough to trust the result without watching. When you've actually delegated well, you're not context-switching constantly between sessions. You hand over a detailed spec, wait for the agent to finish, and evaluate. The watching gets compressed to the handoff and the return, not the whole run.

Most engineers haven't gotten there, because getting there is hard. The spec has to be good enough that the agent can hit an ambiguity without needing to ask, fill a gap without needing your correction, and still produce something worth using. That's a different kind of writing than what most engineers were doing before. It takes the kind of attention that's hard to find when you're also redirecting three other sessions.

The flow state question is the more interesting one. It doesn't disappear. It moves. The continuous-arc attention used to live at the implementation layer. Now it's available at the spec-writing layer. Most people haven't redesigned their work to find it there. The new deep-work mode runs from a high-level goal through a narrow, implementation-ready spec through a validation pass. That can be a continuous arc if you've structured the work to allow it. It just doesn't look like the old one, and the muscle memory for it doesn't exist yet.

Whether that's actually flow or just a different kind of concentration is a real question. The engineers that I know (myself included), who've found something like the old rhythm have moved most of their time/effort upstream in the process. The ones still in the redirect loop are usually starting with stories with the same information they always had in them, ran through an LLM to make them appear more tightly defined.

And not even necessarily when coding… I find that if there is no music playing, I will start a song in my head. That can get frustrating—the song loops, perhaps in fact just the chorus. So I turn on the external music and it seems to allow my brain to do other things.

The work is, among other things:

* Writing components * Writing glue * Requirements gathering * Architectural design * Testing

Which parts are the grunt work depends on the individual. Personally, writing components was the most challenging, least grunt work job there was. Requirements and design was the next most fun, but not really very challenging. Writing glue and testing was grunt work--had to get done, but was mind-numbing.

As one of my friends put it, "Beej, writing software was never the goal."

I might counter that managing LLMs was never the goal, either, so we'll get to see where that leads.

That's happened before, with people submitting batch jobs in the mainframe era, people working on big projects that take an hour to compile, or people waiting for code reviews.

However, even if the LLMs become fast, the coding agent will likely bottleneck on running tools. You will need to keep your tests fast, too.

Great for generating volumes of output. Less great for going into a flow state and coming out with something that looks like I made it, something that I see my hand in

And yeah, maybe it’s because I never quite get into a flow state when I do it this way. Hmm

I’m sysadmin not a dev but I also feel that managing an agent is a fundamentally different feeling than performing admin work like I used to. I used to build bridges out of software. I would learn how they work down to the nuts and bolts, and use them to make robust and occasionally clever solutions for our needs. Over time i was getting better at bash and powershell and regex and automating little tasks.

Gaining knowledge about kubernetes and building images and helm charts was some of the most fun I’ve had professionally. I found enjoyment and value in learning those things and enjoy knowing them for their own sake, much in the same way I enjoy being able to recite mechanics and knowledge about vanilla wow from memory. The knowledge is its own pursuit and obtaining it was fun and fulfilling.

Using AI is nothing like that. It’s not “fun” to me in any way. I don’t learn bash and powershell and templating. I don’t get to enjoy simple wins. AI does those all those for me.

I’m thinking of becoming an electrician. I can’t imagine babysitting an ai for another 30 years.

I think there’d be a lot of demand from long time engineers that loved working in flow state to build tooling that encouraged flow. I think tokens/s needs to get like 10x faster first, because you’re going to be heading into a world where you are receiving very soft and non-distracting suggestions, probably at the periphery of your consciousness. Most will be thrown away.

I can kind of imagine a UI for this. I might experiment a little building something, but it will be by telling some agents to build it.. :)

Programming does not exist or, rather, programming doesn't pay. Whatever this is—vibe coding, agentic software development—it's a new and different discipline, and it may be the only game in town [citation needed].

It's not even been a particularly gradual change. It's been a stark, totalizing turnover in the last 18 months. I don't know how long this era will last (maybe we'll discover a new sort of operational scurvy, and this movement will be mocked and scorned as a ludicrously anemic fad) but it'll leave a distinct layer of discoloration in the geological record.

I've never really been into Phish. Lately, I've been vibing out to the hyperactive chiptune groups Anamanaguchi and Toby Fox. Justice also makes my playlist, alongside more pathos-laden groups like The Glitch Mob and Moderat.

Hell, once I get this teams-of-teams jj-and-weave harness firmly in hand, I can pop into Agent-of-Empires and drop the needle on some Al Hirt—Music to Watch [Pulls] By.

feel this though. also how the era of debating like the best code styles and which new frontend framework is etc best that used to be fun to talk about feels like its coming to an end because no one really cares anymore as long as the bot can build the feature.

I've been leaning in more on e2e test suites. They are slow, brittle and inefficient. But that's almost a feature. I can step away and come back an hour later, and use that time to think about bigger problems.

I never could study to music and much preferred studying in a quiet carrel in the university library.

Simple solution: keep going what you've been doing. Open up https://relisten.net/ and keep jamming, you'll probably be fine.

Couldn't agree more. I'm personally okay with how engineering is changing. At the end of the day, the code is a means to an end for me. That said, the "queue" aspect of how software development is headed is so real. It's a different way of working, and I find the biggest challenge is staying engaged and tuned in while you might have agents take 30 seconds here, 2 minutes there, 5 minutes there, etc. It's easy to get distracted when waiting.

Thought it was an early AI or something.

OP, I sure it’s just a transition. AI will get faster, feedback loops shorter, and we will be back at a more traditional flow state.

I’m really disappointed that I wasn’t in the right headspace to name this post “the trick is to surrender to the flow”, the lyric from Phish’s The Lizards.

But, you know, hindsight.

The flow state is gone. Sadly

Also what do you think about goose

AI still sucks pretty bad at writing code. The only people I've ever known to need a "flow" state to write code are junior devs.

Everyone else is used to constant interruptions and has been through every layer of abstraction many many times. This is why those with experience find it so tempting to say this job can be automated away, but they forget how many gotchas there are, how they crop up, and how brittle all this crap always was. AI is actively making this problem worse.

I've been writing code for 30 years. I welcome AI. It brings different challenges and can reduce the time needed for the end product.

edit: Bouncing around the room is one of their hit songs. Give it a listen.

It's interesting to now see professionals making a similar move themselves when a new cPanel/Wordpress has arrived and wring their hands about how they 'get more done' but 'lost the craft'.

Inbetween I've come across quite a lot of scoffing about using XML to generate code in Java and C#, or just XML itself. Buying queries from a database corporation seems quite a bit weirder to me than designing a data schema, especially if both use cases are supposed to lead to some server boilerplate and an API on a database.