Soon Everyone at Your Company Will Be an Engineer

A product manager I know shipped a finance feature last month without asking an engineer for help. Not "wrote the spec and handed it off." She wired up an agent that pulled usage events from the warehouse, calculated the new usage-based pricing tiers, generated the invoices, and pushed them into the billing system through its API. Then she told me, almost apologetically, "I think I accidentally became an engineer."

She's right, and she's not the last one. The thing nobody's saying out loud is that the wall around engineering is coming down, and it's coming down from both sides. We made building software easier, and at the same time every other function discovered that their job is mostly a series of small systems that someone now has to assemble. Put those two together and you get a company where the question stops being "who are the engineers" and becomes "who isn't one."

Engineering got easy enough to be a side skill

For thirty years, writing software was a moat. You needed to know the syntax, the tooling, the deployment story, the way the database would betray you under load. That knowledge took years to build, so we built a profession around it and put a fence around the profession.

AI didn't remove the hard parts. It removed the entry tax. You no longer need to know how to write a for loop to get a working script, you need to know what you want and how to tell the difference between a result that's correct and one that just looks correct. That second skill is the real one, and it turns out a lot of people who never called themselves engineers already have it. A finance analyst who can spot a wrong number in a model can spot a wrong number in an agent's output. A salesperson who knows their pipeline can tell when the automation is lying about it.

So the people who used to file a ticket and wait two sprints are now building the thing themselves on a Tuesday afternoon. And once they've done it once, they don't go back.

What AI does to the org chart

Here's where it gets strange. If my manager is shipping code, and my skip-level is reviewing PRs, and the people on the marketing floor are pushing agents to production, then the old org chart stops describing reality.

The traditional shape was a tall stack: individual contributors at the bottom, a layer of leads, a layer of managers, directors, VPs, and the executives on top. Each layer existed partly to translate. Engineers spoke one language, the business spoke another, and the middle of the company was full of people whose entire job was carrying meaning across that gap. Product managers translated business into specs. Engineering managers translated specs into tasks. Tech leads translated tasks into code.

Take away the translation problem and most of those layers lose their reason to exist. If the marketer can build the system, you don't need a product manager to write a requirements doc for an engineer who will build the system. The doc, the handoff, the sprint planning, the standup where someone explains a blocker, a lot of that machinery was overhead created by the gap between people who understood the business and people who could build.

What I think we're heading toward is flatter and weirder than the "flat org" everyone talks about. You get a thin layer of people who actually set direction, a thin layer of people who coordinate work across teams, and then a very wide layer of builders who happen to be domain experts. The CEO, a band of people running teams, and underneath, everyone is some kind of engineer.

The "X engineer" title is going to eat everything

We already have this in pockets and we've had it for years. "Sales engineer" is an old title. "Marketing engineer" shows up at growth-heavy startups. "Data engineer" was a novelty a decade ago and now every company has a dozen.

What's new is that the engineering part is becoming the bigger half of the job, not the supporting half. The old sales engineer was a salesperson who could read an API doc. The new one builds the agent that qualifies leads, books the demos, and updates the CRM, then spends their actual time on the three deals where a human voice still closes it. The marketing engineer isn't a marketer who knows some HTML. They run a fleet of agents that generate, test, and kill campaigns faster than any team could by hand, and their skill is designing the system that decides what to keep.

Compliance is the one I keep coming back to, because it's the least obvious and maybe the most important. Compliance is rules applied to evidence at scale, which is almost the definition of something you'd want a system to do. A compliance engineer builds the agents that read every contract, flag the clauses that matter, watch the data flows, and produce the audit trail automatically. The job stops being "review documents" and becomes "build and own the system that reviews documents, and be accountable when it's wrong."

That last clause is the whole thing. Accountability doesn't transfer to the agent. It stays with the person who built and runs it.

What doesn't flatten

I don't want to oversell this, because there's a version of this argument that ends with "and so we won't need people," and that's not where I land.

The skill that matters in a company full of engineers is judgment, and judgment doesn't come from the tooling. Someone still has to decide which problems are worth solving, which automated output to trust, and where the system quietly went wrong in a way that won't show up until a customer or a regulator finds it. The product manager who shipped the billing feature still needs to catch the wrong number before a customer does. The compliance engineer still needs to know which risks are real and which are theater. AI raised the floor on building and did almost nothing to the ceiling on judgment.

So the value moves. It used to live in "can you build this." Now it lives in "do you know what's worth building and can you tell when the machine is fooling you." This is the same shift I've written about as moving from implementer to orchestrator: the work stops being the typing and starts being the direction. Those were always the senior skills. What changed is that you can no longer hide a lack of them behind the years it took to learn the syntax.

There's also a real cost nobody's pricing in yet. When everyone can build, everyone builds, and you get a company drowning in half-maintained agents and scripts that each made sense to one person on one Tuesday. The PM's billing feature breaks when the payment provider changes its API, and now who owns that? We spent the last few years learning that vibe-coded software has a brutal second-day problem. A company where every function ships its own systems is going to learn that lesson at five times the surface area.

I don't have that part figured out, and I'm suspicious of anyone who says they do. The flattening is real and it's already happening on the floors I walk through. Whether it produces leverage or just a much larger mess depends almost entirely on whether these new engineers learn the boring parts of the discipline, ownership, testing, knowing what to throw away, before the systems they built quietly turn into the next decade's legacy code. My bet is that the companies that win won't be the ones where everyone became an engineer fastest. They'll be the ones that figured out, in the middle of all of it, who still needs to not be.

I write about system design and the senior-to-staff transition every week in Monday BY Gazar on Substack, and I break down architecture and engineering decisions on Gazar Breakpoint on YouTube.

If you want this thinking applied live, my next free session is System Design for AI Agents: Senior vs Staff on Tuesday, July 21, 2026, 6:30 PM GMT+1: 45 minutes on the five things that break every LLM agent after the demo, and the design decisions that stop each one. My courses and other free lessons are on my Maven profile.