When I worked at a particular fruit company in Cupertino, my boss had been asked repeatedly by the developer teams to provide a tour of the data center we'd recently finished building out, which housed the servers their code ran on.

He gave them a lengthy, grueling, hyper-detailed tour of the entire facility, encompassing the HVAC systems, electrical systems, network and computing systems, finishing with about 20 minutes where he had them stand inside a hot aisle that he was just outside of, giving a fantastic soliloquy on the importance of code efficiency, and the consequences of ignoring it. It was hilarious to watch from the comfort of the cold aisle, knowing full well what he was doing.

Exactly. For most of my career, bad engineers (or juniors who were earnestly learning) would struggle to even create output that compiled, let alone ran. And it would take them a long time to implement something poorly. So the blast radius from their incompetence would be limited. Today, a bad engineer can churn out ten thousand lines of garbage that actually compiles and runs, before my first cup of coffee. If not on a tight leash, they'll sink the whole codebase or inundate every senior person with garbage code review requests. The blast radius is unlimited!

> We are pushing tons of code and now our CPU usage has grown exponentially over the past year because the bad engineers just ship whatever Claude gives them and do not think about the consequences.

Sometimes this can be a death by a thousand cuts. Any individual change may not impact performance to a noticeable degree but when they're pumping out a 10x increase in commits it can be a slow decline.

Just look at how they're merging ~300 commits a week into bun.

https://github.com/oven-sh/bun/graphs/commit-activity

That really sounds like the kind of people who will complain in university about being forced to study calculus.

Natural consequence: Then they never grasped the concept of computational complexity.

O(n) Vs O(n²)? They have n, what's the difference? Python is fast enough. The only thing that matters is shipping features fast! Features! Our competitor will have this next week, we need to write code fast, everything else is a matter of adding more compute, which we will pay with revenue!

A hackathon for performance improvement screams to me "you'll be re-interviewing for your own job." I don't foresee this going well for the company. Best case scenario: you wildfire churn all the chaff engineers which limits the company's throughput until they're rehired... with no expectation the new hires will be any better. You also lose A LOT of domain experience and are self-inflicting brain drain.

I'd try and push for some "lunch and learn" meeting where the engineers get lunch catered and in exchange sit in on a meeting where you explain your point of view. Without monetary incentive it'll be hard to change the culture, but not impossible (and food goes a long way in greasing the wheels).

Do you have SLO/SLAs defined? Are you monitoring performance? CPU usage? Cost increases?

You should have plenty of data to review regularly and push back on any teams that are causing problems. That's a process problem and you need a process for it.

Trace the increase back to specific deployments, call out those teams, and make them fix their shit.

If your company has sketchy process and minimal checks on the software quality, of course it naturally follows that they hire bad engineers as well. fortunately, that also opens up an opportunity to be a emergency leader with an eye towards promotion.

The handling of backpressure is such a good example to distinguish bad from good engineering. A good implementation even presents all the typical "clean" code indicators: DRY, KISS etc.

Mind sharing where you're at?

Sounds like bad management to me

This has less to do with bad engineers than bad policies and procedures. You don't performance test before shipping to prod? you get what you get.

>> Egotistically, I don't even mind, it's just the salary hit that would be the main issue.

This is whare I am right now. Even senior positions have dropped 50-60K in range so I've effectively priced myself out of a lateral move because I would be taking a massive hit in salary for the same role I'm doing now. I'm currently at a company that continues to lay people off in lieu of offshore talent and AI. I'm stuck in a weird state of purgatory.

>> Should I just apply for a managerial role and in the cover letter state management is my intended path for growth?

I know many of my friends in senior dev roles have put their resume in Claude and said they were interested in moving into a management role and had Claude revamp their resume into something that was more management focused. Three of them were hired quite quickly not only based on their dev backgrounds with mentoring, training and light management of junior devs, but having enough emerging AI skills they said helped them close the deal.

> A good engineer, with a good model and harness will produce great stuff. A bad engineer with a good model and harness will produce something faster, but it will be worse.

A good engineer, without LLM assistance, will still produce great stuff.

In retrospect, the golden age was the pre-internet era. Some rose-colored glasses maybe, but as I remember it:

Paying for software was the norm, so it was more clear what the "product" was, and software writers had a direct incentive to write better software.

Updates could not be pushed out so you had to be pretty sure your code worked before you shipped it. Having to ship physical media to all your customers for a bug fix was very expensive. Any new release was a big deal, so you had to put some real thought into what features it should contain.

