[bonesss]

Religions are about faith, faith is belief in the absence of evidence. Engineering output is tangible and measurable, objectively verifiable and readily quantifiable (both locally and in terms of profits). Full evidence, testable assertions, no faith required.

Here we have claims of objective results, but also admissions we’re not even tracking estimations and are terrible at making them when we do. People are notoriously bad at estimating actual time spent versus output, particularly when dealing with unwanted work. We’re missing the fundamental criteria of assessment, and there are known biases unaccounted for.

Output in LOC has never been the issue, copy and paste handles that just fine. TCO and holistic velocity after a few years is a separate matter. Masterful orchestration of agents could include estimation and tracking tasks with minimal overhead. That’s not what we’re seeing though…

Someone who has even a 20% better method for deck construction is gonna show me some timetables, some billed projects, and a very fancy new car. If accepting Mothra as my lord and saviour is a prerequisite to pierce an otherwise impenetrable veil of ontological obfuscation in order to see the unseeable? That deck might not be as cheap as it sounds, one way or the other.

I’m getting a nice learning and productivity bump from LLMs, there are incredible capabilities available. But premature optimization is still premature, and claims of silver bullets are yet to be demonstrated.

[adriand]

Here's an example from this morning. At 10:00 am, a colleague created a ticket with an idea for the music plugin I'm working on: wouldn't it be cool if we could use nod detection (head tracking) to trigger recording? That way, musicians who use our app wouldn't need a foot switch (as a musician, you often have your hands occupied).

Yes, that would be cool. An hour later, I shipped a release build with that feature fully functional, including permissions plus a calibration UI that shows if your face is detected and lets you adjust sensitivity, and visually displays when a nod is detected. Most of that work got done while I was in the shower. That is the second feature in this app that got built today.

This morning I also created and deployed a bug fix release for analytics on one platform, and a brand-new report (fairly easy to put together because it followed the pattern of other reports) for a different platform.

I also worked out, argued with random people on HN and walked to work. Not bad for five hours! Do I know how long it would have taken to, for example, integrate face detection and tracking into a C++ audio plugin without assistance from AI? Especially given that I have never done that before? No, I do not. I am bad at estimating. Would it have been longer than 30 minutes? I mean...probably?

[beepbooptheory]

Just having a 'count-in' type feature for recording would be much much more useful. Head nodding is something I do all the time anyway as a musician :).

I don't know what your user makeup is like, but shipping a CV feature same day sounds so potentially disastrous.. There are so many things I would think you would at least want to test, or even just consider with the kind of user emapthy we all should practice.

[agent281]

I appreciate this example. This does seem like a pretty difficult feature to build de novo. Did you already have some machine vision work integrated into your app? How are you handling machine vision? Is it just a call to an LLM API? Or are you doing it with a local model?

[adriand]

There was no machine vision stuff in the app at that point. Claude suggested a couple of different ways of handling this and I went with the easiest way: piggybacking on the Apple Vision Framework (which means that this feature, as currently implemented, will only work on Macs - I'm actually not sure if I will attempt a Windows release of this app, and if I do, it won't be for a while).

Despite this being "easier" than some of the alternatives, it is nonetheless an API I have zero experience with, and the implementation was built with code that I would have no idea how to write, although once written, I can get the gist. Here is the "detectNodWithPitch" function as an example (that's how a "nod" is detected - the pitch of the face is determined, and then the change of pitch is what is considered a nod, of course, this is not entirely straightforward).

```

- (void)detectNodWithPitch:(float)pitch { // Get sensitivity-adjusted threshold // At sensitivity 0: threshold = kMaxThreshold degrees (requires strong nod) // At sensitivity 1: threshold = kMaxThreshold - kThresholdRange degrees (very sensitive) float sens = _cppOwner->getSensitivity(); float threshold = NodDetectionConstants::kMaxThreshold - (sens * NodDetectionConstants::kThresholdRange);

    // Debounce check
    NSTimeInterval now = [NSDate timeIntervalSinceReferenceDate];
    if (now - _lastNodTime < _debounceSeconds)
        return;

    // Initialize baseline if needed
    if (!_hasBaseline)
    {
        _baselinePitch = pitch;
        _hasBaseline = YES;
        return;
    }

    // Calculate delta: positive when head tilts down from baseline
    // (pitch increases when head tilts down, so delta = pitch - baseline)
    float delta = pitch - _baselinePitch;

    // Update nod progress for UI meter
    // Normalize against a fixed max (20 degrees) so the bar shows absolute head movement
    // This allows the threshold line to move with sensitivity
    constexpr float kMaxDisplayDelta = 20.0f;
    float progress = (delta > 0.0f) ? std::min(delta / kMaxDisplayDelta, 1.0f) : 0.0f;
    _cppOwner->setNodProgress(progress);

    if (!_nodStarted)
    {
        _cppOwner->setNodInProgress(false);

        // Check if nod is starting (head tilting down past nod start threshold)
        if (delta > threshold * NodDetectionConstants::kNodStartFactor)
        {
            _nodStarted = YES;
            _maxPitchDelta = delta;
            _cppOwner->setNodInProgress(true);
            DBG("HeadNodDetector: Nod started, delta=" << delta);
        }
        else
        {
            // Adapt baseline slowly when not nodding
            _baselinePitch = _baselinePitch * (1.0f - _baselineAdaptRate) + pitch * _baselineAdaptRate;
        }
    }
    else
    {
        // Track maximum delta during nod
        _maxPitchDelta = std::max(_maxPitchDelta, delta);

        // Check if head has returned (delta decreased below return threshold)
        if (delta < threshold * _returnFactor)
        {
            // Nod complete - check if it was strong enough
            if (_maxPitchDelta > threshold)
            {
                DBG("HeadNodDetector: Nod detected! maxDelta=" << _maxPitchDelta << " threshold=" << threshold);
                _lastNodTime = now;
                _cppOwner->handleNodDetected();
            }
            else
            {
                DBG("HeadNodDetector: Nod too weak, maxDelta=" << _maxPitchDelta << " < threshold=" << threshold);
            }

            // Reset nod state
            _nodStarted = NO;
            _maxPitchDelta = 0.0f;
            _baselinePitch = pitch;  // Reset baseline to current position
            _cppOwner->setNodInProgress(false);
            _cppOwner->setNodProgress(0.0f);
        }
    }

}

@end

```

[jakubmazanec]

> An hour later, I shipped a release build

I would love to see that pull request, and how readable and maintainable the code is. And do you understand the code yourself, since you've never done this before?

[fauigerzigerk]

I think you have to make a distinction between indvidual experience and claims about general truths.

If I know someone as an honest and serious professional, and they tell me that some tool has made them 5x or 10x more productive, then I'm willing to believe that the tool really did make a big difference for them and their specific work. I would be far more sceptical if they told me that a tool has made them 10% more productive.

I might have some questions about how much technical debt was accumulated in the process and how much learning did not happen that might be needed down the road. How much of that productivity gain was borrowed from the future?

But I wouldn't dismiss the immediate claims out of hand. I think this experience is relevant as a starting point for the science that's needed to make more general claims.

Also, let's not forget that almost none of the choices we make as software engineers are based on solid empirical science. I have looked at quite a few studies about productivity and defect rates in software engineering projects. The methodology is almost always dodgy and the conclusions seem anything but robust to me.