Live data from Hacker News

What AI coding costs you

tomwojcik.com

101–110 of 206 posts

Re: What AI coding costs you

#101
I have a few parallel AI-authored side projects on the go that have quite different shapes, and I feel quite different things about each

1. A survival horde game (like Vampire Survivors and Brotato). At the moment it's very primitive, very derivative (no new ideas) and not much fun. I have no sense of pride over it, but it is much further along than it would be if i'd been writing it from scratch. I expect once I invest in the fun side (gameplay innovations, graphics) i'll feel a greater sense of attachment, and I plan to do all the art assets myself.

2. A MacOS web app for managing dev env processes, works but is ugly. I don't have confidence in AI making a remotely presentable UI, so I'll be doing that part myself.

3. A useful little utility library. The kind of thing that pre-LLM would've been too far out of my expertise to be motivated to try making. I'm steering the design of it quite heavily, but haven't written any code. It seems like it's already capable of doing very useful things, and I oddly feel quite proud of it. But I have a weird sense of unease in that I _think_ it's good, but I don't _know_ it's good.

I think the main thing I'm learning is to make sure there's always something of yourself in whatever you produce with the help of AI, especially if you want to feel a sense of accomplishment. And make sure you have a good testing philosophy if you're planning to be hands-off with the code itself.

Re: What AI coding costs you

#102
post #8
post #5

[dead]

The biggest problem is it’ll teach you bad habits. For example, Claude and gpt love to use fallbacks. They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient. If you don’t have past knowledge you might just think that’s how it is. Now before someone says that junior devs make the same mistakes, yes, to some extent.

> They generate code that’ll get a positive result at any cost, even if it’s horrible in efficient.

If only efficiency is the only problem with that. Sometimes an error state should an error. This is the equivalent of eating all exceptions and pretending all is fine. It just means nothing works.

Re: What AI coding costs you

#103

I enjoyed the article, though I do have to pick nits with: > Software used to be deterministic Ah, someone fortunate enough to have never coded a heisenbug or trip over UB of various causes. I've written plenty of well structured, well thought out mostly-deterministic software, then spent hours or days figuring what oversight summoned the gremlins. (There is one low priority bug I've occasionally returned to over the…

all code is deterministic for a given input. If you don't understand the behavior, it's because you don't understand the complete set of inputs into the system. Assuming you're not tripping over some hardware defect, it sounds like you're using a gcc hack that llvm doesn't support for a display update, sounds like memory ordering

Re determinism: that's what we'd like to believe, but it's true only if we redefine input to include overall build and execution context, and the latter is generally unreproducible. Over the last few years I've seen plenty of subtle bugs, some caused by UB, some caused by interactions with the overall execution environment, that resulted in mostly correct but sometimes wild and haphazard results, all for the same "input".

Once these bugs were fixed, things became deterministic, but to say that all software is deterministic is to assert some level of programming, build, and operational consistency that is often achievable with great effort.

Re gcc hacks: nope. No gcc'isms anywhere in the code, all warnings enabled, no warnings produced, just one case where a field is not updated in one very specific set of circumstances. Thanks for the suggestion, but that was one of the first things we thought of. There is a slight chance that it is actually a clang/llvm call stack depth bug, but the effort to reproduce that outweighs the impact of the bug, what with one thing and another not relevant here.

UB -> occasional non-determinism.

Re: What AI coding costs you

#104
post #66

Writing code by hand and managing the mental model of its execution and architecture is one of the few remaining joys of my day job, apart from delivering a good product people want and use and being helpful. Even the small things, the tedious chores of refactoring or scaffolding that initial bit of CRUD boilerplate are steps that matter to me. The callouses matter. The tedium matters. These moments of pain and drudg…

That’s why I laugh when people are like “oh, AI writes all the tests, it’s so much easier.” If your code is hard to test, you need to change the abstraction or the interface. Tests are the first reuse of your code, so if it’s a pain to use in tests, it’s going to be terrible to use in general.

Not to mention that tests are at least as critical to get right as the code that is being tested.

Re: What AI coding costs you

#105
post #12

Earlier quoted context omitted.