Significant amounts of your development time were not spent trying to work around browser bugs, or differences in browsers, or supporting random old browsers that your customers still use for <reasons>.

Stack churn was much slower. The feeling of constantly trying to keep up with a treadmill was much less.

Users, while often not technology experts, were a much more competent slice of people than the general public who showed up when they got internet service and a computer at home.

The only ads were in print in trade magazines or publications like Computer Shopper. Yes, people actually used to buy a magazine that was nothing but ads.

I also consider myself a fairly good pragmatic software engineer. I have led small (3 engineers), medium (15), and large (100+) teams.

To me, the best time was late 90s, early 2000s. We had a lot of autonomy. People would just trusted that we knew what and how to build it. I could focus on building a great product. Overtime, we lost control, to the point that we now work based on jira tickets made by managers or product owners with one tenth of the experience that we have.

Alternatively, cutting out labor just results in mass poverty except for the moneyed few, and a new era of technofeudalism.

It seems pretty clear that the current crop of executives strongly prefer the latter scenario.

I don't agree here. Yes Claude is great at following patterns, and for very standard tasks (e.g. "add this HTTP handler" which can copy existing patterns for database transaction management, session management, authentication, etc etc) it does great! The problem is that when you do something that doesn't quite fit int an existing pattern, Claude will optimize for solving the task at hand, producing code that doesn't use a sensible architecture. Doing things like checking user credentials or establishing a database connection deep in domain logic.

If you're a good dev, you can totally prompt Claude to not do this and correct itself, that's not an issue. The issue is that bad devs won't even notice this is happening in the first place.

Strong disagree. A lot of AI development still requires good engineers to keep tight leash on it so I'm seeing more bad developers create a feature until we need to iterate on said feature and we find AI did such a bad job that it becomes extremely difficult to do so.

AI is very good at making the bad dev's PR look plausible and be green in CI. And thus, merged.

A bad developer with any current frontier model will happily produce syntactically correct code that is unreadable, in a spaghetti architecture, and write an elaborate test suite that tests all of the wrong things.

Less sloppy in that it's clean and consistent looking but much more sloppy in the AI good looking non-sense way.

Jury is still out here

> AI tends to write less sloppy code than bad devs, and test/validate it more rigorously

I've often had it test and benchmark against the wrong things = no test.

It also writes over-engineered code. So yes sort, maybe.

Totally agree with your framing here, but that is also what I fundamentally consider "good" code -- it's code that solves the problem that your customers/business needs without making it _harder_ to solve the next problem.

There are valid situations where the best code you can write is code you never look at and throw out the next month; there are equally valid situations where the best code is well thought through and reasoned abstractions for an area you expect to become core to the business in the near future.

This is a great point. I find myself in the middle, where I appreciate and look up to past coworkers who were way better than me at attention-to-detail, but I have a tendency to focus on delivering actual results quickly with maintainable and easy to read code. A lot of engineering teams go into their own world on adhering to best practices with no eye on inefficiencies in the process that causes days of delay because it makes them feel better. I definitely believe in shift-left (findings bugs early saves a lot more time than finding them in production). I believe in balancing fast delivery with quality/process.

If you're writing CRUD, there's no excuse not to write it competently since you're not solving a new problem

In my experience, those that can’t understand design in the small (code level) don’t understand it in the large (sw or systems architecture) either.

Doing the right thing for the customer is independent from good design and good code. It’s a problem of requirements and project management. This is an excuse some poor programmers use, that they can’t write good code, but at least they fulfilled the customer requirements :D

They’ll care when nothing works, nobody seems able to fix it, building new features takes forever and every change breaks something somewhere else.

This was already happening before. But now, a lot more companies that previously might have taken many years to reach an unmaintainable state can now get there in just a few months.

Fair point! I edited my comment, A&D -> Architecture & Design

Trust actually does work that way though, the implicit and collective fuzzy agreement of “having my name on it”. Of course that ambiguity needs enforced automated checks, but reputation and one’s own integrity is not for nothing.

Generative AI breaks that agreement. It took me over a year to realize my previous CTO actually didn’t care too much about the system design he shipped . And the expectation was actually to just throw it away, have AI reimplement “what wasn’t working”. Use AI to ship, AI to learn what shipped, and AI to fix what shipped.

I quit because of it. Hell is working on other people’s AI code.

