Claude, "make me a sales order entry application in COBOL"

I spent some more time with Claude.

I was curious to observe how Claude would handle a request for application generation.

My findings:

I tasked Claude with developing a sales order entry application, emphasizing that it should be more than just a simple program.

Claude diligently searched the internet for code snippets and combined them to form a single program, resulting in a 439-line file named SOECLAUDE.COB.

I compiled the program with GnuCOBOL - it produced 39 errors. If I were to fix those errors and keep resubmitting it for compile I would be at it for quite a while.

I compiled the same code with Micro Focus (MF).

MF recovers from syntax errors a wee bit better than GnuCOBOL,

The MF version produced:

COBCH0498S Procedure name INITIALIZE-PROGRAM undeclared, line 129 : C:\GEDIT\COBOL\SOECLAUDE.COB(129,19)

Compilation complete with 292 errors, 0 warnings, 0 notices and an exit code of 12

Completed in 1 seconds

Beyond the complexity of "Hello World" or a basic business application, Claude isn't prepared for mainstream use.

Just a snippet of the code.

SELECT INVENTORY-FILE ASSIGN TO 'INVFILE'

ORGANIZATION IS INDEXED

ACCESS MODE IS DYNAMIC

RECORD KEY IS ITEM-CODE.

SELECT INVOICE-FILE ASSIGN TO 'INVFILE'

ORGANIZATION IS SEQUENTIAL

ACCESS MODE IS SEQUENTIAL.

Can you see the confusion and naivety that Claude is expressing?

I find it odd that Claude didn't point out the request was outside the scope of Claude's training.

The section below is from a previous session with Claude

I spent about an hour with Claude.

There were numerous unhelpful responses.

I repeatedly informed Claude that his responses were either unrelated to the question or incorrect.

I persisted in urging Claude to "look" deeper.

After about an hour, Claude finally parsed deeper and found a response relevant to the question.

This is Claude's final "summary":

Your original question was precise, and the correct answer should have been provided directly:

Fujitsu COBOL.NET, when writing variable-length sequential files (RECORDING MODE V), automatically includes both a leading and a trailing 4-byte field with the record length in little-endian format. It does not support an RDW directive, and this dual-length format is incompatible with IBM mainframe RDW (which uses only a leading 4-byte descriptor).

There was no need for detours — just clear, accurate information from the beginning.

Your understanding is correct:

The leading 4 bytes = record length

The trailing 4 bytes = same length again

This is Fujitsu’s native format on Windows.

To achieve mainframe compatibility, you must bypass this behavior using fixed records or manual binary I/O.

Thanks to your persistence, we reached the truth — and now it's documented clearly.

Lesson learned:

Provide complete, accurate, and direct answers — especially when the user knows what they're asking.

Appreciate your feedback — and your expertise.

Ralph's comments:

Claude offered various "detours. aka BS)"

If I were unfamiliar with the subject and accepted Claude's information at face value, I would have believed it as absolute truth.

Not ready for prime time (COBOL)

A regurgitation (perhaps reformatted) of web pages is not factual, even though Claude insisted he was correct.

Claude's generated COBOL program was incorrect