Live data from Hacker News

I'm going back to writing code by hand

blog.k10s.dev

471–480 of 656 posts

Re: I'm going back to writing code by hand

#471

Earlier quoted context omitted.

I felt the same with: "it takes too much effort to get the output production ready" turning into "maybe long term the maintenance will be more expensive" I give it three months until people realize that you rarely need to review every single line and fully understand the code, like so many comments are claiming.

If you work on a product that has an existing user base that has an expectation that things will still work then you definitely still need to read the code. LLMs frequently break things or introduce subtle incompatibilities. Maybe on projects with no users you can yolo things.

It's not about the number of users but the kind of software you develop.

In a mobile app, do you think it's more important to test that your drag gesture works as expected on the phone, or to understand every line of the implementation?

Re: I'm going back to writing code by hand

#472

Earlier quoted context omitted.

If they were equivalent, people would be committing the prompts and not the code

And then getting bugs when they use a new version of the AI, just like people occasionally got bugs when they upgraded to new versions of the compiler...

they would get bugs on every invocation of the software, not on a new version of the AI. it's equivalent to your compiler have a RAND function in it where it chooses between a billion different options every time it compiles, it's absolutely not equivalent to a compiler having a bug.

Re: I'm going back to writing code by hand

#473

Earlier quoted context omitted.

Avoiding abstractions "because I like to save time" doesn't sound like something a professional software engineer should ever say

Yea because having 200 different abstractions and DSLs makes stuff easier for sure! Why not use all the stuff that was popular 6 years ago like Prisma, GraphQL and Redux, whoops suddenly you need a whole team of devs knowing all kinds of unecessary abstractions.

Based on the examples you provided, I think the term you're looking for is "external dependencies" not "abstractions"

Edit: Incidentally, I tend to treat "code made by an LLM" and "external dependencies" pretty much the same. Pretty low trust, with a strong interface between it and any code that matters

Re: I'm going back to writing code by hand

#474

When it was Copilot tab-completing lines, people would say, "yea, but you still have to make sure you're the one writing the whole functions". Then when it was completing functions, people would say, "yeah, but you still have to make sure you're the one writing the logic around the functions" Then when it was completing the logic around the functions, people would say, "yeah, but you still have to make sure you're th…

The "people" in your hypothetical story have been wrong the whole time. The correct attitude is: When AI can complete lines, you still have to read and understand the code. When AI can complete whole functions, you still have to read and understand the code. When AI can complete features and tickets, you still have to read and understand the code.

Precisely. And this is why all the MCP servers that people at my company are writing aren't worth using: their apparent goal is automate as much as possible. They're encouraging people not to pay attention. This results in bad code, bad tests, and bugs.

Re: I'm going back to writing code by hand

#475
post #183
post #165

That’s the same story I had. The swindle goes like this, AI on a good codebase can build a lot of features, you think it’s faster it even seems safer and more accurate on times, especially in domains you don’t know everything about. This goes in for a while whilst the codebase gets bigger and exploration takes longer and failure rate increases. You don’t want it to be true and try harder so you only stop after it pra…

I find it interesting that this outcome is a surprise. I don't want this to sound smug, I'm genuinely curious what the initial expectations are and where they come from. They seem to be different for LLMs, because would anyone be surprised if they handed summary feature descriptions to some random "developer" you've ever only met online, and got back an absolute dung pile of half-broken implementation? For some reaso…

Receiving an absolute dung pile of half-broken implementation is honestly what I expect from most working software engineers. Now the step where they spend even a second thinking about what they are doing has been removed. My job as a principle engineer became doing most of the thinking for people and then providing the only worthwhile code reviews before LLMs became a thing. LLMs just made these people even less useful and my job became even more about reviewing their low quality work that I could have done in less time manually.

LLMs also don't solve the much bigger problem of most software engineers having no ability to work with others to clarify requests or offer alternatives. So now bad and/or misunderstood requests can be implemented faster.

