[Art9681]

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.

[wirthal1990]

My experience was exactly the opposite—I came from the other side entirely. I had absolutely no programming knowledge, and until three weeks ago, I didn’t even know what a Parquet file was.

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.

[jrjeksjd8d]

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.

[wirthal1990]

This matches my experience when building my first real project with Claude. The architectural decisions were entirely up to me: I researched which data sources, schema, and enrichment logic were suitable and which to use. But I had no way of verifying whether these decisions were actually good (no programming knowledge) until Claude Opus had implemented them.

The feedback loop is different when you don’t write the code yourself. You describe a system to the AI, after a few lines of code the result appears, and then you find out whether your own mental model was actually sound. In my first attempts, it definitely wasn’t. This friction, however, proved to be useful; it just wasn’t the friction I had expected at the beginning.

[markus_zhang]

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.

[cies]

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.