Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

I'm going back to writing code by hand

blog.k10s.dev

Post reply on HN
Print view View original

361–370 of 656 posts

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

#361

Post by ChicagoDave »

throwaway173738 wrote: post #307
lukan wrote: post #291

Earlier quoted context omitted.

How do you define "bad code"? If I instruct the AI to make small modules where I can verify they work, have tests and no side effects - then it is good enough code for me. It works, is readable and can be extended - and will turn into bad code if this is not done with care.

The concept of a small module is an architecture invariant. You’re making that decision, not the LLM. And you’ve made that decision because the machine is not good at certain things. You’re doing that because you can’t trust the LLM to make that decision on its own.

I’m doing it because as a DDD adherent, I’ve been building software that way for 15 years without GenAI and now with GenAI I can do it faster.

You can’t play whack-a-mole with GenAI. You have to start from well-known principles and watch everything it produces. Every module or bounded context has to have its own invariants.

You can’t fully automate software engineering with GenAI. It seems the vast majority of GenAI users think they can and end up in the same place as the OP.

Maybe learn Domain-Driven Design, Event Sourcing, and then try again. The results will be dramatically improved.

https://devarch.ai/

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

#362

Post by yakattak »

sirwhinesalot wrote: post #277
IdiotSavage wrote: post #260

Earlier quoted context omitted.

So, basically you need to micro-manage it. Where are your 10x gains now? And is it fun to work like that?

This is actually what I do. I'm extremely picky about the code and force the LLM to rewrite it 1000x times until it is basically exactly what I want. You might be wondering what is the point when it would be faster for me to just write the code myself? I have ADHD and for whatever reason telling the LLM what to do instead of doing it myself bypasses the task avoidance patterns and/or focus problems I tend to suffer f…

This is kind of how I feel I think. Putting pen to paper for me is hard.

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

#363

Post by SpaceNoodled »

herdcall wrote: post #306
raincole wrote: post #290

Earlier quoted context omitted.

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.

I'm no longer sure you have to, actually. I mean, we do trust the assembly that compilers produce without having to read it, don't we? We're rapidly getting to that stage with LLMs, IMO.

I've actually taken to double-checking the assembly in some instances. There are surprising times that the compiler won't make the shortcuts and optimizations you thought it should, and I also used this method to call out an unsuitable compiler since I caught it spitting out some ridiculous 10x-long set of instructions in certain critical instances.

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

#365

Post by echelon »

fancythat wrote: post #338
echelon wrote: post #216

Earlier quoted context omitted.

