I think it depends on where you work at and your team.

If you come from a good team with high quality engineers around you, I imagine the experience is not as good, or if you work in a big company where on your daily job you just owe a very small slice of the whole pipeline.

I have worked on several companies where my colleagues were very mediocre on software engineering fundamentals (I'm in AI before ChatGPT a lot of Jupyter Notebook warriors [Data Scientists] having to put stuff in production for midsized companies) and very average engineers, who wouldn't really care implementing patterns, tests, linting, documentation etc...

At the risk of sounding arrogant I always wanted to be able to just 'clone' myself and keep my code discipline consistently on a project, I would push a high quality PR with good test coverage and the cleanest code I could muster, while my colleagues would approve between each other PRs with no test coverage, no linting, horrible technical debt or with work arounds around linting, making my effort moot as the slop overwhelmed any quality I tried to implement. Not just one company, 3 companies I have seen the same experience.

Also I was a full stack AI engineer in the fullest sense of the word, I did devops, deployment, proxy set up, ci/cd pipelines, backend, frontend and AI, on local servers, no external team to deploy for me, no external team to qa for me all myself, with great flexibility (my manager was completely non-technical) to try different stacks and use AI assisted coding where I forced i my AGENTS.md for codex to destroy every code, or feature I was writing as a Staff engineer, allowing me to learn a lot and upskill autonomously extremely quickly.

With this knowledge, I set up my side project where I locked in a good stack, applied solid patterns from the beginning, extensive static checks for code (extremely strict linting, testing and coverage checks) and my trust on AI grew with the project and I catered exactly to my way.

The initial commits I used it to write extremely clean code almost by hand, checking every line, locking in the stack, the linters, testing methodology, tdd methodology, etc, and I was slow but writing very clean code and setting up code examples.

Once I noticed my progress was going slow, and was noticing the AI was getting prompted by my clean code as it read the files to suggest the next lines, I started letting it go more autonomously but checking every line of code, I set up a lot of markdown files on how to test, how to code, code styling, the architecture and the patterns and would make it mandatory reading to the ai before starting, with the existing 'clean code' I got really good results, I just had to enforce the discipline that I could not enforce on my colleagues.

With the memory system in claude code and countless iterations of fixing AI mistakes and not doing stuff the way I liked it, I arrived by myself on a very similar position as Steve Yegge on me and Claude converging to a set of laws and strict way of working, and I just have a lead orchestrator agent and subagents, where I pick the issues and check every PR before merging, and merge by hand always.

This includes a specific cycle of each subagent taking a worktree, symlinking to the .env, checking if the subagent will use Playwright (spin up it's own server) and estimate the RAM memory usage (I have allocated 15GB for programming), forcing subagents to run tests with their own Haiku subagents to not pollute their context, the orchestrator scoping the implementer subagent to Sonnet or Opus depending on complexity, every subagent gets a separate reviewer that enforces the ARCHITECTURE.md and ticket goals and runs mutations on the tests done by the implementer subagents (they are forced to implement with TDD).

It is it's own ecosystem coding exactly how I like, without complaining. My initial clean code few shots the AI on keeping high code standards and there is naturally some smell, but my reviewer agents enforce separation of concerns very strictly, I know the smell is contained and if it becomes an issue on my application I can easily refactor it without breaking the rest, which I think is the most important aspect on agentic development, accept the tradeoff of the speed, and keep it contained.

For example on every issue, my orchestrator will assign the implementer subagent exactly which files it can touch, and explicitly which ones it cannot touch. The orchestrator knows what all the other subagents are doing, and this helps prevent conflicts when you have 5+ running in parallel.

It's a lot, but it's wonderful ONLY if you have full control on the whole process. Having to work under someone else process must be a nightmare. So it's a very mixed bag I would say. However for me after so many iterations and convergence I'm extremely pleased, and am a big advocate for it, but you need discipline, and a high skill ceiling on what you are doing, and know how to build things.

[dead]