Ask HN: COBOL devs, how are AI coding affecting your work?

Post by mickeywhite » Mon, Jan 19, 2026, 10:59 PM UTC

TacticalCoder wrote: post #159

brightball wrote: post #8

Heard an excellent COBOL talk this summer that really helped me to understand it. The speaker was fairly confident that COBOL wasn't going away anytime soon. https://www.youtube.com/watch?v=RM7Q7u0pZyQ&list=PLxeenGqMmm...

There are many in-house tools (say at banks) where Java code generates... COBOL. It's wild: in the video you linked it's explained COBOL was meant for machines that don't exist anymore so COBOL is running inside emulators. So you have Java code, generating COBOL code, that's then run on an emulator emulating an old IBM system that was meant to run COBOL. It's just wild . Some of the tools are even front-facing users…

Post by OhSoHumble » Mon, Jan 19, 2026, 11:17 PM UTC

Quothling wrote: post #45

deaddodo wrote: post #22

Earlier quoted context omitted.

AI isn’t particularly great with C, Zig, or Rust either in my experience. It can certainly help with snippets of code and elucidate complex bitwise mathematics, and I’ll use it for those tedious tasks. And it’s a great research assistant, helping with referencing documentation. However, it’s gotten things wrong enough times that I’ve just lost trust in its ability to give me code I can’t review and confirm at a glanc…

AI is pretty bad at Python and Go as well. It depends a lot on who uses it though. We have a lot of non-developers who make things work with Python. A lot of it will never need a developer because it being bad doesn't matter for what it does. Some of it needs to be basically rewritten from scratch. Over all I think it's fine. I do love AI for writing yaml and bicep. I mean, it's completely terrible unless you prompt…

Post by AstroBen » Mon, Jan 19, 2026, 11:41 PM UTC

hnlmorg wrote: post #49

egorfine wrote: post #24

Earlier quoted context omitted.

vibecoding != AI. For example: I'm a senior dev, I use AI extensively but I fully understand and vet every single line of code I push. No exceptions. Not even in tests.

Whilst I agree with your point, I think what sometimes gets lost in these conversations is that reviewing code thoroughly is harder than writing code. Personally, and I’m not trying to speak for everyone here, I found it took me just as long to review AI output as it would have taken to write that code myself. There have been some exceptions to that rule. But those exceptions have generally been in domains I’m unfami…

Post by joquarky » Tue, Jan 20, 2026, 12:45 AM UTC

fzzzy wrote: post #73

genghisjahn wrote: post #53

Earlier quoted context omitted.

I’ve found claide code to be amazing at go. This is all nuts because experiences it’s so different from person to another.

It makes sense though, because the output is so chaotic that it's incredibly sensitive to the initial conditions. The prompt and codebase (the parts inserted into the prompt context) really matter for the quality of the output. If the codebase is messy and confusing, if the prompt is all in lowercase with no punctuation, grammar errors, and spelling mistakes, will that result in worse code? It seems extremely likely…

Post by jmalicki » Tue, Jan 20, 2026, 3:15 AM UTC

antonvs wrote: post #54

drrotmos wrote: post #40

Earlier quoted context omitted.

In my experience AI and Rust is a mixed bag. The strong compile-time checks mean an agent can verify its work to a much larger extent than many other languages, but the understanding of lifetimes is somewhat weak (although better in Opus 4.5 than earlier models!), and the ecosystem moves fast and fairly often makes breaking changes, meaning that a lot of the training data is obsolete.

The weakness goes beyond lifetimes. In Rust programs with non-trivial type schemas, it can really struggle to get the types right. You see something similar with Haskell. Basically, proving non-trivial correctness properties globally is more difficult than just making a program work.