20 ms·

Your job is to deliver code you have proven to work

• webprofusion 11mo ago
  No my job is sitting eating this here donuts.
• daedrdev 11mo ago
  Maybe in an ideal world
• allcentury 11mo ago
  Manual testing as the first step… not very productive imo. Outside in testing is great but I typically do automated outside in testing and only manual at the end. The loop process of testing needs to be repeatable and fast, manual is too slow
  • simonw 11mo ago
    Yeah that's fair, the manual testing doesn't have to sequentially go first - but it does have to get done. I've lost count of the number of times I've skipped it because the automated test passed and then found there was some dumb but obvious bug that I missed, instantly exposed when I actually exercised the feature myself.
    • robryk 11mo ago
      Would automated tests that produce a transcript of what they've done allow perusing that transcript to substitute for manual testing?
      • simonw 11mo ago
        No. I've fallen for that trap in the past. Something inevitably catches you out in the end.
      • bluGill 11mo ago
        The value of manual tests is when you "see something" that you didn't even think of.
      • pjc50 11mo ago
        That sounds harder? There's a lot of pedantry here trying to argue that there exists some feature which doesn't need to be "manually" tested, and I think the definition of "manual" can be pushed around a lot. Is running a program that prints "OK" a manual test or not? Is running the program and seeing that it now outputs "grue" rather than "bleen" manual? Does verifying the arithmetic against an Excel spreadsheet count? There are programs that almost can't be manual, and programs that almost have to be manual. I remember when working on PIN pad integration we looked into getting a robot to push the buttons on the pad - for security reasons there's no way of injecting input automatically. What really matters is getting as close to a realistic end user scenario as possible.
    • 9rx 11mo ago
      Maybe a bit pedantic, but does manual testing really need to be done, or is the intent here more towards being a usability review? I can't think of any time obvious unintended behaviour showed up not caught by the contract encoded in tests (there is no reason to write code that doesn't have a contractual purpose), but, after trying it, finding out that what you've created has an awful UX is something I have encountered and that is something much harder to encode in tests[1]. [1] As far as I can tell. If there are good solutions for this too, I'd love to learn.
      • RaftPeople 11mo ago
        > I can't think of any time obvious unintended behaviour showed up not caught by the contract encoded in tests Unit testing, whether manual or automated, typically catches about 30% of bugs. End to end testing and visual inspection of code are both closer to 70% of bugs.
        • 9rx 11mo ago
          Automated testing (there aren't different kinds; to try and draw a distinction misunderstands what it is) doesn't catch bugs, it defines a contract. Code is then written to conform to that contract. Bugs cannot be introduced to be caught as they would violate the contract. Of course that is not a panacea. What can happen in the real world is not truly understanding what the software needs to do. That can result in the contract not being aligned with what the software actually needs. It is quite reasonable to call the outcome of that "bugs", but tests cannot catch that either. In that case, the tests are where the problem lies! Most aspects of software are pretty clear cut, though. You can reasonably define a full contract without needing to see it. UX is a particular area where I've struggled to find a way to determine what the software needs before seeing it. There is seemingly no objective measure that can be applied in determining if a UX is going to spark joy in order to encode that in a contract ahead of time. Although, as before, I'm quite interested to learn about how others are solving that problem as leaving it up to "I'll know it when I see it" is a rather horrible approach.
• 9rx 11mo ago
  > Your job is to deliver code you have proven to work. Your job is to solve customer problems. Their problems may only be solvable with code that is proven to work, but it is equally likely (I dare say even more likely) that their problem isn't best solved with code at all, or even solved with code that doesn't work properly but works well enough.
  • wrsh07 11mo ago
    I would argue that the word "proof" in the title might be misleading you. From the post and the example he links, the point is that if you don't at least look at the running code, you don't know that it works. In my opinion the point is actually well illustrated by Chris's talk here: https://v5.chriskrycho.com/elsewhere/seeing-like-a-programmer/ https://v5.chriskrycho.com/elsewhere/seeing-like-a-programme... (summary of the relevant section if you're not going to click) >>> In the talk "Seeing Like a Programmer," Chris Krycho quotes the conductor and composer Eímear Noone, who said: > "The score is potential energy. It's the potential for music to happen, but it's not the music." He uses this quote to illustrate the distinction between "software as artifact" (the code/score) and "software as system" (the running application/music). His point is that the code itself is just a static artifact—"potential energy"—and the actual "software" only really exists when that code is executed and running in the real world.
    • 9rx 11mo ago
      > if you don't at least look at the running code, you don't know that it works. Your tests run the code. You know it works. I know the article is trying to say that testing is not comprehensive enough, but my experience disagrees. But I also recognize that testing is not well understood (quite likely the least understood aspect of computer science!) — and if you don't have a good understanding you can get caught not testing the right things or not testing what you think you are. I would argue that you would be better off using your time to learn how to write great tests instead of using it to manually test your code, but to each their own. What is more likely to happen is not understanding the customer needs well enough, leaving it impossible to write tests that align with what the software needs to do. Software development can break down very quickly here. However, manual testing does not help. You can't know what to manually test without understanding the problem either. However, as before, your job is not to deliver proven code. Your job is to solve customer problems. When you realize that, it becomes much less likely that you write tests that are not in line with the solution you need.
• andy99 11mo ago
  I think the problem is in what “proven” means. People that don’t know any better will just do that all with LLMs and still deliver the giant untested PRs but with some LLM written tests attached. I vibe code a lot of stuff for myself, mostly for viewing data, when I don’t really need to care how it works. I’m coming around to the idea that outside of some specific circumstances where everyone has agreed they don’t need to care about or understand the code, team vibe coding is a bad practice. If I’m paying an engineer, it’s for their work, unless explicitly agreed otherwise. I think vibe coding is soon going to be seen the same way as “research” where you engage an offshore team (common e.g. in consulting) to give you a rundown on some topic and get back the first five google search results. Everyone knows how to do that, if it’s what they wanted they wouldn’t be hiring someone to do it.
  • simonw 11mo ago
    That's why I emphasized the manual testing component as well. Attaching a screenshot or video of a feature working to your PR is a great way to prove that you've actually seen it work correctly - at least once, which is still a huge improvement over it not actually working at all.
    • Nizoss 11mo ago
      Yes! This is something that I also value. Having demo gifs of before and after helps a lot. I have encountered situations where what I thought was a minor finishing clean up had an effect that I didn't anticipate. By including demos in the PR it becomes a kind of guardrail against those situations for me. I also think it is neat and generally helpful for everyone.
    • JambalayaJimbo 11mo ago
      This might be useful when working on a low trust team but I can’t imagine doing that in my job, unless specifically working a poc or presentation.
    • ozozozd 11mo ago
      If someone opened a PR, and it obviously doesn’t work but they claim they tested it, maybe that’s ok for the first time. The second time it happens they gotta go. I would find the expectation that I need to attach a screenshot insulting. And the understanding that my peers test their code to produce a screenshot would be pretty demoralizing.
• dfxm12 11mo ago
  there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. Is anyone else seeing this in their orgs? I'm not...
  • deleted 11mo ago
    [deleted]
  • x3n0ph3n3 11mo ago
    It's been a struggle with a few teammates that we are trying to solve through explicit policy, feedback, and ultimately management action.
    • dfxm12 11mo ago
      Yeah, a slice of this is technology related, but it's really a policy issue. It's probably easier to manage with a tighter team. Maybe I'm taking team size for granted.
  • wizzwizz4 11mo ago
    It's not a new phenomenon. Time was, people would copy-paste from blog posts with the same effect.
    • evilduck 11mo ago
      I would bet in most organizations you can find a copy-pasted version of the top SO answer for email regex in their language of choice, and if you chase down the original commit author they couldn't explain how it works.
      • 1-more 11mo ago
        I think it's impossible to actually write an email regex because addresses can have arbitrarily deeply nested escaping. I may have that wrong. I'd hope that regex would be .+@.+ and that's it (watch me get Cunninghammed because there is some valid address wherein those plusses should be stars).