> The act of writing code by hand seems to be on a trajectory of irrelevance It does not. English (or any human language) is an awful language to write specifications in, because it is not as precise as code. Each time you "compile" your prompt into a program, LLMs spit up something a little bit different. How is it a good thing? > so as long as I maintain my ability to reason about code (both by continuing to read i…

> Each time you "compile" your prompt into a program, LLMs spit up something a little bit different. How is it a good thing? Because that’s not how it works. How can we have a discussion about this topic if we don’t have a mutual understanding of how the tools even work? The code is not replaced by English prompts. The code still exists.

Yes, it exists, but are you going to edit it by hand if you didn't write it in the first place, or you would rather throw another prompt to update it? People tend to do the latter, thinking about the code as some generated artifact, like object files.

Re: What AI coding costs you

#106

Writing code by hand and managing the mental model of its execution and architecture is one of the few remaining joys of my day job, apart from delivering a good product people want and use and being helpful. Even the small things, the tedious chores of refactoring or scaffolding that initial bit of CRUD boilerplate are steps that matter to me. The callouses matter. The tedium matters. These moments of pain and drudg…

Completely resonate with this. There don't seem to be many of us, at least in my online bubble, but you're not alone.

I believe and hope eventually we'll come around to valuing people who have put in the work - not just to understand and review output but to make choices themselves and keep their knowledge and judgement sharp - when we fully realize the cost of not doing so.

Re: What AI coding costs you

#107

Earlier quoted context omitted.

I don't have a contract with AI.

It was meant metaphorically. It gives you something, but it asks for something in return.

"Cost" is a matter of personal judgement. Personally, using AI hasn't cost me anything.

Re: What AI coding costs you

#108
post #62

While I agree with a lot of what this post says, to play devil's advocate for a moment, It's natural that skills we no longer need should be phased out. We should take this as an opportunity to figure out what new skills we need now. If you're working on a personal project or trying to learn something new, by all means write the code yourself. That's still the best way to do it. But your life should not necessarily r…

The problem is this is the difference between one or two obscure skills fading away with disuse (normal); and potentially all ability to load programming information into your working memory being affected; as you didn't develop the neural pathways or knowledge of the codebase (not normal or desirable)

While it is a spectrum around when you choose to use AI, what seems increasingly common in my experience is some people trying to go "all in", feel frustration and burnout when they are relegated to babysitting an LLM; get angry that it has made a mistake, misinterpretation or simply left something obvious out; then thinking it's user error/they didn't prompt well enough/it is their fault. At the same time, they are increasingly cognitively blind to mistakes at a review stage, so they find out the hard way in production and enter into a cycle of hyper vigilance/distrust/justifiable paranoia.

In those cases, it's a recipe for skills loss and depression over the long term and a vicious cycle.

Re: What AI coding costs you

#109

It remains unclear to me why my ability to read and review code (the majority of my job for years now) will atrophy if I continue doing it while writing even less code than I was before. If my ability to write code somehow atrophies because I stop doing it, does that matter if I continue with the architecture and strategy around coding? The act of writing code by hand seems to be on a trajectory of irrelevance, so as…

How do we maintain best practices when the compiler outputs a different result for the spec at any given time? How do we obtain reproducible builds? Do we pin to a specific version of our compiler (ie, snapshot of the model; is this possible anywhere except local currently?), and vigorously test changes after any updates in our "toolchain"? How do we have control over our "toolchain" (again, apart from local), especially when said "toolchain" can, for all its users simultaneously, fold to political pressure from state regimes? And, if the code generated by LLMs is the build artifact, why is it now okay to check the build artifact into source control?

There may come a day when we, as an industry, decide that simply doing it by hand is more expedient when it comes to resolving urgent production issues. We may not know the pain we are causing ourselves until well into the future when it has become too much to bear without a visit to the proverbial doctor.

Re: What AI coding costs you

#110
post #82
post #73

Earlier quoted context omitted.

FWIW, I'm responsible for our engineering team, and I'm the one starting to put some gentle pressure on the developers right now. Velocity used to be one of the bigger issues we had: Features used to be in development over weeks, while customers, product management, and engineers iterated on the feature, until it was finally deemed stable enough and shipped. With AI, we can shorten that cycle considerably, and get st…

> it feels irresponsible And it is. You are going to end up with a wreck of a product and not a single person you can call upon to fix it. It is your choice and you will pay for it.

A wreck of a product is still better than being out of business by not being able to release fast enough. Unfortunately, the market in general does not reward slow high quality.
Post reply on HN