I opened three terminals this week and noticed something strange.
in the first, an agent was refactoring a legacy module. in the second, a sub-agent was reading documentation and spitting out a migration plan. in the third, I was reviewing what the first one had done while the second one waited on me.
in none of the three was I developing. I was orchestrating. deciding how those three pieces would talk to each other, defining how far each one could go on its own, validating one’s output to become another’s input.
and then it hit me: this isn’t development. this is engineering.
a bit of etymology
the word engineering comes from the Latin ingenium — natural ability, talent, genius. it evolved into ingeniator in medieval Latin, the term for someone who built engines: machines, devices, contraptions.
an engineer is someone who creates engines.
a developer… develops. it can be code, a photograph, a child. it’s a much looser term. the industry embraced developer in the 2000s and we all went along, but there’s a subtle difference: a developer writes code. an engineer decides which code deserves to exist.
for a long time the two words described pretty much the same thing, because the work was the same: someone writing the lines that went to production. the distinction was just semantics. not anymore.
what changed
today the agent writes the lines. I haven’t typed for (let i = 0; i < array.length; i++) in months. Claude Code types for me. Cursor types. Copilot types.
what’s left for me?
designing. deciding which agent does what. defining contracts. orchestrating the conversation between them. choosing architecture. deciding what goes in the context and what stays out. validating output. managing trade-offs.
engines. I build engines.
and that completely changes what it means to be good at our job.
and when I stop to look at the whole team of agents I have running — personal agents that remember preferences, sub-agents that coordinate among themselves, hooks, skills, mcps — there’s no way to pretend it’s just “developing a product”. it’s designing a system. small, personal, but a system.
the classics didn’t age. we were just distracted.
here’s where it gets funny.
remember the pragmatic programmer? that book by Hunt and Thomas every bootcamp tells you to read and almost no one finishes? pick it up again now. most of those principles not only still hold — they’ve become more important. not because the principles changed, but because the environment they operate in did.
let me grab a few.
plain text always wins
Hunt and Thomas wrote a whole chapter defending plain text as a durable format. nobody really read it. today the entire agent stack is plain text — claude.md, specs in markdown, .agents/, prompts in files. the chapter became prophecy.
design by contract
Bertrand Meyer, ‘86. you define what the component promises, what it requires, and the invariants. that’s exactly how you talk to an agent: input, output, invariants. specs, schemas, json contracts. without the contract you can’t even start.
tracer bullets
a thin vertical slice connecting point A to point Z, even if ugly, instead of planning everything on paper. AI supercharges the shot, not the aim — you still decide where to point.
orthogonality
independent components, isolated changes. high coupling stopped being a human-only problem — now it blows up tokens, confuses the agent, kills the output. orthogonality moved from “good practice” to a productivity prerequisite.
configure, don’t integrate
the original chapter was about not compiling configuration into code. MCP is configure, don’t integrate elevated to a protocol. each new connector is a config, not an integration — Hunt and Thomas wrote the spec 25 years before it existed.
programming by coincidence
the most dangerous one. it’s when the code works and you don’t know why — but you keep going, because it’s working. with AI it became the path of least resistance: the agent delivers, it looks ok, you merge. if you don’t understand what you accepted, you’re not the engineer of the system, you’re the person who hit enter.
conway’s law
systems mirror the communication structures of those who build them. holds for agents too. if one does the work of three and the others sit idle, you designed a dysfunctional team. Conway is laughing in his grave.
so what?
there’s an old meme of someone looking at a 1995 book and realizing it describes, in different words, exactly the problem you’re solving today. that’s how I feel re-reading Hunt and Thomas, Brooks, Fowler, McConnell.
it’s not that they predicted AI. they were describing principles that survive any generation of tools. the shovel changed — now the shovel digs by itself — but the ground is the same.
the difference is that we used to be able to ignore it and still ship. there was time to redo, to refactor, for the senior architect to save the day at the end of the quarter. today, with an agent spitting out PRs every 20 minutes, if your architecture is weak the agent breaks it in an afternoon. if your contracts are vague, the agent comes up with a thousand different interpretations in the same sprint. if your code is coupled, it gets lost in context and produces noise.
AI didn’t invent engineering. it just took away the excuse we had to ignore it.
and maybe — just maybe — we’ve always been engineers. we were just distracted writing for loops.
ps: the pragmatic programmer is a great book and worth revisiting. it survives well if you understand the timing of when it was written and can separate the principle from what aged out. two episodes from one of my favorite podcasts cover this better than I could here (both in portuguese): great tech books on hipsters, and the revisited version I had the joy of being part of.