[efitz]

There are many projects that should not be built agentically.

For things that are appropriate to build with agents, I have come to hold the strong opinion that you need to go all-in. If you built it with an agent, then you fix it with an agent, you debug it with an agent, and you change it with an agent.

In that case you should not consider yourself the steward of the source code and worry about “cognitive debt”- it’s literally not your job anymore. Your job is the keeper of the specification and care and feeding of the agents.

If you adopt the mindset that “I’m not going to build the documentation for me, I’m going to build it for the agent”, and “I’m not going to try to use my development skills to debug something I didn’t write, I’m going to make specific interfaces for the agent to understand the state and activity of the running code”, etc.- you’ll be a lot happier and more successful.

If you are using agents for autocomplete in your editor, or you open a separate chat window to ask a question about your code- that’s a very low level of agent usage and all your existing dev skills and responsibilities still apply.

If you’re using a planning framework like superpowers (the skill) and just laying out the spec for the program, then keep your fingers out of the source code, and don’t waste your time reading it. Have the agent explain it, showing you in the IDE, and make the agent make any changes you want.

[Aperocky]

This is correct, but it misses out an important dimension.

You can inject philosophy into the agent and ensure that it sticks to it. The LLM will, with sufficient drilling, begrudgingly implement it, most important of which is SIMPLE>COMPLEX on all levels and you have to either manually or agentically continuously monitor this.

Alternatively, LLM will use its tiny context window to build a true spaghetti that even itself cannot fix any more. This is the default path, and the path that way too many has taken.

[prmph]

> Alternatively, LLM will use its tiny context window to build a true spaghetti that even itself cannot fix any more.

And this is (probably) what is happening to the Claude Code product itself. The harness itself has regressed and is increasingly unstable. I get lots of weird glitches:

- I scroll back in the conversation and keep seeing the the same sections repeated, I am not actually able to see the earlier parts of the conversation because of this.

- The whole CLI UI glitches out such that you can't even make sense of what you are seeing. This is usually fixed by resizing the terminal window

- The previous edit in the conversation history gets lost when I escape it to provide direction

- The CLI sometimes consumes huge amounts of memory (more than 10GB per window, multiplied by the number of windows I'm working in)

- Etc

[Aperocky]

90-95% of all projects suffer this fate, and it didn't start with LLM. These projects include major commercial successes such as certain popular desktop Operating System and are essentially the standard state for many web services.

The projects that keep it simple and bare-necessity are either the ones that have scaled to enormous size (and complexity had to be removed for it to work), or ones that had strong philosophical and opinionated guardians, they are quite rare in practice.

[Gravityloss]

I wonder if there is some easy way to have a "spaghetti index" of a codebase. One could then have different criteria for different projects / parts of projects. If it's a business critical thing that also expects to see a lot of future development, one could then communicate to management that the spaghetti index is too high and that must be first lowered before further development can happen. And on the other hand, if it's a throwaway tool that's used for a limited time, no matter.

[Aperocky]

It's not just codebase, it applies to product, design and even human interactions.

It's hard to describe how important I think this principle is for a project, company or even life.

[Gravityloss]

Yes, sure, it won't solve everything and wouldn't be perfect.

In a corporate environment, if you can measure something with a number, then you can set a target and pass/fail criteria and so on. Developers' personal opinions of some code base's quality are harder to build corporate processes around.

There's things like integration tests and static analysis. Of course again, not foolproof and don't solve all problems. But they help. Especially in a corporate environment where you need all the mechanisms you can get to prevent skimping on quality.

[deterministic]

Not my experience at all. I’ve been using Claude Code on a large "hand written" project and it’s genuinely excellent at finding bugs and generating new methods or classes.

That said, it still frequently introduces subtle bugs, so I have to review every change carefully.

The real trick is learning when to use it. Some tasks are much faster to do myself, while others are faster with Claude Code.

[nicbou]

Same experience here. It produces code that I would not accept if it was written by a human, but it also produces a lot of completely fine code. It made me clear tasks that I had been procrastinating for a long time.

[Yokohiii]

tldr; agentic coding just works, you just have to put puny humans on a leash