There are many layers to this. But there is one style of programming that concerns me. Where you neither understand the layer above you (why the product exists and what the goal of the system is) nor the layer below (how to actually implement the behavior). In the past, many developers barely understood the business case, but at least they understood how to translate into code, and could put backpressure on the business. Now however, it's apparently not even necessary to know how the code works!

The argument seems to be, we should float on a thin lubricant of "that's someone else's concern" (either the AI or the PMs) gliding blissfully from one ticket to another. Neither grasping our goal nor our outcome. If the tests are green and the buttons submit, mission accomplished!

Using Claude I can feel my situational awareness slipping from my grasp. It's increasingly clear that this style of development pushes you to stop looking at any of the code at all. My English instructions do not leave any residual growth. I learn nothing to send back up the chain, and I know nothing of what's below. Why should I exist?

The irony is "ownership" is a common management talking point, but when you actually try to take ownership you inevitably run into walls of access, a lack of information, and generally a "why are you here?" mentality.

Granted one person can't know/do everything, but large companies in particular seem allergic to granting you any visibility whatsoever. It's particularly annoying when you're given a deadline, bust your ass working overtime to make it, only to discover that said deadline got extended at a meeting you weren't invited to and nobody thought to tell you about it. Or worse, they were doing some dark management technique of "well he's really hauling ass right now, if he makes the original deadline we'll be ahead of schedule, and if he doesn't we have the spare capacity".

If the expectation is I'm a tool for management to use, then I'll perform my duties to the letter and no further. If the expectation is ownership, then I need to at least sit at the cool kids' table and maybe even occasionally speak when I have something relevant to contribute.

Strangely, I feel that using Claude helps me stay MORE focused on what I am actually trying to accomplish.

In the prior 30 years of my programming life, so much time was spent "yak shaving"... setting up all the boilerplate, adding basic functionality you always have to do, setting up support systems, etc. With Claude, all of those things are so quick to complete that I can stay focused on what I am actually trying to do, and can therefore keep more of the core functionality I am caring about in my head. I don't have to push the core, novel, parts of my work aside to do the parts that are the same across other projects.

I am still missing something like Claude code that's less "hands-off" and optimizes for small edits instead of full feature development

Like you're sitting in your ide, select a few rows, press (for example) caps lock to activate speech and then just say a short line what it should adjust or similar - which is then staged for the next adjustments to be done with the same UX

Like saying "okay, I need a new usecase here, let's start by making a function to do y. [Function appears] great, we need to wire with object into it [point at class] [LLM backtracking code path via language server until it finds it and passes things through]

The main blocking issue to that UX would likely be the speed of the response, as the transcription would be pretty much instant, but the coding prompt after would still take a few moments to be good... And such an interactive approach would feel a lot better with speed.

Too bad nobody seems to target the combined mouse+voice control for LLMs yet. It would even double as a fantastic accessibility tool for people suffering from various typing related issues

You sit on the arbitrating layer. It sounds like you have some programming experience as you miss looking at the code. I did check a lot of code and got tired of how perfect it were, generated by AI. Latest Claude is insane, does not even make errors. You still have to guide it and it will occasionally go astray and make rookie mistakes. If you extrapolate to 6 months down the road, one Claude API = a team of 10 programmers. None of them sloppy and undocumented. So if one wants to remain pertinent in this new economy of infinite coding, one should go back to project management, learn best practice and software fundamentals. I think there will be a lot of demand for ex-programmers able to steer AI in the most efficient stack, the best architecture and the most optimised deployment. Notions of recurring cost, maintenance and security will help for sure.

Well, to be fair, we've already been there, for many years (dependency hell). In those cases, LLMs are likely to actually improve things.

For myself, I like to know what's going on, to a certain extent, but appreciate abstraction.

I am also aware that people like me, probably don't make commercial sense, but that's already been the case for quite some time.

You should absolutely try your hardest to learn the layer above you. If your organization won't volunteer the info easily that's unfortunate, but you definitely have to try.

The average tenure of a developer for the longest was 2.5 years not to mention the developer changing teams, even before AI many developers didn’t know how the code they were brought in to maintain works.

> My English instructions do not leave any residual growth. I learn nothing to send back up the chain, and I know nothing of what's below. Why should I exist?

When you use Claude code, tell it to keep a markdown file updated with the what and the why. Instead of just “Do $y”, “Because of $x I need to do $y”. If it is updated in the markdown file, it will be recorded and sometime the agent will come up with code and mske changes that are correct. But use cases you didn’t think about. You can then even ask it “why did it do $x” that you weren’t expecting but oh yeah, it was right.

> Why should I exist?

That’s the wrong question, the correct question is “why is my employer paying me?”. Your employer is paying you to turn well defined requirements into working code to either make them money or to save them money if (the royal) you are a mid level ticket taker. If someone is working at that level, that’s what they are regardless of title.

No one cares if either you or the LLM decided to use a for loop or a while loop.

At higher levels you are responsible for taking your $n number of years of experience to turn more ambiguous, more impactful, larger scoped projects into working implementations that are done on time, on budget and meets requirements. Before LLMs, that meant a combination of my own coding, putting a team together and delegating and telling my director/CTO that this isn’t something we should be doing in house (ie a Salesforce or Workday integration) at all.

Now add to the mix between all those resources - a coding agent. In either case, I as anything above ticket taker, probably haven’t looked at a line of code first. I test for does it meet the functional and non functional requirements and then mostly look at the hot spots - concurrency issues, security issue, and are there any scalability issues that are obvious before I hammer it with real world like traffic - web request or transactions for an ETL job.

And before the pearl clutching starts, I started programming as a hobby in the 80s in assembly and spent the first decade and a half of my career doing C bit twiddling on multiple mainframes, PCs, and later Windows CE devices.

Chesterton's steamroller, lol.

In an ideal scenario, you want your employees to be fungible. You don't want any irreplaceable individuals who hold the entire organization hostage. One way of defending yourself from such individuals is ensuring that all members have enough knowledge to take other people's roles, at least after some brief training. The problem is, maintaining high level of competency and transparency is very expensive. The other solution is when your organization is a complete mess and nobody knows what they're doing anyway. Yes, this results in your organization being inefficient, but this inefficiency might actually be cheap in the grand scheme of things.