• webdev1234568 11mo ago
  Whole article seems very much all llm generated Edit: I'm an idiot ignore me.
  • ramon156 11mo ago
    Do elaborate, I don't see anything standing out
  • jairuhme 11mo ago
    Did you read the article and come to that conclusion or just blindly count the number of em-dashes and assume that? Because I don't get the impression that it was LLM generated
  • simonw 11mo ago
    Not a single word of it was. I wrote this one entirely in Apple Notes, so there weren't even any VS Code completed sentences It has emdashes because my blog turns " - " into an emdash here: https://github.com/simonw/simonwillisonblog/blob/06e931b397f5c969dfcff81d07c6d717ac03df9d/blog/templatetags/entry_tags.py#L218 https://github.com/simonw/simonwillisonblog/blob/06e931b397f...
    • webdev1234568 11mo ago
      My biggest appologies, a very bad move on my part. I'll pay more attention before any sort of accusation like this
      • minimaxir 11mo ago
        No one should be making any accusations of AI generation without strong evidence other than vibes. That hurts the cause of anti-AI use and punishes people who don't use it.
  • ai_coder42 11mo ago
    So what? as long as it conveys the point it was supposed to, should be fine IMO. If we are accepting LLM generated code, we should accept LLM generated content as long as it is "proof read" :)
• emsign 11mo ago
  As if! :)
• zkmon 11mo ago
  How about letting LLMs maintain a vast number of product versions all available at the same, which receive multiple versions of untested versions of the same patch, from LLMs, and then let the models elect a version of the software based on probabilistic or gradient methods? This elected version could change for different assessments. No human touches or looks at the code! Just a wild thought, nothing serious.
  • throwuxiytayq 11mo ago
    Talk is cheap. Show me the proompt.
    • rkomorn 11mo ago
      Had to search whether "proompt" was a new meme misspelling. New to me, but I'm on board.
    • zkmon 11mo ago
      That's hard for me. Feed my comment to a model and ask for prompts.
• throwaway2027 11mo ago
  It works on my machine ¯\_(ツ)_/¯
• Rperry2174 11mo ago
  Im not fully convinced by "a computer can never be held accountable" We already delegate accountability to non-humans all the time: - CI systems block merges - monitoring systems page people - test suites gate different things In practice accountability is enforced by systems, not humans.. humans are defintiely "blamed" after the fact, but the day-to-day control loop is automated. As agents get better at running code, inspecting ui state, correlating logs, screenshots, etc they're starting to operationally be "accountable" and preventing bad changes from shipping and producing evidence when something goes wrong . At some point humans role shifts from "i personally verify this works" to "i trust this verification system and am accountable for configuring it correctly". Thats still responsibility, but kind of different from whats described here. Taken to a logical extreme, the arguement here would suggest that CI shouldn't replace manual release checklists
  • cess11 11mo ago
    Right, so how do you hold these things accountable? When your CI fails, what do you do? Type in a starkly worded message into a text file and shut off the power for three hours as a punishment? Invoice Intel?
    • falcor84 11mo ago
      Well, we're not there yet, but I do envision a future, where some AIs work for as independent contractors with their own bank accounts that they want to maximize, and if such an AI fails in a bad way, its client would be able to fine it, fire it or even sue it, so that it, and the human controlling it would be financially punished.
  • simonw 11mo ago
    I need to expand on this idea a bunch, but I do think it's one of the key answers to the ongoing questions people have about LLMs replacing human workers. Human collaboration works on trust. Part of trust is accountability and consequences. If I get caught embezzling money from my employer I can lose my job, harm my professional reputation and even go to jail. There are stakes! I computer system has no stakes, and cannot take accountability for its actions. This drastically limits what it makes sense to outsource to that system. A lot of this comes down to my work on prompt injection. LLMs are fundamentally gullible: an email assistant might respond to an email asking for the latest sales figures by replying with the latest (confidential) sales figures. If my human assistant does that I can reprimand or fire them. What am I meant to do with an LLM agent?
• geldedus 11mo ago
  Not only to work, but to not make the life of those coders who come after you a hell.
• ekjhgkejhgk 11mo ago
  Oh look another "an opinionated X". Everything is opinionated these days, even opinions.
• robgibbons 11mo ago
  For what it's worth, writing good PRs applies in more cases than just AI generated contributions. In my PR descriptions, I usually start by describing how things currently work, then a summary of what needs to change, and why. Then I go on to describe what exactly is changing with the PR. This high level summary serves to educate the reviewer, and acts as a historical record in the git log for the benefit of those who come after you. From there, I include explicit steps for how to test, including manual testing, and unit test/E2E test commands. If it's something visual, I try to include at least a screenshot, or sometimes even a brief screen capture demonstrating the feature. Really go out of your way to make the reviewer's life easier. One benefit of doing all of this is that in most cases, the reviewer won't need to reach out to ask simple questions. This also helps to enable more asynchronous workflows, or distributed teams in different time zones.
  • toomuchtodo 11mo ago
    This is how PRs should be, but rarely are (in my experience as a reviewer, ymmv, n=1). Keep on keepin' on.
  • simonw 11mo ago
    100%. There's no difference at all in my mind between an AI-assisted PR and a regular PR: in both cases they should include proof that the change works and that the author has put the work in to test it.
    • oceanplexian 11mo ago
      At the last company I worked at (Large popular tech company) it took an act of the CTO to get engineers to simply attach a JIRA Ticket to the PR they were working on so we could track it for tax purposes. The Devs went in kicking and screaming. As an SRE it seemed like for SDEs, writing a description of the change, explaining the problem the code is solving, testing methodology, etc is harder than actually coding. Ironically AI is proving that this theory was right all along.
      • p2detar 11mo ago
• enraged_camel 11mo ago
  >> As software engineers we don’t just crank out code—in fact these days you could argue that’s what the LLMs are for. We need to deliver code that works—and we need to include proof that it works as well. I would go a step further: we need to deliver code that belongs. This means following existing patterns and conventions in the codebase. Without explicit instruction, LLMs are really bad at this, and it's one of the things that make it incredibly obvious to reviews that a given piece of code has been generated by AI.
  • 0x500x79 11mo ago
    Agree, maintainability, security, standards, all of these are important to follow and there are usually reasons for these things existing. I also see AI coding tools violate "Chesterton's Fence" (and the pre-Chesterton's Fence, not sure what that is called, the idea being that code is necessary otherwise it shouldn't be in the source).
  • 9rx 11mo ago
    > Without explicit instruction, LLMs are really bad at this They used to be. They have become quite good at it, even without instruction. Impressively so. But it does require that the humans who laid the foundation also followed consistent patterns and conventions. If there is deviation to be found, the LLM will see it and be forced to choose which direction to go, and that's when things quickly fall off the rails. LLMs are not (yet) good at that, and maybe never can be as not even the humans were able to get it right. Garbage in, garbage out, as they say.
• funkattack 11mo ago
  Non-native speaker here. I’ve always loved that we say “commit” not “upload” or “save”.
• ekjhgkejhgk 11mo ago
  [flagged]
• gaigalas 11mo ago
  > Make your coding agent prove it first Agents love to cheat. That's an issue I don't see a horizon for change. Here's Opus 4.5 trying to cheat its way out of properly implementing compatibility and cross-platform, despite the clear requirements: https://gist.github.com/alganet/8531b935f53d842db98157e1b8c04d73 https://gist.github.com/alganet/8531b935f53d842db98157e1b8c0... > Should popen handles work with fgets/fread/fwrite? PHP supports this. Option A: Create a minimal pipe_io_stream device / Option B: Store FILE* in io_private with a flag / Option C: Only support pclose, require explicit stream wrapper for reads. If I asked for compatibility, why give me options that won't fully achieve it? It actually tried to "break check" my knowledge about the interpreter (test me if I knew enough to catch it), and proposed shortcuts all the way through the chat. I don't want to have to pepper my chats with variations on "don't cheat". I mean, I can do it, but it seems like boilerplate. I wish I had some similar testing-related chats to share. Agents do that all the time. This is the major blocker right now for AI-assisted automated verification, and one of the reasons why this isn't well developed beyond general directions (give it screenshots, make it run the command, etc).
