Google Research: Themes from 2021 and Beyond
ai.googleblog.com
ai.googleblog.com
The fact that numerous institutions related to AI becoming too powerful exist indicates that there is some part of our capability to progress the state of science that terrifies us. But we don't apply that same type of fear to places like technological addiction that have a significant potential to alter the behavior and development of future human generations.
That's what OP meant. Those logic are defined by business and then translated to implementation logic by dev.
Today there are many situations where one can remove outsourced dev shops, if business themselves can implement the logic that is there in their head. Lowest hanging fruits are perhaps internal IT Tools and workflows.
In my experience business people have a hard time defining logic to the level of granularity that a developer requires.
Even if it's simply a matter of wiring things up, you'd essentially require the developer mindset / training to understand how to wire everything up to accomplish the business objective.
Not to mention knowing exactly what tools to do this in and ensuring any new systems can talk with older ones etc.
Developer jobs aren't going anywhere, it may get quicker to accomplish a task but you're still going to need people who understand the finer details and are able to take a human requirement and break it down and wire things up.
I've converted a few access databases in my day which were surprisingly sophisticated yet the lack of rigor was very transparent. There were good reasons they needed to transition to software written by a developer.
IMO your idea is "a dev shop will write lots of paragraphs in such a way they can be fitted together by an illiterate person using config"
I think putting it that way highlights the problems
Edit: another way to look at it is that managers "design" a company with policies and hiring etc. When a company is "software mediated" then the management is now one step removed from reality of the design of the company - the code is the design and the coders are the new managers
Before software you were hiring people to follow your written policies and your occasional orders as policy did not meet reality. Now with software mediated companies, you are hiring people to write the actual policies - and as you do not / cannot be specific enough except in code the actual design is done for the managers - in short management moves to be either the coders or the managers are investors. Either way the "management" work becomes that of coders.
And management this means writing code. Don't write code? not a manager. you can be an investor, a visionary, an accountant and budget holder. All fine. but not actually an executive
Rules and policies are quite intricately thought through and they get refined as and when 'bugs' or 'holes' are detected (to the detriment of work culture - yet another condition for buying paperclips).
It is often software implementation which does not take care of all ifs and buts, as nobody has patience to write a detailed specs. Most often software tools addresses only frequent cases; when it comes to outliers and exceptions one defaults to 'manual methods' (emails, meetings, face to face talks, etc).
Software implementations can be way behind when trying to keep pace with system intricacies that human minds can conjure up.
The fact that most IT systems are behind is just saying most companies are not software mediated enough, yet. And all the robot automation and so on happening across all companies is a recognition that there needs to be deeper mediation - the implications may not be well thought through but the more a companies processes and decisions are made explicit in software the more change will be forced
As an example just think of volkswagen - someone had to explicitly code up "lie on the exhaust emissions test". if that is not raising / surfacing all explicit rules and assumptions i don't know what is !
"programming" is to "business logic" like "spelling" is to "writing novels".
You don't get to be a Dostoevsky by being very good at spelling. Being able to tell good stories is much more important than spelling.
You don't get everyone to be a good author by providing them with a tape recorder so they don't have to spell.
Programmers are very good at thinking in logic. Programmming languages are just a detail in this.
Programming is the ability to formulate what the rules should be exactly.
Most (business) people are not able to be that precise no matter the tools you provide them.
It sounds very similar to views expressed throughout history saying why the majority of people could not be taught to read write or add up (variously women, girls, poor people, blacks, slaves, Barbarians etc etc.
Turns out all we needed was schools and paper
The grandparent has it backwards, if I understand correctly. "Business logic" is to "programming" as "My first spelling book" is to Dostoevsky.
You can write the analog of a memo easily in Excel, or with great effort you could write a sixty page paper, but programmers these days work in teams to produce things that are the writing equivalent of a coherent blend of the Encyclopedia Brittanica, the tax records of 18th-century England, and an epic story 100 times the size of The Lord Of The Rings. And we need bigger systems than that.
That "everyone" (let's say everyone in a white collar job) can use Excel today is true. And yes it is possible to "program" in excel.
But that's in the "small". And I think you are saying that we don't have the programming ecosystem to support large scale development.
I think I agree. But we have to raise the floor of programming literacy a lot beyond "white collar excel".
But having said all that, I am dubious that we lack the principles of coding to be able to enable massive software projects - I think we lack the organisational (incentives / understanding / will) to do so.
We can imagine a mid sized company that is OSS based, avoids proprietary lock in of its data.
I imagine 2 advanced crafts, Design Engineering (UI), and Systems Engineering (distributed, low level, cloud native, and… data).
Everything in between (full stack, APIS, req/res handling, DB integration, data processing, etc) can all be automated efficiently.
Those previous two areas seem to continuously evolve, while APIs and their integration are pretty straight forward and have been for a long time.
I believe AI to be the reason why those two can’t be automated, coincidentally. AI applications require new architectures, AIUX, advanced UI metrics, etc.
It's going to be a while before an AI can take part in a meeting between 2 project managers wrangle out a spec that makes everyone happy and then negotiate with the rest of the team to make the changes necessary.
It's going to be even longer before the AI can figure out why the site is down and bring it back up. And then figure out how to prevent the outage.
Besides that AI isn’t that intelligent yet. Training on all the jQuery code won’t yet give you an AI that can write React.
If AI writes code then now the systems become exponentially more complex exponentially faster . Unless this AI is truly human or super human it won’t keep up. If we have human level AI then coding jobs are the least of our concerns .
If AI genuinely took over coding then languages would become obsolete. The most basic turing complete language, probably some sort of RISC assembly, would be all that would ever be needed.
But when will we get there? A decade ago it seemed like fully autonomous self driving vehicles were just around the corner. Now? Well that corner seems a lot further away than it did then, simply because the problems getting from 99% to 100% are proving quite resilient. Sigmoid curves look exponential on the way up...
Whenever people say stuff like this, I just think - how are all those chat bots working out? How useful do you find Siri?
Honestly, if we can't even get siri to be able to answer simple questions without telling you she'll google it for you, how on earth do you expect developers to be made redundant in 5-10 years?!
The most obvious is BigQuery, Palantir, Snowflake, etc. So many data pipelines that currently need 10+ teams of engineers to work on will be done through SparkSQL and SparkML by 1 or 2 teams of Data Engineers (i.e. no distributed systems knowledge) instead. It’s not there yet, but dealing (in an asynchronous context) with data at scale is very close to getting commoditized.
Fortunately, UI applications (synchronous, latency sensitive applications, modeling data input from the real world, making things pretty/unique) will likely always need people to write something kinda like code lol. However, I feel like they will likely have classes/experience with HCI/design, product management/MBAs, in the long-long run probably with law/accounting/medicine/architecture/etc.
That said, there is just so much of the real world that needs to be better modeled digitally that everyone that learns coding-like skills will continue to be highly employable. At least, until the singularity. Then all bets are off.
For anything overtly complex (actual data parsing challenges) they usually consult with a data scientist on a team.
I’m constantly reviewing data engineering resume and am wondering “what exactly is this person going to be doing if it isn’t some outdated architecture and o&m work …. Why would we hire this person vs a cloud native software engineer who costs x2 less” etc
I can see the tools being made to make lots of automation and connection of tools possible without understanding code, but there will always be people who have to understand it all.
This really grabbed my attention - I fear big tech is pushing American morals down the throat of the rest of the world. This is great that they’re noticing this and trying to correct for it!
That said, with morals being so different from one location on the planet to the other, it's worth wondering how Google will train its "AI."
Will it pick the least restrictive set, the most restrictive set, or some kind of hodge podge? (For varying definitions of "restrictive.")
My money's on a hodge podge that doesn't make anyone happy.
My guess is on whichever makes them the most money; seems a pretty safe bet to me.
You are absolutely right that for Google to serve everyone, training an AI to do so is a massive challenge. My bet is that they will train several AI and deploy them in broad domains, which is someone equivalent to how they currently operate heuristics that vary from country to country (such as the borders in Maps changing depending on where the request originates). Google seems to tend to like this approach because they think they get the best of both worlds: they satisfy the geocentric power-brokers by saying "See, we have done the right thing by you, when your people make requests they see X," while at the same time knowing that location is a bit of a fantasy online and the sufficiently savvy can get answers from other locations by causing the question to seem to originate from elsewhere in the Internet (i.e. VPN-proxying).
I am aware of https://fuchsia.dev/, but it seems to only target handheld devices, which already use the most broken of security models, the dreaded "yes/no" access to location, photos, etc.
I'm looking for a desktop daily driver that supports fine grained capabilities.
Kyle Evans with an excellent reminder that by default, our mind is optimizing for delivery of projects (features). Products also have unique traits that projects don't encapsulate well: SLA, measurement of success, observability, roadmap, clear long-term ownership, and more: "While project thinking focuses on coming up with solutions up-front and then delivering against a schedule, product thinking keeps the focus on the outcome. That involves some level of comfort with uncertainty and learning, which can be pretty hard. But if we want to get to the right outcome, and not just an on-time output, it is really the only way to work."