Skip to main content

Lessons Learned on AI Agents and AI Coding from Spooling Systems of 1970th

 



The capabilities of IBM's Mainframe Operating Systems of the early 1970s were limited

Lack of Spooling system was one of the limitations. 


Group of four expert Programmers offered IBM a Spooling System which could be integrated into IBM's Operating System.

IBM was ready to pay for that Spooling System because it would enhance significantly the Multi Tasking capabilities.

IBM's managers asked them: How long it will take to code the Spooling System and integrate it with the Operating System? 

The answer was: 6 months.

How long it will take if we will add 70 programmers to your team?

The answer was: 2 years.

Only the 4 experts participated in writing HASP the first Spooling System in IBM Mainframe Operating System.

Later versions evolved from HASP were Jes2 and Jes3.


Lessons Learned on AI Coding



Code created by AI probably is in the level of code created by the 70 programmers mentioned in the previous paragraph.

The code built by the four experts is a lot better. 

It incudes less bugs than the code which would have been written by Average programmer or by AI tool.


It will probably address more of the defined Functionality.


Its performance will be better than the performance of the same functionality code built by AI. 


For more potential limitations of AI coding read 

Legacy Systems modernization is not simple: Is Claude Code COBOL Modernization a useful tool or Hype?  



Is AI Coding useful?

The answer is yes.   

During 40 years of work in IT and Computers I heard about Software tools aiming at replacing the programmers by an automatic tools. 

None of them reached that goal. However, some of them provided skeleton code which was helpful to programmers. 

I do not recommend using AI Code without checking it form the same reasons that I check and verify every idea suggested by a LLM based Chat Bot. 


An example in which AI Coding tool could ne helpful


After 20 years without coding in Mainframe Assembler, a customer told me that after installing a new version of z/OS Operating System non of the Jes2 Exits execute as they should. 

The System Programmers were not able to solve the problem. 

I read the relevant manual and found that a major design change was made by IBM.

After understanding the root cause of the problem I had to fix it.

My assumption was that the reason of any bug is my mistake because two decades without coding is along time.

Two bugs were not solved easily. 

The first finally identified by me as a bug in IBM's Operating System as opposed to my assumption.


I was not able to solve the second for a week. 
It was a Data exception i.e. operation on a field without a valid address. 

It was a complex routine. I assumed that after 20 years of working without any bug the coding is correct  and I am responsible for the bug.


Finally, I found the problem. 
Some of the Assembler commands execute on fixed length fields. 
unfortunately, the code includes 8 for the length of a field in a command with fixed length of 8 bytes.

The Assembler compiler interprated it as add the content of Register 8 to the address.


Prior to the design change Register 8 value was allways zero.

After the change it contained non zero value.


If AI coding function could be able to scan the syntax of all the Assembler commands and produce a report of invalid syntax in commands, I could spare 7 days of work.




Lessons Learned on AI Agents



The expertise level is not the only differentiating factor between a group of four programmers and a group of 74 programmers working on a project.

Another important factor is Management. 

The overhead of managing 74 programmers and coordinating their work is higher.

The potential of errors in a 74 programmers due to misunderstanding is huge.


The same is true for multiple AI Agents which should be coordinated in order to be effective.

As the number of AI Agents increase Management and coordination become more complex and prone to errors. 


Comments

Popular posts from this blog

The mainframe: still alive and kicking

Recently, I was interviewed by  Pcon   (unfortunately the link points to an Hebrew only site) as part of debriefing on Legacy Systems.  Pcon is an Israeli company investigating IT topics by quoting professional articles and interviewing experts. They publish the results of the investigations including practical recommendations. This post is mainly about topics raised by me during the interview, but not included in the debriefing, which will be published.    What are Legacy Systems? The term Legacy Systems refers to old application systems and/or veteran technologies still in use.  Usually, the term Legacy Systems is associated with: 1. Mainframe Hardware e.g. IBM System z and its Operating Systems or Proprietary Servers and Operating Systems such as HP Alpha and OpenVMS Operating System, IBM AS/400 and OS/400   Operating System. 2. Development and Production Environments, e.g. COBOL , Natural and DBMS systems such as Adabas  ...

Will Business and IT Aligned?

For decades we are talking about closing the gap between business and IT , but the gap is still as wide as it was. In the beginning of the ERP era, we focused on aligning Business Processes and Core Systems, but in most enterprises we failed. SOA was the next alignment promise: defining the SOA Services in Business boundaries instead of Technical boundaries, should narrow the gap. However, despite of SOA Business Value ( Agility and Reuse )  in most enterprises,  the large Business-IT Gap remained as large as it was.  The IT Community aimed at the next alignment attempt: SOA is technical and BPM is its Business related complement.  Will the current BPM based alignment attempt succeed? I do not know, but Nick Heath's article  titled: Stop doing what the vendors tell you, CIOs told , published in  Tech Republic , suggests that the root of the problem is not Technological .   Stop Doing What the vendors Tell You Nick Heath's article is based ...

Vendors Survival: Will Software AG Survive until 2019?

This post is another post in the Vendors Survival series following posts on Microsoft , Google , HP , Sun and EMC . On July 14 th Software AG and IDS Scheer announced that Software AG is going to take over IDS Scheer . The intended acquisition is an opportunity to add another post in my Vendors Survival posts series. A brief history of Software AG Mainframe products Software AG is larger than any German software company except SAP . It was established in the Mainframe age (in 1969). I worked with many customers, who used and some of them are still using, its two flagship products Adabas and Natural . Although these products support many platforms, their main platform is IBM Mainframe. Adabas is a database and Natural is a development environment. Like other pairs of Database and Development Environment in the mainframe environment (e.g. Ideal and Datacom , Mantis and Supra) build by the same vendor, they are tied together. As a result, although it is possible t...