Software engineering is getting a second material

Gergely Orosz spent Thursday evening in our New York office for a fireside chat with Michael Grinich, taking his questions in front of a room full of engineers. Most of the conversation was about AI. The most durable idea in it was about material.

Every engineering discipline works with a material that has tolerances. Software never has. That is about to change.

Software is getting a second material

Gergely traced the argument back to a podcast conversation with Hillel Wayne, who set out to answer whether software engineers deserve the title by interviewing people who had worked professionally in both traditional engineering and software. Wayne ran 17 of those interviews for his Crossover Project, and 15 of the 17 said yes, software engineering is really engineering.

The detail Gergely pulled out of it was narrower. A civil engineering job does not take exactly 100 panels. It takes between 80 and 120, and you do not know in advance which. Every discipline works that way except ours, because "our material, software, always works, or it just doesn't work". Bits or bytes. It runs or it fails.

Now there is a second material in the building, and it behaves like everyone else's: it sometimes hallucinates and sometimes doesn't, and it can produce the deterministic kind. Gergely's read is that this makes the job bigger rather than smaller, closer to architecture. Someone has to decide which material a given system gets built from, then answer for cost, latency, and reliability.

Software's original material either works or it doesn't. The second one comes with tolerances, and something has to hold both.

Everyone got faster at the same time

Gergely relayed a conversation with an engineer he knows from Uber who now works at Linear. Two years ago, being an early adopter was a real edge: work that took colleagues a day or two took him an hour. Now everyone runs the same tools and trades the same tips, so he no longer feels more productive at all, even though the whole team is ten or twenty-five times faster than it was. Michael described the same gap from the other side. He feels twenty to thirty times faster when he builds, and the speedup does not show up in revenue or growth.

Individual tool proficiency was an advantage while the baseline was low. The baseline moved.

What the speed does buy is ambition. Gergely pointed at migrations nobody would have green-lit before: a team rewriting its platform and API from Python to Rust, roughly six months in when he interviewed them and ninety percent done when he checked back two months later. Notion has been moving its app to native for years, and the editor, the hardest part, is only going native now, about seven years into the effort. His framing is that these tools raise ambition as much as throughput: teams attempt work they would never have attempted, while people, caution, and the limits of how fast you can push change on customers still apply.

The interesting collapse is at the IC level

Gergely started his career in 2007, when companies hired the Java engineer, the Python engineer, the PHP engineer, and asked for a specific number of years in that specific language. That unwound in stages. His 2022 research caught startups, including ambitious ones, abandoning native mobile for React Native so one engineer could ship one codebase to every frontend platform. The newest stage came from inside a frontier lab: OpenAI's head of engineering told him they stopped hiring iOS and Android engineers, and stopped pulling internal specialists onto mobile work, because the models are good enough at it.

What is left, in his view, is two camps, the product engineer and the platform engineer, and those two are further apart than backend and frontend ever were.

Michael's version of that story predates AI entirely. He picked TypeScript in 2018 to erase the backend/frontend divide, after watching a previous company reject the same candidate twice: too weak for backend, said the backend team; too weak for frontend, said the frontend team. The boundary he engineered around has since dissolved on its own. With agents in the loop, it matters much less what language a service is written in.

More output means more product managers

Here is the part worth copying into a headcount model. WorkOS famously ran without a product manager for its first several years, hired one, and hired two more in the last month. The driver is throughput: each engineer now covers the ground of five to ten engineers, so there are more products in flight and more product work to do. Meanwhile architecture, delivery, QA, and testing all demand more attention, which leaves engineers less brain time for product thinking, not more.

The catch is the bar. WorkOS PMs do not ship production code, but they run their own BI and analysis and build their own prototypes, and because the product is for engineers the role only works if the person is technical. Michael described skipping the spec and the deck for a new product direction and building a prototype instead, then using it as the center of the conversation with the team.

Gergely sees PMs surviving across most companies he talks with, while PMs and engineers both absorb more of the product decisions. Both of them describe more product hiring, not less, which is the opposite of what the headcount-cutting version of this story predicts.

Build the harness you will throw away

Michael explained why WorkOS built its own agent harness instead of adopting a commercial one: "I realized we wouldn't be able to experience what was on the frontier unless we built it." Wait for the commercial version and, at best, you arrive at the midpoint of the adoption curve, and building your own means doing work you will throw away. He was clear this was not an attempt to compete with Devin. The point was to feel what the labs feel while they are building, and he argued there is no way to do that from the outside.

