Simon Willison’s Weblog

--- +++ @@ -10,9 +10,8 @@ The ability to run parallel agents makes this even harder to evaluate, since one human engineer can now be implementing, refactoring, testing and documenting code in multiple places at the same time. -<div id="good-code"> +<h2 id="good-code">Good code still has a cost</h2> -## Good code still has a cost + -</div> Delivering new code has dropped in price to almost free... but delivering *good* code remains significantly more expensive than that. Here's what I mean by "good code":

--- +++ @@ -10,8 +10,9 @@ The ability to run parallel agents makes this even harder to evaluate, since one human engineer can now be implementing, refactoring, testing and documenting code in multiple places at the same time. +<div id="good-code"> ## Good code still has a cost - +</div> Delivering new code has dropped in price to almost free... but delivering *good* code remains significantly more expensive than that. Here's what I mean by "good code":

--- +++ @@ -26,4 +26,12 @@ - The design affords future changes. It's important to maintain [YAGNI](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) - code with added complexity to anticipate future changes that may never come is often bad code - but it's also important not to write code that makes future changes much harder than they should be. - All of the other relevant "ilities" - accessibility, testability, reliability, security, maintainability, observability, scalability, usability - the non-functional quality measures that are appropriate for the particular class of software being developed. -Coding agent tools can help with most of this, but there is still a substantial burden on the developer driving those tools to ensure that the produced code is good code for the subset of good that's needed for the current project. +Coding agent tools can help with most of this, but there is still a substantial burden on the developer driving those tools to ensure that the produced code is good code for the subset of good that's needed for the current project. + +## We need to build new habits + +The challenge is to develop new personal and organizational habits that respond to the affordances and opportunities of agentic engineering. + +These best practices are still being figured out across our industry. I'm still figuring them out myself. + +For now I think the best we can do is to second guess ourselves: any time our instinct says "don't build that, it's not worth the time" fire off a prompt anyway, in an asynchronous agent session where the worst that can happen is you check ten minutes later and find that it wasn't worth the tokens.

--- +++ @@ -20,7 +20,7 @@ - We *know the code works*. We've taken steps to confirm to ourselves and to others that the code is fit for purpose. - It solves the right problem. - It handles error cases gracefully and predictably: it doesn't just consider the happy path. Errors should provide enough information to help future maintainers understand what went wrong. -- It's simple and minimal - it does no more than we need of it, in a way that is simple to understand both now and in the future, for both humans and machines. +- It’s simple and minimal - it does only what’s needed, in a way that both humans and machines can understand now and maintain in the future. - It's protected by tests. The tests show that it works now and act as a regression suite to avoid it quietly breaking in the future. - It's documented at an appropriate level, and that documentation reflects the current state of the system - if the code changes an existing behavior the existing documentation needs to be updated to match. - The design affords future changes. It's important to maintain [YAGNI](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) - code with added complexity to anticipate future changes that may never come is often bad code - but it's also important not to write code that makes future changes much harder than they should be.

--- +++ @@ -20,7 +20,7 @@ - We *know the code works*. We've taken steps to confirm to ourselves and to others that the code is fit for purpose. - It solves the right problem. - It handles error cases gracefully and predictably: it doesn't just consider the happy path. Errors should provide enough information to help future maintainers understand what went wrong. -- It's simple and minimal - it does no more than we need of it, in a way that is simple enough for us to understand both now and in the future, by both humans and machines. +- It's simple and minimal - it does no more than we need of it, in a way that is simple to understand both now and in the future, for both humans and machines. - It's protected by tests. The tests show that it works now and act as a regression suite to avoid it quietly breaking in the future. - It's documented at an appropriate level, and that documentation reflects the current state of the system - if the code changes an existing behavior the existing documentation needs to be updated to match. - The design affords future changes. It's important to maintain [YAGNI](https://en.wikipedia.org/wiki/You_aren%27t_gonna_need_it) - code with added complexity to anticipate future changes that may never come is often bad code - but it's also important not to write code that makes future changes much harder than they should be.