My theory is that there are 4 areas to domain knowledge worth taking about here - there may be more but I like 2*2 matrices
1) explicit internal requirements
- core of how the how the app should work towards achieving your business objectives
- code expresses what should be done and to a pretty large extent, why it should be done
- from business unit requirements - we are building a tool to do “X”
2) implicit internal requirements
- core of how the how the app should work towards achieving your business parameters and constraints
eg profit = selling price - ( total of costs )
- code expresses what should be done but really can’t express why. At best it is in the comments
eg if market is EU then tax = 30% (or some value for a table), AI can see what is being done but rationale is not explicit
3) implicit internal requirements
- core of how the how the app should work towards achieving your business constraints
- code expresses what should be done but really can’t express why. At best it is in the comments
eg if item is “rocket” , shipping = $1m ( we only make rockets in Antarctica and shipping from there is $1m)
4) implicit external requirements
- core of how the how the app should work towards achieving your business constraints
- code expresses what should be done but really can’t express why. At best it is in the comments
eg if item is “rocket” , add a 3 month gating stage to get approval from government to sell the item and do not collect payment till gating approved - AI can see the code but has no idea why it has to be done
These come from partners, regulation, compliance, auditability etc
So, my theory
AI can be good at the explicit stuff trivially (1, 2) but cannot be good at the implicit stuff (3,4)
It might be able to figure out implicit stuff needs to be done but will probably not be able to figure out why it needs to be done and it will definitely not be able to definitively figure out edge cases for when to do it / not do it
As long as you focus on implicit stuff, you will be fine for a little bit
TL;DR - become good and keep being good at being the person who understands the implicit external drivers of software dev
They stop growing a full amount of low value subsistence crops needed to survive and start growing cash crops on some portion or on all of the land. Those cash crops have a higher value.
An example - say you have 4 acres of land and have a family of 4.
In the old world, say you needed one acre per person to grow enough food to the next crop harvest. This would be something like corn or potatoes that can keep. So all your land goes to growing food to survive and you cant make any money.
In the new world, with irrigation, you can do much more - say for the sake of argument, 4 times the crop, in the same space. Now, you only need 1/4 of an acre per person or an acre for everyone. So you grow vegetables that sell for 10 times as much on the 3/4s of land you have that you no longer need to use to survive.
Or even better, you grow high veg on the entire piece of land for income and use the cash to buy your corn and potatoes or whatever as you need them.
Just as all other commercial farmers do across the world.
In other words, solar allows them to become small business owners.
TL;DR version - its about money and business balance sheets, not about technology.
For businesses past a certain size, going to cloud is a decision ALWAYS made by business, not by technology.
From a business perspective, having a "relatively fixed" ongoing cost (which is an operational expense ie OpEx ) even if it is significantly higher than what it would cost to do things with internal buy and build out (which is a capital expense cost ie CapEx), make financial planning, taxes and managing EBITDA much easier.
Note that no one on the business really cares what the tech implications are as long at "tech still sorta runs mostly OK".
It also, via financial wizardry, makes tech cost "much less" on a quarter over quarter and year over year basis.
There are many setups where this is not just not possible. In some cases, doing this is prohibitive because of cost or prohibited by law.
+ for case of cost: lots of very large companies have prod environments that cost big $$$.
Business will not double prod cost for a staging environment mirroring prod. Take an example of any large bank you know. The online banking platform will cost tens if not hundreds of millions of dollars to run. Now consider that the bank will have hundreds of different platforms. It is just not economically feasible.
+ for the case of law: in some sectors, by law, only workers with "need to know" can access data.
Any dev environment data cannot, by law, be a copy of prod. It has to be test data, even anonymization prod data is not allowed in dev/test because of de-anonymization risk.
Given this, consider a platform / app that is multi-tenant (and therefore data driven ) eg a SaaS app in a legally regulated industry such as banking or health care. Or even something like Shopify or GMail for corporate where the app hosts multiple organizations and the org to be used is picked based on data (user login credentials).
The app in this scenario is driven by data parameterization - the client site and content are data driven e.g. when clientXYZ logs on, the site becomes https://clientXYZ.yourAppName.com and all data, config etc are "clientXYZ" specific. And you have hundreds or thousands of clentsAAA through clientZZZ on this platform.
In such a world, dev & test environments can never be matched with prod. Further, the behaviour of the client specific sites could be different even with the same code because data parameters drive app behaviour.
Long story short, mirroring staging and prod is just not feasible in large corporate tech
I like your comment, want to try to expand on it
Comment long but there is a TL;DR at the bottom
My theory is that there are 4 areas to domain knowledge worth taking about here - there may be more but I like 2*2 matrices
1) explicit internal requirements - core of how the how the app should work towards achieving your business objectives - code expresses what should be done and to a pretty large extent, why it should be done - from business unit requirements - we are building a tool to do “X”
2) implicit internal requirements - core of how the how the app should work towards achieving your business parameters and constraints
eg profit = selling price - ( total of costs )
eg if market is EU then tax = 30% (or some value for a table), AI can see what is being done but rationale is not explicit
3) implicit internal requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments
eg if item is “rocket” , shipping = $1m ( we only make rockets in Antarctica and shipping from there is $1m)
4) implicit external requirements - core of how the how the app should work towards achieving your business constraints - code expresses what should be done but really can’t express why. At best it is in the comments
eg if item is “rocket” , add a 3 month gating stage to get approval from government to sell the item and do not collect payment till gating approved - AI can see the code but has no idea why it has to be done
These come from partners, regulation, compliance, auditability etc
So, my theory
AI can be good at the explicit stuff trivially (1, 2) but cannot be good at the implicit stuff (3,4)
It might be able to figure out implicit stuff needs to be done but will probably not be able to figure out why it needs to be done and it will definitely not be able to definitively figure out edge cases for when to do it / not do it
As long as you focus on implicit stuff, you will be fine for a little bit
TL;DR - become good and keep being good at being the person who understands the implicit external drivers of software dev