There is a single standard committee though. There is really nothing stopping them from shipping tooling that can do the conversions for people. The number of vendors isn't really the problem here. The problem is that the committee shifts that responsibility onto the vendors of the compiler rather than owning it themselves.
There is an alternative way make the necessary point here.. Let it go through with comments to the effect that you can not attest to the quality or efficacy of the code and let the organization suffer the consequences of this foray into LLM usage. If they can't use these tools responsibly and are unwilling to listen to the people who can, then they deserve to hit the inevitable quality wall Where endless passes through the AI still can't deliver working software and their token budget goes through the ceiling attempting to make it work.
I am absolutely certain the world isn't just. I'm also absolutely certain the world can't get just unless you let people suffer consequences for their decisions. It's the only way people can world.
IME that simply doesn't work in professional environments. People will either misrepresent the failure as a success or find someone else to pin the blame on. Others won't bother taking the time to understand what actually happened because they're too busy and often simply don't care. And if it's nominally your responsibility to keep something up, running, and stable then you're a very likely scapegoat if it fails. Which is probably why people are throwing stuff that doesn't work at you in the first place. Trying to solve the problem through politics is highly unlikely to work because if you were any good at politics you wouldn't have been in that situation in the first place.
I understand how people can get into these fatalist outlooks from experience. I just refuse to lock myself into them. And because I've refused to do so, every once in a while I have success and make the work environment just that little bit better. So I'll keep doing it.
So what you are a saying is that you removed the people who can make the decisions that keep your software maintainable and kept the people who will slowly over time cause your software to become less maintainable? I'm not sure that tradeoff is a a good one.
I'm every bit as immersed in this as you are. I've been developing my own custom claude code plugins that allow me to delegate more and more the agents. But the one thing the agent is not reliably doing for me is making sound architectural choices and maintaining long term business context and how it intersects with those architectural choices.
I tried teaching all of that in system prompts and documentation and it blows the context window to an unusable size. As such the things that as a high level experienced senior engineer I have been expected to do pre-agents I am still expected to do.
If you are eliminating those people from your business then I don't know that I can ever trust the software your company produces and thus how I could ever trust you.
I'd try a different approach - mechanical engineering isn't that hard and it can benefit greatly from developing some specialized agents and fine-tuned LLMs for it. As a side benefit, that approach happens to create some software jobs too, open source for best results.
> making sound architectural choices and maintaining long term business context and how it intersects with those architectural choices.
I completely agree with you, but this is rapidly becoming less and less the case, and would not at all surprise me if even by the end of this year its just barely relevant anymore.
> If you are eliminating those people from your business then I don't know that I can ever trust the software your company produces and thus how I could ever trust you.
I mean thats totally fine, but do realize many common load bearing enterprise and consumer software products are a tower of legacy tech debt and junior engineers writing terrible abstractions. I don't think this "well how am I going to trust you" from (probably rightfully) concerned senior SWEs is going to change anything.
s
"Im not even sure we will need maintain software" (sic) - I'm not sure what your specific background is, but with a statement like that you lose all legitimacy to me.
Yes, I'd like to hear more of their background, because they seem very naive about writing software, adding to it, testing it, etc.
You can't just whip up a replacement for salesforce using claude code. Who's going to fix the bugs, who is going to have tests, manage performance testing? People will still pay for software that is tested and performant. I could get a replacement for an online spreadsheet, google docs like thing. Suppose you tell it to copy the google docs or whatever programming language. You won't know if it's buggy because you won't haev the same test coverage. You'll never know about bugs that took a long time to reveal in some combination of features.
You can create a new system with a few features together to do something. Again, not tested, not perf tested, isn't away of a compiler bug you had to work around.
But lots of simple things can be claude coded and replaced. Say something that took a photo of a person, centered it, then say put some kind of log on the pic. Something you paid $5 a month to do.
Writings on the wall, it is true, tech debt will no longer be a thing to care about.
"but who will maintain it?" massive massive question, rapidly becoming completely irrelevant
"but who will review it?" humans sure, with the assistance of ai, writing is also on the wall: AI will soon become more adept at code review than any human
I can understand "losing all legitimacy" being a thing, but to me that is an obvious knee jerk reaction to someone who is not quite understanding how this trend curve is going.
Trust me, I’m a well seasoned leathery developer and I’m no newbie when it comes to using AI. But this level of irrational exuberance is so over the top I just can’t take it seriously.
Yes, in the very long term I expect this to be able to replace large swaths of the sw dev lifecycle, product, ideation, the whole kaboodle. That’s a long way off, whatever “a long way off” means in this accelerated timeline.
For the next bunch of years, yes you’ll have to worry about architecture, coupling, testing, etc. I’m happy to have my competitors share your attitude, cause we’ll smoke them in the market.
And the human downstream of this random reorganization of things at will, how do they manage it?
If its AI agents all the way down its commoditization all the way down, if humans have to deal with it there's some sort of cost for change even if its 0 for code.
OpenAI and quite honestly the others think they are in a race to AGI not the bottom. That's why they aren't concerning themselves with moats or cost. This is quite simply a massive bet that we've already cracked AGI and the rest is just funding the engineering to make it happen.
I personally think we haven't cracked AGI yet but it doesn't change their calculus.
There are a number of features and teamsizes that they provide where you have to pay money. Most company users are going to end up paying them money. But also their emphasis on P2P connections means their costs are quite low. It doesn't add much overhead to have the smallish number of personal users out there. They've talked about how having the free tier helps to force them keep those costs down in useful ways.
You can get deterministic output if just turn the temperature all the way down. The problem is that you usually get really bad results, deterministically. It turns out the randomness helps in finding solutions.
I have almost exactly this in my own caddyfile :-D The order of the items in the regex is a little different but mostly the same items. I just pulled them from my web access logs over time and update it every once in a while.
Git storage is just a merkle tree. It's a technology that's been around forever and was simultaneously chosen by more than one vcs technology around the same time. It's incredibly effective so it makes sense that it would get used.
Not sure if it introduces a tiered experience or not. But reading the article it appears that the Rust devs advocated for an api that is clearer in it's semantics with the tradeoff that now understanding how it interacts with C code requires understanding two APIs. How this shakes out in practice remains to be seen.
That is my understanding from the outside as well. The core question here should, I think, be whether the adoption and spread of clearer semantics via Rust is worth the potential for confusion and misunderstandings at the boundaries between C and Rust. From the article it appears that this specific instance actually resulted in identifying issues in the usage of the C api's here that are geting scrutiny and fixes as a result. That would indicate the introduction of Rust is causing the trend line to go in the correct direction in at least this instance.
That's been largely my experience of RIIR over years of work in numerous contexts: attempting to encode invariants in the type system results in identifying semantic issues. over and over.
edit to add: and I'm not talking about compilation failures so much as design problems. when the meaning of a value is overloaded, or when there's a "you must do Y after X and never before" and then you can't write equivalent code in all cases, and so on. "but what does this mean?" becomes the question to answer.
I think you might be missing the posters point. He agrees with you on nearly every point you are making. He is however expanding on that saying that the problem is something of a self-own by the combination of science, science reporting, and science driven policy. Trust was so thoroughly lowered that there was almost no avoiding an event like Trump/RFK. It can be true that 1. RFK is not qualified and is likely to make things worse. 2. This is partly the responsibility of the establishment for squandering the trust that the public put in them.
