Oracle re-learns an old lesson

Oracle implemented AI for its development teams. The good news is that its development teams are providing changes faster with AI than without. The bad news is that Oracle is not delivering updates to customers faster.

The road to AI for Oracle had some problems. While employees adopted the new tools, Oracle didn't initially share the cost of the tools, which meant that, to employees, each tool was equally "free" -- that is, costless. Once the bills arrived (and worked their way through Oracle's accounts payable system) managers saw the true cost of AI and decided to change their strategy. Now the cost is available to employees, and they can pick the AI engine (Clause, GPT, etc.) and consider the cost.

The bigger lesson for Oracle (and all of us) is that improving efficiency in one part of a system does not necessarily improve overall efficiency. AI helped Oracle's developers, and those developers made changes faster than before. But AI also helped the testing teams, and those testing teams found more problems -- and faster -- than before.

The net effect is that Oracle is running faster but delivering at the same rate. That's a particular problem for Oracle, as their revenues are not as high as desired. Its stock price is declining, and shareholders are collecting pitchforks and torches.

Back in the "good old days" we had a saying: "A fool with a tool is still a fool." That saying still holds. We in the development community are learning how to use AI to be effective. AI is easy to use to be active, but effective is elusive. The latter requires judgement, and good judgement comes from experience.

The journey to effective use of AI will be a long one, filled with mistakes. A complicating factor is the rapid change of AI and the frequent release of new AI engines. The rules for one version of GPT may not hold or be efficient for a later version. New versions and new rules for effective use make it hard to learn them.

Why managers like AI and programmers don't

Managers in general like AI engines. Programmers in general don't. The answer to this inconsistency lies not in technology but in psychology.

There are different psychologies for these two groups (managers and programmers) and I think these divisions are helpful.

For programmers, the reasons for disliking AI are simple.

First and foremost, AI has been advertised as a way to replace programmers (and a lot of other workers). That sets up a conflict between programmers and AI. I won't call programmers Luddites, but if the shoe fits...

Second, AI changes the way we program computers. Programmers, especially those with experience in specific technologies, dislike change.  Changing technologies means not only learning the new technology, but also discarding the (hard-won) knowledge of the older technology. In the 1960s, programmers who had significant experience in assembly language resisted the change to the then-new languages of FORTRAN and COBOL. In the 1970s, programmers with experience in FORTRAN resisted the change to BASIC. In the 1990s, programmers with experience in C resisted the change to C++, and resisted the change from DOS' text-mode programming to Windows' graphical programming.

Third, AI is not deterministic. The results from AI queries (or "prompts") change from one iteration to another. (Not from one AI engine to another, but from one prompt to an AI engine to a later instance of that same prompt to the same AI engine.) This randomness is built into the AI algorithms. Programmers (that is, programmers with any experience prior to AI) are taught that randomness and variation in output is a problem, something to be avoided. Pre-AI programmers strive for precision and repeatability, and AI provides slightly different results each time. For those programmers, AI is "doing it wrong".

One final reason: some organizations are forcing programmers to use AI as part of the job. Managers have established minimum quotas for AI use -- although these seem to be reduced now that the AI engines have raised their prices. Forcing programmers (or anyone) to use new tech generates resentment.

All of these factors -- new tech, loss of old (comfortable) tech, irreproducibility, and management-dictated behaviors are reasons for programmers to hate AI.

Now let's look at the managers, specifically managers of development projects. (The managers that are thinking about replacing their human teams with AI.)

From a manager's point of view, AI is a new and convenient way of getting results. AI engines are quite good at searches and provide actual (and often correct) answers to questions. Before AI, a person had to use a search engine and then examine multiple web pages that probably held the answer but often had longer discussions and sometimes were "near misses" for the search. AI provides answers that are accurate and no extra effort is required.

Another benefit is the interactive experience. An AI engine accepts a natural language query and provides an answer. reason is apologies. For a manager of a programming team, the experience of AI is vastly superior to the experience of the team of humans. The human team, when given a task, often asks additional questions (what about this special case? what does this phrase mean? should this work for all users at all times or do we limit it to the local country and business hours?). Some teams, if busy with other tasks, push back (should we stop our current project to build this new one? or do we finish the first and then start on the new task?).

AI engines don't ask questions or push back. They immediately start working on the task. If the task is to write the code for a new program, they write the code for the new program.

Also, AI engines are polite, especially when they make mistakes. When you point out the mistake, they apologize. They apologize right away, and then take actions to produce the correct results. They have no egos.

With that kind of experience, what's not for a manager to like? The AI engine is closer to a puppy than an employee: eager to please and unwilling to ask questions.

AI is best understood through psychology, for both programmers and non-programmers. It's not a technical issue.