logoalt Hacker News

threatofrain • yesterday at 8:35 PM • 1 reply • view on HN

Why must agentic engineering be all in?


Replies

CharlieDigital • today at 12:12 PM

If a team wants the benefits of velocity with AI, the consequence is volume.

To deal with the volume, the system needs more checks than humans can handle. Additionally, the humans no longer understand the details at the low level of implementation at scale. Therefore, the system only needs to assert that it is following agreed patterns.

So the initial scaffolding needs to be agent friendly. The processes need to be aligned to agents. The tooling needs to be agent operable and put on rails. The patterns need to be documented to be enforced.

Otherwise, teams get volume that cannot be handled by humans. So full speed agentic engineering requires teams to be all-in.

A piece of this is to leverage the harness to normalize or standardize output. Standard patterns, standard architecture, standard UI libraries. These are all much easier to enforce with agents than with humans, but requires extensive platform and harness engineering.

Teams do not really understand this yet. Engineering teams still think their job is to build product faster. By the 10th time you tell an agent "implement issue #15639", you realize anyone could have done that. Engineering's job now is to own the enterprise harness (context layer, ephemeral agent env, ingress channels, auth proxies, MCP servers, quality gates, agent ops, etc) so anyone can build the product. That's what "all-in" means.

Once this system is set up and well executed, it really doesn't matter who writes the initial prompt. An enterprise harness designed to enforce safety, security, and best practices applies to a senior dev or a junior dev or a product owner all the same. All-in on engineering the enterprise harness, not the product.