# Writing Code Is Easy Now, Getting the Process Right Isn't > Source: > Published: 2026-08-28 12:38:59+00:00 This year has flipped a lot of what I knew about software engineering upside down. To stay up to date, I've been running a lot of experiments unlearning old habits, and looking at the same problem through the lens of agentic engineering. I'm writing down some of my key learnings, as of August 2026: - It's all about the process now - the sequence of execution, prioritization, the guardrails, the linters, 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 - 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 contracts. - 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. The next thing I'm trying to find an answer to: do we need code review anymore? If it's all generated by a coding agent anyway, perhaps this effort should go into a thorough specs and architecture review.