I'm on the tail end of my 35+ year developer career, but one thing I always do with any LLM stuff is this: I'll ask it to solve something generally I know I COULD solve, I just don't feel like it.

Example: Yesterday I was working with an Open API 3.0 schema. I know I could "fix" the schema to conform to a sample input, I just didn't feel like it because it's dull, I've done it before, and I'd learn nothing. So I asked Claude to do it, and it was fine. Then the "Example" section no longer matched the schema, so Claude wrote me a fitting example.

But the key here is I would have learned nothing by doing this.

There are, however, times where I WOULD have learned something. So whenever I find the LLM has shown me something new, I put that knowledge in my "knowledge bank". I use the Anki SRS flashcard app for that, but there are other ways, like adding to your "TIL blog" (which I also do), or taking that new thing and writing it out from scratch, without looking at the solution, a few times and compiling/running it. Then trying to come up with ways this knowledge can be used in different ways; changing the requirements and writing that.

Basically getting my brain to interact with this new thing in at least 2 ways so it can synthesize with other things in your brain. This is important.

Learning a new (spoken) language uses this a lot. Learn a new word? Put it in 3 different sentences. Learn a new phrase? Create at least 2-3 new phrases based on that.

I'm hoping this will keep my grey matter exercised enough to keep going.

I'm looking forward to the day that LLMs automatically put knowledge like this into Anki or something like it.

I found that big part of learning on Anki is creating the cards myself. Using cards from others / generated cards via LLM is not the same.

I made tools for Open-webui to add to anki. They work well I think. There are probably MCP tools too.

In my experience, if you don't review the generated code, and thus become proficient in C# enough to do that, the codebase will become trash very quickly.

Errors compound with LLM coding, and, unless you correct them, you end up with a codebase too brittle to actually be worth anything.

Friends of mine apparently don't have that problem, and they say they have the LLM write enough tests that they catch the brittleness early on, but I haven't tried that approach. Unfortunately, my code tends to not be very algorithmic, so it's hard to test.

After 16 years of coding professionally, I can say Claude Code has made me considerably better at the things that I had to bang my head against the wall to learn. For things I need to learn that are novel to me, for productivity sake, it’s been “easy come; easy go” like any other learning experience.

My two cents are:

If your goal is learning fully, I would prioritize the slow & patient route (no matter how fast “things” are moving.)

If your goal is to learn quickly, Claude Code and other AI tooling can be helpful in that regard. I have found using “ask” modes more than “agent” modes (where available) can go a long way with that. I like to generate analogies, scenarios, and mnemonic devices to help grasp new concepts.

If you’re just interested in getting stuff done, get good at writing specs and letting the agents run with it, ensuring to add many tests along the way, of course.

I perceive there’s at least some value in all approaches, as long as we are building stuff.

Yes! Valuable, fundamental, etc. - do it yourself, the slow path.

Boring, uninspiring, commodity - and most of all - easily reversible and not critical - to the LLM it goes!

When learning things intrinsic motivation makes one unreasonably effective. So if there is a field you like - just focus on it. This will let you proceed much faster at _valuable_ things which all in all is the best use of ones time in any case.

Software crafting when you are not at a job should be fun. If it’s not fun, just do the least effort that suits your purpose. And be super diligent only about the parts _you_ care about.

IMHO people who think everyone should do everything from first principles with the diligence of a swiss clocksmith are just being difficult. It’s _one_ way of doing it but it’s not the _only right way_.

Care about important things. If a thing is not important and not interesting just deal with it the least painfull way and focus on something value adding.

A few years ago there was a blog post trend going around about “write you’re own x” instead of using a library or something. You learn a lot about how software by writing your own version of a thing. Want to learn how client side routing works? Write a client side router. I think LLMs have basically made it so anything can be “library” code. So really it comes down to what you want to get out of the project. Do you want to get better at C#? Then you should probably do the port yourself. If you just want to have the ported code and focus on some other aspect, then have Claude do it for you.