The trade is unusually explicit about its cost: spend engineering time on something you expect to discard, and what you get back is a position on the adoption curve you cannot buy later.

Reliability is inherited, not bolted on

Someone in the audience asked whether degraded reliability is simply the new normal, more software progress in a year than in the previous ten, and worse uptime to go with it. Gergely's answer was blunt. He pulled his own podcast off Spotify's video format because the platform's video reliability was bad enough to warrant it, after giving them feedback and a chance to improve.

The companies he has looked at that are not degrading, Uber and Ramp, had strict, well-engineered systems before agents arrived, and they are not bolting agents on mindlessly. Uber built systems specifically to cut noise and raise signal in AI-generated code contributions, prioritizes changes by impact, and improved observability alongside. Ramp leans on internal testing, ownership, and what he called paranoia. His conclusion was almost circular, and more useful for it: reliability gets fixed by caring about reliability, and companies that don't will lose business the way Spotify lost his video.

For an engineering leader, that turns the AI reliability question into a question about last year. What did your review, testing, and observability look like the day before you turned agents on? Volume of agent-written code matters much less than that answer.

Agents are a consumer class nobody staffed for

Asked where product interfaces go as more consumption moves through MCP, Michael walked through what WorkOS has already shipped. First an MCP server for the docs, because agents were bad at crawling the site and any docs sitting in a model's pre-training would not cover recently shipped products. Then a headless dashboard where the agent has full control. He did not want to click through the dashboard himself, and he wanted the agent to do the integration end to end.

Then the part that closes the loop. WorkOS published auth.md in May as a discoverable registration path for agents, including an anonymous start where the service allows it. As Michael described it, you can prompt Codex today and it will sign up for a WorkOS account without you involved, get an API key, complete a full integration, test it, and deploy it. The payment rails for that flow are not built yet.

The agent-first path: discover the registration file, get a credential, integrate, deploy, and leave the human account step for whoever shows up later.

Nobody in the room asked the obvious follow-up: in a signup flow with no person and no payment step, what stops it from being abused? The answer in practice is limits rather than identity. Neon used auth.md to build Claimable Neon, where an agent provisions a temporary Postgres project anonymously and a person claims it into an organization later. An unclaimed project expires after 72 hours and is capped at 100 MB of storage and 1 GB of transfer until someone claims it. Give the agent something real, keep it small and short-lived, and make ownership the thing a person has to show up for.

Michael's argument for doing any of it: the web did not die when phones arrived and it will not die now, but agents run at night, in parallel, and faster than a person can read. Keep building for people. A company that is not also building for agents is not building for a new consumer class, and may be giving up its biggest growth opportunity.

Go somewhere you will get scarred

The most practical career advice of the night came out of a story about expertise everyone assumed was worthless. In 2022 or 2023, Gergely and former Uber colleagues were reminiscing about the hypergrowth years, when growth mattered more than profit, and concluding those skills would never be needed again. Those people are in high demand now. The pattern repeats: the engineers who learned ultra-high-scale reliability at Google or Meta early became the architects and engineering leaders of the era that followed. His instruction to the room: "You got the scars. Go to places where you're going to get scarred."

The inverse has a cost he is watching in real time. He has talked with leaders in Australia, New Zealand, and Europe who left their jobs because their organizations could not change fast enough to adopt AI into how software gets built. Not every company is exposed, though. At a summit in February, a founder told him six months was the furthest out he could forecast anything; a commerce leader told him two years was a fine horizon, because manufacturing goods abroad and shipping them over does not change, and AI only makes it more efficient.

On the entry-level question, which someone asked directly: they need reps, there is no recipe yet, and open source helps. Then came the ask he made of everyone senior in the room: go argue for hiring interns. An intern is a one-off three-month cost, it lifts team morale, it gives you a real view of what someone can do, and the new ideas travel in the other direction.

Gergely put the "is this job going away" question to engineers at a frontier lab. A sales-focused engineer said yes, all of it; the platform team said they are as busy as ever, just working on different things. He lands with the platform team, and the material argument is why. There is an enormous amount of software still to build, rebuild, and rebuild again, and from here on, deciding which material each piece is made of is the job.