> The excitement of getting a day's work done in an hour* (for example) is likely to fade once the expectation is to produce 8 of such old-days output per day.

That dumb attitude (which I understand you’re criticising) of “more more more” always reminds me of Lenny from the Simpsons moving fast through the yellow light, with nowhere to go.

https://www.youtube.com/watch?v=QR10t-B9nYY

> I suspect it doesn't matter how we feel about it mind you. If it's going to happen it will, whether we enjoy the gains first or not.

That is quite the defeatist attitude. Society becoming shittier isn’t inevitable, though inaction and giving up certainly helps that along.

The trick is not telling anyone you spent an hour to do 7 hours of work.

That's stupid and detrimental to your mental health.

You do it in an hour, spend maybe 1-2 hours to make it even better and prettier and then relax. Do all that menial shit you've got lined up anyway.

The most challenging thing I'm finding about working with LLM-based tools is the reduction in enjoyment. I'm in this business because I love it, and I'm worried about that going forward.

Exactly, maybe "prompt engineering" is really a skill, but the reward for getting better at this is just pumping out more features at a low skill grade. What's excited about this ? Unless I want to spend all my time building minimum viable product.

For the longest time, IT workers were 'protected' from Marx's alienation of labor by the rarity of your skill, but now it's coming for you/us, too. Claude Code is to programmers what textile machines were to textile workers.

>In the capitalist mode of production, the generation of products (goods and services) is accomplished with an endless sequence of discrete, repetitive motions that offer the worker little psychological satisfaction for "a job well done." By means of commodification, the labour power of the worker is reduced to wages (an exchange value); the psychological estrangement (Entfremdung) of the worker results from the unmediated relation between his productive labour and the wages paid to him for the labour.

Less often discussed is Marx's view of social alienation in this context: i.e., workers used to take pride in who they are based on their occupation. 'I am the best blacksmith in town.' Automation destroyed that for workers, and it'll come for you/us, too.

> The tradeoff of higher velocity for less enjoyment may feel less welcome when it becomes the new baseline and the expectation of employers / customers

This is what happens with big technological advancements. Technology that enables productivity won’t free people time, but only set higher expectations of getting more work done in a day.

Short-term, automated tech debt creation will yield gains.

Long term the craftsperson writing excellent code will win. It is now easier than ever to write excellent code, for those that are able to choose their pace.

That is certainly how it played out for me. Give your employers an inch and they will take a mile.

> The tradeoff of higher velocity for less enjoyment may feel less welcome when it becomes the new baseline and the expectation of employers / customers. The excitement of getting a day's work done in an hour* (for example) is likely to fade once the expectation is to produce 8 of such old-days output per day.

That's why we should be against it but hey, we can provide more value to shareholders!

> The excitement of getting a day's work done in an hour* (for example) is likely to fade once the expectation is to produce 8 of such old-days output per day.

It's not really about excitement or enjoyment of work.

It's the fear about the __8x output__ being considered as __8x productivity__.

The increase in `output/productivity` factor has various negative implications. I would not say everything out loud. But the wise can read between the lines.

You won’t enjoy any of the gains, the company will be worth 10x and you’ll get a 10% raise to match inflation

Even if the developer is keeping the quality of the LLM generated code high (by constant close reading of the output, rejecting low quality work and steering with prompts) does this mean the project as a whole is improving? I have my doubts! I'm also skeptical that this developer has increased their velocity as much as they believe, IMHO this has long been a difficult thing to measure.

Overall, is this even a good thing? With this increase in output, I suspect we'll need to apply more pressure to people requesting features to ensure those requests are high quality. When each feature takes half the time to implement, I bet it's easy to agree to more features without spending as much time evaluating their worth.

>The tradeoff of higher velocity for less enjoyment may feel less welcome when it becomes the new baseline and the expectation of employers / customers.

This is precisely the question that scares me now. It is always so satisfying when a revolution occurs to hold hands and hug each other in the streets and shout "death to the old order". But what happens the next morning? Will we capture this monumental gain for labor or will we cede it to capital? My money is on the latter. Why wouldn't it be? Did they let us go home early when the punch card looms weaved months worth of hand work in a day? No, they made us work twice as hard for half the pay.

