I think there's a both-and answer for the contest. Maybe have one competition where the unenforceable spirit of it is, don't use LLMs for help, and another one where the challenges are just made... quite harder... so that even people who use the LLMs still need to marshal great ingenuity to use them better than others (e.g. the #1 spot is someone who used RAG and chain-of-thought better than the #2 spot, and also had better intuition of what to trust vs challenge from the LLM outputs).
I've been thinking about this for a full year now, and I'm ready to present my opinion: I think AI assistance makes it easier, not harder to get better at programming.
Sure, if you're lazy you won't learn anything because you'll get the AI to do all the work for you. But if you're that lazy I imagine you wouldn't have even tried to learn programming without access to AI assistance, so you're still doing better here!
If you're curious and dedicated to self-education, LLM assistance is a gift that never stops giving. You have to learn HOW to learn with it first, but once you've figured that out you can really fly with it.
The ”illusion of competence” effect can be really strong, and it sneaks up on you without you noticing it.
Highly recommend it. Very much.
By that token, using AI to solve AoC really seems like one would be doing themselves a disservice. You might tell yourself you fully understand what the AI spits out, and maybe you do, but you won't build the same sort of comprehension that you would from solving it yourself. Nor will you retain it for as long.
The human brain/body requires resistance/challenges, otherwise it will always choose the lazy road and won’t improve.
if i'm trying to practice handwriting -- why would i use a type writer, or word processor?
i am not sure how using a machine to do the work you're trying to practice makes you better at that practice, since it's doing the.. mechanics.. for you.
as another commenter pointed out i feel there is a distinction between programmer vs. software engineer just as there is a distinction between writing and say, novelist.
i understand the notion of practicing, and getting better at an evolved workflow for producing results -- but we're practicing foundational skills, not trying to reduce everything simply to achieving results by any means necessary.
i feel that producing results without understanding is a short-sighted investment, and not exactly the point of AoC imo.
Is the difference between telling someone to do something versus asking how to do it.
> Software engineers who think they are better without AI may quickly be replaced with "lesser" software engineers who get things done much quicker.
Using AI to program is just ctrl-c ctrl-v software engineering, very clearly not the point of programming competitions. High level tools as you mention don't make you a better programmer, they make you a better software engineer.
I think the discussion you're raising is a good one it's just not relevant to a programming competition.
Programmers that write "slow C" instead of "fast assembly" were once regarded as lazy and incompetent, same for programmers that write "slow Java instead of fast C" or "slow Python instead of fast Java."
> (If you want to use AI to help you solve puzzles, I can't really stop you, but I feel like it's harder to get better at programming if you ask an AI to do the programming for you.)
This feels very similar.
For day-to-day use, as long as you know what the code is doing when you run it, its fine. But to get to the point where you understand what the code is doing, you have to have written code manually.
That's just abstraction ? We're constantly dealing with legacy abstractions built 30-40+ years ago when we had fundamentally different constraints from today. Leaky abstractions are a fact of life and there's only so much you can reliably know about the stack.
My problem with learning with LLMs is how bad they are at the moment - people are betting big that they will eventually get better - but so far I'm only seeing scaling walls and negative cost/benefit footed by big tech $$$.
Yes, using machines to give an answer, without providing any explanations of the process is not learning. One cannot generally give a young kid a calculator and expect them to learn how adder in the calculator's ALU works.
However, using machines to get an answer that you know how to get to is beneficial. No learning is involved in either process, and it saves time. So if you give a kid, who already knows well how to perform addition, understands the principles, and knows the properties, a calculator to quickly get through their homework, it merely saves their time. You know, just like most people don't exactly like to write boilerplate code that they can type in their sleep.
And using machines that can provide explanations how they got to the answer then reading it is learning. And learning by example could be powerful in certain situations - e.g. when one already knows some stuff, but needs some hints how to apply it to a different problem.
Surely, just asking the machine to solve a puzzle is unlikely to get one anywhere. Asking the machine to guide towards a solution might be very beneficial (if it manages to get things right, of course).
I think that'd exclude most Python, Ruby, Java, JS, Haskell,... developers. Heck, it'd even exclude a bunch of C developers who don't appreciate the fact they're not working on a PDP-11.
(This isn't theoretical - I've done Advent of Code a few times, but I don't get to code too much these days. I am curious about its abilities and having a fun way to approach it might be a reason to do Advent of Code.)
That said, I'm not trying to push to the top of the leaderboard.
I'd say that whatever "better at programming" is quickly evolving. AI is a tool like high level languages, IDEs, autocomplete or all the different types of code analyzers. How is ignoring a powerful tool like AI going to get you better at programming?
Programmers who think they are better programmers without AI may quickly be replaced with "lesser" programmers who get things done much quicker.