alt.hn

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.

by voxleone

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.

by 93n

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.

by finaard

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.

Getting back into code felt like coming home. I'm good at it, I really enjoy it, the problem-solving aspect totally lights up my brain in this amazing way.

I feel exactly the same way. Totally robbed of pleasure at work, with the added kicker of mass layoffs hanging over the sector.

At least OP is sixty, I've got 25 years of work left and I really don't know what to do. I hate it all so much.

by specproc

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.

by throw310822

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.

by sktrdie

> 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.

Claude very much learns if you teach it and tell it to note things in the CLAUDE.md files you want it to remember. Claude is much better than any junior and most mid level ticket takers.

by raw_anon_1111

While reviewing a deep research project I had started, I stumbled upon an inefficiency: The USDA’s phytochemical database is publicly accessible, but it’s spread across 16 CSV files with unclear links. I had the idea to create a single flat table, enriched with data from PubMed, ChEMBL, and patents. Normally, a project like this would have been completely impossible for someone like me—the programming hurdle is far too high for me.

With Claude Opus 4.6, I was actually able to focus entirely on the problem architecture: which data, from where, in what form, for which target audience. Every decision about the system was mine. Claude Opus took care of the implementation.

I’m probably the person your debate about “journey vs. destination” wasn’t meant for. For me, the destination was previously unattainable. My journey became possible, because the AI took over the part that I could never have implemented anyway.

by wirthal1990

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.

by jrjeksjd8d

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.

by cies

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.

by seinvak

- 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.

by antfarm