Euge's blog - Engineerification

Engineerification

Why more professions are becoming engineer-shaped just as engineering itself may be automated

Published on 2026-08-23

| Tags:

ai,

work,

engineering,

systems-thinking,

agents,

mathematics

TL;DR: I have been noticing professionals in very different fields adopting workflows that look increasingly like engineering: repositories, agents, tests, automation, formal specifications, and feedback loops. The deeper change is not that everyone is learning to code. It is that domain experts are becoming responsible for systems that perform parts of their work. I have been calling this engineerification . I do not know whether it is desirable, or even durable. The strange possibility is that many of us may become engineer-like just before agents become capable of doing much of the engineering too.

I recently watched a lecture for mathematicians that spent a surprising amount of time on the terminal.

The speakers recommended working in local directories, giving coding agents carefully limited permissions, keeping projects in repositories, committing changes, writing instruction files, running tests, and using Lean to check formal proofs. They demonstrated Claude Code and Codex, discussed which models were better for long sessions, and explained why a mathematician might move work out of Overleaf and onto a local machine.

This was not a software engineering conference. It was a special lecture on LLMs and mathematics at Brazil's Institute for Pure and Applied Mathematics.

The practical advice was concrete enough to feel ordinary. A mathematician described starting the day by entering a project directory and launching an agent. Another described numerical experiments that once required learning an unfamiliar programming language and can now be assembled by asking a model for subroutines, testing them, and using the results to develop intuition.

Something about this caught my attention.

Mathematicians have used computers for a long time. Numerical methods, symbolic systems, LaTeX, and proof assistants are not new. But this looked like more than adopting another tool. The shape of the work was changing. A mathematical project was becoming a software project: a collection of files with dependencies, permissions, executable checks, version history, and an agent operating inside it.

After that lecture, I started noticing the same shape elsewhere.

A profession changing shape

The other talks I had been watching were less instructional and more existential.

In The Last Generation of Mathematicians, Jacob Tsimerman distinguishes concern for mathematics from concern for mathematicians. Mathematics may continue to expand even if the familiar working life of a mathematician does not. He imagines a period in which people solve problems partly by directing language models, while remaining careful about forecasting what comes after it.

In his ICM 2026 public lecture, Terence Tao approaches the disruption through the values of mathematical practice. Producing a valid argument is not the whole activity. Results must also be verified, explained, digested, connected to existing knowledge, and judged interesting enough to pursue. A machine may accelerate some of these stages without settling what the community should value in the others.

The three lectures seemed to describe different layers of the same transition.

One showed a profession reconsidering its purpose. Another showed anxiety about its identity. The practical lecture showed what people do on Monday morning: open a terminal, navigate to a repository, start an agent, inspect its changes, and decide whether the result can be trusted.

That last layer may be the most revealing. Large changes in work often arrive first as small changes in routine.

More than learning to code

I have been calling this pattern engineerification .

The word is intentionally a little awkward. I do not mean that every mathematician, designer, analyst, or lawyer is becoming a software engineer. I also do not mean that engineering owns systems thinking, or that other professions lacked rigor before Git appeared.

What seems to be spreading is a particular responsibility: domain experts are increasingly expected to create, supervise, and improve systems that perform parts of their domain work.

The important shift is not from natural language to programming language. An agent may hide most of the code. The shift is from doing a task to shaping a process that repeatedly does the task.

That requires a different kind of attention. What information enters the system? Which dependencies does it rely on? How does it behave when the input is strange? What can it modify? How do we know whether its output is correct? How can a change be reviewed, reversed, or reproduced? Who is responsible when a locally reasonable result causes a wider failure?

These are engineering-shaped questions even when the underlying subject is mathematics, design,...