I'm not a software engineer. I'm an electronics engineer who writes code.
This distinction mattered enormously for most of my career. "Real programmers" had computer science degrees, knew algorithms and data structures, could whiteboard Big-O complexity. I could make hardware do things, configure networks, manage systems—but I wasn't a real programmer.
Then AI happened. And suddenly, the domain experts are taking over.
The Abstraction Ladder
The history of programming is a history of rising abstraction:
Punch Cards (1890s-1950s): Programming meant physically creating cards with holes. No abstraction—you were directly manipulating the machine's inputs.
Assembly (1950s): Human-readable mnemonics (MOV, ADD, JMP) mapped directly to machine instructions. One small step of abstraction.
C (1970s): Portable code that compiled to different machines. Memory management still manual, but divorced from specific hardware.
Python, Java, JavaScript (1990s-2000s): Garbage collection, dynamic typing, massive standard libraries. Most programmers never touch memory directly.
Natural Language (2020s): "Build me a dashboard that shows sales by region with a date filter." The machine handles the rest.
Each step up the ladder trades some control for massive gains in accessibility and speed. And each step was denounced by the previous generation as "not real programming."
The Gatekeepers Fall
For decades, the programming profession maintained high barriers to entry. You needed:
- University education (ideally Stanford, MIT, IIT)
- Years of practice to internalize syntax
- Deep knowledge of ecosystem tools
- Cultural fluency in tech norms
These barriers created scarcity. Scarcity created high salaries. High salaries created motivation to defend the barriers.
AI demolishes this structure. When anyone can prompt their way to working code, the scarce resource isn't implementation skill—it's knowing what to implement.
The 10,000-hour rule for mastery? It's now the 100-hour rule for competence. That's not nothing—but it's accessible to domain experts willing to invest a few months.
The Domain Expert Advantage
Who knows what problems exist in healthcare administration? Healthcare administrators. Who knows what logistics companies actually need? Logistics managers. Who knows what researchers struggle with? Researchers.
Previously, these domain experts had to:
- Learn to program (years)
- Or explain their needs to programmers (months of miscommunication)
- Or settle for generic software that fits poorly
Now they can build directly. Not toy projects—real, deployed, useful software.
I've watched a mechanical engineer build a custom simulation tool that would have required a software team. A marketer create a campaign analysis dashboard. A physician develop a patient tracking system.
None of them are programmers. All of them built working software because they knew exactly what they needed.
My Own Journey
My path to plugged.in illustrates this:
Domain knowledge I brought:
- 20+ years understanding enterprise IT needs
- Experience running datacenters and ISP operations
- Deep familiarity with what infrastructure teams struggle with
- ISO 27001 auditing perspective on security requirements
Skills I didn't have:
- Modern frontend frameworks (React, Next.js)
- Mobile app development
- GraphQL API design
- UI/UX design principles
The traditional path would require either hiring developers or spending years acquiring skills. Instead, AI bridges the gap. I describe what I need, AI helps implement, I iterate based on domain expertise.
The result isn't perfect code. It's code that solves real problems for real users. Elegance is nice; utility is essential.
Code Is Temporary, Discovery Is Permanent
Here's a perspective shift that AI forces:
Traditional view: Code is the valuable artifact. Protect it. Document it. Maintain it.
AI-era view: Code is generated output. Understanding is the valuable artifact.
I can regenerate code if needed. AI will improve, producing better implementations over time. What I can't regenerate is the insight about what to build—the accumulated understanding of the domain, the recognition of patterns, the intuition about what users actually need.
This revalues experience. The gray-haired engineer who "can't keep up with new frameworks" may be more valuable than the junior developer who knows the latest syntax. Because the senior has something AI can't provide: judgment about what matters.
The Electronics Engineering Perspective
As an electronics engineer, I see the physical world differently than software people.
I think about:
- Power consumption and heat dissipation
- Signal integrity and noise
- Physical constraints of deployment environments
- Integration with sensors, actuators, and real-world interfaces
These concerns are increasingly relevant as software eats the world. IoT, edge computing, embedded AI—all require understanding the physical layer, not just the abstraction layer.
plugged.in emerged from this perspective: AI agents need to interact with real systems, not just generate text. The Model Context Protocol connects models to tools. Tools connect to physical reality.
Software engineers see AI as a text-generation problem. I see it as a sensing-and-actuation problem. Both views are valid. Domain diversity creates better solutions.
Not the End of Programmers
This isn't the death of programming. It's the expansion of who programs.
Professional software engineers will still exist—probably at higher levels of abstraction, managing AI-generated code, architecting systems too complex for prompt engineering, working on the AI systems themselves.
What changes is the exclusivity. Programming becomes like writing or numeracy—a general skill that many people have at various levels, not a priesthood with exclusive access to the machine.
Some programmers will resist this democratization. They have status and income tied to scarcity. But resistance is futile. The abstraction ladder goes one direction: up.
The Revenge
So why "revenge"?
For decades, domain experts were dependent on technologists. Want custom software? Convince IT. Want process automation? Submit a ticket. Want data analysis? Wait for the BI team.
The power dynamic was clear: domain experts had problems, technologists had solutions. Dependency flowed one direction.
AI reverses this. Domain experts can build their own solutions. Technologists become consultants, not gatekeepers. The power dynamic shifts.
"Revenge" is perhaps too strong. "Rebalancing" is more accurate. But after decades of being told "you don't understand technology," domain experts are discovering they understand enough—and they understand their domains better than any technologist ever will.
That's the revenge: discovering that the barrier wasn't ability, but abstraction. And the abstraction just got a whole lot higher.