Hacker News new | ask | show | jobs
by scottLobster 100 days ago
I'll add "craftsmanship". It isn't just delivering "A" finished product, you want to deliver a "good", if not "the best", finished product.

I guess if you're in an iterative MVP mindset then this matters less, but that model has always made me a little queasy. I like testing and verifying the crap out of my stuff so that when I hand it off I know it's the best effort I could possibly give.

Relying on AI code denies me the deep knowledge I need to feel that level of pride and confidence. And if I'm going to take the time to read, test and verify the AI code to that level, then I might as well write most of it unless it's really repetitive.

4 comments

I don't think AI coding means you stop being a craftsman. It is just a different tool. Manual coding is a hand tool, AI coding is a power tool. You still retain all of the knowledge and as much control over the codebase as you want, same with any tool.

It's a different conversation when we talk about people learning to code now though. I'd probably not recommend going for the power tool until you have a solid understanding of the manual tools.

It can be a power tool if used in a limited capacity, but I'd describe vibe-coding as sending a junior construction worker out to finish a piece of framing on his own.

Will he remember to use pressure treated lumber? Will he use the right nails? Will he space them correctly? Will the gaps be acceptable? Did he snort some bath salts and build a sandcastle in a corner for some reason?

All unknowns and you have to over-specify and play inspector. Maybe that's still faster than doing it yourself for some tasks, but I doubt most vibe-coders are doing that. And I guess it doesn't matter for toy programs that aren't meant for production, but I'm not wired to enjoy it. My challenge is restraining myself from overengineering my work and wasting time on micro-optimizations.

Meanwhile Linus argued against Debuggers in 2000: https://lwn.net/2000/0914/a/lt-debugger.php3

But then he changed his tune? Even on LLMs...

> I'll add "craftsmanship". It isn't just delivering "A" finished product, you want to deliver a "good", if not "the best", finished product.

I don't raise a single PR that I feel I wouldn't have written myself. All the code written by the AI agent must be high quality and if it isn't, I tell it why and get it to write bits again, or I just do it myself.

I'm having quite a hard time understanding why this is a problem for other people using AI. Can you help me?

If you take the time to read the code and understand it to that level, great. But that sort of belies the promise of vibe-coding, where all software engineers essentially become PMs to a bunch of agents.

I use AI to extract information from documentation and write me bespoke examples, but I'd never feel good relying on code it actually generated without extremely thorough testing and review.

> If you take the time to read the code and understand it to that level, great. But that sort of belies the promise of vibe-coding, where all software engineers essentially become PMs to a bunch of agents.

But why would I do vibe coding? I am releasing this code to production systems that will bring the company down if there is a significant error. And my human peers will give me hell for raising terrible code for review.

I have a helpful, endlessly patient junior engineer with superhuman typing speed who will take all of my advice and apply it exactly as a I want it, and write my code for me. When I see errors, I'll tell it, and I'll even ask it to remember why it is a problem in our code base (maybe not others). So it has memory and (mostly) won't do that again.

And I also make sure to apply the same quality to the tests we write together.

Over the last few months I'd say between 50-80% of code being delivered to our repo is "typed" by agents. Humans are still guiding them and ensuring the quality meets our high standards.

I don't really have a grasp on how other people are working with this stuff that they're seeing problems with production code.

You can use (and create) tools to codify what you think of as "quality".

There's the new frontier for delivering good or the best products. Less relying on the feels of an experienced programmer and more configuring and creating deterministic tools to define quality.

Unless you get actual joy and enjoyment from writing 42 unit tests for a CRUD API with slight variations for each test. Then go ahead =)

That's a really good point. And I agree that kind of confidence in craftsmanship is something that's missing from agentic coding today... it does make slop if you're not careful with it. Even though I've learned how to guide agents, I still have some uneasiness about missing something sloppy they have done.

But then it makes me ask if the agents will get so good that craftsmanship is a given? Then that concern goes away. When I use Go I don't worry too much about craftsmanship of the language because it was written by a lot of smart people and has proven itself to be good in production for thousands of orgs. Is there a point at which agents prove themselves capable enough that we start trusting in their craftsmanship? There's a long way to go, but I don't think that's impossible.

I would argue that craftsmanship includes a thorough understanding and cognitive model of the code. And, as far as I understand it, these agents are syntactic wonders but can not really understand anything. Which would preclude any sort of craftsmanship, even if what they make happens to be well-built.