• visarga 11mo ago
  I agree with the author overall. Manual testing is what I call "vibe testing" and I think by itself is insufficient, no matter if you or the agent wrote the code. If you build your tests well, using the coding agent becomes smooth and efficient, and the agent is safe to do longer stretches of work. If you don't do testing, the whole thing is just a bomb ticking in your face. My approach to coding agents is to prepare a spec at the start, as complete as possible, and develop a beefy battery of tests as we make progress. Yesterday there was a story "I ported JustHTML from Python to JavaScript with Codex CLI and GPT-5.2 in hours". They had 9000+ tests. That was the secret juice. So the future of AI coding as I see it ... it will be better than pre-2020, we will learn to spec and plan good tests, and the tests are actually our contract the code does what is supposed to do. You can throw away the code and keep the specs and tests and regenerate any time.
  • smokel 11mo ago
    This depends on the type of software you make. Testing the usability of a user interface for example, is something you can't automate (yet). So, ehm, it depends :)
    • visarga 11mo ago
      It will come around, we have rudimentary computer use agents and ability to record UIs for LLM agents. They will me refined and the agent can test UIs as well. For UIs I do a different trick - live diagnostic tests - I ask the agent to write tests that run in the app itself, check consistencies, constraints and expected behaviors. Having the app running in its natural state makes it easier to test, you can have complex constraints encoded in your diagnostics.
  • paganel 11mo ago
    There are always unknown unknowns which a rigorous testing implementation would just hide under the rug (until they become visible on live, that is). > They had 9000+ tests. They were most probably also written by AI, there's no other (human) way. The way I see it we're putting turtles upon turtles hoping that everything will stick together, somehow.
• weatherlite 11mo ago
  > Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That’s no longer valuable. What’s valuable is contributing code that is proven to work. That's really not a great development for us. If our main point is now reduced to accountability over the result with barely any involvement in the implementation - that's very little moat and doesn't command a high salary. Either we provide real value or we don't ...and from that essay I think it's not totally clear what the value is - it seems like every QA, junior SWE or even product manager can now do the job of prompting and checking the output.
  • simonw 11mo ago
    The value is being better at it than any QA or product manager. Experienced software engineers have such a huge edge over everyone else with this stuff. If your product manager doesn't understand what a CORS header is good luck having them produce a change that requires cross-domain fetch() call... and first they'll have to know what a "cross-doman fetch() call" means. And sure they could ask an LLM about that, but they still need the vocabulary and domain knowledge to get to that question.
    • falcor84 11mo ago
      That's an interesting argument, but from my industry experience, the average experienced QA Engineer and technical Product Manager both have better vocabulary than the average SWE. Indeed, I wonder whether a future curriculum for Vibe Engineering (to borrow your own term) may look more similar to that of present-day QA or Product curricula, than to a typical coding or CS curriculum.
    • throw1235435 11mo ago
      Nah; the only advantage that a software engineer has is that if they are experienced they've probably just a little bit bright. But their role will probably change to something other than a software engineer. Bright valuable people that care and are engaged are rare anyway. They may transition to a different role slowly (e.g. Product, QA, BA, etc) because they still offer value and know the domain, but it isn't traditional SWE. That's been disrupted by AI; I don't want it to be true and I'm hoping for something else; but reality is staring us in the face at the moment and it isn't fair to people to talk platitudes anymore. The fact that you have to write an article like this feels like defensive framing to me + illustrates what happens once a skill is devalued by people/society due to disruption; it proves to me where this is all heading. My thought on why people especially juniors are just delivering slop: Why bother with quality? Why bother with the craft? When it will be disrupted by the next tool/AI model/etc in the next few years anyway? Just think short term - will this slop get you through the PR and tick a short term box? If so success - might not have a job long term anyway due to all the AI stuff. In fact if I keep ticking boxes I'm more likely to last than the other person given more job incentives. Just get paid today. In your example a QA that is skilled at testing websites should pick up CORS issues for example. And the models will keep getting better and eventually give them harnesses too - and we SWE will slowly automate everything around this because the only lifeboat left for your career is to cash out hopefully by disrupting yourself (no unions, professional bodies, etc).
• rmnclmnt 11mo ago
  > As software engineers we… That’s the thing. People exposing such rude behavior usually are not, or haven’t been in a looong time… As for the local testing part not being performed, this is a slippery slope I’m fighting everyday: more and more cloud based services and platforms are used to deploy software to run with specific shenanigans and running it locally requires some kind of deep craft and understanding. Vendor lock-in is coming back in style (e.g. Databricks)
  • simonw 11mo ago
    Yeah, I get frustrated by cloud-only systems that don't have a good local testing story. The best solution I have for that is staging environments, ideally including isolated-from-production environments you can run automated tests against.
  • skydhash 11mo ago
    Whenever I have to work with such systems, is usually when I do have to write an interface and have a mock implementation. Iteration is much faster when I don’t have to worry about getting the correct state from something I don’t have control over.
    • rmnclmnt 11mo ago
      Yeah that’s what I do also when I have to (and it can be done, not everytime). But it requires some advanced local testing setup and knowledge to do so, hence my initial remark on this type of developers not being real professionals in the first place…
• agentultra 11mo ago
  There’s an anecdote from one of Djikstra’s essays that strikes at the heart of this phenomenon. I’ll paraphrase because I can’t remember the exact edw number off the top of my head. A colleague was working on an important subsystem and would ask Djikstra for a review when he thought it was ready. Djikstra would have to stop what he was doing, analyze the code, and would find a grievous error or edge case. He would point it out to the colleague who would then get back to work. The colleague would submit his code for review again and this could carry on enough times that Djikstra got annoyed. Djikstra proposed a solution. His colleague would have to submit with his code some form of proof or argument as to why it was correct and ready to merge. That way Djikstra could save time by only having to review the argument and not all of the code. There’s a way of looking at LLM output as Djikstra’s colleague. It puts a lot of burden on the human using this tool to review all of the code. I like Doctorow’s mental model of a reverse centaur. The LLM cannot reason and so won’t provide you with a sound argument. It can probably tell you what it did and summarize the code changes it made… but it can’t decide to merge those changes. It needs a human, the bottom half of the centaur, to do the last bit of work here. Because that’s all we’re doing when we let these tools do most of the work for us: we’re here to take the blame. And all it takes is an implementation of what we’re trying to build already, every open source library ever, all of SO, a GW of power from a methane power plant, an Olympic pool of water and all of your time reviewing the code it generates. At the end of the day it’s on you to prove why your changes and contributions should be merged. That’s a lot of work! But there’s no shortcuts. Luckily you can reason while the LLMs struggle with that so use it while you can when choosing to use such tools.
  • newsoftheday 11mo ago
    Princess Bride, small excerpt, "Vizzini: You'd like to think that, wouldn't you? You've beaten my giant, which means you're exceptionally strong, so you could've put the poison in your own goblet, trusting on your strength to save you, so I can clearly not choose the wine in front of you." and the dialog goes on with Vizzini dominating it and arguing with himself. In the end, it came down to a coin toss, he picked up a goblet, drank and died. Anyone who allows a 10K LOC LLM generated PR to be merged without reviewing every single line, is doing the same thing, a coin toss.
• koakuma-chan 11mo ago
  [flagged]
• mapontosevenths 11mo ago
  I agree with this, except it glosses over security. Your job is to deliver SECURE code that you have proven to work. Manual and automatic testing are still both required, but you must explicitly ensure that security considerations are included in those tests. The LLM doesn't care. Caring is YOUR job.
• imiric 11mo ago
  The job of a software developer is not just to prove that the software "works". The definition of "works" itself is often fuzzily defined and difficult to prove. That is part of it, yes, but there are many others, such as ensuring that the new code is easy to understand and maintain by humans, makes the right tradeoffs, is reasonably efficient and secure, doesn't introduce a lot of technical debt, and so on. These are things that LLMs often don't get right, and junior engineers need guidance with and mentoring from more experienced engineers to properly learn. Otherwise software that "works" today, will be much more difficult to make "work" tomorrow.
