is your job to write code or develop software that works?

have fun keeping a job doing 1/3 the work of people getting paid the same as you :)

I’m from Europe, so I’ll do just that. Thankfully labor laws are strong enough here to withstand this absurdity.

why does every AI skeptic assume that everyone is lying to them. theres millions of developers using AI to be more productive and you just keep plugging your ears and screaming, claiming its only dumb managers, meanwhile Linus Torvalds is vibe coding stuff.

Who said anything about that? The argument was "if you're not using AI RIGHT NOW, you will fall behind forever"

This is the nonsense management and CTOs are pushing. Use it now if you want, I do. Wait for things to cool down if you want. You'll be fine either way. The comical view that it'll be a "winner takes all" subset of developers who some how would have figured out secret AI techniques that make them 10Kx more productive and every other developer will be SOL is laughable.

knowing how to properly use AI is a skill, there are new tools, new patterns, new primitives etc. you will be unpracticed.

i agree, and its strange that this failure mode continually gets lumped onto AI. The whole point of longer term software engineering was to make it so that the context within a particular persons head should not impact the ability of a new employee to contribute to a codebase. turns out everything we do to make sure that is the case for a human also works for an agent.

As far as i can tell, the only reason AI agents currently fail is because they dont have access to the undocumented context inside of peoples heads and if we can just properly put that in text somehwere there will be no problems.

The failure mode is getting lumped into AI because AI is a lot more likely to fail.

We've done this with Neural Networks v1, Expert Systems, Neural Networks v2, SVM, etc, etc. only a matter of time before we figured it out with deep neural networks. Clearly getting closer with every cycle, but no telling how many cycles we have left because there is no sound theoretical framework.

At the same time, we have spent a large part of the existence of civilisation figuring out organisational structures and methods to create resilient processes using unreliable humans, and it turns out a lot of those methods also work on agents. People just often seem miffed that they have to apply them on computers too.

yeah, thats why people just use Teams

> This is entirely too charitable. Basically all this proves is that the agent could run in a loop for a week or so, did anyone doubt that?

yes, every AI skeptic publicly doubted that right up until they started doing it.

so 99% of all software?

Exactly. That's why you see so many people say it works great. And the rest of us are like "am I the crazy one?" No, you just don't build CRUD apps.

youre verifying std lib function call counts in unit tests? lmao.

i know you could do it, im asking why on earth you would feel its vital to verify stream.filter() was called twice in a function

You're not verifying the observable behavior of your application? lmao

How would you suggest tests around:

    void func() {
        printEvens(someCall().stream().filter(n -> n % 2 == 0).toList());
    }

    void printEvens(List<Integer> nums) {
        nums.stream().filter(n -> n % 2 == 0).forEach(n -> System.out.println(n));
    }

The first filter is redundant in this example. Duplicate code checkers are checking for exactly matching lines.

I am unaware of any linter or static analyzer that would flag this.

What's more, unit tests to test the code for printEvens (there exists one) pass because they're working properly... and the unit test that calls the calling function passes because it is working properly too.

Alternatively, write the failing test for this code.

Idk how exactly to do it in cpp becasue I'm not familiar with the tooling

You could write a test that makes sure the output of someCall is passed directly to printeven without being modified.

The example as you wrote is hard to test in general. It's probably not something you would write if your serious about testing.

In C++, the code would look like:

    #include <vector>
    #include <iostream>
    #include <algorithm>

    std::vector<int> someCall()
    {
        return {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
    }

    void printEvens(const std::vector<int>& nums)
    {
        std::ranges::for_each(nums, [](int n)
        {
            if (n % 2 == 0)
            {
                std::cout << n << '\n';
            }
        });
    }

    int main()
    {
        std::vector<int> data = someCall();
        std::vector<int> tmp;

        std::ranges::copy_if(data,
                             std::back_inserter(tmp),
                             [](int n) { return n % 2 == 0; }
        );
    
        printEvens(tmp);
        return 0;
    }

---

Nothing in there is wrong. There is no test that would fail short of going through the hassle of creating a new type that does some sort of introspection of its call stack to verify which function its being called in.

Likewise, identify if a linter or other static analysis tool could catch this issue.

Yes, this is a contrived example and it likely isn't idiomatic C++ (C++ isn't my 'native' language). The actual code in Java was more complex and had a lot more going on in other parts of the files. However, it should serve to show that there isn't a test for printEvens or someCall that would fail because it was filtered twice. Additionally, it should show that a linter or other static analysis wouldn't catch the problem (I would be rather impressed with one that did).

From ChatGPT a code review of the code: https://chatgpt.com/share/69780ce6-03e0-8011-a488-e9f3f8173f...

> You could write a test that makes sure the output of someCall is passed directly to printeven without being modified.

But why would anyone ever do that? There's nothing incorrect about the code, it's just less efficient than it should be. There's no reason to limit calls to printEven to accept only output from someCall.

A redundant filter() isn't observable (except in execution time).

You could pick it up if you were to explicitly track whether it's being called redundantly but it'd be very hard and by the time you'd thought of doing that you'd certainly have already manually checked the code for it.

what happened to not testing implementation details?

you sound insecure. that guy was making a thoughtful self-reflective observation and it seems like he hit a nerve.

That guy was denigrating somebody who did nothing more than share a list of stuff they thought was cool this year. He came at @fogus (the author) with, essentially, “I’d come across all that cool stuff too if I didn’t have my much better life of wife and kids, I bet he’s existentially unfulfilled.”

Reflective or not, it seems really personal and unfair to swing at a stranger like that. For all he knows, @fogus has the same number of partners and kids as he does, or is just as happy with whatever way their life is organized. I don’t think it’s fair to come at @fogus as “insecure” for reacting to derogatory assumptions.

Maybe everyone else here knows stuff I don’t about @fogus’ life, but I just read somebody being generous enough to share their internal thinking in public and, in exchange, getting shit on for no reason.

And as to gp—I agree the intention seems thoughtful and self-reflective; thank you for sharing those sentiments. I’m glad you’ve found happiness and fulfillment, and I think your point would stand just as strong without swinging at a stranger.

The guy should take his own advice and publish to a private blog.