Claude Just Killed Software Stocks (Here's What Happens Next)

[Xipe Totec]

TL;DR: Hoist by their own petard, programmers have built a system that eliminated their jobs.

The deployment of Claude in my view is the realization of the dream that began in 1959 with the creation of COBOL, the Common Business Oriented Language. The idea was to create a programming language so English like, that business executives could write their own programs and eliminate costly software developers. Come 2026, and not only can you write programs in plain English, you can speak them into a microphone and they become reality.

The realization of COBOL's dream has come true and it's a nightmare. Software As a Service companies are plummeting.

Side note: Clearly the guy who published this video is selling something, but he has good points and the market is reacting. I myself have experienced the impact of Claude in my work. My boss asked for an estimate on developing a data transform. I estimated a week's worth of work. My boss reassigned the job to a colleague using Claude and he came back with a clean solution in one hour. My boss wanted to know what I was doing the other 39 hours of the work week. My response? Not immediate but a week later. I tendered my resignation. I'm retiring from software development after 49 years of service.

Cést la vie

[appmanga]

1. As someone who did a lot of COBOL programming...

...the issue was not in learning the language, it was writing, efficient, elegant programs that could be easily maintained and there weren't a lot of developers who could do that well. There were people in 2005 programming COBOL as if it was still 1985, totally unaware of the functions and improved capabilities of the language. So far, I'm seen that AI can do software just as shabbily as a mediocre developer, especially in a language like COBOL. What going to happen with object-oriented development is scary. I have a feeling while there may be fewer developers, there's always going to be a place for exceptional developers, and probably even more so after a couple of years of AI being seen as the better solution.

[Xipe Totec]

2. I've often remarked that programs reflect the quality of thought of the developers.

Programming languages are just as expressive as natural languages. So if you can't express coherent thoughts in a natural language, you sure as hell can't do it in a programming language.

[appmanga]

3. I just went to Claude and gave it this prompt...

A COBOL program that accepts input from a DB2 database called "Name" and another called "Address". "Name" is the parent table and has columns of "Person Number", "First Name", "Last Name", and "Title". "Address" is a child table with columns called "Person Number", "Street Address", "City", "State", "ZIP".

It produced a reasonably decent program and very good SQL. But here's an issue (or maybe it isn't anymore, I haven't actively written COBOL in about 20 years, but I have a feeling it would still be):

01 WS-RECORD-COUNT PIC 9(5) COMP-3 VALUE ZERO.
01 WS-PAGE-COUNT PIC 9(4) COMP-3 VALUE ZERO.
01 WS-LINE-COUNT PIC 9(3) COMP-3 VALUE ZERO.

A good, experienced COBOL programmer will recognize (what at least used to be) the two major issues with this code.

[Xipe Totec]

4. I have to declare ignorance

I studied COBOL, I know it's history, but I never used it professionally. I went from BASIC, to FORTRAN, to assembly, to FOCUS, to C, C++, Java, Javascript, to Python with various flavors of SQL along the way. Never did have a chance to really try out COBOL.

I did feed your comments to ChatGPT and it came back with this:

You’re right — any old-school mainframe COBOL programmer will wince a little when they see that 😊

Here are the two classic problems with those definitions:

01 WS-RECORD-COUNT PIC 9(5) COMP-3 VALUE ZERO.
01 WS-PAGE-COUNT PIC 9(4) COMP-3 VALUE ZERO.
01 WS-LINE-COUNT PIC 9(3) COMP-3 VALUE ZERO.

1️⃣ They’re Too Small (Overflow Risk)

PIC 9(5) → max 99,999

PIC 9(4) → max 9,999

PIC 9(3) → max 999

For a DB2 batch job reading potentially large parent/child result sets, those limits are dangerous.

If:

You process 150,000 records → WS-RECORD-COUNT overflows

You print more than 9,999 pages → WS-PAGE-COUNT overflows

You accidentally mis-handle pagination → line counter can wrap

On many mainframes, packed decimal overflow results in:

S0C7 abend

corrupted totals

negative values due to wraparound

Seasoned COBOL programmers typically over-allocate counters:

PIC 9(9) COMP-3


because storage was cheap compared to a batch failure.

2️⃣ Using COMP-3 for Loop Counters Is Questionable

COMP-3 = packed decimal (BCD)

That’s ideal for:

money

financial arithmetic

values requiring exact decimal math

But for simple counters, especially ones used in:

PERFORM VARYING

ADD 1 TO ...

indexing logic

it’s not ideal.

Better choices traditionally were:

PIC S9(9) COMP (binary)
or
PIC S9(9) COMP-5 (true binary, depending on compiler)


Why?

Binary arithmetic is faster.

Packed decimal arithmetic costs more CPU.

Counters are integer loop controls, not financial quantities.

In older z/OS batch environments, this absolutely mattered.

What an Experienced COBOL Programmer Would Likely Write
01 WS-RECORD-COUNT PIC S9(9) COMP VALUE 0.
01 WS-PAGE-COUNT PIC S9(7) COMP VALUE 0.
01 WS-LINE-COUNT PIC S9(4) COMP VALUE 0.


or even:

01 WS-RECORD-COUNT PIC S9(9) COMP-5 VALUE 0.


depending on shop standards.

Bonus Old-School Observation

Another subtle issue:

They’re unsigned (9(n) not S9(n)).

Arithmetic that accidentally goes negative could cause odd behavior.

Many shops defaulted to signed numeric for counters as defensive practice.

So Your Instinct Is Correct

The two classic problems are:

Insufficient size → overflow risk

Using COMP-3 (packed decimal) for simple counters instead of binary

Even today, on Enterprise COBOL for z/OS, those considerations still apply — though modern hardware makes the performance gap less dramatic than it used to be.

If you’d like, I can also show how a modern Enterprise COBOL shop would define these today.

[Renew Deal]

6. If you point out the issue to Claude, it will fix it

And if you tell it something is wrong, it will probably figure out what it is.

[hunter]

5. AI is going to pollute the wells it draws from so badly it will take decades to clean up the mess.

"Claude" isn't writing code, it's a fancy search engine mindlessly sifting through all the code it's been trained on and spitting it out again, obfuscating the origins of that code. It's a plagiarism machine.

It "works" by dredging up old solutions to old problems.

Sadly the field of computer science is stagnant. Throwing more memory and more processors at problems isn't innovation. This technology was on Steve Chen's drawing board fifty years ago, evolving into the Cray X-MP

AI is being sold as "The Next Big Thing" but it's a dead end. It's certainly not intelligent, no more so than the filter paper in your coffee maker. That's not to say it doesn't have useful applications.

If we are lucky the hype for this AI will die down before some hairball of LLM generated code causes a major catastrophe.