Don't you need something like a network clock to get deterministic replay?

It can't use immediate return on replay, or else the order will change.

This makes me twitchy. The dependencies should be better modelled, and idempotency used instead of logging and caching.

I regularly have tool-generated commits. I send them out with a reference to the tool, what the process is, how much it's been reviewed and what the expectation is of the reviewer.

Otherwise, they all assume "human authored" and "human sponsored". Reviewers will then send comments (instead of proposing the fix themselves). When you're wrangling several hundred changes, that becomes unworkable.

Consider - it's a voip dialing client which has a requirement to provide location for E911 support.

If the OS vendor starts providing invalid data, it's the OS vendor which ends up being liable for the person's death.

e.g. https://www.cnet.com/home/internet/texas-sues-vonage-over-91...

which is from 2005, but gives you an idea of the liability involved.

The group used feature flags...

    if (a) {
       // new code
    } else {
       // old code
    }

    void testOff() {
       disableFlag(a);
       // test it still works
    }
    
    void testOn() {
        enableFlag(a);
        // test it still works
    }

I can do one flag in ~3minutes. Code edit, pr prepped and sent.

The AI can do one in 10mins, but I couldn't look away. It kept trying to use find/grep to search through a huge repo to find symbols (instead of the MCP service).

Then it ignored instructions and didn't clean up one or the other test, left unused fields or parameters and generally made a mess.

Finally, I needed to review and fix the results, taking another 3-5 minutes, with no guarantee that it compiled.

At that point, a task that takes me 3 minutes has taken me 15.

Sure, it made code changes, and felt "cool", but it cost the company 5x the cost of not using the AI (before considering the token cost).

Even worse, the CI/CD system couldn't keep up the my individual velocity of cleaning these up, using an automated tool? Yeah, not going to be pleasant.

However, I need to try again, everyone's saying there was a step change in December.

Even just taking fault incidence rates, assuming constant injection per dev hour...

open a terminal (OSX/Linux) and type:

    man dup

    man dup

To get recursive, you can try:

    man man unix

There is an "acceptable" fraud rate from a payment processor. This explains why there are different rates for "card present" and "card not present" transactions, and why things like Apple Pay and Google Pay are popular with merchants.

If the system is configured to "fail open", and it's something validating access (say anti-fraud), then the DoS becomes a fraud hole and profitable to exploit. Once discovered, this runs away _really_ quickly.

Treating DoS as affecting availability converts the issue into a "do I want to spend $X from a shakedown, or $Y to avoid being shaken down in the first place?"

Then, "what happens when people find out I pay out on shakedowns?"

USD$200k is 3 engineers in New Zealand.

https://www.levels.fyi/t/software-engineer/locations/new-zea...

Having separate teams makes it adversarial because both orgs end up reporting into separate hierarchies with independent goals.

Think about the metrics each team is measured on. Who resolves conflicts between them? How high up the org chart is it necessary to go to resolve the conflict? Can one team make different tradeoffs on code quality vs speed from another, or is it company-wide?

I see a difference between a more definite operations team (SRE) vs an engineering team having responsibility for how their service works in production (DevOps).

DevOps is something that all teams should be doing - there's no point in writing code that spends it's life generating problems for customers or other teams, and having the problems arrive at the owners results in them being properly prioritized.

In smaller orgs, DevOps and SRE might be together, but it should still be a rotation instead of a fulltime role, and everyone should be doing it.

Engineers who don't do devops write code that looks like:

  if (should_never_happen) {
    log.error("owner=wombat@example.com it happened again");
  }

Too many alarms or alarms at unsocial hours? The engineering team should feel that pain.

Too hard to push? The engineering team should feel that pain.

Strange hard to diagnose alarms? Yep, the engineering team should feel that pain!

The feedback is very important to keeping the opex costs under control.

However, I think the author and I have different opinions on what DevOps is. DevOps isn't a full time role. It's what the engineer does to get their software into production.

Not sure about expected loss, that's a decay rate?

But stuck jobs are via tasks being processed and average latency.

Does using a llm help avoid the cost of training a more specific model?

1) Take the medicaid data.

2) Join that with rental/income data.

3) Look for neighborhoods with cheap rents/low income and low medicaid rates.

Dragnet those neighborhoods.