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.
reply
voxleone 9 hours ago | parent | next [–]
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.
reply
jantb 5 hours ago | root | parent | next [–]
I’m doing the same as you and even though I was producing coding a lot of the actual products I estimated the coding part just to be about 20% of the work. The rest is figuring out what and how to build stuff and what stakeholders really need, and solving production issues in live event driven systems. Agentic coding is just faster at the 20% part, and I can always sit down and code the really hard stuff if I want to or feel I need to if the LLM gets stuck. If it produces something not understandable I either learn from it until I understand it og makes it do a pattern I know instead. So all in all, not so worried.
reply
finaard 9 hours ago | parent | prev | next [–]
> 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.
reply
throw-the-towel 8 hours ago | root | parent | next [–]
Note that you are able to choose freely what parts of the work get done by Claude, and what parts you do yourself. At work, many of us have no such luxury because bosses drunk on FOMO are forcing agent use.
reply
sktrdie 8 hours ago | parent | prev | next [–]
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.
reply
specproc 10 hours ago | parent | prev | next [–]
One hundred percent.
I came back into tech professionally over the last decade. Always been into computers, but the first decade or so of my career was in humanitarian amin. Super interesting sector, super boring day-to-day.