If there are 8 days per day worth of work to be done (which I doubt), why wouldn’t you want to have it done ASAP? You’re going to have to do it eventually, so why not just do it now? Doesn’t make sense. You act like they’re just making up new work for you to do when previously there wouldn’t have been any.

> The tradeoff of higher velocity for less enjoyment

I'm enjoying exactly what the author describes, so it's different strokes for different folks.

I always found the "code monkey" aspect of software development utterly boring and tedious, and have spent a lot of my career automating that away with various kinds of code generators, DSLs, and so on. \

Using an LLM as a general-purpose automated code monkey is a near-ideal scenario for me, and I enjoy the work more. It's especially useful for languages like Go or Java where repetitive boilerplate is endemic.

I also find it helps with procrastination, because I can just ask an LLM to start something for me and get over the initial hump.

> whether we're actually trading away more quality that we realise.

This is completely up to the people using it.

For me, on small personal projects, I can get a project to a point in about 4 hours where previous to new AI tools it would’ve taken about 40. At work, there is a huge difference due to the complexity of the code base and services. Using agents to code for me in these cases as 100% been the loop of iterating on something so often, I would’ve been better off with a more hands on approach, essentially just reviewing PRs written by AI.

I bet some people felt the same way when we collectively moved from assembly to compilers.

It definitely feels like a move towards management, which is something I've avoided for my entire career.

It's a perfectly cromulent approach and skillset - but it's a wildly different one.

It's a change in mindset. AI is like having your own junior developer. If you've never had direct reports before where you have to give them detailed instruction and validate their code then you're right, it might end up more exhausting than just doing the work yourself.

So basically what an engineering manager or product manager enjoys doing

It's not. And people are realizing that, which is causing them to bring back and reinvent aspects of software engineering to AI coding to make it more tolerable. People once questioned whether AI will replace all programming languages with natural language interfaces, it now looks like programming languages will be reinvented in the context of AI to make their natural language interface more tool-like.

There is no “creative part of the brain” and even if there was listening to music would have nothing to do with it.

You may be experiencing getting to different understanding of sth when you switch context. Similar to when you are stack it may be better to go for a walk than keep your head on top of a piece of paper or screen. I have had many of my breakthroughs while taking a shit in the toilet in the midst of working. Others experience similar with showers and whatever.

Afaik most ppl listen to music during certain tasks because it helps focusing. Esp when working in a busy office it really helps me to listen to certain kinds of predictable music to keep me from getting distracted. It creates a sort of entrainment that helps with attention.

Some people find music itself distracting, I myself find some kinds of music distracting, or during certain types of tasks. Then it obviously it does not fill its purpose.

I describe it slightly differently. Similar to what the author described, I'll first plan and solve the problem in my head, lay out a broad action plan, and then put on music to implement it. But, for me the music serves something akin to clocks in microcontrollers (and even CPUs), it provides a flow that my brain syncs to. I'm not even paying attention to the music itself, but it stops me from getting distracted and focus on the task at hand.

> discover that everything I've coded is unnecessary and there is an easier way to achieve the same goal

In my experience, there is no good shortcut to this realization. Doing it wrong first is part of the journey. You might as well enjoy the necessary mistakes along the way. The third time’s the charm!

This was actually studied at some point (at least 15-20 decades ago, as I remember learning about this in college): they gave the same programming problem to a bunch of developers and had some listen to music while they did the task while others worked in silence. There was no real difference between how long it took to do the task between the same group... but the people who listened to music were much much less likely to realize that the entire task was a red herring and the code reduced down to return 0;.

I'm sorry but that's nonsense. Listening to music is not a creative process, it does not at all take away creativity from somewhere else.

I've never, ever, ever once in 40 years of coding listened to music while coding and later found the code "unnecessary" or anything of the sort.

I engage in many creative pursuits outside of coding, always while listening to music, and I can confidently say that music has never once interfered in the process or limited the result in any way.

I don't think that's down to music per se, but a more generalized thing. Software developers love being in a flow state, some of them pursue it all the time (...guilty) and get frustrated when their job changes (e.g. moving towards management) so they spend less time in that flow state.

