Instead of spending days updating a software package to the latest version, to get the exact same features I already had, I can focus my time prioritizing features and designing the code infrastructure.
Ask HN: Dealing with Vibe Coding Depression?
11–20 of 27 posts
Re: Ask HN: Dealing with Vibe Coding Depression?
#12Re: Ask HN: Dealing with Vibe Coding Depression?
#13> The painter finds joy in painting, and the result is valued because
Engineers are not painters in one very fundamental way!
Painter’s product is an asset. Software engineer’s code is a liability.
Painter is an artist, creating art. Its primary purpose is in itself.
Software engineer is a craftsman, he creates a mean to an end. A tool to reach product/business goal.
Re: Ask HN: Dealing with Vibe Coding Depression?
#14LLMs allow me to create more. I get to solve more difficult problems. I get to solve more business problems. I get to create more. Instead of spending days updating a software package to the latest version, to get the exact same features I already had, I can focus my time prioritizing features and designing the code infrastructure.
Re: Ask HN: Dealing with Vibe Coding Depression?
#15You’ve got it wrong in the first place! > The painter finds joy in painting, and the result is valued because Engineers are not painters in one very fundamental way! Painter’s product is an asset. Software engineer’s code is a liability. Painter is an artist, creating art. Its primary purpose is in itself. Software engineer is a craftsman, he creates a mean to an end. A tool to reach product/business goal.
Re: Ask HN: Dealing with Vibe Coding Depression?
#16I don’t get it. Is anyone forcing you to vibe code? If you don’t like vibe coding, don’t do it. The time you save when vibe coding is offset almost 1:1 by the time you need to verify the AI’s output for all but the most trivial applications. And even then, were you happy writing trivial code?
I haven't experienced this at all, especially when you can ask the AI to generate unit tests based off of specs.
I'm manually testing AI output twice as much as if I wrote the code myself, but I'm generating code 10x faster so I'm still gaining massive amounts of productivity.
Re: Ask HN: Dealing with Vibe Coding Depression?
#17That's where we are right now. The best bespoke hand-crafted coders are far less valuable than they used to be.
It sucks for the weavers who loved to weave, but this is the consequence of technological progress.
Re: Ask HN: Dealing with Vibe Coding Depression?
#18You’ve got it wrong in the first place! > The painter finds joy in painting, and the result is valued because Engineers are not painters in one very fundamental way! Painter’s product is an asset. Software engineer’s code is a liability. Painter is an artist, creating art. Its primary purpose is in itself. Software engineer is a craftsman, he creates a mean to an end. A tool to reach product/business goal.
I got into programming originally because for me it was an act of creation in a very similar way to my sketches and paintings at the time. Software can be art. Interactive art, in fact - so, much 'more' than a painting in some dimensions. Sure, often at work you are creating a means to an end. A painting can be a means to an end in the same way that software can - so many artists take commissions or work for bigger c…
End product is an asset, not the implementation details. That's the truth, regardless of how you or I feel about it.
That doesn't mean there is no beauty in the craft of writing the code etc. But it's not the key part.
Re: Ask HN: Dealing with Vibe Coding Depression?
#19Earlier quoted context omitted.
I got into programming originally because for me it was an act of creation in a very similar way to my sketches and paintings at the time. Software can be art. Interactive art, in fact - so, much 'more' than a painting in some dimensions. Sure, often at work you are creating a means to an end. A painting can be a means to an end in the same way that software can - so many artists take commissions or work for bigger c…
Act of creation of a product for sure, not lines of code. End product is an asset, not the implementation details. That's the truth, regardless of how you or I feel about it. That doesn't mean there is no beauty in the craft of writing the code etc. But it's not the key part.
For folks who love software, it absolutely is a key part. Donald Knuth titled his book series "The Art of Computer Programming" for a good reason. It taps into the human creative impulse under a compelling set of technical constraints.
Generative AI in any form has the effect of forcing us toward the vanguard, to create something genuinely new or humanly beautiful if it is to be at all valued by others -- whether that novelty/beauty is because of the unique constraints of your company's internal software ecosystem or because you're striking out and building something others haven't built before (even a novel combination of existing ideas).
Novelty is very hard for most people, but perhaps the beauty (in the classical sense) of software projects[0] can still be recovered. Human agency always will be a powerful thing. (And there will always be other people for whom to create things.)
[0] 37Signals has always exhibited a compelling sense of joy in the process of creating beautiful software for people.
Re: Ask HN: Dealing with Vibe Coding Depression?
#20Earlier quoted context omitted.
Act of creation of a product for sure, not lines of code. End product is an asset, not the implementation details. That's the truth, regardless of how you or I feel about it. That doesn't mean there is no beauty in the craft of writing the code etc. But it's not the key part.
> That doesn't mean there is no beauty in the craft of writing the code etc. But it's not the key part. For folks who love software, it absolutely is a key part. Donald Knuth titled his book series "The Art of Computer Programming" for a good reason. It taps into the human creative impulse under a compelling set of technical constraints. Generative AI in any form has the effect of forcing us toward the vanguard, to c…
Those are the folks from early days when it was more about math (which is an art) and exploration rather than about actual software _engineering_.
If you're building new algorithms, new computers etc. - yes, your product is the tool itself. But this is a very limited case these days.
Unfortunately many folks drag this attitude in their business software domain and this leads to overengineering and redundant complexity.
With experience you can smell if this part of codebase was mostly made by folks who just like engineering for the sake of it, rather than people trying to reach the business goal in a reasonable time/cost. And this smell is terrible.