This was made in two days of vibe coding. It has flaws, but it's impressive as hell: https://tinyskies.vercel.app/ It's got a fun Zelda-inspired mechanic (I won't say which one), and you'll have to unlock abilities and parts of the world over several quests and modes to "win". It's also multiplayer.

Unless there is a way to see or check the whole prompt that made this game, it is hard for me personally to say if this is impressive or not as I don't know what percentage of this was vibe coded. I also see there is an incentive to skew the truth here, as there is a substantial prize pool and that usually makes people become very creative. In the past, I was trying to reproduce vibe coding results when I managed to…

He's been fairly forthcoming about his process:

https://x.com/DannyLimanseta/status/2052040017007251946

Here are the direct links:

https://github.com/dannylimanseta/tinyskies

https://github.com/dannylimanseta/tinyskies/blob/cursor/glob...

https://github.com/dannylimanseta/tinyskies/blob/cursor/glob...

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

#366

Post by wombat-man »

perarneng wrote: post #256
pron wrote: post #192

Yep. The only people I've heard saying that generated code is fine are those who don't read it. The problem is that the mitigations offered in the article also don't work for long. When designing a system or a component we have ideas that form invariants. Sometimes the invariant is big, like a certain grand architecture, and sometimes it’s small, like the selection of a data structure. You can tell the agent what the…

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…

Yeah I agree. It's improved quite a bit just in the past few months. The code should always be reviewed, and you need to spend some time tuning your skills and agent configs. If you're still getting bad code out of your LLM tooling, you might not be using or configuring it correctly.

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

#367

Post by raincole »

jstummbillig wrote: post #303
raincole wrote: post #290

Earlier quoted context omitted.

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.

Not at all. Code is not important, intent is. The leader of a product/company does not have to read code. It doesn't matter if it is generated by humans or non-humans. It simply needs to be correct enough to be usable and then steerable towards better outcomes. Understanding of code never existed from the business perspective.

> The leader of a product/company does not have to read code.

Yeah, because they believe (sometimes wrongly) their subordinates read it.

> Understanding of code never existed from the business perspective.

It does, it's called organizational wisdom and domain knowledge, because you need those witty names to sell books to aspiring managers.

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

#368

Post by lo_zamoyski »

marginalia_nu wrote: post #171
IanCal wrote: post #131

Earlier quoted context omitted.

This is fine if it’s more enjoyable for you, that’s what’s important in personal projects most of the time. But we don’t follow the same things for dependencies, work of colleagues, external services, all the layers down to the silicon when trying to work. Why is AI suddenly different? We just have to do this by risk and reward. What’s the downside if it’s wrong, and how likely is an error to be found in testing and…

It is and has always been immensely helpful to understand what you are doing in any context. There are some programmers who treat the job as just plumbing together what is to them completely incomprehensible black boxes, who treat the computer as a mystery machine that just does things "somehow", but these programmers will almost always be hacks that spend their entire career producing mediocre code. There are things…

That's a little simplistic and lacking in nuance.

> To get beyond being a hack, you need to understand the entire stack, including the code that you didn't write, including both libraries, frameworks and the OS, and including the hardware, the networking layers, and so forth.

I think maybe you overestimate your own knowledge here. It's one thing to understand general principles and design or to understand a contextually-relevant vertical or whatever. It's another to demand comprehensive (even if not expert) familiarity in non-trivial projects, especially those created by many developers over long time spans. It's not just a question of intelligence or dedication or even just time spend working on a project.

The amount of software even your typical piece of code relies on is staggering and shifting, and it's only getting more complicated. A good chunk of software engineering and programming language research has been focused on making it practical to operate in such an complex environment - an environment that nobody fully understands - which is a major part of why modularity exists. Making software like "plumbing together [...] black boxes" is exactly what such research aspired to accomplish, because it allows different developers to focus on different scopes and focus on the domain they're working on. Software engineering is a practical field, and any system that requires full knowledge to operate, modify, and extend is either relatively small (maybe greenfield and written by a sole developer) or impractical to work with.

So I would say there's a wide gap between "lazy guy who doesn't give a shit" and "guy who thinks he can understand everything". Both lack the humility and wisdom needed to know the limits of their knowledge, to circumscribe what he needs to understand, and to operate within the space these afford. (Both extremes remind me of cocky junior devs. On the one hand, you have the junior dev who carelessly churns out "hot shit" garbage code by plumbing things together with no grasp or appreciation of sound design; on the other you have the dev who makes a big show about "rigor" completely detached from the actual realities and needs of the project. In each case, the dev is failing to engage intelligently with the subject matter.)

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

#369

Post by keybored »

djeastm wrote: post #275

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…

There are always people who will disagree, no matter how amazing something is, and they naturally respond with concerns close to the locus of the LLMification. It would be absurd to respond to “AI autocomplete is great now” with “but you still need to architecture your code”. What’s people saving seconds writing code minutiae got to do with architecturing the code?

This blob of people criticizing AI is just that, a blob. A gaggle of discrete people that your brain makes up a narrative about being some goalpost shifting entity.

Of course there could be individuals who have moved the goalposts. Which would need a pointed critique to address, not an offhand “people are saying” remark.

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

#370

Post by gonational »

thunky wrote: post #230
jwpapi wrote: 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…

> You look at the code again and there is so much code spaghetti is an understatement it’s the Chinese wall. I don't understand this. A large codebase should be a collection of small codebases, just like a large city is a collection of small cities. There is a map and you zoom into your local area and work within that scope. You don't need to know every detail of NYC to get a cup of coffee. Its your responsibility to…

It's not that you can't "build a sane architecture" as much as it is difficult to justify the time spent to do this when you can "bang out features" in 10 minutes that would take days to do manually. It's about the economics of code generation. When inventing structure and typing it out as code takes time, thinking deeply about architecture first makes sense. There is another factor, as well: "thinking deeply about the architecture" involves experimentation. You might go down a particular path while coding, and then realize some limitations and/or new ideas, etc. You ultimately craft something that will work well and play well with future code, and which may be easily understood. If somebody stops by your desk and says, "you finish that yet?", that'll be the last time you think deeply about anything at work.

Rather than arguing about the specifics, it's easier to point to numerous concrete examples, such as a fairly simple system - which should be easy to implement in 8-15k lines of code, depending on certain choices (I've been writing code long enough to estimate this relatively accurately) - being still-incomplete while approaching 150k lines. These kinds of atrocities are usually economically infeasible in hand-written code, for 2 reasons: 1) the cost to produce that much code is very high, and 2) the cost of maintaining that much code is insurmountable.

I guess you could say that AI is great at generating code that only AI can understand and maintain.

Post reply on HN