We had a dedicated QA team and an extensive test base... which we fired to reduce headcount, and we've trimmed back because we don't have the hardware resources to run those tests sufficiently expeditiously.

Secondarily, the business itself is also driving the throughput increases by demanding more volume, but there is no accountability to them for asking for throughput at the expense of quality. They may also deny the engineering time to work on things that would stabilize quality that supports faster delivery because features earn money more directly than developing quality processes.

This isn't coming solely from engineers wanting to produce more stuff faster.

Quality assurance and test plans don't catch slop. They just test your code. It can't prove the absence of bugs.

In general, the way we still do it is: some basic static analysis finding anti-patterns, but the meat of it is, and always will be, code review. Except you can't review code at the pace AI generates it.

Where I work someone is still responsible for the output. We expect developers to examine the code the LLM produces before burdening someone else with it.

>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.

>What tends to happen is that the EMs and PMs look at who’s free and give that person the task.

The gp you replied to qualified it with "enterprise software" (LOB, CRUD, etc aka "cost center") so your observations where senior -vs- junior engineers being more fungible can be true.

However, in "engineering" type of software products (game engines, RDBMS engines, operating systems, etc) where the software is more often a "product" that's sold (aka profit center) ... there are definitely different layers of complexity where senior and junior engineers are not fungible at all.

One way to describe the differences of complexity and criticality in various parts of the source tree is the "core" parts vs the "leaf" parts. E.g. in a game engine or Linux kernel, the deep parts of the engine or os process scheduler where the tight loops are located are the "core" parts. They most likely would be worked on by the most senior people.

But the game engine may have some less complex code for handling text width on a menu for different foreign languages. Or the os needs a new menu option on the installer to ask for the users age. Those would be more "leaf" functionality in the source tree. A junior could get assigned to those parts with less risk. After a few years of experience, he might be trusted enough to work on the deep "core" logic without screwing things up in catastrophic ways for a million customers.

A product with several million lines of source code will invariably have both the "hard parts" and "easy parts" so the new hires and juniors will work on the easier stuff first.

There's also a spectrum of hard-to-easy in enterprise software but it's much more narrow than engineering code bases.

Nor have I seen this "punch every hiccup into google" approach. Most errors are things that (a) you've seen before if you have any significant experience and (b) have a pretty obvious cause if you simply read the error message and look at your code.

Sure you might lean more on Google or SO if it's something you haven't seen before, or it's something deep in a stack that isn't code you actually wrote. But as the noob eventually learns when he thinks he's found a bug in a runtime or compiler that thousands of other people are using every day: No. It's probably your code.

I suppose there are people who never advanced beyond the "type (or copy/paste); run; google the errors" loop, but I've never seen anyone with more than a year or two of experience doing that very often.

Oh I'd say its real. Years ago I worked as that senior who divvied up the work to a team of 4 mid-level engineers in that exact fashion (they were mostly Latin American contractors with limited english). We actually shipped some good stuff too!

Unfortunately, looking back, I could easily see Claude replacing 3 out of 4 of those developers. Myself + one other dev + AI would probably would've shipped a bit more a little faster. With that said tokens aren't free so the net cost savings would've been 2 dev salaries maximum.

> This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.

I would have said the same thing for the first 15 years of my career across several jobs and acquisitions.

Then I took a job at a company that fit this description. They had so many managers and PMs that every task was talked about, broken down, and documented so much that every Jira ticket was a little piece of work that a junior could handle by Googling things.

The quirk was that they had started hiring a lot of experienced and staff level engineers, too, but then tried to force this same framework on to everyone. We spent more time discussing tasks than doing them by a factor of 2-50X. There are some situations where this is appropriate, but none of our work was actually high scale or difficult. Your day might be spent writing design docs and collective sign offs as you worked through committees until the tickets at the end were so simple that any junior could do them.

It didn’t lead to better software. It was one big cargo cult game of performative management. A frequent outcome was that someone would get into the micromanaged tickets and realize there was a better way to handle something, but it wasn’t worth doing all of the fighting and meetings involved to do the meeting and Jira ticket dance all over again.

>This is the theory, but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice.

Same but with 10 years, and I don't think I would do well in a place like that. That removes you from writing code and there is a similar complaint about relying too much on AI and not writing enough code on your own.

> If your company is highly product driven, you’ll often find that the juniors end up lea[d]ing projects more often than not because they will tell the PM exactly what they want to hear

