I keep hearing the same concern: AI is taking programming jobs, especially junior positions. Companies want people who can contribute immediately, but AI tools can now write code surprisingly effectively, including drivers, boilerplate templates, test cases, and even help with debugging.
In the rest of this post, I want to dig into the stats: are companies really laying off developers or freezing hiring? If so, what does that mean for someone trying to get started in embedded systems? I’ll leave general programming out for now and focus on embedded engineering.
What’s Actually Happening in the Job Market
The bad news: what you’ve been hearing about drops in entry-level positions is true. Entry-level hiring at major tech companies fell by roughly 25% from 2023 to 2024. Compared to 2022, entry-level job postings are down by about 34%, and the share of roles requiring five or more years of experience has increased noticeably over the same period. Some analyses estimate that junior-level postings have declined by more than 35% since 2023. Today, only around 15–18% of tech job postings are truly entry-level.
That lines up with what we’ve been hearing from new graduates and job seekers: fewer openings, more competition, and higher expectations.
At the same time, layoffs have been very real. The tech industry saw roughly 245,000 layoffs in 2025, followed by tens of thousands more in early 2026, including about 27,000 in January alone and around 71,000 by April.
Despite the layoffs, about 92% of companies still report plans to hire in 2026, just not for the same kinds of roles. Companies are looking for more specialized roles, including “AI/ML engineers, cybersecurity, data engineering, and cloud architects” (source). Long-term projections for software and related engineering roles are still positive. So, what we’re seeing isn’t a collapse of demand, but a restructuring of what companies need in response to growing AI demand.
How AI Is Changing Entry-Level Work
While AI has not eliminated engineering jobs, it has caused companies compress a lot of the work that used to justify hiring junior developers. This includes tasks like writing boilerplate code, setting up basic drivers, or stitching together simple application logic, which can now be done much faster with AI assistance. The tasks don’t go away, but it does mean companies need fewer people whose primary value is doing that work manually.
You can see a similar pattern in adjacent fields. In cybersecurity, for example, only about 17% of roles are now entry-level, while senior-level positions have increased significantly. The same general trend is showing up across software roles: fewer junior openings, more demand for experienced engineers, and higher expectations for everyone in between.
From this we can see that AI is not replacing engineers but rather replacing low-level work.
Why Embedded Systems Is in a Strong Position
Unlike many areas of software, embedded work is tightly coupled to the physical world. Embedded developers need to deal with hardware, timing constraints, memory limits, power budgets, and communication with real devices that don’t always behave as expected. While AI can help you write code for an I2C peripheral or suggest how to configure a driver, it struggles with debugging: reading logic analyzer traces and figuring out why a bus is locking up. It lacks intuition about hardware quirks or high-level architecture designs.
Embedded systems engineers who can reason about interactions between hardware and software are becoming more valuable, not less. This shift lines up with stories I heard from Electrical and Computer Engineering department heads at the ECEDHA conference last month: ECE departments are seeing an uptick in new students over the last couple of years thanks to AI pushing out entry-level hires from computer science alone.
What Companies Are Actually Looking For Now
Companies are redefining what “junior” level means for developers rather than dropping the role altogether. In the past, a junior engineer might be someone who could follow instructions, write code with guidance, and gradually ramp up over time. Today, companies are far more likely to ask whether a candidate can contribute meaningfully within the first month or two.
Writing code is no longer the scarce skill it once was. Companies are now placing more emphasis on people who can operate above the level of code. This includes deciding what to build, how to structure it, and how to debug it when things go wrong.
They’re also looking for people who can work effectively with AI, rather than be replaced by it. AI-generated code often looks correct but contains subtle issues, inefficiencies, or unsafe assumptions. Engineers who can review that output, test it against real hardware, and catch edge cases are increasingly important.
Finally, companies are implicitly expecting experience, even for entry-level roles. That doesn’t necessarily mean years in industry, but it does mean evidence that you’ve built and understood real systems. With smaller teams and tighter timelines, many companies no longer have the capacity to train someone entirely from scratch.
How to Position Yourself to Get Hired
Given all of that, the question becomes: what should you actually do? The most important shift is to stop thinking of yourself as someone who writes code, and start thinking of yourself as someone who builds systems.
If your experience is limited to implementing isolated pieces of functionality (i.e. an isolated driver here, protocol, or simple application), you’re competing in the space that AI is actively compressing. However, if you can show that you’ve built complete systems that integrate hardware, firmware, and communication, you start to look more enticing to companies.
That also means making your thinking visible. You need to show how you made decisions rather than just build something. For example, why did you choose an RTOS, or decide not to use one? Why did you handle something with interrupts instead of polling? What tradeoffs did you consider around memory or timing? What broke along the way, and how did you fix it?
This kind of reasoning is difficult to fake and impossible for AI to fully replicate. It’s also exactly what hiring managers are trying to assess. You should be ready to answer these questions about your projects in an interview.
Another area that becomes increasingly important is debugging. When a system doesn’t behave as expected, the ability to systematically isolate the problem, gather the right signals, and test hypotheses is what determines whether you succeed. AI can assist with debugging, but it cannot replace the process. Learning how to read datasheets deeply, use tools like logic analyzers and oscilloscopes, and instrument your firmware with meaningful diagnostics will set you apart quickly.
At the same time, you shouldn’t avoid AI. You should be using it regularly, but with the right mindset. Instead of treating it as an oracle that produces correct answers, treat it as a fast but imperfect collaborator. Let it generate starting points, but take responsibility for verifying and refining the results.
A useful way to think about this shift is to look at what happened in machining when CNC tools became widespread. Before CNC, a lot of value came from being able to manually operate a mill or lathe with high precision. The industry moved away from manual milling, which upset the required skills for machinists. Today, companies aren’t hiring people just because they can turn a crank accurately. They’re hiring people who can design parts, understand tolerances, program CNC machines, and troubleshoot when something goes wrong. In other words, the work didn’t disappear, but rather, it moved up a level.
Something similar is happening with programming. Writing basic code used to be a core differentiator for junior engineers. Now that AI can generate much of that code, the value is shifting toward people who can design systems, reason about tradeoffs, and debug real-world behavior. Knowing how to write code is still important, just like knowing how machining works is still important. However, to be hirable, you need to operate at the system level.
Practical Tips for Getting Hired as an Embedded Engineer
So what should you actually focus on if you’re trying to break into embedded systems right now? Students and new graduates might be struggling to find jobs when AI seems to be taking everything. Here are some practical tips on what to learn or focus on to make you stand out.
- Still learn to code. This is a baseline requirement: it teaches you how to think through logic, debug issues, and recognize when something is off. It also gives you the foundation to evaluate AI-generated code. Like typing or machining, it’s expected, but it probably won’t get you hired on its own anymore.
- Learn hardware. Embedded systems live in the physical world, and that’s where AI still struggles. Understanding electronics, microcontroller architecture, datasheets, and real-world constraints (timing, noise, power) is a huge differentiator. In addition to designing, your job is to verify that the system will actually work.
- Build complete, end-to-end projects. Don’t just write isolated drivers or small demos. Rather, you should build systems that read data, process it, and communicate reliably. Companies want to know you can think at a system level and contribute to real products. Make sure you can clearly explain your design decisions, tradeoffs, and what broke along the way.
- Don’t rely entirely on AI when building. It’s tempting to vibe code everything, but that skips the hard lessons that actually build intuition. If you don’t understand what you built, it will show quickly in an interview. Build at least some projects from scratch so you experience the bugs, edge cases, and tradeoffs firsthand. This might mean putting AI aside for a little while so you can struggle with the details.
- Learn and apply best practices (with judgment). Things like MISRA-C, defensive programming, and safe memory handling exist to prevent common and costly failures. It’s important to understand when those rules apply and when they might need to be bent. The goal is to develop engineering judgment rather than just following a checklist.
- Get good at debugging. When systems fail (not “if”), debugging is what separates engineers from code generators. Learn how to isolate problems, gather the right signals, and test hypotheses systematically. Tools like logic analyzers, oscilloscopes, and well-placed logs are often more valuable than writing more code.
- Learn to work with AI, not depend on it. AI is becoming part of the workflow, and employers expect you to use it effectively. Treat it as a fast but imperfect collaborator: great for generating ideas or scaffolding, but not something you blindly trust. Your value comes from verifying the output and integrating it into a correct, reliable system.
Ultimately, what employers want to see is evidence that you can contribute. A strong portfolio goes a long way here. Projects that resemble real-world systems (i.e. data is collected, processed, and transmitted reliably) carry much more weight than isolated examples. When someone looks at your work, they should be able to imagine you stepping into their team and making progress within a few weeks.
Conclusions
The numbers around declining entry-level roles and rising expectations are real, and the impact of AI on workflows is undeniable. It’s understandable to feel uneasy about this shift, but it’s not the first time engineering or programming as gone through such a shift. At various points, compilers reduced the need to write assembly. Libraries replaced large amounts of custom implementation.
Frameworks eliminated boilerplate and standardized patterns. Each time, the nature of the work changed, but the need for engineers and developers did not disappear. AI is doing something similar: it’s removing friction and accelerating certain types of work, particularly the repetitive and well-defined parts. In doing so, it’s raising the baseline expectation for what an engineer can accomplish.
If your value is tied primarily to how quickly you can write code, this shift will feel threatening. However, if your value comes from understanding systems, making decisions, and solving messy real-world problems, this shift can work in your favor. Embedded systems, in particular, sits at the intersection of software and the physical world. That intersection is difficult to automate and deeply reliant on human judgment.
Focus on becoming the kind of engineer who can design, reason about, and debug complete systems so that you can work with AI rather than have it replace you.