mrloba

No, I said that not everything is about the result itself, but also the process behind it. I value that process. You'll have to ask the philosophers about value judgements, but to me it's just because I'm a human and evolution made me care about other people, how they think and act. For me, then, it _feels_ different reading something if it's made by a human. It tells me something about that person and I feel I get to know them, if only a little bit.

Same reason I value home made cooking, home made furniture, and my kids drawings. Not everything is about the result itself. The process is important to me. Knowing that there is a human on the other side matters. In fact, learning that there is/isn't changes my perception entirely.

If AI replaces programming it will indirectly replace a lot of other jobs as well, just by good ol' automation

Human accomplishment is a predictor of future accomplishment. AI not as much.

Human effort signals value, AI does not.

Human effort is often inviting collaboration. AI rarely does.

I really doubt spec driven development is gonna last. As before, creating working software and iterating on it is faster and makes it easier to understand what you thought you wanted but don't, even if it's vibe coded. So, hello agile, welcome back.

That depends on how many details I specify. If I specify a lot, I usually get what I want. But in the extreme this is just another form of coding (high quality code is quite similar to a detailed spec). In many cases I find I have to do many "passes" to get the right balance of correctness, performance, security, and clean architectural boundaries. Having a loop to fix these often makes it worse since they can often be contradictory.

There's also some types of code that I believe is often wrong in the training data that is almost always wrong in the LLM output as well. Typically anything that should have been a state machine, like auth flows, wizards, etc.

When all is said and done I think the main savings come from the high throughput of low-value generic solutions. I don't currently see this changing, and the reason is that high quality products cannot be generated without specifying a lot of details. Of course, we may not want quality.

Well they then use more AI to try to fix the PR, which leads to many more rounds of the same. It's like I'm coding using an AI except through a real person who mangles the prompt. I've had some success as well in talking people out of it, but it feels like I'm gonna lose eventually

It is everywhere. Even on birthday invites for my kids there's nonsense from an LLM. At work I review PRs with code that doesn't even run. Doing research is harder than ever as more and more references are completely made up.

We're too lazy and too obsessed with getting ahead to use this technology responsibly in my opinion.

One of my favourite features in n++ is to enable "show all characters". Discovered a lot of weird end-of-line and bom issues like that

I always found that a simple merge style patch is enough, and a lot simpler. You just have to know that there is a difference between null and undefined. For large arrays, it's usually some sort of bulk operation that can be solved by an array of patch/delete requests, which is both safer and simpler. Maybe I've just not hit a proper use case for this yet

The problem with this standard is all the free text and bank specific fields that banks will use instead of the standard. One bank I integrated with had the equivalent of "Our fee is 5.65" in a text field which you had to parse, instead of the field for fees. Of course, the language of that string could also change. Fun times

Then you should store the time as well, because the number of decimals in a currency can change (see ISK). Also, some systems disagree on the number of decimals, so be careful. And of course prices can have more decimals. And then you have cryptocurrencies, so make sure you use bigints

I agree, and I just want to highlight what you said about generating a config file. It's extremely useful to constrain the config itself to something that can go in a json file or whatever. It makes the config simpler, easier to consume, and easier to document. But when it comes to _writing_ the config file, we should all use a programming language, and preferably a statically typed language that can check for errors and give nice auto complete and inline documentation.

I think aws cdk is a good example of this. Writing plain cloudformation is a pain. CDK solves this not by extending cloudformation with programming capabilities, but by generating the cloudformation for you. And the cloudformation is still a fairly simple, stable input for aws to consume.

Has anyone had any success in code generation? I feel like chatgpt usually completely fails to write even a small function correctly unless it's a very trivial or well known problem. I usually have to go back and forth for a good long while explaining all the different bugs to it, and even then it often doesn't succeed (but often claims it's fixed the bugs). The types of things it gets wrong makes it a bit hard to believe it could improve enough to really boost dev productivity this year.