Or, again more generally:

- implementing security features earlier (DevSecOps)

- implement tracing and metrics/analysis tools earlier, use them to test and debug apps earlier (as opposed to laptop-based solutions)

- building the reliable production model earlier (don't start with a toy model on your laptop if you're gonna end up with an RDS instance in AWS; build the big production thing first, and use it early on)

- add synthetic end-to-end tests early on

The linked article is talking about Shift Left in the context of developing semiconductors, so you can see how it can be applied to anything. Just do the needed thing earlier, in order to iterate faster, improve quality, reduce cost, ship faster.

Yes, it can be applied to anything, but might not pay off with software like it does with semiconductors? Better tests and more static analysis are useful, but teams will often work on making their releases faster and easier, iterating more frequently, and then testing some things in production. We don’t want our software to be too brittle, so it should tolerate more variation in performance.

But with chip design, they can’t iterate that fast and performance is more important, so they are doing more design and testing before the expensive part, using increasingly elaborate simulations.

So aside from automation (which also has tradeoffs), when you shift left, what gets shifted right?

The knowledge needed to do the 'shift-left' tasks. The downside of making your developers take on more tasks that used to be handled by someone further down the chain is they need to know how to do those tasks.

Why can’t you shift the “someone further down the line” left along with the task?

This is interesting. Seems like it would mean something like having QA or infosec pair program with app devs. I'm sure somebody does this and am curious how it works out in practice.