I was just thinking... "BugHog? The platform famously broken more often than not?"
We have a whole posthog interface layer to mask over their constant outages and slowness. (Why don't we ditch them entirely? I, too, often ask this, but the marketing people love it)
It sounds like there’s another failure here, which you could have documented. If the test team didn’t understand what they were meant to test, that’s a failure of communication. Simply saying “they were wrong” is not sufficient exploration of the failure so, if that’s the point your manager was making, I agree with them. Blaming a third party for misunderstanding is less useful than seeking to improve the clarity of your own communication.
I think this and other recent posts here hugely overcomplicate matters. I notice none of them provides an A/B test for each item of complexity they introduce, there's just a handwavy "this has proved to work over time".
I've found that a single CLAUDE.md does really well at guiding it how I want it to behave. For me that's making it take small steps and stop to ask me questions frequently, so it's more like we're pairing than I'm sending it off solo to work on a task. I'm sure that's not to everyone's taste but it works for me (and I say this as someone who was an agent-sceptic until quite recently).
I've been through the last ~10 or ~15 posts on his Medium this evening, to check. Sentence-by-sentence I don't see anything that goes beyond "what if". Can you share some of the quotes you have in mind?
I think this is an interesting phenomenon, because it seems that lots of people throw personal insults at him (not saying that's you btw) without addressing the meat of whatever they're reacting to.
And lest we forget! One of the founding essays [1] of this very website discusses it: if you're slinging ad hominem attacks or personal insults around, you're by definition losing the "argument" (not that I think this qualifies as an "argument").
Not much, but just confirmation that it's in the expected part of the sky is quite exciting. There's a probable capture of it from Perseverance here (it's just a tiny faint smudge):
As one of the curious minority who keeps trying agentic coding but not liking it, I've been looking for explanations why my experience differs from the mainstream. I think it might lie in this nugget:
> I believe with Claude Code, we are at the
> “introduction of photography” period of
> programming. Painting by hand just doesn’t
> have the same appeal anymore when a single
> concept can just appear and you shape it
> into the thing you want with your code review
> and editing skills.
The comparison seems apt and yet, still people paint, still people pay for paintings, still people paint for fun.
I like coding by hand. I dislike reviewing code (although I do it, of course). Given the choice, I'll opt for the former (and perhaps that's why I'm still an IC).
When people talk about coding agents as very enthusiastic but very junior engineering interns, it fills me with dread rather than joy.
> still people paint, still people pay for paintings
But in what environment? It seems to me that most of the crafts that have been replaced by the assembly line are practiced not so much for the product itself, but for an experience both the creator and the consumer can participate in, at least in their imagination.
You don't just order such artifacts on Amazon anonymously; you establish some sort of relationship with the artisan and his creative process. You become part of a narrative. Coding is going to need something similar if it wants to live in that niche.
I totally get this side of things. I see the benefits of Agentic coding for small tasks, minor fixes, or first drafts. That said, I don't understand the pseudo-tribalism around specific interfaces to what amounts to only a few models under the hood and worry about what its doing for (or not doing for) junior devs.
Also, if we could get AI tooling to do the reviews for us reliably, I'd be a much happier developer.
I don't think it's a complete good comparison. In the past painting was the only way to depict real world events, but painting is also art, and it often doesn't necessarily depict reality, but the artist's interpretation of it. That is why people still paint.
So yeah if you like coding as an art form, you can still keep doing that. It's probably just a bit harder to make lots of money with it. But most people code to make a product (which in itself could be a form of art). And yeah if it's faster to reach your goals of making a product with the help of AI, then the choice is simple of course.
But yeah in a way I'm also sad that the code monkey will disappear, and we all become more like the lead developer who doesn't really program anymore but only guides the project, reviews code and makes technical decisions. I liked being the code monkey, not having to deal a lot with all the business stuff. But yeah, things change you know.
A more apt metaphor is moving from hand-tools to power-tools.
The painting/photography metaphor stretches way too far imo - photography was fundamentally a new output format, a new medium, an entirely new process. Agentic coding isn't that.
All source code is technical debt. If you increase the amount of code, you increase the amount of debt. It's impossible to reduce debt with more code. The only way to reduce debt is by reducing code.
(and note that I'm not measuring code in bytes here; switching to single-character variable names would not reduce debt. I'm measuring it in statements, expressions, instructions; reducing those without reducing functionality decreases debt)
I'll try a counterargument. If more code is more technical debt then writing more succinct code is less technical debt. But succinct code is often harder to grok and maintain than code written for the average Joe dev. So less code can sometimes mean less maintainability and thus more technical debt.
I think you instead meant to say more business logic implemented in code is more technical debt, not necessarily just more code.
No, I really mean more code. It's an unpopular opinion I know, but I think debt scales linearly with code, mainly because I also think bugs scale linearly with code. I recognise that readability and maintainability are important, but it doesn't change the basic equivalence of code = debt for me.
