4 ms·

I disagree with the premise. It made all engineering easier. Bad and good. I believe vibe coding has always existed. I've known people at every company who add

• bensyverson 7mo ago
  In corporate app development, I would see tests to check that the mocks return the expected values. Like, what are we even doing here?
  • anilakar 7mo ago
    Someone was asked to test untestable code so verifying mock contents was the best they could come up with.
    • mvpmvh 7mo ago
      No. Someone was asked to meet an arbitrary code coverage threshold. I'm dealing with this malicious compliance/weaponized incompetence at $current_job
      • dwoldrich 7mo ago
        How will you deal with it? I successfully convinced $big_important_group at $day_job to not implement a policy of failing their builds when code coverage dips below their target threshold > 90%. (Insane target, but that's a different conversation.) I convinced them that if they wanted to treat uncovered lines of code as tech debt, they needed to add an epic stories to their backlog to write tests. And their artificially setting some high target coverage threshold will produce garbage because developers will write do-nothing tests in order to get their work done and not trip the alarms. I argued that failing the builds on code coverage would be unfair because the tech debt created by past developers would unfairly hinder random current-day devs getting their work done. Instead, I recommended they pick their current coverage percentage (it was < 10% at the time) and set the threshold to that simply to prevent backsliding as new code was added. Then, as their backlogged, legit tests were implemented, ratchet up the coverage threshold to the new high water mark. This meant all new code would get tests written for them. And, instead of failing builds, I recommended email blasts to the whole team to indicate there was some recent backsliding in the testing regime and the codebase had grown without accompanying tests. It was not a huge shame event, but good a motivator to the team to keep up the quality. SonarQube was great for long-term tracking of coverage stats. Finally, I argued the coverage tool needed to have very liberal "ignore" rules that were agreed to by all members of the team (including managers). Anything that did not represent testable logic written by the team: generated code, configurations, tests themselves, should not count against their code coverage percentages.
  • RobRivera 7mo ago
    I'm trying to wrap my head around here. So there are tests that leverage mocks. Those mocks help validate software is performing as desired by enabling tests to see the software behaves as desired in varying contexts. If the software fails, it is because the mocks exposed that under certain inputs, undesired behavior occurs, an assert fails, and a red line flags the test output. Validating that the mocks return the desired output.... Maybe there is a desire that the mocks return a stream of random numbers and the mock validation tests asserts said stream adheres to a particular distribution? Maybe someone in the past pushed a bad mock into prod, that mock validated a test that would have failed given better mock, and a post mortem when the bad software, now pushed into prod, was traced to a bad mock derived a requirement that all mocks must be validated?
    • bensyverson 7mo ago
      Yeah, seems plausible, or it was just "belt and suspenders." Sure made a lot of pretty green checkmarks.
  • bdangubic 7mo ago
    we use this https://github.com/auchenberg/volkswagen https://github.com/auchenberg/volkswagen
  • steve_adams_86 7mo ago
    # abstract internals for no reason func doThing(x: bool) if (x) return true else return false # make sure our logic works as expected assert(doThing(true)) # ??? # profit It's excellent software engineering because there are tests
  • dwoldrich 7mo ago
    You could ask the same thing about tests themselves. And I'm not talking about tests that don't exercise the code in a meaningful manner like your assertions on mocks(?!) I'm saying you could make the same argument about useful tests themselves. What is testing that the tests are correct? Uncle Bob would say the production code is testing the tests but only in the limited, one-time, acceptance case where the programmer who watches the test fail, implements code, and then watches it pass (in the ideal test-driven development scenario.) But what we do all boils down to acceptance. A human user or stakeholder continues to accept the code as correct equals a job well done. Of course, this is itself a flawed check because humans are flawed and miss things and they don't know what they want anyhow. The Agile Manifesto and Extreme Programming was all about organizing to make course corrections as cheap as possible to accommodate fickle humanity. > Like, what are we even doing here? What ARE we doing? A slapdash job on the whole. And, AI is just making slapdash more acceptable and accepted because it is so clever and the boards of directors are busy running this next latest craze into the dirt. "Baffle 'em with bullsh*t" works in every sector of life and lets people get away with all manner of sins. I think what we SHOULD be doing is plying our craft. We should be using AI as a thinking tool, and not treat it like a replacement for ourselves and our thinking.
• furyofantares 7mo ago
  Well, it's made bad engineering massively easier and good engineering a little easier. So much so that many people who were doing good engineering before have opted to move to doing three times as much bad engineering instead of doing 10% more good engineering.
  • myrak 7mo ago
    [dead]
  • queenkjuul 7mo ago
    This is precisely my experience at work. Mid-levels who used to produce good code are now producing LLM code.
• nhaehnle 7mo ago
  I believe the article exaggerates to make a point. Yes, good engineering can also be assisted with LLM-based agents, but there is a delta. Good engineering requires that you still pay attention to the result produced by the agent(s). Bad engineering might skip over that part. Therefore, via Amdahl's law, LLM-based agents overall provide more acceleration to bad engineering than they do to good engineering.
  • 0xcafefood 7mo ago
    The connection to Amdahl's law is totally on point. If you're just using LLMs as a faster way to get _your_ ideas down, but still want to ensure you validate and understand the output, you won't get the mythical 10x improvement so many seem to claim they're getting. And if you do want that 10x speedup, you have to forego the validation and understanding.
    • koonsolo 7mo ago
      I do agree with you, but don't underestimate the projects where you can actually apply this 10x. For example, I wanted to get some analytics out of my database. What would have been a full weekend project was now done in an hour. So for such things there is a huge speed boost. But once software becomes bigger and more complex, the LLM starts messing up, and the expert has to come in. That basicaly means your months project cannot be done in a week. My personal prediction: plugins and systems that support plugins will become important. Because a plugin can be written at 10x speed. The system itself, not so much.
      • judahmeek 7mo ago
        I think there will also be a lot of work in how to modularize month long projects into plugin sized pieces.
        • koonsolo 7mo ago
          Yes, definitely. I also don't think every project is able to create a plugin platform. Sometimes you just have a lot of interconnected components, where they kind of influence each other. What I was trying to say is that in future developments, as a developer, one of the extra questions on your mind should be: can we turn this into a platform with separate plugins? Because you know those plugins can be written fast, cheap, and don't require top notch engineering work. But I think I get what you are saying: what you gain in plugin simplicity, you pay in effort to design the platform to support them. I guess it will depend from project to project, and so the typical "it depends" applies :).
