Indeed, one of my favourite things about coding assistants is that I can now get an easy code review on my personal projects, or once I've thought through my approach have it think up alternatives I may not have stumbled on.
I've found it very unsatisfactory (both experience and results) to use them to replace code production. But in terms of augmenting the process - used to critique, explore alternatives, surface information - they're getting really quite handy.
It feels like reputation / identity are about to become far more critical in determining whether your contribution, of whatever form, even gets considered.
Unsure if you were getting at this too, but software development in the UK can absolutely be ineligible for R&D tax credits yet still require treatment as capital expenditure for tax purposes (and thus not simply fully deductible in year 1 like revenue expenditure) - see [0] from the AAT on this.
Disclaimer: Not an accountant, not your accountant, get professional advice.
I won't try and read into whether or not there's ageism anywhere in the tweet stream, but certainly when talking about hiring the magic words are "find experienced engineers to run it". This is very much legal and ethical in the UK - we're not precluded from setting an experience-based hiring bar. I'm sure if a 25 year old had come along with two browsers under their belt they'd gladly have been hired into a leadership role too.
In all fairness on that last point, if you're referring to his "Gitote" project, the author has stated here [0] that it was a fork of Gogs, and seems to have retained the proper copyright notices in the source files:
"// Copyright 2015 - Present, The Gogs Authors. All rights reserved.
// Copyright 2018 - Present, Gitote. All rights reserved." [1]
I agree it should probably have been given more prominent mention, but given the number of commits doesn't seem (at quick glance) to be a hasty "fork and rename".
I think there'd be two big issues - (1) what is reasonable behaviour when you reach your budget, and (2) the consistency of billing.
On (1), if you get to say the 14th of the month and run out of budget, what would be the expected behaviour? - shut down all your services? delete all your data so that's not incurring a charge too? It'd probably have to be configurable on a service by service basis, and that's an awful lot of complexity to introduce for a tiny minority of their revenue base.
On (2), their billing systems are almost certainly eventually consistent in logging and charging usage, so they'd either have to shut you down early in anticipation of delayed charges, or let any delayed charges bring you over budget. Either is liable to make customers fairly unhappy one way or the other.
The TL;DR version - it'd be nigh on impossible to have good UX with such a feature, would be complicated to implement, and it's not likely to move the needle on any metric they really care about considerably.