In my 30+ years of SWE/SWA career this is the first time I can harvest the benefits of a well defined and exactly implemented architecture.

Thanks to LLMs.

Before LLMs even if the architecture principles were simple and clear, distilled into templates + codegens added for boilerplate / skeleton generation ... It was impossible to follow them on the long run. Devs tried their best, but on the long run everything eroded and there were no resources for refactoring.

Now, with coding agents, I was able to create a production grade app following a similar architecture to Presentation Domain Data Layering, from this article.

Now the codebase is 100% uniform both in content (code) and structure (files and folders). It's like being written by a single person. Finding a specific file takes a second with no cognitive load. Editing a file is straightforward since every file follows a specific template.

LLMs have benefits and drawbacks, and in this case their help is enormous.

▲

simonw 8 hours ago | parent [-]

Something I recently realized is that the fastest and easiest way to use coding agents is if you apply them to problems where there is just one, obvious solution.

This absolutely relates to architecture. If your system is designed such that any given feature fits in an obvious place, using obvious patterns, with obvious ways to test it... 90% of the time a coding agent will be able to do exactly the right thing from a single, short prompt.

This also makes code review so much less taxing - if the solution is obvious, reviewing and checking that the agent followed that obvious path takes much less time than if you're trying to untangle something a lot more complicated.

▲

csbartus 8 hours ago | parent [-]

Exactly! What I use is a main workflow document where I embed at every step pointers to architecture and templates.

My prompt is ... "We are implementing the X feature. We are at step 6. Plan first"

Then the agent spits out identical plans then identical code for every feature.

▲

amosjyng 8 hours ago | parent [-]

I am so curious as to how you make this happen.

1. How do you organize your architecture files so that agents know where to find and update architectural info? E.g. everything in one big file, or sharded per module/subsystem with an AGENTS.md for discoverability, or something else?

2. What gets templated? What do your template files contain or look like?

3. How do you get the LLMs to actually slot something into the right place? E.g. a problem I repeatedly run into is the LLM weakening abstraction boundaries. I have to explicitly tell it things such as "No, this is obviously a UI-specific endpoint that belongs on the BFF rather than on the business logic focused backend API." Of course it gets better as I add more examples and rules each time I catch something dumb, but it sounds like you're avoiding this problem altogether with good architecture. How are you doing that?

4. It sounds like you have some sort of workflow that is standardized yet still generalizable enough to cover the generic case of new feature development on the system. How is that possible? What can you share about this flow?

	▲	speedbird 4 hours ago \| parent [-]
		You can use a well known template like ARC42 and insist on the maintenance of suitable indexes for agent access and review for coherence on a regular basis. Ultimately any useful documentation needs active curation. Getting devs to do this well is hard. Agents can be driven to do a fair job through suitable prompt frameworks and repetition eg as PR reviewers. I’ve had reasonable success with a combination of space dimensions structured requirements and component based indexes and time dimensions of decision records and commits. Also a strong design model to give common structure - hex arch with ports and adapters and pure business logic. YMMV