I worked in a company where this happened, and it wasn't pretty. Product managers used their experience and seniority to intimidate junior engineers and exert control over project management of engineering projects, which they predictably used to move as much work as possible to post-launch, including testing and security. They also gaslit junior engineers into agreeing that issues with contradictory or impossible product asks could be figured out later, leading to software getting released to customers that fundamentally could not be made reliable, performant, or even secure.

Even after the entire company went on site visits where customers told us they weren't using any of the features released in the last year because they were all buggy, and the only information they wanted about upcoming releases was assurance that their use cases wouldn't be impacted, product still kept claiming that the time it took to release new features was the biggest problem facing the company and kept fighting back against engineers who said we were in a quality crisis and desperately needed to make time for better testing and design.

The only thing that can shield you is good engineering management. Weak management will end up getting rolled by product and start promoting the bad behavior that product insists on. At that company I had a boss whose attitude towards us was "engineers in a startup should make decisions independently and stand by their work" but made sure engineers felt unsafe making engineering decisions that product wasn't happy with, likely because they felt unsafe themselves.

I've never thought about it this way before but this definitely mirrors my experience

> but I’ve never worked anywhere (and I’ve worked at a lot of places over 20 years) that actually did it like that in practice

I've seen a twist - not juniors but just offshore engineers.

> I’ve worked at a lot of places over 20 years

Primarily in Silicon Valley or outside of it?

I worked most of my two decades in the Valley but also spent time outside of it. There is in many cases a vast gulf between the dev cultures. What the parent comment is describing I've seen many many times.

I think that’s a completely different problem.

I’ve worked with two junior devs recently who are very good precisely because they’re trying to understand what they’re doing, rather than just producing code.

I’ve also worked with senior devs who basically gave up and stopped trying to understand the code. They became much worse engineers as a result. At this point I would much rather work with those 2 juniors.

They use it to explore things they don’t understand, ask me questions to clarify their reasoning, double-check assumptions. They generally use the tools available to increase their understanding.

It's true that developing junior devs is challenging (but it always was), but that's not what this is about: This is about the kind of not-that-good, mid-ass programmers who make up the silent bulk of the industry. The ones who have 20 years of experience, but who you still wouldn't trust to write fizzbuzz.

Those people are doomed. Which is fine in a lot of ways, but will be devastating for their economic prospects.

Yeah. Technology and social change has done this all over the economy. E.g. from my dad's field, there's not enough public health people with field experience to replace the folks who are retiring. We have plenty of entry level people who can't get a job, but then there's a gaping hole in the pipeline between them and the graybeards who are retiring.

by then we'll have an mfc, instead of trying to get llms to write code our prompts will compile and execute efficiently. after that inversion "programming" becomes "using language to describe some processing" it's just writing. knowing a computer language of old helps but not necessarily

also who knows if prolonged ai development for years actually doesn't atrophy your coding muscles so to speak such that you are fully reliant on ai programming to get things done

> Kind of like the fortran crisis of the last decade or so....

I’m convinced the only reason there’s a Fortran crisis is because nobody wants to work on Fortran or make a career out of it.

Has nothing to do with willingness to hire juniors. Good luck finding promising juniors who survey their career opportunities and decide that Fortran is a good technology for building their resume.

It also ignores the effects of having a critical tool in the software pipeline controlled by a large corporation. That is an absolute sea change from the years when you could (and some of us did) run most of our software development on open tools.

Think about all the open source the world got from some random person in Finland or Sicily or wherever hacking on a cool idea. Will that still happen with a high (for someone who is not employed... maybe a student) monthly cost?