• onlyrealcuzzo 7mo ago
  Even if you agree with the OP, there's a large portion of applications where it simply doesn't matter if the quality of the software is good or terrible as long as it sufficiently works.
  • tyleo 7mo ago
    Yeah, I've seen this too. I like to call them "single-serving apps". I made a flashcard app to study for interviews and one-shot it with Claude Code. I've had it add some features here and there but haven't really looked at the code. It's just a small CLI app in 3 TypeScript files.
• ffsm8 7mo ago
  > Ive known people at every company who add copious null checks rather than understanding things and fixing them properly. ynow "defensive programming" is a thing, yeah? Sorry mate, but that statement I'd expect from juniors, which are also often the one's claiming their own technical superiority over others
  • retrodaredevil 7mo ago
    Adding null checks where they aren't needed means adding branching complexity. It means handling cases that may never need to be handled. Doing all that makes it harder to understand "could this variable ever be null?" If you can't answer that question, it is now harder to write code in the future, often leading to even more unnecessary null checks. I've seen legacy code bases during code review where someone will ask "should we have a null check there?" and often no-one knows the answer. The solution is to use nullability annotations IMO. It's easy to just say "oh this is just something a junior would say", but come on, have an actual discussion about it rather than implying anyone who has that opinion is inexperienced.
    • ffsm8 7mo ago
      No, the branching complexity exists anyway. You've just made it clearly visible by adding a null check or accept that the computational may fail if violated. You never know what changes are being done in the future, while today the variable may not be nullable in the scenario you're up-to-date on, that doesn't necessarily mean it'll stay like that in the future. Ultimately, there is a cost associated with null checks everywhere and another by omitting them. The person I responded to just insinuated that people which introduce copious amounts of null checks are inept and lazy. In response to that I pointed out that that's literally one of the core tenets of defensive programming, and people that make such sweeping statements about other people's capabilities in this way are very often juniors. I stand by this opinion. You can disagree on specific places were a null check may have been placed unnecessary, but that's always a discussion about a specific field and cannot be generalized like he did there.
• roncesvalles 7mo ago
  I think it's easy to forget that the LLM is not a magic oracle. It doesn't give great answers. What you do with the LLM's output determines whether the engineering you produce is good or bad. There are places where you can plonk in the LLM's output as-is and places you can't, or times when you have to keep nudging for a better output, and times when nothing the LLM produces is worth keeping. It makes bad engineering easier because it's easy to fall into the trap of "if the LLM said so, it must be right".
• archagon 7mo ago
  Except vibe coding is not "engineering," but more akin to project management. Engineering presupposes a deep and thorough understanding of your code. If you ship code that you’ve never even looked at, you are no longer an engineer.
• ikidd 7mo ago
  `On Error Resume Next`