You say programming used to be a meditative activity.

Then why get overwhelmed by LLMs and meditate to calm down, when you can just write the code yourself at a healthier pace? Tools are supposed to be designed around humans, it’s not the human that has to adapt to the machine.

In any case, meditating with an end to destress or to reach higher levels of productivity is missing the point of meditation.

▲

cl3misch 4 days ago | parent | next [-]

> Tools are supposed to be designed around humans

This is a common thing to say, but when during the development of human civilization has this actually been the case? Is agriculture designed around humans more than hunting/gathering? Is industrialized work more designed around humans than agrarian society?

I don't mean to sound pessimistic or technocratic; quite the contrary. But I think we shouldn't project our desire for equanimity onto romantized versions of civilization.

▲

specialist 3 days ago | parent [-]

We shape the tools that in turn shape us.

▲

sph 2 days ago | parent [-]

True; I have seen the agentic workflow and I would rather not be shaped by it.

It looks like absolute hell of constant distraction making it impossible to reach a state of flow.

	▲	specialist 2 days ago \| parent [-]
		For me, autocomplete is an unbearable distraction. I never took to pair programming either. I've bounced off Claude Code (et al) multiple times. But very recently I've had some successes. With some bulk bug fixes, it felt the same as scripting data quality fix ups. With proof of concepts in mind, tried 3 very different ideas. Two quickly flamed out, revealing that I needed to chew on those ideas (a lot) more. If we're measuring how to "fail faster", I'd score these as useful efforts. But one has been a very unexpected delight to work on. Almost addictive, like coding feels when you're in the flow. Any way. The current mania for coding harnesses is total insanity. Mario of Pi.dev fame is spot on and far more insightful and articulate than me.

▲

varjag 4 days ago | parent | prev [-]

It's fine for your pet projects. But for most of professional programming it's no longer feasible as you'll be at a small fraction of your machine assisted performance.

▲

sph 4 days ago | parent | next [-]

My performance in writing code was never once the problem. I don’t get why I should increase the amount of output by depending on a third party tool to do my thinking to whom I have to explain my very abstract thought process in words.

The point of being an experienced programmer is thinking in data structures and transformations, not in prose. Why would I introduce all that friction?

▲

witx 4 days ago | parent | prev [-]

If you think performance relates to speed and amount of code per unit of time yes. If you're more grounded with the reality of software engineering then no

▲

varjag 4 days ago | parent [-]

I have in fact masters in SE and three decades experience of commercial programming. Loved every minute of it (well except the burnout episode) and still do my hobby projects. So I would say no, you are wrong. The models decimate not just the coding (the best and the most fun part of development) but all the pseudo-engineering roles like architects or product managers too. Simply because there's less need for communication in the team as the surface of work for each dev is now quite enormous.

	▲	witx 4 days ago \| parent [-]
		Well and my experience of 2 years working full time with AI (and 15 others of engineering) on safety critical adjacent products tells me you're full of it and wrong. We've had 4 teams on this model and sure it helped in some things (mostly data analysis and scripts) but generating code and doing architecture is utter crap 90℅ of the time. So much so that we've even had juniors noticing some design patterns that, and I quote: "this is one the examples of bad code we were taught in sw design classes'. The worst is how non deterministic they are. The same prompt from different people yields vastly different results SW engineering is mostly x + y + z Where x=planning, y=writting code and z=reviewing, then rinse and repeat. Llm spedup y but made everything else take so much longer that equation result is much worse. Now reviewing is utter torture and during planning we're dicussing how to mitigate the pitfalls of LLM (like over engineering, too many abstractions) that we spend fewer time on the planning of the engineering itself and more on cuddling this brain addled tool