Really if your goal is to learn something, then no matter what you do there has to be some kind of struggle. I’ve noticed whenever something feels easy, I’m usually not really learning much.

Before AI, there was copy paste. People who copied code from Stackoverflow without understanding it learned nothing, and I saw it up close many times. I don't see a problem with you asking for advice or concepts. But if you have it write everything for you, you definitely won't learn

That being said, you have to protect your time as a developer. There are a million things to learn, and if making games is your goal as a junior, porting GDscript code doesn't sound like an amazing use of your time. Even though you will definitely learn from it.

The difference now is that LLMs propose to provide copy+paste for everything, and for your exact scenario. At least with Stack Overflow, you usually had to adapt the answers to your specific scenario, and there often weren’t answers for more esoteric things.

Based on my usage of Claude Code, i would not trust it with anything so major.

My problem with it is that it produces _good looking_ code that, at a glance, looks 'correct', and occasionally even works. But then i look at it closely, and it's actually bad code, or has written unnecessary additional code that isn't doing anything, or has broken some other section of the app, etc.

So if you don't know enough C# to tell whether the C# it's spitting out is good or not, you're going to have a bad time

I think this is a really interesting point. I have a few thoughts as a read it (as a bit of a grey-beard).

Things are moving fast at the moment, but I think it feels even faster because of how slowly things have been moving for the last decade. I was getting into web development in the mid-to-late-90s, and I think the landscape felt similar then. Plugged-in people kinda knew the web was going to be huge, but on some level we also know that things were going to change fast. Whatever we learnt would soon fall by the wayside and become compost for the next new thing we had to learn.

It certainly feels to me like things have really been much more stable for the last 10-15 years (YMMV).

So I guess what I'm saying is: yeah, this is actually kinda getting back to normal. At least that is how I see it, if I'm in an excitable optimistic mood.

I'd say pick something and do it. It may become brain-compost, but I think a good deep layer of compost is what will turn you into a senior developer. Hopefully that metaphor isn't too stretched!

I’ve also felt what GP expresses earlier this year. I am a grey-beard now. When I was starting my career in the early 2000’s a grey-beard told me, “The tech is entirely replaced every 10 years.” This was accompanied by an admonition to evolve or die in each cycle.

This has largely been true outside of some outlier fundamentals, like TCP.

I have tried Claude code extensively and I feel it’s largely the same. To GP’s point, my suggestion would be to dive into the project using Claude Code and also work to learn how to structure the code better. Do both. Don’t do nothing.

Thx to both of you, I think these replies helped me a bit.

Yup, I absolutely agree with you. I've been coding professionally for around 25 years now, 10-ish before that as a hobby as a child and teenager. There's lots of stuff I know, but still lots of stuff I don't know. If my goal is to learn a new language, I'm going to build the entire thing without using a coding assistant. At most I might use Claude (not Code) to ask pointed questions, and then use those answers to write my own code (and not copy/paste anything from Claude).

Often I'll use Claude Code to write something that I know how to write, but don't feel like writing, either because it's tedious, or because it's a little bit fiddly (which I know from past experience), and I don't feel like dealing with the details until CC gives me some output that I can test and review and modify.

But sometimes, I'll admit, I just don't really care to learn that deeply. I started a project that is using Rust for the backend, but I need a frontend too. I did some React around 10 years ago, but my knowledge there (what I remember, anyway) is out of date. So sometimes I'll just ask Claude to build an entire section of a page. I'll have Claude do it incrementally, and read the code after each step so I understand what's going on. And sometimes I do tell Claude I'm not happy with the approach, and to do something differently. But in a way I kinda do not care so much about this code, aside from it being functional and maintainable-looking.

And I think that's fine! We don't have to learn everything, even if it's something we need to accomplish whatever it is we've set out to accomplish. I think the problem that you'll run into is that you might be too junior to recognize what are the things you really need to learn, and what are the things you can let something else "learn" for you.

