Short answer: no, and the demand for computer engineering is currently being driven by the AI build-out itself. Someone has to design the chips, the boards, the interconnects, the power delivery and the thermal systems that these models run on, and that work has expanded sharply. The US Bureau of Labor Statistics projects computer hardware engineers to grow 9 percent between 2025 and 2035, adding about 6,900 positions to a 2025 base of 76,100 at 2025 median pay of $161,740, while software developers, quality assurance analysts and testers grow 10 percent with 185,400 additional jobs. Both sit far above the 3.5 percent projected across all employment.
The Term Covers Two Different Careers
Computer engineering spans hardware and software, and their exposure profiles differ enough that a single answer is misleading.
Hardware-side computer engineering covers processor and accelerator design, board layout, memory systems, interconnect, verification, power and thermal design, and firmware. Physical constraints dominate, iteration is expensive, and mistakes are extremely costly because you cannot patch silicon.
Software-side computer engineering covers systems software, embedded software, compilers, drivers and infrastructure. Code generation has a real effect here, concentrated on the routine end.
The important asymmetry: the hardware side is currently the most demand-constrained part of the entire technology sector, because the compute build-out has a physical bottleneck and the physical bottleneck needs engineers.
Where Automation Actually Helps and Where It Does Not
| Activity | Effect | What the engineer still owns |
|---|---|---|
| RTL and testbench authoring | Meaningfully faster | Micro-architecture decisions |
| Verification coverage closure | Automated stimulus generation | Deciding what constitutes adequate coverage |
| Physical design and place-and-route | Long automated, now better optimised | Floorplan strategy and timing closure judgement |
| Firmware and driver development | Faster for routine paths | Hardware bring-up and silent hardware faults |
| Compiler and systems work | Assisted | Correctness reasoning and performance analysis |
| Thermal and power modelling | Faster simulation | Design decisions under real constraints |
| Board bring-up | Not automated | All of it |
| Debug of an intermittent hardware fault | Not automated | All of it |
Two rows carry no automation at all, and they are the rows where projects succeed or fail. Bringing up a new board and chasing a fault that appears once every four hours under specific thermal conditions is where hardware engineering time actually goes, and it is oscilloscope-and-hypothesis work that no language model touches.
Why silicon economics resist automation differently
Software has a forgiving error model: ship, discover a bug, patch. Hardware does not. A mask set costs a great deal, a respin costs months, and a functional bug discovered after tape-out can end a product cycle.
That asymmetry forces verification to dominate hardware schedules, often exceeding design effort. Automation genuinely helps generate stimulus and close coverage, and it makes the underlying problem harder rather than easier, because more coverage produces more results to interpret and the question of whether coverage is adequate remains a judgement call that a person signs off.
This is the same structural pattern seen in every safety-critical or high-consequence field. Cheap generation plus expensive mistakes equals more demand for people who can judge, not fewer.
A Bug That Shows Where the Boundary Is
Hardware engineers recognise this pattern immediately, and it explains the profession better than any abstract argument.
A new board mostly works. Under sustained load, roughly once every few hours, a data corruption appears on one memory channel. It is not reproducible on demand. It does not occur on two of the five boards. It stops when the lab air conditioning is turned up.
Nothing in that description is a software problem, and nothing about it can be reasoned out from documentation. The investigation is physical: instrument the channel, capture the failure with a triggered scope, correlate against temperature and against the specific traffic pattern that precedes it. Somewhere in the process someone will discover that the failing boards came from a different assembly lot, or that a decoupling capacitor is marginal at temperature, or that a timing margin that passed at nominal does not survive at the corner.
Getting there requires forming hypotheses about physical mechanisms, designing an experiment for each one, and accepting that most experiments will be inconclusive. It also requires the judgement to stop: to decide the margin is adequate, or that the fix is a board respin, and to justify that decision to a programme manager who does not want to hear it.
Tooling helps with parts of this. It can generate the analysis scripts, search the errata, and suggest hypotheses worth checking. It cannot connect the probe, and it cannot decide when the evidence is sufficient. That combination of physical experiment and consequential judgement is why hardware engineering is the least automatable branch of the discipline, and why it is currently the hardest of the two to hire for.
What to Know Before You Draw Conclusions
The build-out is physical. BLS notes utilities as the fastest growing major sector at 9.8 percent through 2035, with growth concentrated in electric power generation, transmission and distribution partly because of AI power demand. That demand becomes power delivery, cooling and interconnect engineering, all of which are computer and electrical engineering work.
Specialised silicon is proliferating. More custom accelerators means more design teams, not fewer. Each one needs architecture, verification, physical design and firmware.
Exposure measures are not employment forecasts. BLS published AI exposure categories alongside its projections, sorting occupations into Low, Moderate, High and Very high relative exposure, and states explicitly that exposure “does not imply job loss, productivity gains, automation probability, or wage effects.” Engineering registers on those measures while being projected to grow at close to three times the workforce rate.
The junior software path is genuinely narrowing. Routine implementation work was how new engineers learned systems. That is compressing, and teams that do not deliberately replace it will have a seniority gap in a few years.
Hardware has a supply problem, not a demand problem. Experienced verification and physical design engineers are difficult to hire in most markets, which is the opposite of an occupation being automated away.
One further point that often gets missed in this debate: the compute build-out has moved the industry’s binding constraint from logic density to energy and heat. That shift promotes a set of specialisms that were previously considered unglamorous, including power delivery, packaging and cooling design, into the most sought-after roles in the sector. Engineers who spent years on those problems are finding their expertise revalued sharply upward, which is close to the opposite of what an automation narrative would predict.
Where the Work Is Concentrating
- Accelerator and custom silicon design. Architecture, verification and physical implementation for AI workloads.
- Power and thermal engineering. Currently one of the hardest constraints on data centre scaling, and a genuinely underserved specialism.
- High-speed interconnect and memory systems. Moving data is the bottleneck in most modern systems, which makes this work valuable.
- Verification. The largest single hiring category in hardware, and the one where generation increases rather than decreases workload, because more stimulus produces more results that someone has to interpret before sign-off.
- Embedded and edge systems. Running models on constrained devices is a hard engineering problem combining hardware and software knowledge.
A Decision Framework for Computer Engineers
- Software-side, writing routine implementation code. The most compressed position. Move toward systems-level work: performance, correctness under concurrency, or anything where the difficulty is reasoning rather than typing.
- Hardware-side, early career. Strong position and getting stronger. Verification and physical design are where the hiring is, and both reward depth over breadth.
- Mid-career hardware engineer. Your risk is niche obsolescence rather than automation. The build-out favours anyone who can move toward accelerators, power or interconnect.
- Deciding what to study. Computer engineering with real depth in hardware is currently one of the better-positioned technical educations available, precisely because it is harder and fewer people choose it.
The test that applies across all four: when something does not work, is the answer available by reading, or does it require an experiment? Careers built on the second kind of problem are considerably more durable.
Hybrid roles and the shape of the job market
One clear job market trend worth naming: the roles growing fastest are hybrid ones that sit between traditional boundaries. Hardware engineers who can write and profile the software that runs on their silicon. Software engineering specialists who understand memory hierarchy well enough to explain why a kernel is slow. Firmware engineers comfortable with both a schematic and a build system.
These hybrid roles exist because AI integration into products has made the boundary between hardware and software design commercially expensive to maintain. A team that hands a specification across that boundary iterates slowly, and iteration speed is what determines whether a product ships on the current generation of hardware or the next one.
The consequence for the future of work in this field is that engineering judgment about the whole system, rather than depth in one layer, is what employers increasingly pay for. That judgment is built by working across the boundary rather than by adding another framework to a list, and it is precisely what neither code generation nor design automation supplies.
Common mistakes right now
- Merging generated RTL or firmware without reasoning about the corner cases it did not consider.
- Treating coverage percentage as a proxy for verification quality.
- Optimising for simulation speed rather than for finding the bug that will cost a respin.
- Letting generated documentation replace the design rationale, which is the artefact the next engineer actually needs.
Building the Fluency the Sector Now Assumes
Hardware and systems teams increasingly expect engineers to work fluently with machine-learned components in two directions: using these tools inside the design flow, and designing systems that run them efficiently. Both require understanding what the models actually do computationally, where the memory and bandwidth costs come from, and why a given workload behaves the way it does on given hardware.
That understanding is what separates an engineer who can optimise a system for a workload from one who can only benchmark it. Learning it in a structured sequence gives you the concepts rather than one framework’s abstractions, which matters in a field where the frameworks turn over faster than the hardware. Pairing that with a certificate and applied work makes the capability visible when a team is staffing an accelerator project. If you want a structured route in, explore Coursiv AI lessons and check current plan details on the official site.
FAQ
Is computer engineering a safe career?
Which side is more secure, hardware or software?
Will AI design chips?
Does code generation hurt embedded and firmware work?
What should a student focus on?
Your Next Step
Look at your last month of work and separate the hours spent producing artefacts from the hours spent forming and testing hypotheses about why something did not behave as expected. The second category is what the profession actually sells, and in hardware it is most of the job. If your ratio is heavily weighted toward the first, the fastest correction is to volunteer for the bring-up or the intermittent-fault investigation nobody else wants, because that is where the durable expertise is built.