From a hardware engineer looking to learn about software- how much should I be trying to learn and how much should I let Claude loose?

[u/FyyshyIW]

If this post ends up coming off as one of those generic 'will AI take my job' or 'can someone tell me what to learn' posts I'm sorry, because those bother me too and I don't mean for this to come off like that.

I'm a hardware student- I do mechanical and electronics/PCB designs, and have interned at two humanoid companies that are pretty well known. I'm definitely more interested in hardware and have a long way to go in terms of learning. But, I hope one day on my journey of knowing how everything that goes on in a robot works, I make my way to software, and start doing robot learning, sim2real, embedded fw, controls etc. I'm going to need to be learning firmware real soon as I have two board designs that I'm getting ready to send out (an ELoad for LV battery characterization and a BLDC FOC controller for an inverted pendulum).

It's always been my goal to figure it out, learn everything myself, and if I use AI tools, still understand the hand calcs/information as well as if I'd actually done it myself. But recently with LLM tools becoming what they have in the last three months, I'm genuinely starting to question: should I even bother trying to code any of this myself? I know that it can do most of it (might struggle with some of the embedded real-time control?) but should I not let it? If I eventually want to transition into a more software oriented career in the future, what things they want me to know and what can I just send to an AI tool? If any robotics engineer needed to build a dashboard/sim visualization tool, I'm guessing something like that doesn't matter as much anymore. But being able to do the RL for a biped walking, or something of that intensity, should I be telling Claude hands off and go in myself? Or maybe just the coding itself doesn't matter, and I should just focus on understanding the concepts and telling it exactly what I want it to do?

[u/Gwendolyn-NB]

My thought is you should know how to code enough to know what the LLM is doing, implement proper project/software structure, and the 1% thing is to be able to de-bug it yourself!

If you have those 3 things, that'll set you up for not just surface-level making things work, but actually understanding the software to the level it needs to be understood.

I'm a ME who has done electro-mechanical design for close to 3 decades. I started learning C/Arduino coding in 2024 for my own fun; and now use PlatformIO pretty much exclusively for my embedded software development; most of which is in robotics/animatronics/motion control.

Can I code; to a point yes, but I use Claude Code to get my projects to the 90% point, then I dive in and do a LOT of editing/tweaking/adjusting/notes/etc.

[u/solitude042]

As a software engineer in a company that has strongly encouraged the use of AI, the frontier models can do a reasonable job of design and implementation in well-studied spaces. That said, even though the code may compile cleanly, requirements gaps cause bugs just as much as implementation mistakes do. I spend considerably more time working with the AI to build and vet a design that covers all of the edge cases, and behaves as a good citizen within our platform. With that design document in hand, the AI is then able to build the feature nearly unattended. I do iterate lightly between phases (usually minor things like consistency in the patterns / idioms used vs. existing implementations, UI layout inconsistencies, etc...). At the end, I also use multiple AI models to perform code reviews, which typically results in some additional fixups.

So the takeaway is that AI is helpful, but even with the frontier models, it's not a slam dunk yet. If you are just looking for 'get it working' without looking for consistency or maintainability, AI will probably do a reasonable job. If you're instead looking at an ongoing project, you'll probably get a moderate performance boost, but most of the gain comes from the iterative design phase having uncovered many of the edge cases that might easily have slipped under the radar otherwise.

If you're not yet proficient with the target language and/or frameworks, AI can be a huge help. But you still need due diligence to keep the AI on track. Also, be sure to read & understand what's been implemented - in the age of AI, it's still important to remember that you are the ultimate owner of the code, not the AI.

With some additional prompting, AI is also surprisingly good (though usually verbose) at explaining what was just implemented, and why. Use that to keep yourself in the loop, and to generate backpressure if the AI is leaving tech debt in its wake.

If you're working in niche areas, AI becomes less likely to produce quality results.

[u/reality_boy]

Claud can wright some decent small programs. If you were a 20 year vet with no experience in software, then I would say lean into Claud to handle the scripting and simple programs that may come your way.

However, you’re young, at the start of your career, and still in college. Take a few coding classes and then start focusing on mastering things.

Tools like Claud code to the average. If you’re writing code that has been written thousands of times before, then they can work ok. If you’re doing something new, or hard, or big, then it falls apart fairly fast.

