I get this question a lot, and I found it hard to answer briefly, so I ended up writing a longer post about how I work:

https://www.trigosec.com/insights/mob-programming-for-one/

The short version is that I don’t let AI agents work unsupervised on my code. I treat them like participants in a mob programming session instead of autonomous developers. Different agents get different roles (implementer, reviewer, architect, security reviewer, etc.), and I stay involved throughout the process.

I also agree with your point about architecture. Generating isolated components is relatively easy; preserving and evolving the architectural boundaries across a larger codebase is much harder.

We’re still missing a good way to express and measure architectural quality. Until then, architecture heavy work requires much closer supervision than implementation heavy work

I personally limit LLMs to single files only at the moment. Self-contained components.

Using LLMs in a larger scope can sometimes work, but it has the real risk of turning a project into a mess after which you will have to undo the work and lose a lot of time.

Also, using LLMs this way with less clear boundaries will make reading and maintaining the code more cumbersome.

Me when not trying to meet management expectations, only as smarter code completion, formatting code, basic code analysis, and helping copy pasting code examples between languages.

Me when meeting management expectations, agent orchestration tools like Boomi and Workato calling into tools, doing with AI what a few years ago would be done with BPEL.

I built this with 94% written by coding agents: https://buildermark.dev/

The complete log of all prompts and commits is here: https://demo.buildermark.dev/projects/u020uhEFtuWwPei6z6nbN

I used LLMs to develop Whistle Enterprise (https://whistle-enterprise.com) from the ground up, from scratch.

It's taken _a lot_ of time and effort, but this is an example of what can be developed using LLMs alone.

You have to have dedication and a goal to reach, but you can absolutely build anything if you're building with the right foundations in mind.

You have to make those architectural decisions and feed them to the agents. Be very specific. That's been my experience.

I found that this guys stuff has really helped me:

https://youtu.be/-QFHIoCo-Ko?is=FYYdukWluYX3vdQL

Worth a watch.

It's great for people who are just maintaining something. Less so for someone building something from scratch, in the earlier phases.

There are hour long youtube videos where people explain the process by using a complex toy project. Search for them.

For decades, engineers understood that large code reviews are harder than small ones. Out of both politeness and a desire to receive better code reviews, we learned to break our large changes into smaller chunks. Some engineers took things even further and replaced code reviews with pair programming. But then LLMs showed up and everyone seems to have forgotten those lessons.

They can be still be applied now using coding agents, if you're willing to push back against the default setup and change your mode of thinking a little bit. Of course it doesn't help that an entire industry is dedicated to persuading us that maximizing token spend is the only way to get shit done.

I appreciate this probably seems like an extremist take, but I wrote some more about it here in case there's anybody out there who identifies with it:

https://philbooth.me/blog/agentic-coding-and-mental-models

Proper review should take longer than writing it yourself, because you need to know the correct solution, understand the proposed solution, and evaluate the difference between the two. When designing it yourself, you just need to know the correct solution and write it, and with modern high-level languages and IDEs with autocomplete writing it is hardly a bottleneck.

If I'm attentive during spec/plan creation I sort of build this "expectation" of what the actual PR will look like, the mental model of it. Then it's somewhat easier to review. But the mental load is brutal tbh, and still not sure if it's "worth it"

There are tons of people, those are just not as vocal.

Could be (the overcomplicating part), I'm just not yet comfortable loosing the mental model of the final application. At least not in all types of tickets. Are you not seeing that?..

All these people saying UI/UX is dead, then I see their designs and they're absolutely the worst (but they're always swearing by how incredible it is).

Sorry access to an LLM (even if it could center a div reliably and make a responsive designs, it can't) does not give you taste, intuition or make you good at building user interfaces. You people/sloppers have no idea the amount of sweat that gets poured into great UX.

Its insulting when you people say these things and Im not even a designer or frontend dev.

I actually think UI/UX designers and devs will be the last to fall. I will want beautiful products that were built by beautiful minds, thats how you will set yourself apart from the slop. And fortunately it will be even easier when 80% of everything is half assed cranked out UI by llm design tools. The contrast is already glaring.

> All of processor above have reference manuals and sometimes example git repositories available on open internet.

okay? then give those reference manuals and git repositories? I haven't heard something know LLMs can't get around and figure out?