Code Modernization, Upgrading, Refactoring with an AI Coding Companion – Which to use?
I have been playing with a little experiment this week and I thought I would share the results while they are still fresh. The star of the show is a classic little RPGLE subfile program I wrote years ago, it’s languished in a dusty corner of my old hard drive for a few years. This is a column sortable subfile program called SORTSFL. It is nothing particularly fancy, just a sortable list pulled from a physical file, with the usual page up/down, a couple of sort options, and the traditional footer full of function keys.
The trouble is, my RPGLE code is old, and looks terribly dated!
So, it’s time to modernise and freshen this code for 2026.
The obvious question is then “Which IDE shall I use to clean this code? Can an AI do it for me?”
This, in turn, led to the great 2026 BOB vs VSCODE debate:
The challenge was simple: I gave both IBM BOB and Visual Studio Code (with its FREE AI ) exactly the same three tasks. Same prompts, no extra hand holding on the first attempt. Then I compared what came back.
Here are the three jobs I asked them to do:
- Convert the footer function keys to proper MOUSECLICK buttons (you know, the PSHBTNFLD and PSHBTNCHC approach so users can actually click with a mouse instead of reaching for PF keys).
- Create a standalone SQL script that populates SORTPF with 100 rows of decent test data.
- Convert the native file I/O (all the READ, SETLL, READE, CHAIN stuff) over to clean embedded SQL in SQLRPGLE.
Let us dive in and see who came out swinging.
Task 1: Turn Those Function Keys Into Mouse Clickable Buttons
This is a small but very satisfying modernisation. Traditional DDS footers use CF03(03 ‘F3=Exit’) style keywords. The modern way uses a MOUSECLICK field defined as a push button field so the 5250 emulator (or ACS) lets you point and click.
Prompt I used for both AIs:
Update the DDS footer record format. Replace the CFxx function key definitions with a MOUSECLICK field using PSHBTNFLD and the correct PSHBTNCHC entries for F3=Exit, F5=Refresh and the sort options. Then update the RPGLE logic so we test the value of the MOUSECLICK field after the EXFMT instead of checking *IN indicators. Keep everything else exactly as it is.
What IBM BOB delivered:
It came back with similar syntax I have used in other subfile examples on this site. But the MOUSECLICK field was not quite correct, properly numbered PSHBTNCHC entries with the CAxx command keys attached, and the RPG side used a simple select on the returned value – but the value was incorrectly defined as 10alpha (rather than the correct 2numeric). But, BOB did add a short comment block explaining why we were making the change.
First time, very close to a neat solution – sadly it had compile errors!
What VSCode delivered:
For this task, VSCode chose AI(GPT-5.3-Codex)
It got most of the way there. The MOUSECLICK field and PSHBTNFLD were correct, but one of the PSHBTNCHC lines had the syntax slightly wrong – it tried to attach the function key in the wrong place exactly the samw way that IBM BOB did!. On the RPG side it left a couple of the old *IN03 checks still in place, so the logic would have only half worked. Weird! I suspect some AI cheating was going on. Some virtual peeking over a school boys shoulder to see their anwers (which happene to be wrong when they were copied)
Verdict on Task 1: BOB won this time. It understood the full conversation between the DDS and the RPG program without me having to explain it twice. But it had errors and I feel it got it 80% correct. VS-Code, on the other hand, simply copied BOB (and his errors) so VS-CODE is being given detention on this one.
Task 2: Add 100 Rows of Test Data via SQL
Nothing complicated here, just a script that will populate our physical file (table) with a hundred rows of data, which makes the subfile look realistic when we are testing dislpay, subsets, sorts and paging.
Prompt I used:
Create a standalone SQL script that inserts 100 rows of realistic test data into SORTPF. Match the column definitions exactly. Give me varied names, sensible quantities, amounts and dates so the sorting examples actually look different. Include a short header comment explaining how to run it.
IBM BOB result:
It produced a single INSERT INTO SORTPF (columns) VALUES (…), (…), … statement with 95 rows. The data looked properly thought out. IDs ran sequentially, names had a nice mix (including a couple of gloriously silly ones that made me laugh), dates were spread across a sensible range, and amounts varied enough that sorting by value actually changed the order. It even added a comment telling me to run it from ACS Run SQL Scripts or STRSQL. Ready to go.
Weirdly – the test data had some errors. When I ran the script it failed because a few user names were 11 character longs and the field is only ten. I told BOB he was very naughty and he want back, checked his sql script, and fixed it:
VSCode Copilot result:
Also gave me 96 rows in a VALUES clause. The syntax was fine, but the data felt very generic. Every name was basically “Test Customer 001”, amounts were all in a narrow band, and a couple of the decimal values would have failed on insert because of precision. It worked after I fixed three rows, but it was clearly the work of a bright generalist rather than someone who has loaded test data on IBM i before.
Verdict on Task 2: VS-CODE this time. Both performed well with BOB doing it faster, but VSCode won because of BOB’s weird few test results which were 11 characters in a 10 character field. For both of these, the AI generation was incredibly useful and saved me lots of time. The test data definitely made the subfile testing easier.
Task 3: Convert Native File I/O to SQLRPGLE
This was the big one. SORTSFL originally used a full F spec for SORTPF, plus the usual READ, SETLL, READE dance inside the subfile load routine and the sort rebuild logic.
Prompt I used:
Convert all native file I/O for SORTPF to embedded SQL. Use a cursor with dynamic ORDER BY support based on the existing sort parameter. Keep the subfile load loop structure similar but replace the read operations with FETCH. Make it modern free form SQLRPGLE. Add sensible SQL error handling and a short comment explaining the change. Do not change the display file or the main control logic.
IBM BOB result:
This is where the specialist training really showed. BOB produced a clean DECLARE CURSOR with a CASE expression or parameterised ORDER BY (depending on how you like to do it), a proper OPEN, a FETCH loop that loaded the subfile fields, and correct SQLCODE / SQLSTATE handling. It kept the subfile page at a time logic intact and even suggested wrapping the cursor declaration in a SET OPTION for date format consistency. The resulting code was actually a little shorter and easier to read than the original native version.
VSCode Copilot result:
It converted the main load loop reasonably well and used a cursor. However its version of the code was a little bloaty with duplicated work fields, it chose string concatenation for the dynamic sort (technically works but not my favourite pattern), and missed adding any SET OPTION or commitment control comments. It didnt compile first time, and it needed another pass to make it consistent and production tidy.
Verdict on Task 3: BOB was clearly more comfortable in the IBM i SQLRPGLE world. Copilot needed more editing to reach the same standard.
So Who Won?
For straight IBM i work, especially anything that touches DDS, subfile control logic, or the slightly quirky corners of RPG that only exist on this platform, IBM BOB came out ahead in this test. It felt like I was pair programming with someone who has actually lived in the trenches rather than someone who has read a very good book about them.
That does not mean VS-CODE with it’s choice of AI is useless. Far from it. Using CLAUDE and CHATGPT it is quite noticeably slower than my IBM BOB tasks (but I cannot complain since the VS-Code usage is free). For lots of general purpose tasks it is excellent. But when the job is deeply tied to IBM i specifics, BOB needed less back and forth and produced code that felt more “at home” on the platform.
The bigger point though is this: both tools saved me serious time compared with doing the work completely by hand. The real value comes when an experienced developer reviews what the AI produces, tweaks it to match shop standards, and makes sure it will still behave at 3 a.m. on a Friday night.
I am going to keep running these little head to head tests on real code I actually use. If you have done something similar, or if you have a favourite task where one AI clearly beats the other on IBM i, drop a comment below or start a thread on the forum. I would genuinely like to hear what has worked (or not worked) for you.
Right, If you want to watch my dropping these instructions into both IBM BOB and VS-Code in real time then watch this. Don’t watch it if you are triggered by my incessant mumbling, side stories, rambling code updates and occasional nose scratching:
Happy modernising!