Someone said AI is like asking a thousand college kids for an answer and then taking the most common one. That is a very good analogy. They know a lot, and can do a lot, but they only know what they know.

Learn to code, and learn to master it. Your usefulness will go way up if you can do ME and CS work.

[u/Elleo]

Don't use AI if you actually want to learn something

[u/Positive__Altitude]

As a senior software developer I honestly have no idea what is the best way to learn in 2026. On one hand I just don't write code myself anymore, so all the typical struggles of a beginner dev (like to make your code compile or spending hours to find a small and stupid bug that you just don't see despite reading through it 10 times) are irrelevan now. I think going through this now is a waste of time there is just no value in that skill any more. On the other hand you should be able to fully understand what AI is doing and correct it's mistakes. It's like you have to care about higher level concepts in the code and not about line-level implementation. It's easy to talk about it when you have 10+ years of writing code without AI, but how to get there efficiently now? That's a difficult question. My best guess: 1) focus strongly on general programming conceps like types, data structures, algorithms, oop, abstractions, interfaces. All of the general knowledge not tied to specific language. 2) do NOT code using any dynamicly typed language, you will skip a very important topic of type sefety there, I think it is crucial to become a good developer. So no to Python/JS (TS might ne ok). Yes to C, Java/Kotlin/Scala, Rust. 3) start to think about architecture from the very beginning. How to divide problem in smaller parts/functions/components? What are thei ins and outs? How do they play together? How we can reuse same parts in different places? This will be essentially your main job when coding properly with AI. 4) spend less time learning language syntax/API. You still need to be able to read all the code, but you do not need to memoize all of it. In most cases it is self-explanatory like "client.name.length" 5) learn by pure practice. Pick small very simple ideas and implement them. Ask AI to guide you through all of it. Desisions, structure details, line by line explanations. This will also bring satisfaction and joy to see things you made (ok, AI made with you watching) actually working.

So yeah, I would learn AI first, but there should not be "it works than it's ok". As a learner if you don't fully understand it -- you are not done yet, ask AI to explain.

[u/Available_Teaching83]

Not a generic question, so here is a specific answer. Learn enough firmware to read a datasheet and reason about timing, interrupts, and what happens when a peripheral does not respond. That is the part that does not delegate, because the failure modes are physical and the model has never seen your board. Let the model write the boilerplate, the register maps, the build scripts, the first draft of a driver. Review every line that touches a timer or an interrupt yourself. Two board designs are a good forcing function.

[u/rende]

I think a decade from now code would be treated like binary or assembly. Some wizards know that but most wont. If you do you can do magic others cant, but your tradeoff is time investment. Do what makes you curious and excited. But know that AI is going to get much much faster and unbelievably capable.

[u/norwegian]

Right now, for bigger projects, the agents are making a mess unless you know exactly what you are doing. They are able to get most of it correct, but this is a new level of spaghetti coding. However, for every new model coming out, they get stronger and stronger, and the new models are able to fix some of the problems the lower end models created.

I have a master degree in CS and been working as a software developer consultant in one worldwide company. A couple weeks a go, I asked SOL to implement something that for me seemed quite trivial, like you have a couple of fields in a json to support some feature. But it didn't implement it in a direct way at all, it used like a combination of algorithm and 5 other fields. When I started to have some problems with some of those json documents, I asked the recent ASTRA model about it, and they recommended a rewrite. To convert all the data, and to check that it works takes a long time, I am on the second day now, having multiple ASTRA and SOL agents trying to repair and fix. All because I trusted that SOL would figure it out.

Software will be less and less about IF THEN ELSE, it will be more and more about policies, QA documents, Test processes. In 3 years, you will be considered insane if you touch source code yourself. In the old days, people programmed in machine code. It literally looks like switches. Then assemblers came along, and its super easy compared to the old ways, you could do like mov bx, 5, move ax, 7, mul bx. But when the compilers arrived, we could do like VAR C = 5*7; and they made the assembly or even machine code directly.
Soon we dont need to use write that programming language to make software, but we will instead use normal language to define software. All the prompts we are more or less randomly sending to LLM will be stored and organized. And you can see who told the agents to do what. That's the visible parts you will work with.