But also, this can create waste, in that people write the Best Code Ever in their flow state (while listening music or not), but... it wasn't necessary in the first place and the time spent was a waste. This can waste anything from an hour to six months of work (honestly, I had a "CTO" once who led a team of three dozen people or so who actually went into his batcave at home for six months to write a C# framework of sorts that the whole company should use. He then quit and became self-employed so the company had to re-hire him to make sense of the framework he wrote. I'm sure he enjoyed it very much though.)

I just think it's distracting. I get caught up listening to the lyrics and kind of mentally singing along, stuff like that which disrupts my thought and distracts from what I actually want to be thinking about.

I think this is individual, I have the same problem in social settings - if I'm having a conversation and a song I like is playing in the background I some times stop listening to the conversation and focus on the music instead, unintentionally.

My solution is to listen to music without vocals when I need to focus. I've had phases where I listen to classical music, electronic stuff, and lately I've been using an app I found called brain.fm which I think just plays AI generated lo-fi or whatever and there's some binaural beats thing going on as well that's supposed to enhance focus, creativity etc. I like it but some times I go back to regular music just because I miss listening to something I actually like.

Your experience suffers from confirmation bias.

Can you explain why it is a masterpiece? Im just curious.

This is why I reject every Teams call

Robots don't listen to music, I'm pretty sure that's the longer term plan.

Hard to tell if this is parody or not but I chuckled at the idea of replacing tedious programming with a "simple stream" of handwritten XML.

Whenever I need some sort of quick data pipeline to modify some sort of file into another format, or do some batch transformation, or transform some sort of interface description into another syntax, or things like that, that would normally require me to craft a grep, awk, tr, etc pipeline, I can normally simply paste a sample of the data and with a human language description get what I need. If it’s not working well I can break up the steps in smaller steps.

In my experience, it seems the people who have bad results have been trying to get the AI to do the reasoning. I feel like if I do the reasoning, I can offload menial tasks to the AI, and little annoying things that would take one or two hours start to take a few minutes.

That very quickly adds up to some real savings.

Every kind of project is faster with AI, because it writes the code faster.

Then you have to QA it for ages to discover the bugs it wrote, but the initial perception of speed never leaves you.

I think I'm overall slower with AI, but I could be faster if I had it write simple functions that I could review one by one, and have the AI compose them the way I wanted. Unfortunately, I'm too lazy to be faster.

Pretty much what somebody else said: AI takes over simple tasks, the "fluff" around the business logic, error handling, stuff like that, so I can focus on doing the harder stuff at the core.

I'm slowed down (but perhaps sped up overall due to lower rewrites/maintenance costs) on important bits because the space of possibilities/capabilities is expanded, and I'm choosing to make use of that for some load bearing pieces that need to be durable and high quality (along the metrics that I care about). It takes extra time to search that space properly rather than accept the first thing that compiles and passes tests. So arguably equal or even lower velocity, but definitely improved results compared to what I used to be capable of, and I'm making that trade-off consciously for certain bits. However that's the current state of affairs, who knows what it'll look like in 1-2 years.

Where I work there are like 2x as many front end developers as there is need for. They spend an insane amount of time doing meetings, they require approval of 2 different people for every simple CSS change.

Their job is to do meetings, and occasionally add a couple of items to the HTML, which has been mostly unchanged for the past 10 years, save for changing the CSS and updating the js framework they use.

I’m building a moderately complex system with FastAPI + PG + Prefect executing stuff on Cloud Run, and so long as I invest in getting the architecture and specs right, it’s really a dream how much of the heavy lifting and grunt work I can leave to Claude Code. And thank god I don’t have to manage Alembic by myself.

Greenfield development of small web apps. I’m familiar enough with everything that I can get something up and running on my own, but I don’t do it regularly so I need to read a lot of docs to be up to date. I can describe the basic design and requirements of an app and have something like Claude Code spit out a prototype in a couple of hours

Random example:

I set up a model in DBT that has 100 columns. I need to generate a schema for it (old tools could do this) with appropriate tests and likely data types (old tools struggled with this). AI is really good at this sort of thing.

There's a local website that sells actual physical Blu-rays. Their webshite is a horror show of Javascript.

I had Claude Code build me a Playwright+python -based scraper that goes through their movie section and stores the data locally to an sqlite database + a web UI for me to watchlist specific movies + add price ranges to be alerted when it changes.

Took me maybe a total of 30 minutes of "active" time (4-5 hours real-time, I was doing other shit at the same time) to get it to a point where I can actually use it.

