Commit messages, comments and function names are hard to come up with, that's why we spent years to argue on maximizing value. We also learned to pay attention because we new that this particular name is like that with a reason.
Now it's hard to pay attention to code comments and commit messages because costs to produce them is zero and llm doesn't care about communication and your attention budget
All above comes at a cost of author slowly starting to understand less and less code in their own projects.
Then in other projects as well.
After the initial boost is over they will have to pay money just to stay afloat because they have already outsourced their thinking.
I’m not anti AI, but I’m very worried about this bragging “you are not better engineer if you do things yourself”. Yes, you are, it all comes in small details.
Humans are highly dependent on the environment; you can blame people for eating too much of highly processed food and lots of sugar, but that's what happens if all you see around is highly processed food and sugar
About year and a half ago I put together code review guide for human-written code to help my team speed things up and show how to operate based on trust, respect, and mutual goals;
This aged well and now the same article shared as a prompt guides LLMs to review generated code focusing on understanding and maintaining consistency in a codebase
a lot of cool-looking stuff in my ECS is supported by Swift parameter packs; however, once you start using them a lot you find limits pretty soon.
One example: the following wouldn't compile in swift:
func query<each T, each K>(
_ body: ((repeat each T), (repeat each K)) -> Void
) { ... }
so you kinda work around it with extra type wrappers but this looks ugly - I've been using macros to hide some of the ugliness away xD
edit: the example is oversimplified just to show the point - in this example compiler can't really tell where T ends and K starts, so its logical; but I had more complex cases where a human would've been able to infer types correctly
About a year ago I was curious about building an ECS-based game engine with world simulations like in dwarf fortress, but obviously at much smaller scale while playing Starfield. Something cool started to materialise after tinkering so I thought why not turn it into a space-sim roguelike with a simulated living world.
I use swift because it gives me fantastic devex with all its great type inference and macros + raylib gives me cross platform input handling / rendering and window management.
C-interop setup is basically instant - you point compiler to c headers and the API becomes immediately visible on swift side
As for swift ergonomics, I particularly love that I can now write very readable code, like:
If we invent a meta-farmer profession (for those who hired a farmer) I will be great meta-farmer, but still suck as a farmer