My 10 Observations From Implementing Agentic Engineering Processes

A developer reports that implementing agentic engineering processes shifts focus from writing code to defining constraints, guardrails, and architectural principles, with greenfield projects easier than adapting large codebases. The author emphasizes the need for invariant test cases, periodic cleanup, componentization, and clean architecture to manage token usage and costs, while noting that customer outcomes and observability data remain the ultimate measures of success.

I've been spending most of my time this year trying to keep up to date with agentic engineering processes, and implementing them both for complex client projects and also my personal experiments. Here are some observations: - It's all about the process now - the sequence of execution, prioritization, the guardrails, the lints, the tests. Writing the actual code became the easy part. - Your focus needs to be on creating the right constraints for your code to grow into what you want it to be, rather than controlling every single detail of its internals. - You need to know what you want it to be though - it's you who brings the domain and the systems architecture expertise. - You need some guiding invariant test cases that let the agent move forward without drifting away from the requirements. Your agent shouldn't be able to modify them without your explicit approval. - You need strong and clearly defined architectural principles, available to the agent at all times. Examples: stick to the object oriented programming paradigm, use strongly typed data transfer objects rather than throwing around generic instances of hash/dict, use hexagonal architecture etc. This prevents the agent from mixing too many different styles in a single codebase and ending up with a huge chunk of spaghetti. The exact choice is up to you, whatever you know will work well for this particular application. - You need a periodic cleanup process, because all the leftovers and dead code confuse your agent and lead to it generating overcomplicated code later on. - Building greenfield projects is generally easier than adapting large existing codebases to agentic engineering processes. If you have the right set of guardrails from the start, it's easier for a coding agent to work with the codebase. - Componentization of large applications helps a lot. Either via microservices or isolated packages. It comes with overhead, but it's easier to manage constraints in a smaller codebase, and test the integration contract. - A clean architecture naturally optimizes the project for token usage, which in turn keeps the cost under control and the loop execution time reasonable. That said, I wouldn't make the token usage my only metric to optimize for, as the per-token costs will likely go down in the upcoming years. - The ultimate answer to whether a feature is well implemented is whether it works well for the customers and honestly, it's always been like that . The more data you can get from the observability layer in prod, and feed it back to the agentic engineering process, the better.