One of the things I really worry about this current time we're in is that companies will start firing their junior engineers, with a belief (however misguided) that their senior engineers, armed with coding assistants, can be just as productive. So junior engineers will lose their normal path to gaining experience, and young adults entering college will shy away from programming, since it's hard to get a job as a junior engineer. Then when those senior engineers start to retire, there will be no one to take their places. Of course, the current crop of company management won't care; they'll have made their millions already and be retired. So... push to get as much experience as you can, and get over the hump into senior engineer territory.

Well I think you've identified a task that should be yours. If the writing of the code itself is going to help you, then don't let AI take that help from you because of a vague need for "productivity". We all need to take time to make ourselves better at our craft, and at some point AI can't do that for you.

But I do think it could help, for example by showing you a better pattern or language or library feature after you get stuck or finish a first draft. That's not cheating that's asking a friend.

How much do you care about experience with C# and porting software? If that's an area you're interested in pursuing maybe do it by hand I guess. Otherwise I'd just use claude.

Disagree entirely, and would suggest the parent intentionally dive in on things like this.

The best way to skill up over the course of one's career is to expose yourself to as broad an array of languages, techniques, paradigms, concepts, etc. So sure, you may never touch C# again. But by spending time to dig in a bit you'll pick up some new ideas that you can bring forward with you to other things you *do* care about later.

I agree here. GP should take time to learn the thing and use AI to assist in learning not direct implementation.

If there is going to be room for junior folks in SWE, it will probably be afforded to those who understand some language’s behaviors at a fairly decent level.

I’d presume they will also be far better at system design, TDD and architecture than yesterday’s juniors, (because they will have to be to drive AI better than other hopeful candidates).

But there will be plenty of what will be grey beards around that expect syntactical competence and fwiw, if you can’t read your own code, even slowly, you fail at the most crucial aspect of AI accelerated development—-validation.

It does definitely seem to be, and stands to reason, that better developers get better results out of Claude et al.

You're on the right track in noticing you'll be missing valuable lessons, and this might rob you of better outcomes even with AI in the future. As it is a side project though keeping motivation is important too.

As well, you'll eventually learn those lessons through future work if you keep coding yourself. But if instead you lean more toward assistance it is hard to say if you would become as skilled in the raw skill of coding, and that might affect yoir abilityto wield AI to full effecf.

Having done a lot of work across many languages, including gdscript and C# for various games, I do think you'll learn a huge amount from doing the work yourself and such an opportunity is a bit more rare to come by in paid work.

It depends how you use it. You can ask Claude Code for instructions to migrate the Code yourself, and it will be a teacher. Or you can ask it to create a migration plan and the execute it, in which case learning will of course be very limited. I recommend to do the conversion in smaller steps if possible. We tried to migrate a project just for fun in one single step and Claude Code failed miserably (itself thought it had done a terrific job), but doing it in smaller chunks worked out quite well.

For something like this, i'd ask claude code to review the project and create design and architecture documents for it.

Then i'd ask it to create a plan to recreate it in c#.

Next i'd ask claude code to generate a new project in c#, following the small steps it defined in the planning document.

Then i'd ask claude code to review its experience building the app and update the original plan document with these insights.

Then throw away the first c# project, and have another go at it. Make sure the plan includes starting with tests.

Have it generate the code. Then have another instance criticize the code and say how it could be improved and why. Then ask questions to this instance about things you don't know or understand. Ask for links. Read the links. Take notes. Internalize.

One day I was fighting Claude on some core Ruby method and it was not agreeing with me about it, so I went to check the actual docs. It was right. I have been using Ruby since 2009.

As someone who is programming computers for almost 30 years and professionally for about 20 by all means do some of it manually, but leverage LLMs in tutor/coach mode, with „explain this but don’t solve it for me” prompts when stuck. Let the tool convert the boring parts once you’re confident they’re truly boring.

