Engineer stepping up to a higher platform, representing the move from spec taker to higher-scope individual contributor work

I wrote in January about why engineering managers are naturally great at AI. I wrote in March about why companies should stop building another Claude and onboard the ones that already exist. Those posts left out a big group: the engineers themselves. The ones who take a spec and turn it into code. This one is for you.

The short version: AI just made one kind of engineer dramatically more valuable, and you’ve been training to be that kind your whole career. You just haven’t named it yet, which is why you don’t know what to claim.

The Writing on the Wall

You’ve probably seen most of this already. Business users are building their own AI-assisted tools at their desks. Microsoft calls it fusion development: citizen developers build the frontend and the logic, professional engineers fill the gaps. Gartner is projecting citizen developers will outnumber professional developers 4:1 by 2026. The work engineers were called in for is being distributed to the people closest to the problem.

Companies are flattening too. Block cut 40% of their workforce and published a three-role manifesto: individual contributors, directly responsible individuals, and player-coaches. No middle management layer. Amazon eliminated 30,000 roles as part of what their CEO called an anti-bureaucracy push. The middle of the org chart is thinning.

The advice about what to do is unhelpful. “Learn AI” catches you up with the rest of the workforce, it doesn’t give you an edge. “Become a billion-dollar solopreneur” is a horizon, not a next step. Meanwhile spec-taking feels more commoditized every week. That’s accurate. AI competes most directly on that exact lane.

What a Super IC Actually Is

The old model was simpler. Someone else defined the problem, wrote the spec, prioritized the backlog, and your job was to turn that into code. The code was the output.

A Super IC owns more of the loop than that. You notice where users are struggling, where a KPI is moving the wrong way, where a workflow is taking too much friction, and you start shaping solutions directly against reality. You prototype fast, watch how people actually behave, iterate, and keep tightening the loop until something works. Code is still part of the job, but it isn’t the outcome. The outcome is a real shift in behavior, throughput, reliability, or business results.

That’s what AI changes. It compresses the cost of implementation and prototyping, which means one strong IC can now move from signal to working reality much faster than before. Things that used to require months of coordination, approvals, and handoffs can often be explored in days. The Super IC is the engineer who uses that compression to own the path from problem signal to durable outcome.

Your non-engineering coworkers are part of that picture too. They’re already using AI to automate parts of their own work. Weekly reports that used to take half a day. Data analysis that used to need a meeting. Workflows that used to require copy-pasting between three systems. Some of those experiments are worth scaling across the team or the org. Most aren’t.

Take one concrete example. A product marketer on your team automates their weekly campaign report with Claude, saving three hours a week. Two months later, four more marketers want the same thing. The Super IC sees that as an emerging capability worth scaling and owns the buildout. You see the shape of what’s been proven, decide the report is worth scaling across the team, and build the durable version. Shared data pipeline. Standardized format. Access controls so different teams see their own data. Monitoring that catches when a source format changes. The marketer keeps owning the content and the judgment. You own what makes it reliable for four other people.

Two clarifications before the practice section. A Super IC works alongside the domain owner, you won’t out-domain a thirteen-year veteran and you shouldn’t try. Think of it as this quarter’s move for taking on more scope as an IC, the one-person-company solopreneur endgame can wait.

The practice has three pieces.

You decide what deserves to scale. AI generates more working prototypes than any org can productionize. Some should become infrastructure the org depends on. Some should stay local to one person’s workflow. Some shouldn’t be automated at all, because the work being automated is where human judgment needs to stay. The Super IC’s first job is knowing which is which.

You set up hard verification so AI can self-correct. Tests, specs, metrics, verifiable targets. Without something to check its work against, AI wanders. With hard artifacts to climb toward, it improves on its own, and you stop having to babysit it.

You onboard generic AI into the specific domain where it needs to work. Give it read access to the right systems. Document the processes it has to follow. Set the boundaries of what it’s allowed to do without human approval. That’s what turns a generic assistant into something actually useful in a specific domain.

Practicing those three across your own work and your coworkers’ work is the Super IC operating mode.

Why We Have an Edge

Three things business users can’t replicate and AI can’t shortcut.

Systems thinking compounds with domain expertise. Domain experts know their domain deeply: the rules, the exceptions, the edge cases. Systems thinking is a different kind of knowledge: architecture, integration, failure modes, scale, how distributed systems actually behave under load. That layer is reusable across domains. When a domain expert ships a working prototype with AI, your systems judgment is what turns it into something the org can actually depend on. Domain depth and systems depth compound, and that compounding is harder to find than either side alone.

Production discipline is invisible from the outside. The laptop script works once. Making something reliable, observable, scalable, and recoverable is a career’s worth of skill. Veracode found that 45% of AI-generated code fails security tests, and the failure rate isn’t improving with newer models. Every vibe-coded app Tenzai Security tested across five different tools lacked CSRF protection and had no security headers. That’s the gap the domain expert can’t close on their own. It’s also the gap that determines whether their work matters beyond a demo.

Onboarding is a skill you’ve already practiced. Every system you’ve built has three layers: what data it can read, what actions it can take, what requires permission or approval. You’ve wired up APIs, set up auth, configured access controls, handled escalation paths. That’s onboarding. The AI version is the same craft with different glue. Give AI read access to the systems it needs, document the processes it has to follow, set boundaries on autonomous actions. If you’ve built systems, you’ve done this work before.

The engineer’s edge has always been knowing what to trust, what to scale, what to connect, and what must stay under human judgment. AI didn’t replace that edge. It made that job more valuable in the room, and you can claim it without moving into management.

You’ve been training for this kind of work your whole career, AI just raised the value of it.