AI is an extremely useful engineering tool. But it is not an engineer.
After several decades writing assembly, C, C++, Python, VHDL and SystemVerilog across embedded systems, networking, communications and FPGA development, that distinction matters to me practically — not philosophically.
Over the past year, I started using AI coding assistants seriously in my day-to-day work. Like many engineers, I initially wondered whether AI was being overhyped. After extensive use, my conclusion is straightforward:
AI can dramatically accelerate implementation, but engineering judgement remains as important as ever.
Where AI Helps Me Significantly
AI coding assistants are particularly useful for:
- Boilerplate code generation
- Python utilities and automation scripts
- Test benches and test scaffolding
- Parsing and data-processing scripts
- Documentation drafts
- Learning unfamiliar APIs and libraries
- Exploring alternative implementation approaches
- Converting concepts between languages
Tasks that might have taken an hour can often be reduced to minutes. For experienced engineers, AI often feels like having a very fast junior developer available on demand.
Where AI Often Struggles
The difficulties usually appear when problems become domain-specific. Examples include:
- System architecture decisions
- Hardware/software partitioning
- Real-time constraints
- Concurrent and multi-threaded systems
- Legacy code bases
- Performance-critical code paths
- Safety-critical systems
- Certification environments
- Root-cause debugging
These areas depend heavily on context, experience and trade-offs that may never appear in the prompt.
Hardware Engineers Should Be Particularly Careful
One observation from FPGA and embedded development is that AI often produces outputs that are syntactically correct and technically plausible, yet subtly wrong.
Examples I have encountered include:
- FPGA constraints that look reasonable but assign signals incorrectly
- Register maps that are internally inconsistent with protocol requirements
- Synthesis attributes that compile successfully but are inappropriate for the design objectives
- Interface definitions that violate timing assumptions
- Peripheral initialization sequences that appear valid but miss device-specific requirements
The dangerous part is not that the code fails immediately. The dangerous part is that it often looks correct. Software bugs are usually discovered during testing. Hardware and FPGA issues can survive synthesis, implementation and even initial bring-up before revealing themselves.
The Biggest Mistake Engineers Make With AI
Many people assume the biggest mistake is trusting AI too much.
In my experience, the bigger mistake is asking AI to solve a poorly understood problem.
If requirements are vague, AI can generate pages of code very quickly — but it will simply accelerate confusion. When requirements are clear and well-defined, AI can be remarkably effective.
If there is one lesson from a year of daily use: AI amplifies clarity. It does not create clarity.
When AI Should Be Used Carefully
I become far more cautious when dealing with:
- Device drivers
- Interrupt handling
- Hardware interfaces
- Protocol implementations
- Security-sensitive software
- Safety-critical functionality
- FPGA constraints and timing closure
In such situations, every line must be reviewed and understood. Verification remains the engineer's responsibility.
What Works Well For Me Today
My current workflow is straightforward:
- Define requirements carefully.
- Use AI to accelerate implementation.
- Review all generated code.
- Verify assumptions independently.
- Test thoroughly.
- Keep engineering judgement in the loop.
The better I understand the problem, the more useful AI becomes. The less I understand the problem, the less I trust the generated solution.
Final Thoughts
AI coding assistants have already become part of my daily engineering toolkit. They save time, reduce repetitive effort and help explore alternatives rapidly.
However, they do not replace requirements analysis, design decisions, debugging skills or engineering judgement.
At least in my experience, the engineers who benefit most from AI are not those who rely on it blindly. They are the engineers who understand enough to challenge it.
Have thoughts on this workflow? I am always keen to discuss complex engineering challenges with fellow systems architects. Connect with me on LinkedIn or drop me a line at abhaya.kumar.deshmukh@technology-consultant.in.
I regularly write about the practical intersections of hardware engineering, communications, and modern software workflows. Follow along for upcoming articles on CPU vs DSP trade-offs and reproducible FPGA builds.