Programming takes experience to acquire taste for what’s right, what’s not, and what smells bad and will bite you but you can temporarily (yeah) not care. If you let the tool do everything for you you won’t ever acquire that skill, and it’s critical to judge and review your work and work of others, including LLM slop.

I agree it’s hard and I feel lucky for never having to make the LLM vs manual labor choice. Nowadays it’s yet another step in learning the craft, but the timing is wrong for juniors - you are now expected to do senior level work (code reviews) from day 1. Tough!

What’s wrong with using a Claude code to write a possible initial iteration and then go back and review the code for understanding? Various languages and frameworks have there own footguns but those usually are not unfixable later on.

AFAICT you learn significantly more in building something from the ground-up than you do when code-reviewing someone else's code. In my experience you really don't build the mental model of how the code is working unless you either build it yourself, refactor it yourself, or you have to heavily debug it to fix a bug or something.

In my experience, determining what to write is harder than how to write it, so you deprive yourself of that learning if you start from generated code

I actually think this helps in that learning - it's sitting alongside a more experienced expert doing it and seeing what they came up with.

In the same sense that the best way to learn to write is often to read a lot, whether English or code. Of course, you also have to do it, but having lots of examples to go on helps.

Cursor has made writing C++ like a scripting language for me. I no longer wrestle with arcane error messages, they go straight into Cursor and I ask it to resolve and then from its solution I learn what my error was.

Can you really use Cursor for CPP ? Would you mind describing your setup? How better is it than copilot or windsurf?

Open your C++ project in Cursor. Before anything else ask it to review the codebase and tell you what the codebase does so you can understand its power. Play around asking it to find sections of the code that handle functionality for certain features. It should really impress you.

Continue to work on it in your preferred IDE let’s say Visual Studio. When you hit your first compile error, just for fun even if you understand the error, copy and paste it into Cursor and ask it to help you understand the cause and propose a solution. Ask it to implement it, attempt to compile, give it back any further errors that its solution may have to review and fix. You will eventually compile.

Then before you go back to work writing your next task, ask Cursor to propose how it might complete the task. After the proposal review and either tell it to proceed to implement or suggest tweaks or better alternatives. For complex tasks try setting the model manually to o3 and rerunning the same prompt and you can see how it thinks much better and can one shot solutions to complex errors. I try to use auto and if it fails on more complex tasks I resubmit the original query with o3. If o3 fails then you may have to gather more context by hand and really hold its hand through the chain of reasoning. That’s for a future post.

More advanced: Create a build.bat script that Cursor can run after it has implemented code to run and see its own errors so you can avoid the copy paste round trip. (Look into Cursor rules for this but a rule prompt that says 'after implementing any significant code changes please run .\build.bat and review and fix any further errors') This simple efficiency should allow you to experience the real productivity behind Cursor where you’re no longer dying the death of 1000 cuts losing a minute here or a minute there on rote time consuming steps and you can start to operate from a higher natural language level and really feel the ‘flow’.

Typing out the code is just an annoying implementation detail. You may feel ‘competency leaving your fingers’ as DHH might say but I’d argue you can feel your ass filling up with rocket fuel.

Is GDScript really less efficient than C# in Godot?

What bottlenecks are you experiencing?

I'm a developer experienced with Python (GDScript-like) and C#, but am new to Godot and started with GDScript.

It really depends on how much actual logic you implement in Gdscript. It is really slow though, even slower than python as far as I know. So if you’re doing anything beyond gluing engine calls together (eg writing complicated enemy logic) its easy to run into performance issues. The “official” way to deal with that is to create gdextensions for the slow stuff, but at that point you might aswell do everything in C# (imo).

It’s easy to convince yrself that code is going to be fast enough, but games run into bottlenecks really quickly, and it also makes your stuff inaccessible to people who don’t have great hardware.

Doing the easy stuff is what gives you the skills to do the harder stuff that a LLM can’t do, which arguably makes this hard indeed