Hacker Newsnew | past | comments | ask | show | jobs | submit | solatic's commentslogin

Azure's management APIs break connections coming from outside Azure's network every time they use DNS to execute a blue/green swap on their public load balancers. Existing connections are not gracefully drained. Terraform state gets corrupted (it thinks the operation failed when it actually succeeded and the resource was actually created) and requires manual fixing.

This happened frequently enough at large enough scale we seriously considered building an automation to attempt to analyze the Terraform logs for the connection breaking and automatically import the created resource.

Azure support was completely worthless.


I have no doubt that this approach works better than recurring meetings, but I do want to point out the trade-off, which is that this approach requires much more management attention and energy to keep their finger on the pulse and ensure all concerns are handled, compared to their time management being on autopilot with recurring meetings.

So it's a bit of a tautology. Managers who manage time better are more effective. Who knew?


I’d also give some pushback based on scheduling: fixed meetings are a known quantity people can schedule around.

For coders and people with lives, knowing what their week looks like is critical to planning and stress management (ie in X work hours topic Y will be landed, I have X - 2 hours to have my facts in line; daily 9:15 meeting ends at 9:30, everything after 9:30 is a predictable block I manage).

Now, to the issues and whattabout’s that implies:

1) bruuuuutal meeting discipline: off topic gets killed, new topics insta-popped onto next agenda, scripts of expected responses prepared and shared (“we are green, need approval by X”). Stand if ya gotta, chess-clock if ya gotta, bring in a non-teammate for secretary duties as needed. Meetings are not gab sessions.

2) if that agenda isn’t lava hot with everyone actively getting something, W-O-W, end the meeting. Split off, 1-on-1, task-group it. Fixed project meetings are to make manager-me not have to chase anyone or anything, we are racing to get that done ASAP and the second we’re done it’s time to get the fu… <ahem> grab a coffee, and return to the activities everyone is being paid for. Gab sessions naturally follow, as needed, dynamically adapting to needs and pressures.

Managers who manage meetings manage to meet without meetings managing them. Manage time or time will manage you. The real MBA was the one inside you the entire time.


This sounds horrible to me.

I think it seems tautological to us because it's obvious to us. But other people do not understand or care to understand or even care to think about it. You can see it in this very comment section that there are people swearing how amazingly helpful fixed standups supposedly are even on a whole org level. It's obviously absurd but they have different jobs and priorities, they don't have to understand the inner workings of the product and for them it's invisible that the meetings are almost entirely worthless for the actual workers. The meetings are helping them in their job and so it must be great for the org, that's how many people managers think.

I’ve been on both sides of this. Engineers who complain loudest about the waste of time from too many meetings will also complain the loudest about how they feel disconnected from the decisions and from the product IME.

Decisions rarely need to be made on-the-spot in synchronous meetings. You can have asynchronous approaches with shared documents and RFC processes, where you make everything available if people want to contribute to areas that they find interesting. This does not, of course, mean that decisions need to be made by committee, and people who provide feedback should understand that getting the privilege to provide input does not mean that they also get a veto.

It's quite rare to find companies that do this for the same reason it's quite rare to find companies willing to "do agile correctly" and really scope out work before sprints and not put additional work in the middle of a sprint. It takes too much effort and gives up too much flexibility for most managers to make the investment and see if it pays off.


> only a concern if you're charging money

No, it's a concern if you care about impact. Improving commercial profits is one kind of impact that is relevant to for-profit corporations, but there is also impact like "improving user privacy" or "helping lower-income people manage their finances with a free-as-in-beer product". This impact can be measured and the feedback can be used to improve the product according to non-profit, non-commercial goals.

There are also people who build open-source software as a hobby and couldn't give two shits whether other people use it or not. More power to them. For those people, you are correct. https://book.iced.rs/philosophy.html comes to mind.

Then there are projects like Streisand (maybe a bad example, I see it has since been archived, but it came to mind) that want to change the world in some way. Those projects very much do need to care about metrics like, how many people are downloading the software, are people opening GitHub issues, are we obscure or is our target audience talking about us, hopefully positively but if not, how can we improve that? Value must always be worth the cost (even when the code is free, it must be worth the time to download, give it a try, give it CPU/RAM, maintain/upgrade the installation) - are we giving users value or are they churning?

It might blow your mind but even non-profits hire people with MBAs (and universities offer programs for MBAs that focus on non-profit management), precisely because some organizations focus on non-financial impact.


> Even if you RAID them, there's not a good way to move that VM to another host if there's a RAM or CPU or other hardware issue on that host.