Re: I'm going back to writing code by hand

#476

Earlier quoted context omitted.

This is great until the "gun to your head" is your skip-level manager demanding that a feature be implemented by the end of the week, and they know you can just "generate it with AI" so that timeline is actually realistic now whereas two years ago it would have required careful planning, testing, and execution.

Well, that's nice. Your manager is unknowingly helping you create a form of job security for yourself, with all the technical debt and bugs being accumulated. He might not understand it, and it might not be the type of work you want to do, but someone is going to have to fix those issues. And the longer they wait, the bigger the task gets.

The bet that management is making is that the AI will continue to improve and that it will be able to fix those issues on the cheap - so far this has proven to be true for us. We use AI to generate code at scale, that code has issues at scale, so we use AI to fix those issues.

Re: I'm going back to writing code by hand

#477

Earlier quoted context omitted.

Avoiding abstractions "because I like to save time" doesn't sound like something a professional software engineer should ever say

Yea because having 200 different abstractions and DSLs makes stuff easier for sure! Why not use all the stuff that was popular 6 years ago like Prisma, GraphQL and Redux, whoops suddenly you need a whole team of devs knowing all kinds of unecessary abstractions.

> Prisma, GraphQL and Redux, whoops suddenly you need a whole team of devs knowing all kinds of unecessary abstractions.

Ah, let me guess / you're one of those non-technical PMs who can finally shove it to the devs - by spitting out unreadable HTML storing all it's data in a flat file? Oh boy, do I have news for you...

Re: I'm going back to writing code by hand

#478

Earlier quoted context omitted.

This is great until the "gun to your head" is your skip-level manager demanding that a feature be implemented by the end of the week, and they know you can just "generate it with AI" so that timeline is actually realistic now whereas two years ago it would have required careful planning, testing, and execution.

If the manager is unreasonable, you were always going to have a problem with them, eventually. Nothing you can do with fix this. If manage is reasonable, you can explain to them that there isn't time to check the work of the AI, and that it frequently makes obscure mistakes that need to be properly checked, and that takes time. At this point, if they still insist you just give it the AI's work, they've made a decisio…

The problem is that this mode of operation for them works - they get the features made in a fraction of the time it used to take, the feature does what it says on the tin, they feel good about pushing the product in a specific direction. If something goes wrong, the AI can fix it, too.

I'm not sure that there's really a "bomb" hiding in here anywhere. The issue is that it IS "reasonable" now to expect big features to be done within a week.

Re: I'm going back to writing code by hand

#479
post #151

I always find these kinds of posts interesting, to compare the velocity that people seem to get with Ai, vs what I get by just coding by hand Coincidentally I've been working on a project for about 7 months now: its a 3d MMO. Currently its playable, and people are having fun with it - it has decent (but needs work) graphics, and you can cram a few hundred people into the server easily currently. The architecture is p…

This is probably because the people who feel like they receive the most benefit from LLMs never actually knew much about or were just incapable of writing good software before they started using LLMs.

Re: I'm going back to writing code by hand

#480
post #264

Earlier quoted context omitted.

If you know how to write good code you can force AI to write good code with various techniques. It's 100% doable. You just need to figure out the problems AI has and find solutions to make it easier for it. Ex: extremely small contexts Modularize to modules with clear boundaries and only allow the AI to work within those boundaries. Make modules pure from IO so they are easily testable. Hide modules behind interfaces…

That doesn't quite work, and precisely for the reason I mentioned: You can definitely tell the AI to follow some strategy, but at some point the strategy will need to change, and the AI won't tell you that (even if you tell it to). Unless you read the code every time you won't know if the AI is following the strategy and producing good results or following it and producing bad results because the strategy has to chan…

This is reductive. What you're describing already happened in codebases without AI. LLM's just speed up thing because they are a great calculator and not a replacement for human input.
Post reply on HN