> Anything that requires actual brainpower and thinking is still my domain. I just type a lot less than I used to.

And that's a problem. By typing out the code, your brain has time to process its implications and reflect on important implementation details, something you lose out on almost entirely when letting an LLM generate it.

Obviously, your high-level intentions and architectural planning are not tied to typing. However, I find that an entire class of nasty implementation bugs (memory and lifetime management, initialization, off-by-one errors, overflows, null handling, etc.) are easiest to spot and avoid right as you type them out. As a human capable of nonlinear cognition, I can catch many of these mid-typing and fix them immediately, saving an significant amount of time compared to if I did not. It doesn't help that LLMs are highly prone to generate these exact bugs, and no amount of agentic duct tape will make debugging these issues worthwhile.

The only two ways I see LLM code generation bring any value to you is if:

* Much of what you write is straight-up boilerplate. In this case, unless you are forced by your project or language to do this, you should stop. You are actively making the world a worse place.

* You simply want to complete your task and do not care about who else has to review, debug, or extend your code, and the massive costs in capital and human life quality your shitty code will incur downstream of you. In this case, you should also stop, as you are actively making the world a worse place.

So what about all these huge codebases you are expected to understand but you have not written? You can definitely understand code without writing it yourself.

> The only two ways I see LLM code generation bring any value to you is if

That is just an opinion.

I have projects I wrote with some help from the LLMs, and I understand ALL parts of it. In fact, it is written the way it is because I wanted it to be that way.

> So what about all these huge codebases you are expected to understand but you have not written?

You do not need to fully understand large codebases to use them; this is what APIs are for. If you are adventurous, you might hunt a bug in some part of a large codebase, which usually leads you from the manifestation to the source of the bug on a fairly narrow path. None of this requires "understanding all these huge codebases". Your statement implies a significant lack of experience on your part, which makes your use of LLMs for code generation a bit alarming, to be honest.

The only people expected to truly understand huge codebases are those who maintain them. And that is exactly why AI PRs are so insulting: you are asking a maintainer to vet code you did not properly vet yourself. Because no, you do not understand the generated code as well as if you wrote it yourself. By PRing code you have a subpar understanding of, you come across as entitled and disrespectful, even with the best of intentions.

> That is just an opinion.

As opposed to yours? If you don't want to engage meaningfully with a comment, then there is no need to reply.

> I have projects I wrote with some help from the LLMs, and I understand ALL parts of it. In fact, it is written the way it is because I wanted it to be that way.

See, I could hit you with "That is just an opinion" here, especially as your statement is entirely anecdotal But I won't, because that would be lame and cowardly.

When you say "because I wanted it to be that way", what exactly does that mean? You told an extremely complex, probabilistic, and uninterpretable automaton what you want to write, and it wrote it not approximately, but exactly as you wanted it? I don't think this is possible from a mathematical point of view.

You further insist that you "understand ALL parts" of the output. This actually is possible, but seems way too time-inefficient to be plausible. It is very hard to exhaustively analyze all possible failure modes of code, whether you wrote it yourself or not. There is a reason why certifying safety-critical embedded code is hell, and why investigating isolated autopilot malfunctions in aircraft takes experts years. That is before we consider that those systems are carefully designed to be highly predictable, unlike an LLM.

The best time to debug is when writing code.

The best time to review is when writing code.

The best time to iterate on design is when writing code.

Writing code is a lot more than typing. It's the whole chimichanga

Unfortunately, your reasoning has an enormous hole in it. A huge part of a product's quality is how it fares over time, i.e. how many years it lasts and how much it costs to maintain. Sadly, this either takes time or a realistic assessment to determine, both of which cannot part of a market bubble.

The 10$ shirt becomes a much shittier proposal once, in addition to its worse looks, fit, and comfort, you factor in its significantly lower durability and lifespan. That's why the 100$ shirt still exists after all. Nevermind that the example is a bad one to begin with because low-price commodities like T-shirts are never worth fixing when they break, but code with a paid maintainer clearly is.

In an market bubble like the one we find ourselves in, longevity is simply not relevant because the financial opportunity lies precisely in getting off in the train right before it crashes. For investors and managers, that is. Developers may be allowed to change cars, but they are stuck the train.

It's sad how some of the doomed are so desperate to avoid their fate that they fall prey to promises they know to be bullshit. The argument for Wish and TEMU products is exactly the same, yet we can all see it for what it is in those cases: a particularly short-lived lie.

Just addressing the comparison: a t-shirt can be changed for the cost of the new t-shirt. A software product costs not only the new one (being AI, very cheap) but also the cost of integrating it with processes and people - and this can kill you.

Are you sure? Based on what? All I see is people desperately throwing money they don't have at AI like a gambling addict who just converted their child's college fund into chips.

