186 points by fred1268 12 hours ago | 153 comments on HN
| Neutral High agreement (3 models)
Community · v3.7· 2026-03-15 22:31:27 0
Summary Work & Cultural Participation Acknowledges
This Hacker News discussion post reflects on AI's impact on personal work satisfaction, comparing journey-oriented versus destination-oriented approaches to coding. The content engages minimally with human rights frameworks, though it touches on Article 19 (free expression) through the author's ability to share opinions publicly, and Article 27 (cultural participation) by reflecting on evolving engagement with creative practice. The post frames a potential labor displacement concern as a philosophical preference difference, thereby sidestepping substantive labor rights engagement.
Rights Tensions1 pair
Art 19 ↔ Art 23 —Post freely expresses personal views on work transformation through AI, but frames labor displacement as a preference matter rather than a worker rights concern, thereby subordinating Article 23 labor dignity to Article 19 expression.
I'm not sure I understand... why not simply ignore AI and keep coding the way you always have? It's a bit like saying motorboats killed your passion for rowing.
I enjoy the journey too. The journey is building systems, not coding. Coding was always the most tedious and least interesting part of it. Thinking about the system, thinking about its implementation details, iterating and making it better and better. Nothing has changed with AI. My ambition grew with the technology. Now I don't waste time on simple systems. I can get to work doing what I've always thought would be impossible, or take years. I can fail faster than ever and pivot sooner.
It's the best thing to happen to systems engineering.
As I commented in the other post, it killed mine at work, because my boss is pushing "AI" really hard on the devs. Fortunately, he's now seeing enough evidence to counteract the hype, but it's still going to be present and dragging down my work. But it my off time, I only experiment with LLMs to see if they're getting better. Spoiler alert: they aren't, at least not for the kind of things I want to do.
> it depends on what you enjoy: the journey or the destination
This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. The fun part is in the building, it's in the understanding, the growth of me.
I have coworkers who get itchy when they don't see their work on production, and super defensive in code review but I've never really cared. The goal is to solve the puzzle. If there's a better way to solve the puzzle, I want to know. If it takes a week to get through code review, what do I care, I'm already off to the next puzzle.
Being forced to use Claude at work, it really just took away everything that was enjoyable. Instead of solving puzzles I'm wrangling a digital junior dev that doesn't really learn from its mistakes, and lies all the time.
The sad truth of life. This story reminded me of the time when I tried my first MMO - at first it felt like a fairy tale, something unknown, something that could still surprise you. And then you get familiar with all the mechanics, and the magic disappears. Now it’s just a “tool.”
For me (60 too) it's both, the journey and the destination. LLMs not only help me get around the boring stuff so I have more time for the things I really want to design and build, but they also open areas for me in which I always wanted to go but for which it was very time consuming or difficult to get the required knowledge (e.g. tons of academic papers which are neither well written nor complete and sometimes just wrong). The LLMs help me to explore and find the right way through those areas, so these adventures suddenly become affordable for me, without doing a PhD on each subject. And even if the LLM generates some code, it still needs a "guiding hand" and engineering experience. So for me, no, AI doesn't kill my passion, but offers a very attractive symbiosis, which makes me much more efficient and my spare-time work even more interesting. I find myself watching fewer and fewer streaming videos because exploring new areas and collaborating with the LLM is much more entertaining.
If you enjoyed coding for the sake of coding it hasn't gone anywhere. People still knit for themselves when they can go buy clothes off the rack. People still enjoy chess and Go even though none of them can beat a machine.
If you enjoyed that you could do something the rest of the world can't - well yeah some of that is somewhat gone. The "real programmers" who could time the execution of assembly instructions to the rotation speed of an early hard drive prob felt the same when compilers came around.
It has rekindled my joy however. Agentic development is so powerful but also so painful and it's the painful parts I love. The painful parts mean there is still so much to create and make better. We get to live in a world now where all of this power is on our home computers, where we can draw on all the world's resources to build in realtime, and where if we make anything cool it can propagate virally and instantly, and where there are blank spaces in every direction for individuals to innovate. Pretty cool in my view.
14 years ago hearing Dan Pink talk on motivation (https://youtu.be/u6XAPnuFjJc) catalyzed the decision to change jobs.
One of the three motivators he mentions is mastery. And cites examples of why people waste hours with no pay learning to play instruments and other hobbies in their discretionary time. This has been very true for me as a coder.
That said, I enjoy the pursuit of mastery as a programmer less than I used to. Mastering a “simple” thing is rewarding. Trying to master much of modern software is not. Web programming rots your brain. Modern languages and software product motivations are all about gaining more money and mindshare. There is no mastering any stack, it changes to swiftly to matter. I view the necessity of using LLMs as an indictment against what working in and with information technology has become.
I wonder if the hope of mastering the agentic process, is what is rejuvenating some programmers. It’s a new challenge to get good at. I wonder what Pink would say today about the role of AI in “what motivates us”.
I found my peace with AI aided coding during the last three months. I started development of an environment for programming games and agent simulations that has its own S-expression based DSL, as a private project. Think somewhere between Processing and StarLogo, with a functional style and a unique programming model.
I am having long design sessions with Claude Code and let it implement the resulting features and changes in version controlled increments.
But I am the one who writes the example games and simulations in the DSL to get a feel for where its design needs to change to improve the user experience. This way I can work on the fun and creative parts and let Claude do the footwork.
I let Claude simultaneously write code, tests and documentation for each increment, and I read it and suggest changes or ask for clarification. I find it a lot easier to dismiss an earlier design for a better idea than when I would have implemented every detail of the system myself, and I think so far the resulting product has largely benefited from this.
To me, now more than ever it is important to keep the love for programming alive by having a side project as a creative outlet, with no time pressure and my own acceptance criteria (like beautiful code or clever solutions) that would not be acceptable in a commercial environment.
What do you all think about the "Solve It" method by the Answer dot AI folks?
It's more like iterating on the REPL with AI in the loop, meaning the user stays in control while benefitting from AI, so real growth happens.
Interesting thing to consider, in a couple of years, will there be a differentiator between people who are good at driving company-specific AI tools and those who are generally better by having built skills the hard way ground up with benefit of AI?
I have decided that I will only write artisanal code. I’m even thinking of creating a consultancy agency where people can hire me to replace AI generated code.
I’ve given AI a try and found the destination felt empty.
I’ve made the choice to not go full bore into AI as a result. I still use it to aid search or ask questions, but full on agentic coding isn’t for me, at least not for the projects I actually care about and want/need to support long-term.
I’ve made a bunch of tools to help me get around file system limitations on modern Macs (APFS) and treating my entire legacy file
collection as CMS challenge and have cranked out more binaries in 3 months than in the 10 years before the arrival of these tools. If you know how to use these tools and how to think
like an architect and not a hobbyist Claude is truly in the technological lead.
I am a bit, but not much, younger than 60 and have been coding since Apple II days.
These tools are pretty close to HAL 9000 so of course GIGO as always has been the case with computer tech.
Almost everything is in Go except an image fingerprinting api server written in Swift. The most USEFUL thing I’ve written is a Go based APFS monitor that will help you not overfill your SSD and get pained into corner by Time Machine.
Those who say they enjoy "building" with AI instead of coding are just outsourcing the coding part (while training the AI for outsourced company). It's nothing to enjoy, but yeah, you get the product, which is probably what people enjoy. Getting the product.
It's like buying a IKEA furniture and you think you made it by merely assembling it. If you don't know IKEA effect, it's having a greater value for something than it actually is, because you were partly 'involved' in creating/assmebling it.
Doesn't AI just replace the coding that other people have done many times? That is, we don't have to do repetitive work because of AI. Yes, I don't know how to write a React app even though I can vibe code it quickly, but that's repetitive nonetheless. It's just that it is another person who has repeated the code before. That said, there are a ton of code to write by hand if we push the envelop. The 10 algorithms that I no one has build for production. This concurrency library that no one has built in my favorite language. That simulation that Claude Code just can’t get right no matter how much prompts/context engineering/harness engineering I do. The list can go on and on.
I'm completely the opposite. 100% the opposite. I wrote code because it was the only way to make the lights blink. I saw code as an impediment to completing a project. There was a lot of friction between the design and the final result. AI reduces that friction substantially.
The remaining friction is fundamentally the same as that which existed when writing code manually. The gap between what you envision for your design/solution and the tools for implementing that vision. With code, the friction encountered when implementing your vision is substantial; with AI, that friction is significantly reduced, and what's left is in areas different from what past experience would lead you to expect.
I think it's perfect understandable that some people feel dreaded while others feel excited. But whatever the outcome, we have to adapt.
For people who feel that AI kills a passion, I'd recommend finding another hobby. Especially at the age of 60, when you don't have to work, you can plan retirement -- the next 20+ years as if it is your second childhood, and do whatever you want. I encourage you to search for greater meanings. After all, programming is just a man-made wonder, and the universe is full of grandeur.
Well, I'm 55 - and have been a pentester for the past 15 years, but I am having a blast. CC is so enabling - I build something new most weekends (this is my best project so far - which is a site which collects and writes stories for all the latest AI security research: https://shortspan.ai/). All sorts of projects I have had on the back burner are now coming to life. I have 4 kids, so wouldn't have time without Codex/Claude Code. Maybe I have an hour here or there, and that is enough to make something or improve something
The friction is the feature for journey-focused builders. When AI removes the cognitive resistance—debugging a parser, wrestling with state management, naming things—it also removes the scaffolding that forces you to really understand what you're building. You end up in implementation details faster, which feels productive until you realize you're solving problems you wouldn't have encountered if you'd thought harder upfront.
My hypothesis around this and other peoples sentiments who dislike AI while citing similar reasons as the post is not simply that they enjoyed arriving at the destination.
Rather the issue is they believe they are GOOD at the "journey" and getting to the destination and could compare their journey to others. Another take is they could more readily share their journey or help their peers. Some really like that part.
Now who you are comparing to is not other people going through the same journey, so there is less comradery. Others no longer enjoy that same journey so it feels more "lonely" in a way.
Theres nothing stopping someone from still writing their own code for fun by hand, but the element of sharing the journey with others is diminishing.
But to push the analogy a bit. If you are rowing on a lake with motorboats, it is a totally different experience. Noisy, constant wake. We are part of an ecosystem, not isolated.
Growing up, the lakes in New England were filled with sailboats. There were sailing races. Now, its entirely pontoon boats. Not a sailboat to be found.
I suppose in a way it's like saying diesel engines killed passions for sailing.
A career sailor on a sailing ship who finds meaning in rigging a ship just so with a team of shipmates in order to undertake a useful journey may find his love of sailing diminished somewhat when his life's skills and passions are abruptly reduced to a historical curiosity.
Other sailors may prefer their new "easier" jobs now they don't have to climb rigging all day or caulk decking (but now they have other problems, you need far fewer of them per tonne of cargo).
And the diesel engine mechanics are presumably cock-a-hoop at their new market.
(This analogy makes no claim as to the relative utility of AI compared to diesel ships over sailing vessels).
So much agreed. I'm constraining my AI, that always wants to add more dependencies, create unnecessary code, broaden test to the point they become useless. I have in mind what I want it to build, and now I have workflows to make sure it does so effectively.
I also ask it a lot of questions regarding my assumptions, and so "we" (me and the AI) find better solutions that either of us could make on our own.
I hear everyone say "the LLM lets me focus on the broader context and architecture", but in my experience the architecture is made of the small decisions in the individual components. If I'm writing a complex system part of getting the primitives and interfaces right is experiencing the friction of using them. If code is "free" I can write a bad system because I don't experience using it, the LLM abstracts away the rough edges.
I'm working with a team that was an early adopter of LLMs and their architecture is full of unknown-unknowns that they would have thought through if they actually wrote the code themselves. There are impedance mismatches everywhere but they can just produce more code to wrap the old code. It makes the system brittle and hard-to-maintain.
It's not a new problem, I've worked at places where people made these mistakes before. But as time goes on it seems like _most_ systems will accumulate multiple layers of slop because it's increasingly cheap to just add more mud to the ball of mud.
He's not getting customers by rowing them across the river when the motorboats do it faster and cheaper. You compared a hobby to doing something "for a living".
I turned 59 this week. I am excited to go to work again. I use Claude every day. I check Claude. I learn new things from Claude.
I no longer need a "UI person" to get something demonstrable quickly. (I've never been a "UI guy"). I've also never been a guy coding during every waking moment of my life as that would have been disastrous for my mental health.
I am retiring in <=2 years, so I am having fun with this new associate of mine.
One pitfall I've managed to avoid all these 36 years I've been at it is not falling in love with the solution. I fall in love with the problems. Claude solves those problems far quicker than I ever could.
Oh wow, that's exactly the opposite of how I feel, and conversely, I am that developer who gets itchy when his work doesn't go to prod quickly enough and gets defensive on code reviews.
Sure, part of the fun of programming is understanding how things work, mentally taking them apart and rebuilding them in the particular way that meets your needs. But this is usually reserved for small parts of the code, self-contained libraries or architectural backbones. And at that level I think human input and direction are still important. Then there is the grunt work of glueing all the parts together, or writing some obvious logic, often for the umpteenth time- these are things I can happily delegate. And finally there are the choices you make because you think of the final product and of the experience of those who will use it- this is not a puzzle to solve at all, this is creative work and there is no predefined result to reach. I'm happy to have tools that allow me to get there faster.
I've been coding since I was about 15 and still love it. These days I mostly build tailored applications for small and medium companies, often alone and sometimes with small ad-hoc teams. I also do the sales myself, in person. For me, not using LLMs would mean giving up a lot of productivity. But the way I use them is very structured. Work on an application starts with requirements appraisal: identifying actors, defining use cases, and understanding the business constraints. Then I design the objects and flows. When possible, I formalize the system with fairly strict axioms and constraints.
Only after that do LLMs come in, mostly to help with the mechanical parts of implementation. In my experience it's still humans all the way down. The thinking, modeling, and responsibility for the system are human. The LLM just helps move the implementation faster.
I also suspect the segment I work in will be among the last affected by LLM-driven job displacement. My clients are small to medium companies that need tailored internal systems. They're not going to suddenly start vibe-coding their own software. What they actually need is someone to understand the business, define the model, and take responsibility for the system. LLMs help with the implementation, but that part was never the hard part of the job.
> This has been 100% my experience. I enjoy the puzzle solving and the general joy of organizing and pulling things together. I could really care less about the end result to meet some business need. The fun part is in the building, it's in the understanding, the growth of me.
Quite a few of the projects I always wanted to do have components or dependencies I really don't want to do. And as a result, I never did them, unless they eventually became viable to do in a commercial setting where I then had some junior developer to make the annoying stuff go away.
Now with LLMs I have my own junior developer to handle the annoying stuff - and as a result, a lot of my fun stuff I was thinking about in the last 3 decades finally got done.
One example from just last week - I had a large C codebase from the 90s I always wanted to reuse, but modern compilers have a different idea of how C should look like. It's pretty obvious from the compiler errors what you need to do each case, but I wasn't really in the mood for manually going through hundreds of source files. So I just stuck a locally running qwen coder in yolo mode into a container, forgot about it for a week, and came back to a compiling code base. Diff is quick to review, only had a handful of cases where it needed manual intervention.
It would have been worth it if the frontier models were open weight. Right now, if you invest time in mastering tools like Claude Code or Google’s Antigravity, there is no guarantee that you won’t be removed from their ecosystems for any reason, which would make your efforts and skills useless.
You still care about end result though: in your case, the end result being the puzzled you solved.
AI can make that process still enjoyable. For instance I had to build a very intricate cache handler for Next.js from scratch that worked in a very specific way by serializing JSON in chunks (instead of JSON.parse it all in memory). I knew the theory, but the API details and the other annoyances always made it daunting for me.
With AI I was able to thinker more about the theory of the problem and less about the technical implementation which made the process much more fun and doable.
Perhaps we're just climbing the ladder of abstraction: in the early days people were building their own garbage collection mechanisms, their own binary search algorithms, etc. Once we started using libraries, we had to find the fun in some higher level.
Perhaps in the future the fun will be about solving puzzles within the realm of requirement definitions and all the intricacies that stem from that.
because my company is mandating that we use motorboats instead of rowboats.
i can continue to row as a hobby, but i've been very lucky in that my work has always been something i genuinely enjoyed. now that it's become something that's actively burning me out, it's far harder to find time for hobbies and interests.
Maybe this could work for some as a general recipe for how to collaborate with AI:
- Split up the work so that you write the high-level client code, and have AI write the library/framework code.
- Write some parts of your (client) code first.
- Write a first iteration of the library/framework so that your code runs, along with tests and documentation. This gives the AI information on the desired implementation style.
- Spend time designing/defining the interface (API, DSL or some other module boundary). Discuss the design with the AI and iterate until it feels good.
- For each design increment, let AI implement, test and document its part, then adapt your client code. Or, change your code first and have AI change its interface/implementation to make it work.
- Between iterations, study at least the generated tests, and discuss the implementation.
- Keep iterations small and commit completed features before you advance to the next change.
- Keep a TODO list and don't be afraid to dismiss an earlier design if it is no longer consistent with newer decisions. (This is a variation of the one-off program, but as a design tool.)
That way, there is a clear separation of the client code and the libraries/framework layer, and you own the former and the interface to the latter, just not the low-level implementation (which is true for all 3rd party code, or all code you did not write).
Of course this will not work for you if what you prefer is writing low-level code. But in a business context, where you have the detailed domain knowledge and communicate with the product department, it is a sensible division of labour. (And you keep designing the interface to the low-level code.)
At least for me this workflow works, as I like spending time on getting the design and the boundaries right, as it results in readable and intentional (sometimes even beautiful) client code. It also keeps the creative element in the process and does not reduce the engineer to a mere manager of AI coding agents.
With coding (by hand), there are two aspects of it. One is the pleasure of figuring out how to do things, and one is the pleasure of making something that didn't exist before. Building with AI gives you the second pleasure, but not the first.
Or maybe it still gives you the first, too. Maybe you get that from figuring out how to get the AI to produce the code you want, just like you got it from trying to get the compiler to produce the code you want.
Or maybe it depends on your personality and/or your view of your craft.
Anyway, the point is, people take pleasure in their work in different ways. Those who enjoy building with AI are probably not all lying. Some do enjoy it. And that is not a defect in them. It's fine for them to enjoy it. It's fine for you not to enjoy it.
> The fun part is in the building, it's in the understanding, the growth of me.
I agree with this sentiment as well. Without a doubt, my favorite part of the job is coming up with a solution that just 'feels right', especially when said solution is much cleaner than brute force/naive approach. It sounds cheesy, but it truly is one of my favorite sensations.
I'm the senior-most engineer on my team of about 15. I try to emphasize software craftsmanship, which resonates with some but not all. We have a few engineers who have seemingly become reliant on AI tooling, and I struggle with them. Some of them are trying to push code that they clearly don't understand and aren't reviewing, and I think they're setting themselves up for failure due to lack of growth.
Maybe it is just my experience, because I'm not a system programmer, but instead learning it. I find that concepts in system programming are not really very hard to understand (e.g. log-based file system is the one I'm reading about today), but the implementation, the actual coding, the actual weaving of the system, is most of the fun/grit. Maybe it is just me, but I find that for system programming, I have to implement every part of it, before claiming that I understand it.
Post exercises freedom of opinion and expression by sharing a personal viewpoint on technology, work, and passion in a public forum without apparent censorship.
FW Ratio: 50%
Observable Facts
Author posts a substantive reflection on AI's impact on coding satisfaction without apparent editorial restriction.
Post receives responses and generates discussion, indicating platform allows expression and engagement without suppression.
Inferences
The ability to post a nuanced, personal perspective on a contentious technology topic suggests the platform supports Article 19 expression rights.
The open comment thread structure enables others to respond and engage, supporting the dialogical dimension of free expression.
Post reflects on participation in coding culture and the evolution of creative practice; author expresses concern about the transformation of creative work through AI tools, which touches on Article 27's concern with participation in cultural life.
FW Ratio: 50%
Observable Facts
Author describes coding as both a professional and personal passion practice, reflecting participation in tech culture.
Post engages with questions of how technology shapes human engagement with creative work.
Inferences
The reflection on coding practice and passion touches on cultural participation and the right to participate in the scientific and cultural life of the community.
The author's concern about loss of engagement with coding practice implies an underlying interest in maintaining meaningful participation in creative work.
Post does not explicitly advocate for freedom of assembly or association.
FW Ratio: 67%
Observable Facts
The thread is structured as a community discussion where multiple participants can engage in conversation around a shared topic.
Platform enables voluntary association through discussion without requiring membership approval or ideological alignment.
Inferences
The community structure of the discussion platform enables informal association and collective deliberation, though the editorial content itself does not emphasize Article 20.
Post does not advocate for privacy; the author shares personal professional experience publicly on a platform where comments are permanently archived and searchable.
FW Ratio: 67%
Observable Facts
The post reveals the author's age (60) and professional coding history in a public forum.
Hacker News displays usernames and timestamps alongside all posted content without requiring explicit consent for archival.
Inferences
The lack of privacy controls on the platform creates structural conditions where personal information shared during discussion can be permanently indexed and searchable.
Post reflects on work satisfaction but frames AI-driven work changes as a personal preference matter (journey vs. destination) rather than as a labor rights issue; the author expresses loss of passion without articulating concerns about working conditions, fair wages, or labor dignity.
FW Ratio: 50%
Observable Facts
Author describes loss of enjoyment in coding work due to AI, framing it as a philosophical difference in satisfaction sources.
Post does not reference working hours, compensation, job security, or labor organization.
Inferences
The framing of work dissatisfaction as a personal taste matter (journey vs. destination) depoliticizes what could be understood as labor displacement concern, thereby sidestepping Article 23 protections.
The absence of any reference to labor rights, fair compensation, or worker agency suggests the content does not engage with the substantive dimensions of Article 23.
Hacker News provides a community discussion space where individuals can engage in collective conversation and exchange ideas, supporting Article 20 structurally.
Hacker News platform enables participation in tech culture and discussion of cultural-technical shifts; the structure allows voices to engage with evolving practices.