Basically small utilities for limited release (personal, team, company-internal) is what AI coding excels at.

Like grabbing results from a survey tool, adding them to a google sheet, summarising the data to another tab with formulas. Maybe calling an LLM for sentiment analysis on the free text fields.

Half a day max from zero to Good Enough. I didn't even have to open the API docs.

Is it perfect? Of course not. But the previous state was one person spending half a day for _each_ survey doing that manually. Now the automation runs in a minute or so, depending on whether Google Sheets API is having a day or not =)

CRUD work, Boilerplate config for network stuff, converting lots of oracle stored procedures. It's saving me days.

If you know how to do it well, you just do it well, its hard work but dooable. What is harder is learning to understand why what was written, that looks good, is actually bad. Usually something small, tucked away, or an issue arising from multiple things spanning distinct functions that culminate in a werid issue. That kind of detective work is draining and time consuming. It doesnt come with the emotional boost of looking at your work and feeling pride. Instead you look at something that finally works and feel releif that its over. That alone paves the way to a totally different emotional and cognitive relationship with your work. That is why for me, at least, it is more cogntiviely intense.

There is a distinction I believe between challenging and focusing. The difference lies in difficulty (the former being more dificult) and workload (the latter being more intellectualy labor intensive), which is an interesting approach to intellectual menial labor as distinct from intellectual craft.

I think there are (at least) two types of programmer - I am the kind of programmer who wants everything done right. Others don't care as long as it works and the boss is happy.

I suspect that the type of programmer who enjoys vibe coding is the latter. For me it's pretty tiring to explain everything in excruciating detail, it's often easier to just write the code myself rather than explain in English how to write it.

It feels like I am just doing the hard part of programming all the time - deciding how the app should work and how the code should be structured etc, and I never get those breaks where I just implement my plan.

You're expected to run several projects in parallel with latency hiding like a human GPU. No downtime!

For me, it's 1 minute bullet chess.

Kind of sounds like using LLMs to generate code is like eating USA junk/fast food. It is quick and tasty, and you get a dopamine rush from that sugar and fat in your body, but it leaves you feeling unsatisfied and unsatiated.

The same word is "prach" in Czech: dust, powder. The "ch" sounds like "kh" (soft k?). In Czech slang prachy means cash, money.

Even in the fun stuff there's dog work to do and the LLMs can definitely help there.

I did that for 2 hours yesterday and then scrapped everything the agents did because it didn’t work and left everything in disarray.

That's not the same flow state experienced by programmers.

While programming, it's possible to get into a trance-like state where the program's logic is fully loaded and visible in your mind, and your fingers become an extension of your mind that wire you directly to the machine. This allows you to modify the program essentially at the speed of thought, with practically zero chance of producing buggy code. The programmer effectively becomes a self-correcting human interpreter.

Interrupting someone in this state is incredibly disruptive, since all the context and momentum is lost, and getting back into the state takes time and focus.

What you're describing is a general workflow. You can be focused on what you're doing, but there's no state loaded into memory that makes you more efficient. Interruptions are not disruptive, and you can pick up exactly where you left off with ease. In fact, you're constantly being interrupted by those agents running in the background, when they finish and you give them more work. This is a multitasking state, not flow.

So the article is correct. It's not possible to get into a flow state while working with ML tools. This is because it is an entirely different activity from programming that triggers different neural pathways.

CAN you get into a state of flow when directing an LLM? I don't have a lot of experience using LLMs to code, but it always feels like I'm coaching a junior staff member. No way to flow that, IMHO.

Same. I’ve been a coder over 25 years. I love music and am a musician, but I can’t listen to music while coding, I need silence. Too distracting. In fact music is often distracting for me during conversations, if it’s on in the background, say in a shop or bar.

That's why metal works well here.

JimTV on YT has great programming music.

Exactly, came here to say this, it happened long ago for me. Classical, jazz, electronica… all great for coding and vibing alike, for me.

> Absolutely—I feel like I can ship at a crazy velocity now, like I have a team of interns at my disposal to code up my every silly demand.

I also wonder what type of simple CRUD apps people build that have such a performance gain? They must be building well understood projects or be incredible slow developers for LLMs to have such an impact, as I cant relate to this at all.