Call me a buzzkill here, but my bet is you aren't gonna hit it big. While you can win at the casino, that requires a careful plan with contingency solutions, which AI simply does not have. Realistically speaking, it is indeed best to just not play this game; you are just digging a deeper hole.

I think you missed the point. The EU is "winning by doing nothing" whereas the US is liable for the huge failing investment it made. US economical growth is now entirely reliant on AI, so an AI crash guarantees immediate recession and out-of-control stagflation. The EU with its "less advanced" economy will keep growing just fine with or without AI, surviving the front-line bloodbath by staying behind.

As for defense, they are spending exactly as much as necessary at each point in time: just enough to keep credible US backing until 2025, and as much as they can without destroying their economy since. There is no good argument for an irresponsible spending spree, as the only powers that can realistically challenge the EU without triggering nuclear holocaust are the US and China anyways (Russia don't stand a chance).

Is that a moon? No, that's your survivorship bias!

Jokes aside, congratulations on slipping and falling up the summit, collecting not a single bruise to your ego or soul along the way. I am genuinely happy for you.

> If a company is so broken that promotions are decided based on factually incorrect information, there's nothing to do other than escape to a different company.

To me, this means that every traditionally run company (top-down) must be broken by construction. And indeed, I have never seen or heard of truly fact-based management.

The entire challenge with multi-level management is that you always play a long game of telephone with increasingly less technical people, which are unable (due to lack of time and understanding) to grasp the ground-truth facts without simplification. Thus, management based on hard facts is impossible in this setting, though it is a great theoretical ideal many aspire to.

In practice, doing so is very hard and people are lazy, so the "facts" can become so twisted as to be entirely unrecognizable.

> One of the reasons companies get dysfunctional is low- & mid-tier managers seem to be allergic to the idea of laying out what the priorities are and provide feedback on whether people are working on them or not.

Have you considered the possibility this is not a result of incompetence, but intentional? If these things are never clearly communicated and, more importantly, put in writing, management can just reframe what was agreed upon as best suits them later to deflect any blame if things go sideways. This is a perfectly rational move, since they hold all the power to do so.

I think a lot of what is wrong with this discussion is that people implicitly assume management is honest and communicates openly and sincerely. This is sadly only true in a small fraction of cases, likely because the incentives point squarely in the opposite direction: those who judge the game are always better off cheating.

exactly. my last job the project i was working on suddenly became "my project" where manager wanted to "give me a win" by shipping. it became my project when we discovered all the way in the end that what he had come up with isn't viable at all. thing i was telling from the get go but he didn't listen and adamant that it would be fine.

we even had it in writing the i had objected to his scheme and that he overrode it but that document was completely hidden from upper managment.

As with all forms of verbal abuse, the presence of a power imbalance is paramount. And since we abolished slavery, it is about as high as it gets here.

What an employee says about their boss generally has zero implications on their career and lives, so long as it does not outright accuse them of a crime. When's the last time someone called you to provide a reference on your boss? I thought so.

In turn, what a boss says about their employees can be entirely career-ending and therefore life-altering, even if said in jest or later retracted. A higher standard exists precisely because the stakes are so much higher.

> Open source handles conflict by forking. I wouldn’t call that good coordination.

Forking is far from the first step in conflict resolution; it is the ultima ratio between projects in the open-source world, when all dialogue breaks down. In other words, the worst outcome is that people agree to disagree and go their separate ways, which is arguably as good a solution as is possible.

In the corporate world, coordination mostly exists within companies through top-down decision-making, as you said. Between them, however, things look much grimmer. Legal action is often taken lightly, and more often than not, a core business goal is to not just dominate, but to annihilate the competition by driving them out of business.

Coordination between corporations, such as through consortia, is only ever found if everyone involved stands to profit significantly and risks are low. And ironically, when it does happen, it often takes the form of shared development of an open-source project, to eliminate the perceived risk of being shafted.

> Forking is far from the first step in conflict resolution; it is the ultima ratio between projects in the open-source world, when all dialogue breaks down.

You also do a fork if you simply want to try out some rather experimental changes. In the end, this fork can get merged into the mainstream version, stay independent, or become abandoned. People wanting to try out new things has barely anything to do with all dialogue breaking down.

You may also fork from having different goals or ideas about some mutually incompatible requirements without an communication or coordination issues. Friendly forks happen all the time.

Right. In this case I am talking about a "hard" fork, where core contributors disagree on where a project is headed and split up with no intention of collaborating further. Of course, forking with the intent of merging back contributions does not apply here, as is a cooperative and coordinated process. In that case, the "fork" really only serves as a staging ground for contributions.

There is more to choosing a job than money. No engineer likes being managed by incompetent assholes, and the best engineers also get to choose the best managers. And the bar for those is, sadly, quite low.