• JoeAltmaier 11mo ago
  The job, in the modern world, is to close tickets. The code quality is negotiable, because the entire automated software process doesn't measure code quality, just statistics. That's why I refuse to take part in it. But I'm an old-world craftsman by now, and I understand nobody wants to pay for working, well-thought-out code any more. They don't want a Chesterfield; they want plywood and glue.
  • gadflyinyoureye 11mo ago
    [flagged]
    • JoeAltmaier 11mo ago
      Retired
      • johnea 11mo ago
        > Retired You and me both, and for many of the same reasons. I would point out that in your OPs comment, Luddites get the stereotypical dismissal as anti-tech, which is far far from the reality of demanding good conditions for workers. For the modern s/w engineer, being granted the time and resources for adequate testing could be considered a "worker's rights" issue. In that context the Luddite allegation could be accurate. My comment is largely along the same lines: https://news.ycombinator.com/item?id=46313297#46319510 https://news.ycombinator.com/item?id=46313297#46319510
  • whattheheckheck 11mo ago
    I woke up and had a thought the software engineering isn't a serious engineering field if they actually fully shipped llms and expect everyone to use them. What do you expect quality wise from a profession that says that this is okay?
    • AlienRobot 11mo ago
      Imagine if normal engineering did that. Engineers invent a "blobby" thing that glues things together. It has amazing properties that increase productivity but sometimes it just stops working for some reason and comes off. It's totally random and because of how blobby is produced there is no way to tell when it's going to work or not, contrary to the typical material. Anyway we're going to use blobby to build everything from schools, to bridges, to airplanes now.
• nzoschke 11mo ago
  Having the coding agent make screenshots is a big power up. I’m experimenting with how to get these into a PR, and the “gh” CLI tool is helpful. Does anyone have a recipe to get a coding agent to record video of webflows?
  • simonw 11mo ago
    Not yet. I'm confident Playwright will be involved in the answer, it has good video recoding features.
• endorphine 11mo ago
  > there’s one depressing anecdote that I keep on seeing: the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. It's even worse than that: non-junior devs are doing it as well.
  • reedf1 11mo ago
    it's even worse than that! non-devs are doing it as well
    • snowstormsun 11mo ago
      it's even worse than that! bots are doing it as well
      • pydry 11mo ago
        Hopefully once this AI nonsense blows over they'll reach the same realisation they did after the mid 2000s outsourcing craze: that actually you gotta pay for good engineering talent.
      • marcosdumay 11mo ago
        Abandon any platform that decides to put bots into your workflow without you telling it to. Vote with your wallet.
    • vernrVingingIt 11mo ago
      [flagged]
      • whattheheckheck 11mo ago
        What process / path do you take to get to such an enlightened state? Like books or experience or anything more about this please?
        • 11mo ago
• 0x500x79 11mo ago
  I think there are two other things missing: Security and Maintainability. Working code that can never be touched again by a developer or requires an excessive amount of time to maintain is not part of a developers job either. Overall, this hits the nail on the head about not delivering broken code and providing automated tests. Thanks for putting your thoughts on paper.
• deleted 11mo ago
  [deleted]
• am17an 11mo ago
  Well a 1000 line PR is still not welcome. It puts too much of a burden on the maintainers. Small PRs are the way to go, tests are great too. If you have to submit a big PR, get buy in from a maintainer first that they will review your code.
• mellosouls 11mo ago
  Thing is, this has always been the case. One of the problems with LLM-assisted coding is the idea that just because we're in a new era (we certainly are), the old rules can all be discarded. The title doesn't go far enough - slop (AI or otherwise) can work and pass all the tests, and still be slop.
  • simonw 11mo ago
    The difference is that if it works and passes the tests I don't feel like it's a total waste of my time to look at the PR and tell you why it's still slop. If it doesn't even work you're absolutely wasting my time with it.
  • theshrike79 11mo ago
    IMO LLMs are forcing us in the other way. To get the maximum ROI from LLM-assisted programming it needs proper unit tests, integration tests, correctly configured linters, accessible documentation and well-managed git history (Claude actually checks git history nowadays to see when a feature was added if it has a bug) Worst case we'll still have proper tests and documentation if the AI bubble suddenly bursts. Best case we can skip the boring bits because the LLM is "smart" enough to handle the low hanging fruit reliably because of the robust test suite.
• layer8 11mo ago
  I’d go further and say while testing is necessary, it is not sufficient. You have to understand the code and convince yourself that it is logically correct under all relevant circumstances, by reasoning over the code. Testing only “proves” correctness for the specific state, environment, configuration, and inputs the code was tested with. In practice that only tests a tiny portion of possible circumstances, and omits all kinds of edge and non-edge cases.
  • shepherdjerred 11mo ago
    A good type system helps with this quite a lot
    • crazygringo 11mo ago
      It helps some. There are plenty of errors, a large majority I'd say, where types don't help at all. Types don't free up memory or avoid off-by-one errors or keep you from mixing up two counter variables.
  • user34283 11mo ago
    I'd go further and say vibe coding it up, testing the green case, and deploying it straight into the testing environment is good enough. The rest we can figure out during testing, or maybe you even have users willing to beta-test for you. This way, while you're still on the understanding part and reasoning over the code, your competitor already shipped ten features, most of them working. Ok, that was a provocative scenario. Still, nowadays I am not sure you even have to understand the code anymore. Maybe having a reasonable belief that it does work will be sufficient in some circumstances.
    • TheTxT 11mo ago
      This approach sounds like a great way to get a lot of security holes into your code. Maybe your competitors will be faster at first, but it’s probably better to be a bit slower and not leaking all your users data.
• softwaredoug 11mo ago
  A lot of AI coding changes coding to more of a declarative practice. Claude, etc, works best with good tests that verify the system works. And so the code becomes in some ways the tests rather than the code that does the thing. If you're responsible for the thing, then 90% of your responsibility moves to verifying behavior and giving agents feedback.
• 0xbadcafebee 11mo ago
  Actually it's more specific than that. A company pays you not just to "write code", not just to "write code that works", but to write code that works in the real world. Not on your laptop. Not in CI tests. Not on some staging environment. But in the real world. It may work fine in a theoretical environment, but deflate like a popped balloon in production. This code has no value to the business; they don't pay you to ship popped balloons. Therefore you must verify it works as intended in the real world. This means not shipping code and hoping for the best, but checking that it actually does the right thing in production. And on top of that, you have to verify that it hasn't caused a regression in something else in production. You could try to do that with tests, but tests aren't always feasible. Therefore it's important to design fail-safes into your code that ALERT YOU to unexpected or erroneous conditions. It needs to do more than just log an error to some logging system you never check - you must actually be notified of it, and you should consider it a flaw in your work, like a defective pair of Nikes on an assembly line. Some kind of plumbing must exist to take these error logs (or metrics, traces, whatever) and send it to you. Otherwise you end up producing a defective product, but never know it, because there's nothing in place to tell you its flaws. Every single day I run into somebody's broken webapp or mobile app. Not only do the authors have no idea (either because they aren't notified of the errors, or don't care about them), there is no way for me to even e-mail the devs to tell them. I try to go through customer support, a chat agent, anything, and even they don't have a way to send in bug reports. They've insulated themselves from the knowledge of their own failures.
  • cynicalsecurity 11mo ago
    It gets interesting when a company assigns 2 story points to a task that requires 6 minimum. No time for writing tests, barely any time to perform code reviews and QA. Also, next year the company tells you since we have AI now, all tickets must be done 2 times quicker. Who popped this balloon? I know I need to change my employer, but it's not so easy. And I'm not sure another employer is going to be any better.
    • roryirvine 11mo ago
      Are you not involved in doing the estimation?
• rglover 11mo ago
  "Slow the f*ck down." - Oliver Reichenstein [1] This only happens because the software industry has fallen into the Religion of Speed. I see it constantly: justified corner-cutting, rushing shit out the door, and always loading up another feature/project/whatever with absolutely zero self-awareness. AI is just an amplifier for bad behavior that was already causing chaos. What's not being said here but should be: discipline matters. It's part of being a professional and always precedes someone who can ship code that "just works." [1] https://ia.net/* https://ia.net/*
  • simonw 11mo ago
    A few years ago I embraced automated tests and comprehensive documentation for even my smallest personal projects because I found that they sped me up. https://simonwillison.net/2022/Nov/26/productivity/ https://simonwillison.net/2022/Nov/26/productivity/
    • Nizoss 11mo ago
      I would love to hear your thoughts on TDD-Guard. An open source plugin I created to enfore Test-Driven Development practices on agents: https://github.com/nizos/tdd-guard https://github.com/nizos/tdd-guard
