Moving fast

Building software is faster now. Meaningfully faster. Problems that used to take days take hours. Code that would have required a week of careful architecture gets scaffolded in an afternoon. That part is genuinely good, the velocity is real, and nobody is going back.

The part of engineering that used to be slow, the part where you got stuck, where the system pushed back, where you hit an edge case you had not anticipated and had to figure out why, that is the part where you actually understood what you were building. The friction was not waste. It was information. When a system takes time to build, it has time to teach you what it needs to be. When it comes together in an afternoon, you skip a lot of that. You get to the end faster and you know it less well.

Everyone feels this. The code is correct. The tests pass. And there is a part of every engineer right now that is not sure they would catch the thing that breaks it in six months because nobody spent enough time in the middle.

Agentic tooling makes this more complicated. There is a real question about where in the stack autonomous systems should operate, and the industry has not answered it honestly yet. Changes from the top of the stack are expensive, in tokens, in surface area, and in downstream consequences that are hard to predict. A system that can generate code faster than you can review it is a system that can accumulate debt faster than you can see it.

The flip side is real too. The iteration speed means you cover more ground faster, see patterns in an afternoon that used to take weeks to encounter. That exposure is tangible - when using new tools, you aren't only reading docs; you are seeing how the tools apply in your own codebase within a few minutes. GitClear's analysis of over 153 million lines of code found that code duplication has risen fourfold with AI adoption - which suggests a lot of pattern matching is happening without the deeper architectural thinking that used to accompany it.

The identity question is one everyone is sitting with. Not in a crisis way, more in a genuine uncertainty way. Are we here to build things, or to make sure the things that get built are good? Are we guardrails or engineers? The answer is probably both, but the balance is shifting faster than anyone can track.

We are building systems for systems for systems, and the recursion does not have a clear bottom. The definition of the work keeps changing before anyone has figured out the last version of it. For me, at least - that same complexity is what makes it interesting to be in the industry right now.

The people who figure out how to stay grounded in what makes software actually good, not just fast, not just functional, are going to build things worth building.

Taking a beat to catch up