Let me fire these actual workers doing real work with the hope that $magic_upcoming_tech will hold the ship.
Great plan
Great plan
If anyone is convinced of the tech it's them.
Cutting headcount is a consequence of cuts which is a consequence of priorities, legal, under performance, politics, etc. The very idea that some idiot has the power within the org to just sack developers because they have misunderstood how generative AI works is..... oh wait, that is extremely realistic because humans are very stupid. But also I would suggest it is not indicative of any sort of incoming trend and its unlikely to be best practice.
Capital being spent on GitHub to develop it could be used elsewhere or banked as profit if you had a smaller team.
GitHub isn't in a position that it's market dominance will be threatened by a slower pace of development.
You're also talking in absolutes, GitHub says there's a 40% productivity boost from using ai. Assuming (simplistically) that this results in a 40% required headcount reduction for the same output, you can then see:
0% headcount reduction, 40% improvement in velocity
40% headcount reduction, 0% improvement in velocity
Scale these two factors mentally to see that it's not all or nothing, maybe they've gone 20/20 and so some people still get to keep their jobs.
That is their own marketing bumpfh and idk if any org should dog-food sales copy as strategy.
I am saying that cutting development teams by 40% on the wonky maths that generative AI makes developers 40% more "developery" won't be best-practice. I don't think its a leap before you look job and I don't think the toolsets and practices are mature enough to bank that 40%, at least, not yet. Therefore I think the slashing of the engineering team in India is not related to AI but rather budget or political or smth else.
I guess at the executive level its about whether you think you can increase sales with more R&D or whether you have entirely saturated your market or organisational capacity. Still, I would argue that mindlessly cost cutting is more the domain of the post-IPO, than that of the entrepreneur.
It's funny how even various "must haves" from the start of the project get cut, other things sneak in.
The back log grows and grows.
On the other side: if we increase productivity by say 3x, will we cut the backlog or will it grow 3x faster ?
I think we would, at least have a much better chance of exceeding our MVPs from the start of the project.
The reality is programming is a form of automation. The world's thirst for automation is insatiable. I don't think programming will always exist, but think of it this way: when you eliminate them, you automate automation. We've never been in a scenario like that, and it would be quite the thing to behold.
Think of it a bit like high frequency trading, but without the regulation or the barrier to entry. Sounds "great."
This assumes the company is making sound decisions. I see companies prioritise new sales over features that would make the software more usable and effective in existing deployments. This prioritisation of immediate cash flow makes it much harder for the organisation to understand why some customers ditch the product later or don't use it enough to knit it into their processes.
It is the perennial enterprise question as to whose needs are more important? The features the CEOs/CTOs of new customers ask for, or the productivity features the users of the products ask for.
In other cases operational efficiency can be easily backlogged just because its harder to perceive. I've seen specialists and consultants be required for installation and setup because key features required for ease of deployment and use are never prioritised. Its easier budgetarily to just write a bit of python to paper over some cracks than get the required features into the core product but this just broadens the code base and arguably increases the liability. Later, managers might hand-wring about why its so expensive to deploy and maintain without ever being able to prioritise the relevant tickets to address those issues.
1. Independently pick work. 2. QA it, sort out code reviews and then finally add them to the release cycle. 3. Write documentation or write change logs for it.
While all of this can be automated, there would need to be manual verification at some point (to fix broken tests or update configuration values) and that would require an engineer who is aware of the involved domain. And to adjust for vacations, sickness and other events, multiple engineers would be needed. All of whom need to have experience working with that area of the codebase, for which hands-on experience would be hard to gain, since the models are doing most of the grunt work. And at this point the company would be paying for both the engineers and the operational cost of running those models.
The operational cost is many times smaller than that of an engineer, and with proper loops it can work tirelessly.