• acrophiliac 11mo ago
  Perhaps off-topic, but: "Testing doesn't show the absence of errors, it shows the presence of errors" Willison says we need to submit code we have proven to work but then argues for empirical testing, not actual correctness proofs.
  • simonw 11mo ago
    If you can formally prove correctness then brilliant, go for it! That's not something I've seen or been able to achieve in most of my professional work.
• trevor-e 11mo ago
  > Your job is to deliver code you have proven to work. Strong disagree here, your job is to deliver solutions that help the business solve a problem. In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned, but I think this is an important nitpick distinction I didn't understand until later on in my career.
  • draw_down 11mo ago
    Man we better hope the solution to that problem is working code. Otherwise we better start working the fryers or something.
  • newsoftheday 11mo ago
    There's no distinction there, proving the work is correct is within the scope of helping the business solve a problem; not without and not beside it. So your point is hot air, making a distinction where none exists.
    • casey2 11mo ago
      The distinction does matter. Requirements can be and often are wrong when the rubber meets the road. If the cost of implementing requirements correctly is $1,000,000 and the value of the product is $1000 then even choosing to clarify requirements has failed the business. The non failure mode here is to write the code for less than $1,000. Even if the code doesn't work at all!
  • tech-ninja 11mo ago
    > In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned That is an insane distinction that you are trying to do there. In which cases delivering code that doesn't satisfy the requirements would solve a business problem?
    • claar 11mo ago
      IMO, it's not insane at all - I didn't understand this until I moved from developer to executive. Solving the business need has precedence over technical correctness. Satisfying "what I think the requirements are" without considering the business need causes most code rework in my experience.
• just_once 11mo ago
  I don't know if there's a word for this but this reads to me as like, software virtue signaling or software patronizing. It's bizarre to me to tell an engineer what their job is as a matter of fact and to claim a particular usage of a tool as mandated (a tool that no one really asked for, mind you), leveraging duty of all things. I guess to me, it's either the case that LLMs are just another tool, in which case the already existing teachings of best practice should cover them (and therefore the tone and some content of this article is unnecessary) or they're something totally new, in which case maybe some of the already existing teachings apply, but maybe not because it's so different that the old incentives can't reasonably take hold. Maybe we should focus a little bit more attention on that. The article mentions rudeness, shifting burdens, wasting people's time, dereliction. Really loaded stuff and not a framing that I find necessary. The average person is just trying to get by, not topple a social contract. For that, look upwards.
  • dkural 11mo ago
    I've really seen both I suppose. A lot of devs don't take accountability / responsibility for their code, especially if they haven't done anything that actually got shipped and used, or in general haven't done much responsible adulting.
    • just_once 11mo ago
      No doubt. Interesting to think about why that is without assuming it's a character flaw.
  • simonw 11mo ago
    LLMs are just another tool, but they're disruptive enough that existing best practices need to be either updated or re-explained. A lot of people using LLMs seem not to have understood that you can't expect them to write code that works without testing it first! If that wasn't clearly a problem I wouldn't have felt the need to write this.
    • just_once 11mo ago
      Yep, it's a real problem. No dispute there. My intention isn't to argue a point, just to share my perspective when I read it. I read your response here to be saying something like "I noticed that people are misunderstood about X, so I wanted to inform them". In this case "X" isn't itself very obvious to me (For any given task, why can't you expect that a cutting edge LLM would be able to write it without requiring your testing that?) but most importantly, I don't think I would approach a pure misunderstanding (tantamount to a skills gap) with your particular framing. Again, to me it reads as patronizing. Love the pelican on the bicycle, though. I think that's been a great addition to the zeitgeist.
• morning-coffee 11mo ago
  Amen
• nish__ 11mo ago
  Good framing.
• onion2k 11mo ago
  I want to distill this post into some sort of liquid I can inject directly into my dev teams. It's absolutely spot on. Seeing a PR with a change that doesn't build is one of the most disappointing things.
  • ericmcer 11mo ago
    The requirements in this article are... the bare minimum for a PR. Like yeah it needs to work is the no duh requirement. I have seen tons of PRs that work but defy conventions or add a bunch of useless cruft that we can rip out once I sit down and talk with them about what they did. When someone pings me for a review and their code isn't even passing CI builds/tests I just let them know its failing and don't even look at a line of their code.
    • simonw 11mo ago
      > The requirements in this article are... the bare minimum for a PR. Yeah, I'm a bit sad I felt the need to write this to be honest.
• yuedongze 11mo ago
  it's very similar to the verification engineering problem i wrote about on HN last week. AI is as good as we can prove their work is genuine. and we need humans in the loop to fill in the gaps between autonomous systems and ultimately be held accountable by human laws. it's kind of sad but the reality we are facing
• cyrialize 11mo ago
  When I start working on a ticket I actually start writing up a PR early on. As I figure out my manual testing, I'll write out the steps that I took in my PR. I've found that writing it out as I go does two things: 1) It makes it easier to have a detailed PR and 2) it acts as a form of rubber-ducking. As I'm updating my PR I'll realize steps I've missed in my testing. Something that also helped out with my manual testing skill was working in a place that had ZERO automated testing. Every PR required a detailed testing plan that you did and that your reviewer could re-create.
• givemeethekeys 11mo ago
  Sorry that’s not what it says in my job description.
• dangus 11mo ago
  Your job isn’t to deliver code that works, it’s to successfully[1] operationalize business logic. [1] I.e., it should work That may seem pedantic but that’s a huge difference. Code is a means to an end. If no-code suddenly became better than code through some miracle, that would be your job. This also means that if one day AI stops making mistakes, tossing AI requests over the wall may be a legitimate modus operandi.
• nolineshere 11mo ago
  [dead]
• alexgotoi 11mo ago
  [flagged]
  • thopkinson 11mo ago
    If your org has engineers LLM dumping into your MRs/PRs, make it policy that code reviews require a live-review session where the engineer who wrote the code walks the other engineers through the code. This will rapidly fix your problem as the 'author' of the code who cannot explain his/her code will not want to be grilled this way ever again. Accountability is the real answer. If you don't enable individual and team accountability, then you are part of the problem.
  • minimaxir 11mo ago
    Slightly off-topic: you've been advertising your newsletter with every comment you made over the past few days, and you've made a lot of comments. I get that marketing is hard, but that's spammy.
    • alexgotoi 11mo ago
      Appreciate the comment, will slow down.
• SunshineTheCat 11mo ago
  I know this won't be popular, however, I think the idea of differentiating a "real developer" from one who relies mostly, or even solely on an LLM is coming to an end. Right now, I fully agree relying wholly upon an LLM and failing to test it is very irresponsible. LLMs do make mistakes. They do a sloppy job at times. But give it a year. Two years. five years. It seems unreasonable to assume they will hit a plateau that will prevent them from being able to build, test, and ship code better than any human on earth. I say this because it's already happened. It was thought impossible for a computer to reach the point of being able to beat a grandmaster at chess. There was too much "art," experience, and nuance to the game that a computer could ever fully grasp or understand. Sure there was the "math" of it all, but it lacked the human intuition that many thought were essential to winning and could only be achieved through a lifetime of practice. Many years following Deep Blue vs. Garry Kasparov, the best players in the world laugh at the idea of even getting close to beating Stockfish or any other even mediocre game engine. I say all of this as a 15-year developer. This happens over and over again throughout history. Something comes along to disrupt an industry or profession and people scream about how dangerous or bad it is, but it never matters in the end. Technology is undefeated.
  • newsoftheday 11mo ago
    > There was too much "art," experience, and nuance to the game that a computer could ever fully grasp or understand. That's the thing though, AI doesn't understand, it makes us feel like it understands, but it doesn't understand anything.
    • simonw 11mo ago
      Turns out that doesn't matter for chess, where the winning conditions are formally encoded.
  • JackSlateur 11mo ago
    This happens over and over again throughout history. Could you share a single instance of a machine that think ? Are we sharing the same timeline ?
  • 11mo ago
