Tag: engineering culture

AI can shorten implementation without shortening discovery. This essay gets the center of Domain-Driven Design right: the valuable part is not a diagram, a document, or a fashionable folder structure. It is the repeated work of learning the business, naming concepts precisely, separating contexts, and turning that shared understanding into software. An agent can draft an impressive model, but the team has gained little if nobody can explain which assumptions it made or recognize when the real domain contradicts it.

The useful tension is that a domain model still needs artifacts. Code records the implemented model, tests hold selected invariants, and decision notes preserve reasons, but none of them is the whole understanding. That makes DDD more valuable and easier to counterfeit at the same time. The practical standard is not how much domain language an agent can generate. It is whether engineers and domain experts can use the same vocabulary to challenge a design, keep changes small enough to review, and notice when an apparently correct implementation solves the wrong problem.

This is a useful designer's notebook on software quality because it pushes quality out of the narrow "does it work" box and back into the felt experience of using a product. Speed, clarity, reliability, craft, and the absence of papercuts all matter, even when they do not show up as a failing test.

The Hacker News pushback is worth keeping next to it: quality is not only the absence of visible problems. It is also resilience under harder conditions, maintainability, security, and the cost of change. The mature version combines both views: users feel polish at the surface, while teams feel quality in how safely the system can keep evolving.

This piece is worth saving because it is less about whether AI can write code and more about what happens when the job shifts from making the thing to supervising the thing. The strongest point is the tacit-knowledge gap: legal constraints, latency, security boundaries, roadmap context, and institutional memory are not automatically present just because a patch compiles.

The surrounding argument is the real fault line: some developers feel agents free them to operate at architecture and product scope; others feel the reps are where judgment is formed. My take is that both are true depending on the work. Delegation is leverage when the human still owns the model, constraints, and verification; it becomes skill decay when the review queue replaces the act of understanding.