5 ms·

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

• null_deref 8mo ago
  Does the use AI always implies slope and vibe coding? I’m really not sure
  • jebarker 8mo ago
    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.
    • sarchertech 8mo ago
      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.
      • eps 8mo ago
        > 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.
    • 0xCE0 8mo ago
      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.
  • foxmoss 8mo ago
    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.
    • shermantanktop 8mo ago
      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.
• egorfine 8mo ago
  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.
  • eps 8mo ago
    Aye. AI is also great for learning specifics of poorly documented APIs, e.g. COM-based brainrot from Microsoft.
    • refneb 8mo ago
      Hey now, that COM based rot paid for my house and kid’s college expenses.
      • egorfine 8mo ago
        Not anymore. AI actually does this part much better.
  • tjr 8mo ago
    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?
  • elzbardico 8mo ago
    And I do a lot of top level design when I use it. AIs are terrible at abstraction and functional decomposition.
  • hnlmorg 8mo ago
    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.
• ironbound 8mo ago
  Management loves trying to save money, a bunch of grads with AI have differently had a project to try to write COBOL!
• shevy-java 8mo ago
  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.
  • pverheggen 8mo ago
    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.
  • pixl97 8mo ago
    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.
  • shakna 8mo ago
    ECB is mostly COBOL and Fortran. The interfaces are Java, but not the backend.
  • jamesfinlayson 8mo ago
    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.