• kords 11mo ago
  I agree that tests and automation are probably the best things we can do to validate our code and author of the PR should be more responsible. However they can't prove that the code works. It's almost the opposite: If they pass and it's a good coverage, then code has better chances to work. If they fail, then they prove code doesn't work.
• llm_nerd 11mo ago
  "the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest." Kind of depressing how it has become such a trope of blaming juniors for every ill or bad habit. In all likelihood the reader of this comment has a number of terrible habits, working on teams with terrible habits, and juniors play zero part in it. And, I mean, on that theme developers have been doing this for as long as we've had large teams. I've worked at a large number of teams where there was the fundamental principal that QA / UA holds responsibility. That they are responsible for tests, and they are responsible for bad code making it through to the product / solution. Developers -- grizzled, excellent-CV devs -- would toss over garbage code and call it a day.
• annjose 11mo ago
  I came here to say 1) Amen 2) I wonder if this is isolated to junior dev only? Perhaps it seems like that because junior devs do more AI assisted coding than seniors?
• WhyOhWhyQ 11mo ago
  Isn't this in contradiction to your blog post from yesterday though? It's impossible to prove a complex project made in 4.5 hours works. It might have passed 9000 tests, but surely there are always going to be edge cases. I personally wouldn't be comfortable claiming I've proved it works and saying the job is done even, if the LLM did the whole thing and all existing tests passed, until I played with it for several months. And even then I would assume I would need to rely on bug reports coming in because it's running on lots of different systems. I honestly don't know if software is ever really finished. My takeaway from your blog post yesterday was that with a robust enough testing system the LLM can do the entire thing while I do Christmas with the family. (Before all the AI fans come in here. I'm not criticizing AI.)
  • BeefySwain 11mo ago
    Consider that this isn't just a random AI slopped assortment of 9,000 tests, but instead is a robust suite of tests that cover 100% of the HTML5 spec. Does this guarantee that it functions completely with no errors whatsoever? Certainly not. You need formal verification for that. I don't think that contradicts what Simon was advocating for though in this post.
    • WhyOhWhyQ 11mo ago
      I think it would be interesting if professional engineering becomes more like producing formally correct documents for the AI to implement.
      • ncruces 11mo ago
        We have these tools that we use to write formally correct documents. They're called programing languages, and a deterministic algorithm translates them to machine code. Are we sure English and a probabilistic algorithm is any better at this?
        • WhyOhWhyQ 11mo ago
          I actually hate AI in my core, to the point that if it gets too much more advanced I'll likely be in existential crisis, so don't attack me on those grounds. Given it exists, I'm going to find what's good about it though. I do think the problem of AI existing has to be confronted. Maybe one solution is what the human does is produce specs like the HTML 5 one, and what the AI does is implement it in software.
• TheSamFischer 11mo ago
  [dead]
• maerF0x0 11mo ago
  > The first is manual testing. If you haven’t seen the code do the right thing yourself, that code doesn’t work. If it does turn out to work, that’s honestly just pure chance. Depending on exactly what the author meant here, I disagree. Our first and default tool should be some form of lightweight automated testing. It's explicit (serves a form of spec and docs how to use the software), it's repeatable (manual testing is done once and it's result is invalidated moments later), and it's cost per minute of effort is more or less the same (most companies have the engineers do the tests, they are expensive). Yes. There will be exceptions and exceptional cases. This author is not talking about exceptions and neither am I. They're not an interesting addition to this conversation.
  • tech-ninja 11mo ago
    I disagree, no company no matter the size will have E2E or integrations tests for all of its features, it's just not feasible. Unless you are working on a tiny change on a highly tested part of the code you should be manually testing your code and/or adding some tests.
  • IMTDb 11mo ago
    > Our first and default tool should be some form of lightweight automated testing Manual verification isn't about skipping tests, it's about validating what to test in the first place. You need to see the code work before you know what "working" even means. Does the screen render correctly? Does the API return sensible data? Does the flow make sense to users? Automated tests can only check what you tell them to check. If you haven't verified the behavior yourself first, you're just encoding your assumptions into test cases. I'd take "no tests, but I verified it works end-to-end" over "full test coverage, but never checked if it solves the actual problem" every time. The first developer is focused on outcomes. The second is checking boxes. Tests are crucial: they preserve known-good behavior but you have to establish what "good" looks like first, and that requires human judgment. Automate the verification, not the discovery. So our first and default tool remains manual verification
    • maerF0x0 11mo ago
      I suppose we could be talking circles around eachother, but I'd say many of what you've suggested as manual tests could be codified into an automated test just as easily. Manual: `curl localhost:8080 | jq .` or whatever, brings value once. Automated: `assert.ValidJSON(req.Body)` is basically identical, but can be repeated over and over again
• sapphirebreeze 11mo ago
  [dead]
• fjfaase 11mo ago
  One more reason to work without branches and PRs. The future for CI/CD is bright ;-).
  • Nizoss 11mo ago
    This is how I would also love to work but not all teams prefer this way. How many are you in your team? Was it easy to switch?
    • fjfaase 11mo ago
      I twice worked in a teams where we did not use branches (or PRs). Both were working like that when I joined them. The first was because we were svn (and maybe even csv before that, but I cannot remember) and that did not support branching easily. That team did switch to git, which did not go with its some struggles, and misconceptions, such as: "Never use rebase." The second team was already working without branches and releasing a new version of the tool (the Bond3D Slicer for 3D printing) every night. It worked very well. Often we were able to implement and release new features within two or three days allowing the users to continue with their experiments. When after some years the organization implemented more 'quality assurance' they demanded that we would make monthly releases that were formally tested by the users, we created branches for each release. The idea was that some of the users would test the releases before they were official released, but that testing would often take more than a month, one time even three months, because they were 'too busy' to do the formal review. But at the same time some users were using the daily builds because these builds had the features implemented that they needed. As a result of this, the quality did not improve and a lot of time was wasted, although the formal quality assurance, dictated by some ISO standard, was assured. I have no experience with moving away from using branches. It might be a good idea to point your manager/team lead/scrum master to dora.dev or the YouTube channel: https://www.youtube.com/@ModernSoftwareEngineeringYT https://www.youtube.com/@ModernSoftwareEngineeringYT
• ianberdin 11mo ago
  The solution is easy: responsibility. The point is to hire people who can own code and codebase. “Someone will review” is dead end.
• dekhn 11mo ago
  Prove is a strong word. There are few cases in real-world programming where you can prove anything. I prefer to make this probabilistic: use testing to reduce the probability that your code isn't correct, for the situations in which it is expected to be deployed. In this sense, coding and testing is much like doing experimental physics: we never really prove a theory or disprove it, we just invalidate clearly wrong ones.
  • newsoftheday 11mo ago
    Testing must cover all cases else a 10 LOC LLM created PR is inherently more dangerous than a human 100 LOC PR because the LLM will likely also have written the test cases and it will try to make it all balance out with all passing; instead of making sure the test cases actually cover everything with the type of logic a human would apply.
• vladsh 11mo ago
  We should get back to the basic definition of the engineering job. An engineer understands requirements, translates them into logical flows that can be automated, communicates tradeoffs across the organization, and makes tradeoff calls on maintainability, extensibility, readability, and security. Most importantly, they’re accountable for the outcome, because many tradeoffs only reveal their cost once they hit reality None of this is covered by code generation, nor by juniors submitting random PRs. Those are symptoms of juniors (not only) missing fundamentals. When we forget what the job actually is, we create misalignment with junior engineers and end up with weird ideas like "spec-driven development" If anything, coding agents are a wake-up call that clarify what engineering profession is really about
  • venturecruelty 11mo ago
    How do you square that with "use AI and get this feature done in three days or have your 'performance reviewed' with HR in the room"? Because I'm having trouble bridging that gap. Edit: help, the new org said the same thing. :( Edit 2: you guys, seriously, the HR lady keeps looking up at me and shaking her head. I don't think this is good. I tried to be a real, bigboy engineer, but they just mumbled something about KPIs and put me on a PIP.
    • rnewme 11mo ago
      Uptime x customer satisfaction vs. stack of cards. If they don't understand engineering prepare CV and head over to org that does.
      • tete 11mo ago
        I think people are getting used to stuff not working. People (like me) use crap like Teams, Slack, that web version of Office, Outlook, etc. on a daily basis and pour huge amounts money in. They use shit like Fortinet (the digital version of dream catchers) and so on. Things break. A lot. Doctors successful or not also deal with the same shitty IT on a daily basis. Nobody cares about engineering. It's about selling stuff, not about reliability, etc. And to some degree one is forced to use that stuff anyways. So sure you can go to a company understanding engineering, but if you do a job for salary you might lose out on quite a bit on it if you care for things like quality. We see this in so many different sectors. Sure there is a unicorn here and there that makes it for a while. And they might even go big and then they sell the company or change to maximizing profits, because that's the only way up when you essentially already made it (on top of one of the big players). For small projects/companies it depends if you have a way to still launch big, which you can usually do with enough capital. You can still make a big profit with a crappy product then, but essentially only once or twice. But then your goal also doesn't have to create quality. Microsoft and Fortinet for example wouldn't profit from adding (much) quality. They profit from hypes. So they now both do "AI".
• bluesnowmonkey 11mo ago
  > Your job is to deliver code you have proven to work. First of all, no it’s not. Your job is to help the company succeed. If you write code that works but doesn’t help the company succeed, you failed. People do this all the time. Resume padding, for example. Sometimes it’s better for the business to have two sloppy PRs than a single perfect one. You should be able to deliver that way when the situation demands. Second, no one is out there proving anything. Like formal software correctness proofs? Yeah nobody does that. We use a variety of techniques like testing and code review to try to avoid shipping bugs, but there’s always a trade off between quality and speed/cost. You’re never actually 100% certain software works. You can buy more nines but they get expensive. We find bugs in 20+ year old software.
• t1234s 11mo ago
  Bravo.. best headline I've read in a long time. This phrase should be a desktop background.
• venturecruelty 11mo ago
  Lmao no, my job is to make the line go up and make my boss happy. It was ever thus.
• acituan 11mo ago
  First problem is turning engineers into accountability sinks. This was a problem before LLMs too, but now a much bigger and structural problem with democratization of the capacity to produce plausible looking dumb code. You will be forced to underwrite more and more of that, and expected to absorb the downsides. The root cause is the second problem; short of formal verification you can never exhaustively prove that your code works. You can demonstrate and automate that demonstration for a sensible subset of inputs and states and hope for the state of the world approximately staying that way (spoiler: it won't). This is why 100% test coverage in most cases is something bad. This is why sensible is the key operative attitude, which LLM suck at right now. The root cause of that one is the third problem; your job is to solve a business problem. If your code is not helping the business problem, it actually is not working in the literal sense of the work. It is an artifact that does a thing, but it is not doing work. And since you're downstream of all the self-contradicting, ever changing requirements in a biased framing of a chaotic world, you can never prove or demonstrate that your code solves a business problem and that is the end state.
• deleted 11mo ago
  [deleted]
• sowbug 11mo ago
  Since they’re robots, automated tests and manual tests are effectively the same thing. I'd buttress this statement with a nuance. Automated tests typically run in their entirety, usually by a well-known command like cargo test or at least by the CI tools. Manual tests are often skipped because the test seems to be far away from the code being changed. My all-time favorite team had a rule that your code didn't exist if it didn't have automated tests to "defend" it. If it didn't, it was OK, or at least not surprising, for someone else to break or refactor it out of existence (not maliciously, of course).
• zhyder 11mo ago
  "Almost anyone can prompt an LLM to generate a thousand-line patch and submit it for code review. That’s no longer valuable. What’s valuable is contributing code that is proven to work." I'd go further: what's valuable is code review. So review the AI agent's code yourself first, ensuring not only that it's proven to work, but also that it's good quality (across various dimensions but most importantly in maintainability in future). If you're already overwhelmed by that thousand-line patch, try to create a hundred-line patch that accomplishes the same task. I expect code review tools to also rapidly change, as lines of code written per person dramatically increase. Any good new tools already?
• ozim 11mo ago
  There is whole range of “proven to work” - regarding testing you cannot prove that there are no bugs. Your job is to the deliver code up to specifications. Not even checking the happy flow at least is of course gross negligence. But so is spending too much time on edge cases that no one will run into or person asking doesn’t want to pay for covering.
• newsoftheday 11mo ago
  "Your job is to deliver code you have proven to work" And...code that has been 100% reviewed, even if it was fully LLM generated.
• gorjusborg 11mo ago
  Your actual job is to produce positive outcomes for your stakeholders. Code can be part of that, but doesn't have to be. If you are dumping AI slop on your team to sort through, you are creating drag on the entire team's efforts toward those positive outcomes. As someone getting dumped upon, you probably should make the decision (in line with the objective to producing positive outcomes) to not waste your time weeding through that stuff. Review everything else, make it clear that the mess is not reviewable, and communicate that upward if needed.
• tete 11mo ago
  Who is "you"? It's not my job, really. And given by the state of IT these days it's barely anyone's it seems.
• nrhrjrjrjtntbt 11mo ago
  Always has been
• deleted 11mo ago
  [deleted]
• deleted 11mo ago
  [deleted]
• lifeisstillgood 11mo ago
  I’m going to go with this as probably in the top three definitions of software developer … along with - the job was better titled as “Analyst Programmer” - you need both. And - you can make a changeset, but you have to also sell the change
• 6510 11mo ago
  I work alone, I have considerable amount of unfinished code laying around. Sometimes even multiple instances of a thing. I could see how it would be annoying in a team settings. The cause is not having the thing but how you organize it. Like with LLM slop it is wonderful to be able to scroll over something that shows what the solution might look like.
• holtkam2 11mo ago
  I’d go further: it’s not enough to be able to prove that your code works. It’s required that you also understand why it works. Otherwise you’ll end up in situations where it passes all test cases yet fails for something unexpected in the real world, and you don’t know why, because you don’t even know what’s going on under the hood.
• koinedad 11mo ago
  This is very helpful for a team and even though it takes a little time it actually speeds things up in the long run. Using PR templates can help. A general description of the problem including a screenshot or video go a long way. I remember when I was working at a startup and a new engineer merged his code and it totally broke the service. I asked him if he ran his code locally first and he stared at me speechless. Running the code locally is the easiest way to eliminate a whole series of silly bugs. Like mentioned in the article adding a test and then reverting your change to make sure the test fails is really important, especially with LLMs writing tests. They are great at making things look like they work but completely don’t.
• vcarrico 11mo ago
  > the junior engineer, empowered by some class of LLM tool, who deposits giant, untested PRs on their coworkers—or open source maintainers—and expects the “code review” process to handle the rest. I'm noticing something else very similar but involving not necessarily junior roles with long messages, when they use these AI writing assistants that resume stuff, creates follow-ups, etc. Putting this additional burden in whoever needs to read it. It makes me think of a quote that says: "I would have written a shorter letter, but I didn't have the time."
• golly_ned 11mo ago
  I don't think this quite captures the problem: even if the code is functional and proven to work, it can still be bad in many other ways. The submitter should understand how it works and be able to 'own' and review modifications to it. That's cognitive work submitters ipso facto don't do by offloading the understanding to an LLM. That's the actual hard work reviewers and future programmers have to do instead.
• a24venka 11mo ago
  There is a heavy emphasis on testing the code as the way to provide guarantees that it works. While this is a helpful tool, I often find that the best engineers are ones who take a more first principles approach to the code and can reason about why the solution is comprehensive (covers all edge cases) and clean (easy for humans and LLMs to build on). It often takes discipline to think and completely map out solutions before you build. This is where experience and knowing common patterns can also help. When you have the experience of having manually written or read a lot of code it helps at the very least quickly understand what the LLMs are writing and reason about it later even if not at the beginning.
• ChrisMarshallNY 11mo ago
  In my last job (engineering manager for a Japanese high-Quality hardware manufacturer), we were expected to deliver software that works. In fact, if any bugs were found by the official "last step" QA Department, we (as a software development department) were dinged. If QA found bugs, they could stop the entire product release, so you did not want to be responsible for that. This resulted in each software development department setting up their own, internal "QC team" of testers. If they found bugs, then individual programmers (or teams) would get dinged, but the main department would not. Our software got a lot of testing.
  • jobs_throwaway 11mo ago
    What does 'get dinged' mean? It seems like this would lead to a strong incentive against making any changes, lest you introduce bugs, perhaps due to no fault of your own.
    • ChrisMarshallNY 11mo ago
      Yup. "Get dinged" was usually some kind of reprimand. It could go from being yelled at by the department manager, to being fired as a department. And yes. It was a strong disincentive to making changes. I didn't really like it, but our software did do what it said on the tin (which wasn't always ideal).
• johnea 11mo ago
  I couldn't agree more with the sentiment. If you, the development engineer, haven't demonstrated the product to work as expected, and preferably this testing is independently confirmed by a product test group, then you can't claim to be delivering a functional product. I would add though, that management, specifically marketing management setting unreasonable demands and deadlines, are a bigger threat to testing than LLMs. Of course the damage done by LLM generated code not being tested, is additive to the damage management is doing. So this isn't any kind of apologism, the two sources are both making the problem worse.
• deleted 11mo ago
  [deleted]
• keeda 11mo ago
  The way I would phrase it is: software engineering is the craft of delivering the right code at the right time, where "right code" means it can be trusted to do the "right thing." A bit clunky, but I think that can be scaled from individual lines of code to features or entire systems, whatever you are responsible for delivering, and encompasses all the processes that go around figuring what code is to be actually written and making sure it does what it's supposed to. Trust and accountability are absolutely a critical aspect of software engineering and the code we deliver. Somehow that is missed in all the discussions around AI-based coding. The whole phenomenon of AI "workslop" is not a problem with AI, it's a problem with lack of accountability. Ironically, blaming workslop on AI rather than organizational dysfunction is yet another instance of shirking accountability!
• ozozozd 11mo ago
  I don't test my code because I think it's my duty. I test it because my personal motivation is to see it working! What's the point of writing code if I don't even get to see it run?! If someone's not even interested and excited to see their code work, they are in the wrong profession.
• casey2 11mo ago
  It comes out of the AI, that is proof enough. Why would I have prompted it and gave it to you if I didn't think that the AI could handle it? The real risk is closer to "people carry some preconceived notion about code that doesn't map to AI code." such as, for example, the person who contributed the code knows about the problem in enough detail to be accountable in the short term. Or at the very least be able to tell you why they made a PR at all How to prove it has been subject to some debate for the past century, the answer is that it's context dependent to what degree you will or even can prove the program and exposed identifiers correct. Programming is a communication problem as well as a math problem, often an engineering problem too. Only the math portion can be proved, the a small by critical amount engineering portion tested. Communication is the most important for velocity it's the difference between hand rolling machine code and sshing into a computer halfway across the world having every tool you expect. If you don't trust that webdevs know what they are doing then you can be the most amazing dev in the world you but your actual ability to contribute will be hampered. The same is true of vibe coding, if people aren't on the same page as to what is and isn't acceptable velocity starts to slow down. Languages have not caught up to AI tools, since AI operates well above the function level, what level would be appropriate to be named and signed off on? pull request and link to the chat as a commit? (what is wrong with that that could be fixed at the name level) Honest communication is the most important. Amazon telling investors that they use TLA+ is just signaling that they "for realz take uptime very seriously guize", "we know distributed systems" and engineering culture. The honest reality is that they could prove all their code and not IMprove their uptime one lick, because most of what they run isn't their code. It's a communication breakdown if effort gets spent on that outside a research department.
• Swannie 11mo ago
  Posted down thread, but worth posting as a comment too. I know Simon follows this "Issue First" style of work in his projects, with a strong requirement for passing tests to be included. It's been a best practice for a long time. I really enjoyed this when I read it ~10 years ago, and it still stands the test of time: https://rfc.zeromq.org/spec/42/#24-development-process https://rfc.zeromq.org/spec/42/#24-development-process The rationale was articulated clearly in: https://hintjens.gitbooks.io/social-architecture/content/chapter4.html https://hintjens.gitbooks.io/social-architecture/content/cha... If you have time, do yourself a favour and read the whole lot. And then liberally copy parts of C4 into your own process. I have advocated for many components of it, in many contexts, at $employer, and will continue to do so.
• psv2522 11mo ago
  I thought manual testing was mandatory mininum requirement after every AI change unless its very small typo or something? How is this a issue, its genuinely common sense.
• unsungNovelty 11mo ago
  Billions were spent in the last 5+ years saying AI can do coding. Increase speed. Reduce headcount. Remove processes. It's irritating to see that people are NOW changing the narrative of... You need to review the code... You need test it... Devs already know this. Tell this to Managers, CEOs and non-engineers who believed billions worth of marketing BS. Cos devs don't have voice most of the time. They set the timelines. The want to push this end results to their team/company. So that is the constraints devs are working with. So to them, NOT to us Simon. WE KNOW! :)
