Hacker News Reader

Comment by 0xCE0 | Hacker News Reader

I really wouldn't want any vibe-coded COBOL in my bank db/app logic...

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.

Aye. AI is also great for learning specifics of poorly documented APIs, e.g. COM-based brainrot from Microsoft.

Hey now, that COM based rot paid for my house and kid’s college expenses.

Not anymore. AI actually does this part much better.

That is my preferred way to use it also, though I see many folks seemingly pushing for pure vibe coding, apparently striving for maximum throughput as a high-priority goal. Which goal would be hindered by careful review of the output.

It's unclear to me why most software projects would need to grow by tens (or hundreds) of thousands of lines of code each day, but I guess that's a thing?

And I do a lot of top level design when I use it. AIs are terrible at abstraction and functional decomposition.

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 unfamiliar with. So we are back to trusting AI as a research assistant, if not a “vibe coding” assistant.

I think the point is in a banking context, every line of code gets reviewed thoroughly anyway.

I’d expect every line of code to get reviewed in any organisation.

The difference with AI is that the “prompt engineer” reviews the output, and then the code gets peer reviewed like usual from someone else too.

You'd be surprised...

Would you consider Knight Capital Group[1] a banking context?

[1]: https://en.wikipedia.org/wiki/Knight_Capital_Group#2012_stoc...

> as long to review AI output as it would have taken to write that code myself

That is often the case.

What immensely helps though is that AI gets me past writer's block. Then I have to rewrite all the slop, but hey, it's rewrite and that's much easier to get in that zone and streamline the work. Sometimes I produce more code per day rewriting AI slop than writing it from scratch myself.

The worst is reviewing the code and realizing it stinks and should be done another way

So you re-roll the slot machine and pay the reviewing cost twice

I don't think AI's biggest strength is in writing code

Unfortunately, the people who are "pro-AI" are so often because it lets them skip the understanding part with less scrutiny

The good news here is that their code is of such a poor quality it doesn't properly work anyway.

I have recently tried to blindly create a small .dylib consolidation tool in JS using Claude Code, Opus 4.5 and AskUserTool to create a detailed spec. My god how awful and broken the code was. Unusable. But it faked* working just good enough to pass someone who's got no clue.

> The good news here is that their code is of such a poor quality it doesn't properly work anyway.

This is just wishful thinking. In reality it works just well enough to be dangerous. Just look at the latest RCE in OpenCode. The AI it was vibe-coded with allowed any website with origin * to execute code, and the Prompt Engineer™ didn't understand the implications.

> it works just well enough to be dangerous

Excellent. I for one fully welcome Prompt Engineers™ into the world of software development.

I assume you don't understand some of the words in the rest of my comment. Or you're a nihilist and enjoy watching everything burn to the ground.

It's all fun and games until actual lives are at stake.

I'm watching the voters around the world electing charismatic leaders and then cheering the consequences.

Thus companies electing to replace software developers with AI slop are not of a much surprise to me.

It doesn't matter whether people will die because of AI slop. What matters is keeping Microsoft shareholders happy and they are only happy when there is a growing demand for slop.

> Not even in tests.

This should be "especially in tests". It's more important that they work than the actual code, because their purpose is to catch when the rest of the code breaks.

Does the use AI always implies slope and vibe coding? I’m really not sure

No, it doesn't. For example, you could use an AI agent just to aid you in code search and understanding or for filling out well specified functions which you then do QA on.

You 100% can use it this way. But it takes a lot of discipline to keep the slop out of the code base. The same way it took discipline to keep human slop out.

There has always been a class of devs who throw things at the wall and see what sticks. They copy paste from other parts of the application, or from stack overflow. They write half assed tests or no tests at all and they try their best to push it thought the review process with pleas about how urgent it is (there are developers on the opposite side of this spectrum who are also bad).

The new problem is that this class of developer is the exact kind of developer who AI speeds up the most, and they are the most experienced at getting shit code through review.

> But it takes a lot of discipline to keep the slop out of the code base.

It is largely a question of working ethics, rather than a matter of discipline per se.

To do quality QA/code review, one of course needs to understand the design decisions/motivations/intentions (why those exact code lines were added, and why they are correct), meaning it is the same job as one would originally code those lines and building the understanding==quality on the way.

For the terminology, I consider "vibe-coding" as Claude etc. coding agents that sculpts entire blocks of code based on prompts. My use-tactic for LLM/AI-coding is to just get the signature/example of some functions that I need (because documents usually suck), and then coding it myself. That way the control/understanding is more (and very egoistically) in my hands/head, than in LLMs. I don't know what kind of projects you do, but many times the magic of LLMs ends, and the discussion just starts to go same incorrect circle when reflected on reality. At that point I need to return to use classic human intelligence.

And for COBOL + AI, in my experience mentioning "COBOL" means that there is usually DB + UI/APP/API/BATCHJOB for interacting with it. And the DB schema + semantics is propably the most critical to understand here, because it totally defines the operations/bizlogic/interpretations for it. So any "AI" would also need to understand your DB (semantically) fully to not make any mistakes.

But in any case, someone needs to be responsible for the committed code, because only personified human blame and guilt can eventually avert/minimize sloppiness.

Because the question almost always comes with an undertone of “Can this replace me?”. If it’s just code search, debugging, the answer’s no because a non-developer won’t have the skills or experience to put it all together.

That undertone is overt in the statements of CEOs and managers who salivate at “reducing headcount.”

The people who should fear AI the most right now are the offshore shops. They’re the most replaceable because the only reason they exist is the desire to carve off low skill work and do it cheaply.

But all of this overblown anyway because I don’t see appetite for new software getting satiated anytime soon, even if we made everyone 2x productive.

How many banks really use COBOL? Here in central Europe it seems to be Java, Java, Java for the most part. Since many years actually.

In the US, there are several thousands of banks and credit unions, and the smaller ones use a patchwork of different vendor software. They likely don't have to write COBOL directly, but some of those components are still running it.

From the vendor's perspective, it doesn't make sense to do a complete rewrite and risk creating hairy financial issues for potentially hundreds of clients.

As others have said, US banks seem to run a lot of it, as in they have millions of lines of code of it.

This is not saying that banks don't also have a metric shitload of Java, they do. I think most people would be surprised how much code your average large bank manages.

ECB is mostly COBOL and Fortran. The interfaces are Java, but not the backend.

I'm in Australia and a friend of a friend had a COBOL job working at a mid-sized bank (the COBOL had lots of Java on top). Australia's big banks are older than this bank so if they're not using COBOL at the bottom layer, they'll be using something similarly old for sure.

Management loves trying to save money, a bunch of grads with AI have differently had a project to try to write COBOL!

Reply on news.ycombinator.com