I think that smart companies (don't laugh, a few exist) will still hire juniors. Fewer, more carefully selected, but still some.

The StackOverflow devs being replaced were never going to become real senior developers no matter how much time was given to them. There is an entire cohort of people who were told to go to college for programming because it was an easy way to make good money, who did what they were told while having zero interest in it and never touching a line of code outside of work/school hours. Those people were never going to understand actual programming, all they were doing was copy-pasting code for a paycheck. Does it suck for them that they're being replaced by automated copypasting bots, yep. But frankly speaking nobody should've ever been paid 6-figure salaries to copy paste snippets from SO and jam JS library legos together in the first place.

By contrast I have not worked anywhere that engineers originated tickets. And thankfully, only one place that used Jira (but the engineers didn't interact with it).

Tickets came from the product side, after being evaluated and prioritized. Engineers got involved with estimating effort (in "points") and doing the actual implementation of course.

you're one of the lucky ones.

usually in most when engineers tend to create their own tickets - it's for useless shit like improve x, clean up y etc.

very few people have worked in places with high agency - where you work with a higher up & create a feature/product line that has customer impact. startups are one of the few places I can think of with high agency.

My last job was like that, it was miserable having no agency. The whole team was from fang companies and were all ok with the tell me what to do dynamic.

Do you think it's acceptable to do the work of multiple full time positions? I can't imagine it's very sustainable, nor healthy for you (both body and soul).

Not really in my experience. I’d much rather have just the prompt rather than the seven paragraph slop

Nobody is getting paid significant money just to build a simple CRUD app. Even before AI. Companies pay experienced engineers because the supposedly simple CRUD sits inside a messy real system with years of business rules, constraints, integrations and bad decisions have consequences.

Django? Django is older than jQuery…

The decisions are important, but the understanding is that you define them as constraints. Which is what a segment of the software community, the upper class if you will, has always believed you should do, even before LLMs were a thing. The LLM simply becomes a constraint solver: machines do the work, people do the thinking.

This is the challenge of the middle class developer. They aren't accustomed to working with constraint thinking and they're past the junior stage where one is expected to still be shaping their thinking so they are struggling to find a fit.

> It will become very easy to build most software

We keep hearing this, but where is the Photoshop killer written by a gas station attendant? Where is the PayPal alternative written by a retired nurse?

Over and over we're told that software is now trivial to write, and Claude is evidently writing some billions of lines of code a day, but where are the results? Where is the vibe coded app toppling the legacy hand-coded monster product from 20 years ago?

I agree. And I would remove the basically. I give it five years before essentially just a few very senior people are managing the whole cycle. Downward pressure on wages is just gonna keep ratcheting up.

All fields are basically over as a long term career besides perhaps prostitutes and even there I'm not entirely sure. But the questions of how soon and by how much matter a lot. Being early is the same as being wrong a clever guy once said.

nah the world needs more software - it's just the delivery mechanism that's different.

we are entering the world of smaller service firms (1 - 3 people) - where technical chops will even get paid more. the age of cookie-cutter apps is over.

Only if you run out of things to write. Is your back log ever empty?

Pretty much no other engineering field made sense to go into for about a decade. Even kids who did go EE, Mech E, or even Chem E ended up taking software jobs. The pay, benefits, and work/life balance of SWE just absolutely obliterates everything else. Or did at least

And how do you think people go from fresh graduates to senior devs?

Degrees take 4 years. It's a very laggy indicator.

Orrrrrr... it could be a complex combination of outsourcing, an over-reliance on degrees, LLMs, a lack of "apprenticeship" mentoring, etc etc etc.

I was very fortunate to get a job in a NOC a little bit after high school where I learned things one'd expect to learn in an entry level job. The team I worked on was all about mentorship, learning, and building people to the next level.

Haven't seen that attitude elsewhere in my entire career except in the non-profit world where I reside these days. It blows me away that people are surprised that these industries have failed to build entry level positions.

My job was just taken by Cognizant, which is technically American, so I guess you're technically right!

have you been inside any big tech company? lots of orgs are > 80% foreign.

But those H1Bs all come for a very narrow set of work - mostly software development or other adjacent roles. So your 4 million figure that counts all graduates in all fields doesn't make sense when we talk about tech.

There are around 100k U.S CS graduates . You're telling me 100k H1-Bs don't make any impact on them?

-85,000 NEW visas granted each year, not including renewals - The mass majority of those are going into the tech/software - there are only around ~100k CS graduates each year - H1B workers will take much lower salaries and benefits than their US citizen counterparts.

have you been inside a big tech company? there arent many american fresh grads working there, its mostly foreign

Spend some time processing tech job applications and you’ll realize you’re wrong

We always talk about damage, what's the damage here?

Exactly this for me too. I don't know how to feel about this overall honestly, I'm able to do so much more but now I barely get to write any code. It's weird.

See https://en.wikipedia.org/wiki/Zero-based_numbering, e.g. “computer programmers might use zeroth in situations where others might use first”.

Lots of (most?) programming languages are 0-indexed so it feels natural for software developers and our ilk.

Hey everyone! I found the COBOL developer!

2026 is starting to slow time there emergency and 2027 will clean. Unfortunately they still contribute to overwhelm socials media with there content.

Nice first name btw

Too real. I got DMed by management recently asking if I was anti-AI because I had the lowest spend on the team as the lead, y'know, the one that has to review all the slop my peers are generating.

I wasn't saying that either

That is an incredibly short sighted view. By acting this way, the industry is essentially selling its future for short term gains. A systemic reduction in the number of people capable of maintaining systems directly correlates with an inevitable collapse in overall software quality.

The perspectives of market advocates often stop at this short sighted level. In reality, their modeling is incredibly simplistic. I will not elaborate at length on their poor modeling here. The short sighted local optimization that only chases the margin of the next quarter is the exact enemy we must guard against the most. (Of course, given the nature of HN, this specific part of the comment will likely be attacked.)

It is not a matter of companies not owing anything; rather, companies are actively committing self sabotage.

Is it truly right to eat tomorrow's seed corn today?

The essence of the software industry is not the 'generation' of code, but the 'maintenance' of it throughout its life cycle. Why is Linux continually maintained, and why is Windows continually maintained? The core of this industry is fundamentally tied to the entire life cycle of a product.

You might be able to fix code with AI. However, under the current LLM structure, can it actually modify projects spanning hundreds of thousands or millions of lines? It cannot. The skill required to partition those architectures is still entirely left to humans. And the ability to define those boundaries is born strictly from experience.

Labeling certain individuals as useless or inadequate inherently destroys the resilience and buffer of the collective as a whole.

Why do humans embrace and care for the vulnerable when society has the capacity to do so? Why do we strive to preserve diversity? It is because, depending on the context, those very traits might prove to be more advantageous. Every human possesses distinct skills, and their unique temperament and proficiency simply manifest depending on the situation they face.

Do you have examples? Ideally a startup that isn’t itself selling AI to other AI companies

Debt is debt. Some of it is absolutely worth taking on.

I don’t have any issue with intentional debt when you understand the trade-off and have a clear payoff plan.

That's only one of the three reasons in the article: 1) Reviewer burden - LLMs can produce a deluge plausible but incorrect code which can overwhelm human reviewers. 2) Safety and Security - Many corporations depend on the JDK so stability is a high priority. 3) Copyright/IP about who owns submissions generated by AI is not settled in law.

The article also goes on to compare the JDK teams policy to GraalVM, also in Oracle which is more similar to the Linux kernel policy, where AI submissions are allowed, but the human submitter is accountable to them, which is reasonable too.

It's not unreasonable, in my opinion, for the JDK team to limit AI contributions based on their stated priorities, just like how other teams might not require those same restrictions.

Oracle banned AI code from a public project they maintain and backport/share with a commercial product because they're a very litigious company, anticipating future legal cases.

It strongly argues against a position that many people including myself have taken, that all code will soon be AI code and the only people still writing code by hand are those who haven’t gotten the memo. (I don’t mean to rule out the possibility that Oracle, despite their involvement in AI infrastructure, is just being dumb and the lawyers made them create a policy that’s not compatible with the modern practice of software development.)

I know what you mean, but the amplifier could genuinely work both ways ( magnify bad and good outcomes ).

I hate that framing because it glosses over what makes AI distinct from other technology. Pretty much anything can be used as a tool, that’s not an interesting aspect of AI. However standard tools do not take decisions on behalf of the user, they do not apply judgement. They come with assumptions and constraints that make some decisions more likely to be made. But the whole thing about LLMs is that they apply judgement and take decisions. When you use an LLM you delegate both aspects to it with very little overview or control.

I don’t think it’s “just a tool”, it’s something that directly compete with the role of humans in a system, by design

Ai is a tool in the same way an employee is a tool. very unlike a hammer.

right but we have never seen a tool like this

Do you think it's impossible for someone to have a 25K line PR / diff but not know what's going on in the system?

I ask because I've pushed some of this to the limit in my own testing and when I get the right building blocks / primitives in place in the repo, I'm able to get plans written in a way where I don't just describe what I want but specifically mention outcomes, verifications, constraints, etc. that utlimately describe the shape of my system and my intent.

My plan is my understanding of my system and the changes I'm making, and the execution of that plan (e.g. with subagents), verified against my spec, is the code itself.

With the correct building blocks, I've found that frontier models can write code in fairly predictable ways that lets me maintain my understanding and confidence in pretty large PRs.

I think perhaps the quoted part of your post seems to imply it's not possible / isn't phrased with that nuance?