I agree with the one of the author's points: Running tests pre-commit is the answer.<p>What I don't see is how this translates to getting rid of git and Jenkins.<p>It seems that (1) setting up a command/script to run the test locally and (2) having CI run this command/script and nothing else will be enough to fix all of the author's problems.
Additionally, I can imagine nice IDE integration that continuously runs the tests in the background and indicates if the code is ready to be committed or not.<p>Of course we'd still need git for code history/code review; and CI, just in case someone does changes without using IDE.<p>(Also, I'd like to comment on this phrase: "How often have you or a coworker pushed an empty commit to "re-trigger" the CI?" -- dude, your tests are broken. The CI is not supposed to be flaky. Fix your tests, or if you cannot do this, add a "retry" block to your Jenkinsfile. And if you don't want to do this, at least give developers permission to re-run failed jobs, so they don't have to keep pushing empty commits!)
Sounds like a conversation starter on where Microsoft is going with Github live code editing and whether or not we are going to play along.<p>Looking at all the other "massively crazy stupid" ideas that are the norm today (eg managed databases on someone else's servers), live coding (in the cloud) with a form of CI as hinted in this articles does sound far fetched at all.<p>I'm pretty sure MS is already working on that and will be releasing something along those lines in the next year or two.<p>If they do that, I can't think of any software related aspect that MS will not be in complete control of. From writing the code to getting it to end users, their ecosystem controls every aspect.