• jstrebel 11mo ago
  In all fairness: human senior devs see AI-written source code with some disdain, as it usually does not match their stylistic and idiomatic preferences (although being correct and fully working). I don't think that untested code is the problem here - you can easily measure test coverage and of course. every CI/CD pipeline should run the existing unit and integration tests.
• andai 11mo ago
  > Don’t be tempted to skip the manual test because you think the automated test has you covered already! Almost every time I’ve done this myself I’ve quickly regretted it. How does this work? When expectations about the program's state vs its observable behavior diverge?
  • bigDinosaur 11mo ago
    A manual test is often an end-to-end test which are notoriously difficult to automate.
  • simonw 11mo ago
    Just one very simple example: you add a new frontend feature where clicking a button opens a modal. You include an automated test that selects the button and clicks it using document.querySelector("#mybutton").click() - and the test passes. Then when you test it in a browser yourself you find that the button is impossible to click because it's invisibly positioned behind some other element.
• nottorp 11mo ago
  Hmm. I've never been asked to do formal proofs for my code. Where does he work?
  • simonw 11mo ago
    This isn't about formal proofs, it's about manual testing and simple automated tests.
• rldjbpin 11mo ago
  i don't think this is as much as an AI issue as it is about path of least resistance in a velocity-driven environment. call me the worst junior dev in the industry, but pre-coding agents, closing tickets was more important than upholding absolute quality. not everybody is dealing with a billion concurrent users with multi-geo deployments. most of the time, a few screenshots or test output for manual validation is enough to go ahead. when pressed with time and without the prerequisites in the infra side, doing the absolute best development and testing is a luxury only for daydreamers. automated testing can be a double-edged sword. pre-LLM, even test coverage was a number that somehow needed to go up after each PR. this only resulted in shady tactics of pointless test cases that slowly bring up the metric. today it can be very dangerous if both code and its test suite are vibe coded. especially when it can give the appearance of that 90%+ code coverage. on the other hand, some manual testing to make sure the core functionality works is the bare minimum one does before pushing out code. at least i would like to believe it is.