This is the critical point. All hardware fails eventually. The CPU and RAM are, in a real sense, also ephemeral. The only relevant question is what the risk tolerance of the use-case is. If restoring from async backup is sufficient, then embrace ephemerality and keep backups. If you need round-the-clock availability, pick an architecture that lets you fall over gracefully to another machine, and embrace the ephemerality when you inevitably need to do so.


Quite the opposite: retirees will flee to low cost of living areas, taking the money that they spend in other sectors (food, health, entertainment, etc.) elsewhere.

There's multiple tools that generate architecture diagrams from text/code (Mermaid, LikeC4...). You start using one and tell the model to generate the text for the architecture diagram and it'll do it. Stuff like https://erode.dev tries to use LLMs to keep it in sync.

Spec-mode in the Kiro IDE generates requirements and design docs for a feature; the design always contains one or more Mermaid diagrams of the arch in the feature.

Considering that people expect literally the same thing, I can understand how even small regional differences can seem extreme. Like not finding any beef on the menu in India, or any bacon in the Middle East.

Your point isn't contrary to LLMs or LLM-powered robotics. LLMs have access to the entire human corpus, including documented regional specializations, as you describe. The LLM knows via sensors where it is and what local conditions are. The LLM could even hypothetically conduct experiments to try to find further hyper-local specializations, instead of just relying on monocrop agriculture.

It all depends on the agent harness and the system prompts.


> "post capitalist society" was the recognition that capital ceased being the primary factor of production. No matter how much capital you throw at a problem, if you can't retain people that know what you're doing, you won't get far.

This leads to the reformulation of knowledge workers as "human capital", and it's hardly post-capitalist. A capitalist society is one where people assemble different forms of capital to produce capital returns that are larger than the sum of the capital inputs, where the possibilities available to you depend on the amount and quality of capital that you have access to. This is all still very relevant when discussing human capital - access to human capital is determined by the quality of your professional networks, whether you decide to be present in geographic talent clusters (i.e. cities as centers of industry), and whether you have sufficient financial capital available in trade.

AI will not transition us to a post-capitalist society. Its promise is solely the ability to replace human capital with other forms: chips and electricity. It does not spell the death of human labor any more than computers and spreadsheets did for accountants.


Well it is 'post-capitalism' rather than 'anti-capitalism' or 'non-capitalism' the same way 'post-punk' relates to 'punk'. Human capital is something of a conceptual misnomer as the knowledge itself is owned by the individual and can only be licensed or contracted by investors and management, not traded on capital markets.

> A capitalist society is one where people assemble different forms of capital to produce capital returns that are larger than the sum of the capital inputs, where the possibilities available to you depend on the amount and quality of capital that you have access to.

The reason we live in post-capitalism is that capital is largely abundant these days, although many regional and cultural barriers remain due to bias, prejudice and risk aversion. But is no longer the determining factor of economic growth - necessary but not sufficient.

> This is all still very relevant when discussing human capital - access to human capital is determined by the quality of your professional networks, whether you decide to be present in geographic talent clusters (i.e. cities as centers of industry), and whether you have sufficient financial capital available in trade.

I feel this is a stretch. In a non-capitalist economic system, for example, the wealth of the collective is arguably also bounded by the scarcity of knowledge in that collective. Knowledge does not have the same properties of capital accumulation that Marx described.

> AI will not transition us to a post-capitalist society. Its promise is solely the ability to replace human capital with other forms: chips and electricity. It does not spell the death of human labor any more than computers and spreadsheets did for accountants.

Spoken like someone who didn't even read my parent comment. We are already living in a post-capitalist society, and have been for several decades.

"Chips and electricity" is reductio ad absurdum, and ignores a vast number of other input factors. AI will not eliminate labor or human capital, that's just marketing. It certainly will transform it as other tools have.


Most commenters here: "Mythos is powerful because you can point it at a whole codebase, if you point the smaller models at a whole codebase and iterate through small sections of code, you'll get too many false-positives to handle."

This misses the point entirely. You pay $20k as a one-time fee to establish a baseline. Your codebase develops one PR at a time, which... updates isolated sections of code. Which means you don't need Mythos for a PR, just small, open-weight models. Maybe you run Mythos once a year to ensure that you keep your baseline updated and reduce the risk that the open-weights models missed anything.

Seeing this as anything but a huge win for open-weights models and a huge loss for Anthropic misses the point entirely. Mythos isn't something you can persuade Fortune 500 companies to spend $20k/day or even $20k/week to spend on, like they were hoping for. $20k/year is a lot less valuable, and it won't justify development costs or Anthropic's growth multiple.


Consider applying for YC's Summer 2026 batch! Applications are open till May 4

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: