11–17 of 17 posts
[flagged]
> …If you don't measure it, you don't see > it until something breaks in production… > … > …the slow, silent divergence between > what you intended and what actually exists… What's your take on the absence of any mention of tests in the OP's loop steps?
[flagged]
Two important part that has been left out from the article is 1) service code size, our services are small enough to fit in a context + leave room for implementation of the change. If this is not the case you need to scope it down from 'read the whole service'.
The other part is that our services interact with http apis specified as openapi yaml specs, and the refactoring hopefully doesn't alter their behaviour and specifications. If it was internal apis or libraries where the spec are part of the code that would potentially be touched by the reafctoring I would be less at ease with this kind of approach
The service also have close to 100% test coverage, and this is still essential as the models still do mistakes that wouldn't be caught without them
Earlier quoted context omitted.
> …If you don't measure it, you don't see > it until something breaks in production… > … > …the slow, silent divergence between > what you intended and what actually exists… What's your take on the absence of any mention of tests in the OP's loop steps?
Opus 4.6 is smart enough to run the tests without being told to do so, that's why it isn't in the prompt
So, thanks :)
[flagged]
That's the point of the loop, (the prompt is in another comment) start with a fresh context at every step, read the whole code base, and do one thing at a time. Two important part that has been left out from the article is 1) service code size, our services are small enough to fit in a context + leave room for implementation of the change. If this is not the case you need to scope it down from 'read the whole service…
> …our services interact with http apis…
> …
> …If it was internal apis or libraries…
Given my admittedly limited experience with coding agents, I'd expect a fully autonomous agent to have a tendency to do naïve juniory dev stuff.
Like, for example, write code that makes direct calls to your data access layer (i.e., the repository) from your controllers.
Or bypass the façade layer in favor of direct calls from your business services to external services.
FWIW: Those are Java/Spring Boot idioms. I'd have to research whether or not there are parallels in microservices implemented in Go.
Earlier quoted context omitted.
That's the point of the loop, (the prompt is in another comment) start with a fresh context at every step, read the whole code base, and do one thing at a time. Two important part that has been left out from the article is 1) service code size, our services are small enough to fit in a context + leave room for implementation of the change. If this is not the case you need to scope it down from 'read the whole service…
> …our services interact with http apis… > … > …If it was internal apis or libraries… That reminds me that I wanted to ask you: How good is your agent with complying with your system's architectural patterns ? Given my admittedly limited experience with coding agents, I'd expect a fully autonomous agent to have a tendency to do naïve juniory dev stuff. Like, for example, write code that makes direct calls to your dat…
In my experience the latest model (Opus 4.6 in this case) are perfectly able to do senior stuff. It's just that they don't do it from the get go, as they will give you the naive junior dev solution as a first draft. But then you can iterate on refactoring later on
Earlier quoted context omitted.
> …our services interact with http apis… > … > …If it was internal apis or libraries… That reminds me that I wanted to ask you: How good is your agent with complying with your system's architectural patterns ? Given my admittedly limited experience with coding agents, I'd expect a fully autonomous agent to have a tendency to do naïve juniory dev stuff. Like, for example, write code that makes direct calls to your dat…
The architectural patterns are similar in go. The part of the prompt that contains the refactoring concerns that I wanted to fix are specific to this go project. You can very well add what you just explained and not only will it follow it, it will cleanup the parts when it isn't done. You don't need to fully explain the concept as it probably nows them well, just mentionning the concept you want to fix is enough. In…
> …You don't need to fully explain the
> concept as it probably nows them well…
> 1 Establish a Clear Vision
…
You have experienced the world, and you want to work together with a system that has no experience in this world you live in. Every decision in your project that you don’t take and document will be taken for you by the AI…
Instead, I ended up getting a coding agent to run through a thought experiment [1] based on the method described in the blog post.
The AI's critique sounds kinda harsh to me. So, I'm quoting only a snippet of it here…
———
…Running this specific recursive loop without a higher-level architectural constraint or a "convergence metric" will likely result in a specific type of technical debt known as _Ravioli Code_ (the inverse of Spaghetti Code)…
…
The prompt provided optimizes for _local code metrics_ (file length, shallow SRP) at the expense of _global architectural cohesion_.
In your specific $A \to B(C)$ scenario: _$A$ stops being a class that "does something" and becomes a class that "configures things that do things_."
The eventual system is one where every piece is perfectly unit-testable, perfectly mockable, and adhering to strict SRP, yet the system as a whole is incomprehensible to a human reader because the "story" of the code has been shredded into a thousand paragraphs scattered on the floor…
———
Again, those are the words of the automaton; not mine. I simply pointed it at the blog post and this thread. I asked it what it thought of the approach and final results discussed in the blog post.
Then, in the vibe coders' vernacular, I "let it rip" ;)
Today I noticed a follow up blog post [2]. That one noted a number of things that resonate with my relatively lightweight experience with agentic coding…
> …
> We're not there yet…
> …
> If you want the agent to tackle a
> specific architectural smell, you
> need to name it…
> …
> You need to give direction. The
> refactoring principles are specific
> to each project's goals and technology choices.
> …
[2] https://frederic.vanderessen.com/posts/unsupervised-refactor...