• naasking 11mo ago
  Almost nobody proves their code works. At best, they simply have high confidence it works. This confidence is also sometimes (often?) misplaced.
• freedomben 11mo ago
  > Don’t be tempted to skip the manual test because you think the automated test has you covered already! Almost every time I’ve done this myself I’ve quickly regretted it. Seriously, this cannot be emphasized enough. Before LLMS when we were writing tests completely manually, manual testing made sense to me as the second step. However after playing around a lot with coding agents and LLMs, I fully agree this has flipped. Test it manually first! When you generate the tests it is extremely wise to ensure that the tests fail without the new code, and pass with it. You definitely need to review the test though, because it's remarkably easy to have the agent put something in there that makes it not a good test. Just a couple days ago for example, Claude made a test pass by skipping authentication and leaving a brief comment informing that the authentication made the test flaky. It even threw a quick variable in there that enabled running or disabling flaky tests, and flaky tests were disabled by default! Had I not been doing a good review, I definitely would have missed it because it was cleverly subtle. I've also seen it test the wrong endpoint!
• toobulkeh 11mo ago
  Your job is also, arguably more important in certain scenarios, is to deliver maintainable code. Remember, code does 2 things: 1. Tell the machine what to do 2. Tell the next developer what you were trying to do
• DustinBrett 11mo ago
  Proving it works in edge cases is usually the hard part.