9 ms·

I’m seeing this more and more, where people build this artificial wall you supposedly need to climb to try agentic coding. That’s not the right way to start at

by exitb 6mo ago

I’m seeing this more and more, where people build this artificial wall you supposedly need to climb to try agentic coding. That’s not the right way to start at all. You should start with a fresh .claude, empty AGENTS.md, zero skills and MCP and learn to operate the thing first.

heliumtera 6mo ago
Operate == me send https post and pray for the best
- dietr1ch 6mo ago
  That's the goal, keep spending tokens and claim you are super productive because of it
jameshart 6mo ago
Yes, but as soon as you start checking in and sharing access to a project with other developers these things become shared. Working out how to work on code on your own with agentic support is one thing. Working out how to work on it as a team where each developer is employing agentic tools is a whole different ballgame.
- georgeburdell 6mo ago
  In my own group, agentic coding made sharing and collaboration go out the window because Claude will happily duplicate a bunch of code in a custom framework
  - mitchell_h 6mo ago
    In my AGENTS.md I have two lines in almost every single one: - Under no condition should you use emoji's. - Before adding a new function, method or class. Scan the project code base, and attached frame works to verify that something else can not be modified to fit the needs.
    - himmi-01 6mo ago
      I'm curious about the token usage when it scans across multiple repositories to finding similar methods. As our code grows so fast, is it sustainable ?
  - xmprt 6mo ago
    I think the idea is that by creating these shared .claude files, you tell the agent how to develop for everyone and set shared standards for design patterns/architecture so that each user's agents aren't doing different things or duplicating effort.
- sceptic123 6mo ago
  But why is it different? Why does it need to be? I don't write code the same as other devs so why would/should I use AI the same? Is this a hangover from when the tools were not as good?
  - thierrydamiba 6mo ago
    [dead]
  - lucideer 6mo ago
    I'd see this as being useful for two reasons: 1. Provision of optional tools: I may use an ai agent differently to all other devs on a team, but it seems useful for me to have access to the same set of project-specific commands, skills & MCP configs that my colleagues do. I amn't forced to use them but I can choose to on a case by case basis. 2. Guardrails: it seems sensible to define a small subset of things you want to dissuade everyone's agents from doing to your code. This is like the agentic extension of coding standards.
  - IanCal 6mo ago
    > I don't write code the same as other devs Most people do, most people don’t have wildly different setups do they? I’d bet there’s a lot in common between how you write code and how your coworkers do.
    - benoau 6mo ago
      I bet there's a lot more consistency now that AI can factor in how things are being done and be guided on top of that too.
freedomben 6mo ago
I totally agree with you that this not the right way to start. But, in my experience, the more you use the tool the more of a "feel" you get for it, and knowing how all these different pieces work and line up can be quite useful (though certainly not mandatory). It's been immensely frustrating to me how difficult it is to find all this info with all the low-quality junk that is out there on the internet.
- embedding-shape 6mo ago
  > all the low-quality junk that is out there on the internet. Isn't this article just another one in that same drawer? > What actually belongs in CLAUDE.md - Write: - Import conventions, naming patterns, error handling styles Then just a few lines below: > Don’t write: - Anything that belongs in a linter or formatter config The article overall seems filled with internal inconsistencies, so I'm not sure this article is adding much beyond "This is what an LLM generated after I put the article title with some edits".
Fishkins 6mo ago
I agree with most of this, with one important exception: you should have some form of sandboxing in place before running any local AI agent. The easiest way to do that is with .claude/settings.json[0]. This is important no matter how experienced you are, but arguable the most important when you don't know what you're doing. 0: or if you don't want to learn about that, you can use Claude Code Web
- post-it 6mo ago
  The default sandboxing works fine for me. It asks before running any command, and I can whitelist directories for reading and non-compound commands.
  - arcanemachiner 6mo ago
    That's not a sandbox.
    - kseniamorph 6mo ago
      there is a real one though — https://www.anthropic.com/engineering/claude-code-sandboxing https://www.anthropic.com/engineering/claude-code-sandboxing. needs to be enabled with /sandbox, not on by default.
      - Fishkins 6mo ago
        Right, that's what I was referring to
- sroussey 6mo ago
  Do people really run claude and other clis like this outside a container??
  - kenforthewin 6mo ago
    Let's not fool ourselves here. If a security feature adds any amount of friction at all, and there's a simple way to disable it, users will choose to do so.
hmokiguess 6mo ago
with Anthropic already starting to sell "Claude Certified Architect" exams and a "Partner Network Program", I think a lot of this stuff is around building a side industry on top of it unfortunately
beyonddream 6mo ago
.claude has become the new dotfiles. And what do people do when they want to start using dotfiles ? they copy other’s dotfiles and same is happening here :)
- silverwind 6mo ago
  .claude is likely to contain secrets and also contains garbage like cache etc, if it is shared, it should only be partially shared.
pgwhalen 6mo ago
Who is building an artificial wall? Maybe I skimmed the post too fast, but it doesn't seem like this information is being presented as "you have to know/do this before you start agentic engineering", just "this is some stuff to know."
Aurornis 6mo ago
This article isn't saying you must set up a big .claude folder before you start. It repeats several times that it's important to start small and keep it short. It's also not targeted at first-timers getting their first taste of AI coding. It's a guide for how to use these tools to deal with frustrations you will inevitably encounter with AI coding. Though really, many of the complaints about AI coding on HN are written by beginners who would also benefit from a simple .claude configuration that includes their preferences and some guidelines. A frequent complaint from people who do drive-by tests of AI coding tools before giving up is that the tools aren't reading their mind or the tools keep doing things the user doesn't want. Putting a couple lines into AGENTS.md or the .claude folder can fix many of those problems quickly.
nunez 6mo ago
This matters for big engineering teams who want to put _some_ kind of guardrails around Claude that they can scale out. For example, I have a rule [^0] that instructs Claude to never start work until some pre-conditions are met. This works well, as it always seems to check these conditions before doing anything, every turn. I can see security teams wanting to use this approach to feel more comfortable about devs doing things with agentic tools without worrying _as much_ about them wreaking havoc (or what they consider "havoc"). As well, as someone who's just _really_ getting started with agentic dev, spending time dumping how I work into rules helped Claude not do things I disapprove of, like not signing off commits with my GPG key. That said, these rules will never be set in stone, at least not at first. [^0]: https://github.com/carlosonunez/bash-dotfiles/blob/main/ai/claude/default_rules/____read_these_first.md https://github.com/carlosonunez/bash-dotfiles/blob/main/ai/c...
- bisonbear 6mo ago
  I'm also thinking on how we can put guardrails on Claude - but more around context changes. For example, if you go and change AGENTS.md, that affects every dev in the repo. How do we make sure that the change they made is actually beneficial? and thinking further, how do we check that it works on every tool/model used by devs in the repo? does the change stay stable over time?
  - nunez 6mo ago
    Given the scope that AGENTS has, I would use PRs to test those changes and discuss them like any other large-impact area of the codebase (like configs). If you wanted to be more “corporate” about it, then assuming that devs are using some enterprise wrapper around Claude or whatever, I would bake an instruction into the system prompt that ensures that AGENTS is only read from the main branch to force this convention. This is harder to guarantee since these tools are non-deterministic.
    - bisonbear 6mo ago
      PRs for AGENTS.md are necessary, but not sufficient, exactly because of non-determinism. You can LGTM the AGENTS.md change, but it's so hard to know what downstream behavioral effects it has. I feel like the only way to really know is by building a benchmark on your repo, and actually A/B testing the AGENTS.md change. I'm building something in the space - happy to share if it's something that sounds interesting to you
stronglikedan 6mo ago
Seems maybe you're just not the target audience for this article.
gck1 6mo ago
I'd also go even further and say that you likely should never install ANY skill that you didn't create yourself (i mean, guided claude to create it for you works too), or "forked" an existing one and pulled only what you need. Everyone's workflow is different and nobody knows which workflow is the right one. If you turn your harness into a junk drawer of random skills that get auto updated, you introduce yet another layer of nondeterminism into it, and also blow up your context window. The only skill you should probably install instead of maintaining it yourself is playwright-cli, but that's pretty much it.
- hombre_fatal 6mo ago
  I had an issue with playwright MCP where only one Claude Code instance could be using it at a time, so I switched to Claude's built-in /chrome MCP. In practice, I also find it more useful that the Chrome MCP uses my current profile since I might want Claude to look at some page I'm already logged in to. I'm not very sophisticated here though. I mainly use use browser MCP to get around the fact that 30% of servers block agent traffic like Apple's documentation.
  - egeozcan 6mo ago
    I was using the built-in chrome skill but it was too unreliable for me. So I switched to playwright cli and I can also have it use firefox to get help debugging browser-specific issues.
  - silverwind 6mo ago
    Would love if there is a way to parallelize playwright mcp using multiple agents and such, but it seems it's a fundamental limitation of that MCP that only on instance/tab can be controlled. Chrome MCP is much slower and by default pretty much unusable because Claude seems to prefer to read state from screenshots. Also, no Firefox/Safari support means no cross-browser testing. There appears to be https://github.com/sumyapp/playwright-parallel-mcp https://github.com/sumyapp/playwright-parallel-mcp which may be worth trying.
- s900mhz 6mo ago
  Yes this is the path I’m taking. Experiment, build your own toolbox whether it’s hand rolled skills or particular skills you pull out from other public repos. Then maintain your own set. You do not want to log in one day to find your favorite workflow has changed via updates. Then again this is all personal preference as well.
butlike 6mo ago
It's not as bucolic as this when trying to get an org on board. We're currently very open to using Claude, but the unknowns are still the unknowns, so the guardrails the `.claude` folder provides gives us comfort when gaining familiarity with the tool.
ymolodtsov 6mo ago
Peter Steinberger himself says he's just chatting with AI instead of coming up with crazy coding workflows.
abtinf 6mo ago
Seriously, just use plan mode first and you get like 90% of the way there, with CC launching subagents that will generally do the right thing anyway. IMHO most of this “customize your config to be more productive” stuff will go away within a year, obsoleted by improved models and harnesses. Just like how all the lessons for how to use LLMs in code from 1-2 years ago are already long forgotten.
- JohnMakin 6mo ago
  I loved all the dumb prompt “hacks” back then like “try saying please”
  - imiric 6mo ago
    Modern "skills" and Markdown formats of the day are no different than "save the kittens". All of these practices are promoted by influencers and adopted based on wishful thinking and anecdata.
    - JohnMakin 6mo ago
      Uh, this couldn't be more false. I've implemented these from scratch at my company and rolled them out org-wide and I've yet to watch a youtube video and don't consume any influencers. Mostly by just using the tools and reading documentation - as any other technical tool. Perhaps your blanket statement could be wrong, and I would encourage you to let your mind be a bit more open. The landscape here is not what it was 6 months ago. This is an undeniable fact that people are going to have to come to terms with pretty soon. I did not want to be in this spot, I was forced to out of necessity, because the stuff does work.
      - imiric 6mo ago
        Great, so how do you know this stuff works? Did you evaluate it against other approaches? How do you know it's actually reliable? The Vercel team had some interesting findings[1]: > In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Others had different findings for commonly accepted practices[2], some you may have adopted from reading documentation, which surely didn't come from influencers. And yet others swear by magical Markdown documents[3]. So... who is the ultimate authority on what actually works, and who is just cargo culting the trendy practice of the week? And how is any of this different from what was being done a few years ago? [1]: https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals https://vercel.com/blog/agents-md-outperforms-skills-in-our-... [2]: https://arxiv.org/abs/2602.11988 https://arxiv.org/abs/2602.11988 [3]: https://soul.md/ https://soul.md/
keeganpoppen 6mo ago
this is true, but i think people are best off starting with SOME project that gives users an idea of how to organize and think about stuff. for me, this is gastown, and i now have what has gotta be the most custom gastown install out there. could not agree more that your ai experience must be that which you build for yourself, not a productized version that portends to magically agentize your life. i think this is the real genius of gastown— not how it works, but that it does work and yegge built it from his own mind. so i’ve taken the same lesson and run very, very far with it, while also going in a totally different direction in many ways. but it is a work of genius, and i respect the hell out of him for putting it out there.
dominotw 6mo ago
> empty AGENTS.md, zero skills which is basically every setup because claude sucks at calling skills and forget everything in claude.md with a few seconds.
- girvo 6mo ago
  Right? I laughed when I read this: >If you tell Claude to always write tests before implementation, it will. If you say “never use console.log for error handling, always use the custom logger module,” it will respect that every time. It just isn't true lol
- silverwind 6mo ago
  Yep, it regularily ignores CLAUDE.md files. It seems these files are not weighted high enough vs. the prompt.
bonoboTP 6mo ago
2 months ago I built (with Claude) a quite advanced Python CLI script and Claude Skill that searches and filters the Claude logs to access information from other sessions or from the same session before context compaction. But today Claude Code has a builtin feature to search its logs and will readily do it when needed. My point is, these custom things are often short lived band-aids, and may not be needed with better default harnesses or smarter future models.
- nzoschke 6mo ago
  This is very insightful thanks for sharing. I’ve been developing and working on dev tools for more than 15 years. I’ve never seen things evolve so rapidly. Experiment, have fun and get things done, but don’t get too sure or attached to your patches. It’s very likely the models and harnesses will keep improving around the gaps you see. I’ve seen most of my AGENTS.md directives and custom tools fade away too, as the agents get better and better at reading the code and running the tests and feeding back on themselves.

by exitb 6mo ago

heliumtera 6mo ago

Operate == me send https post and pray for the best

dietr1ch 6mo ago
That's the goal, keep spending tokens and claim you are super productive because of it

jameshart 6mo ago

Yes, but as soon as you start checking in and sharing access to a project with other developers these things become shared. Working out how to work on code on your own with agentic support is one thing. Working out how to work on it as a team where each developer is employing agentic tools is a whole different ballgame.

georgeburdell 6mo ago
In my own group, agentic coding made sharing and collaboration go out the window because Claude will happily duplicate a bunch of code in a custom framework
- mitchell_h 6mo ago
  In my AGENTS.md I have two lines in almost every single one: - Under no condition should you use emoji's. - Before adding a new function, method or class. Scan the project code base, and attached frame works to verify that something else can not be modified to fit the needs.
  - himmi-01 6mo ago
    I'm curious about the token usage when it scans across multiple repositories to finding similar methods. As our code grows so fast, is it sustainable ?
- xmprt 6mo ago
  I think the idea is that by creating these shared .claude files, you tell the agent how to develop for everyone and set shared standards for design patterns/architecture so that each user's agents aren't doing different things or duplicating effort.
sceptic123 6mo ago
But why is it different? Why does it need to be? I don't write code the same as other devs so why would/should I use AI the same? Is this a hangover from when the tools were not as good?
- thierrydamiba 6mo ago
  [dead]
- lucideer 6mo ago
  I'd see this as being useful for two reasons: 1. Provision of optional tools: I may use an ai agent differently to all other devs on a team, but it seems useful for me to have access to the same set of project-specific commands, skills & MCP configs that my colleagues do. I amn't forced to use them but I can choose to on a case by case basis. 2. Guardrails: it seems sensible to define a small subset of things you want to dissuade everyone's agents from doing to your code. This is like the agentic extension of coding standards.
- IanCal 6mo ago
  > I don't write code the same as other devs Most people do, most people don’t have wildly different setups do they? I’d bet there’s a lot in common between how you write code and how your coworkers do.
  - benoau 6mo ago
    I bet there's a lot more consistency now that AI can factor in how things are being done and be guided on top of that too.

freedomben 6mo ago

I totally agree with you that this not the right way to start. But, in my experience, the more you use the tool the more of a "feel" you get for it, and knowing how all these different pieces work and line up can be quite useful (though certainly not mandatory). It's been immensely frustrating to me how difficult it is to find all this info with all the low-quality junk that is out there on the internet.

embedding-shape 6mo ago
> all the low-quality junk that is out there on the internet. Isn't this article just another one in that same drawer? > What actually belongs in CLAUDE.md - Write: - Import conventions, naming patterns, error handling styles Then just a few lines below: > Don’t write: - Anything that belongs in a linter or formatter config The article overall seems filled with internal inconsistencies, so I'm not sure this article is adding much beyond "This is what an LLM generated after I put the article title with some edits".

Fishkins 6mo ago

I agree with most of this, with one important exception: you should have some form of sandboxing in place before running any local AI agent. The easiest way to do that is with .claude/settings.json[0]. This is important no matter how experienced you are, but arguable the most important when you don't know what you're doing. 0: or if you don't want to learn about that, you can use Claude Code Web

post-it 6mo ago
The default sandboxing works fine for me. It asks before running any command, and I can whitelist directories for reading and non-compound commands.
- arcanemachiner 6mo ago
  That's not a sandbox.
  - kseniamorph 6mo ago
    there is a real one though — https://www.anthropic.com/engineering/claude-code-sandboxing https://www.anthropic.com/engineering/claude-code-sandboxing. needs to be enabled with /sandbox, not on by default.
    - Fishkins 6mo ago
      Right, that's what I was referring to
sroussey 6mo ago
Do people really run claude and other clis like this outside a container??
- kenforthewin 6mo ago
  Let's not fool ourselves here. If a security feature adds any amount of friction at all, and there's a simple way to disable it, users will choose to do so.

hmokiguess 6mo ago

with Anthropic already starting to sell "Claude Certified Architect" exams and a "Partner Network Program", I think a lot of this stuff is around building a side industry on top of it unfortunately

beyonddream 6mo ago

.claude has become the new dotfiles. And what do people do when they want to start using dotfiles ? they copy other’s dotfiles and same is happening here :)

silverwind 6mo ago
.claude is likely to contain secrets and also contains garbage like cache etc, if it is shared, it should only be partially shared.

pgwhalen 6mo ago

Who is building an artificial wall? Maybe I skimmed the post too fast, but it doesn't seem like this information is being presented as "you have to know/do this before you start agentic engineering", just "this is some stuff to know."

Aurornis 6mo ago

This article isn't saying you must set up a big .claude folder before you start. It repeats several times that it's important to start small and keep it short. It's also not targeted at first-timers getting their first taste of AI coding. It's a guide for how to use these tools to deal with frustrations you will inevitably encounter with AI coding. Though really, many of the complaints about AI coding on HN are written by beginners who would also benefit from a simple .claude configuration that includes their preferences and some guidelines. A frequent complaint from people who do drive-by tests of AI coding tools before giving up is that the tools aren't reading their mind or the tools keep doing things the user doesn't want. Putting a couple lines into AGENTS.md or the .claude folder can fix many of those problems quickly.

nunez 6mo ago

This matters for big engineering teams who want to put _some_ kind of guardrails around Claude that they can scale out. For example, I have a rule [^0] that instructs Claude to never start work until some pre-conditions are met. This works well, as it always seems to check these conditions before doing anything, every turn. I can see security teams wanting to use this approach to feel more comfortable about devs doing things with agentic tools without worrying _as much_ about them wreaking havoc (or what they consider "havoc"). As well, as someone who's just _really_ getting started with agentic dev, spending time dumping how I work into rules helped Claude not do things I disapprove of, like not signing off commits with my GPG key. That said, these rules will never be set in stone, at least not at first. [^0]: https://github.com/carlosonunez/bash-dotfiles/blob/main/ai/claude/default_rules/____read_these_first.md https://github.com/carlosonunez/bash-dotfiles/blob/main/ai/c...

bisonbear 6mo ago
I'm also thinking on how we can put guardrails on Claude - but more around context changes. For example, if you go and change AGENTS.md, that affects every dev in the repo. How do we make sure that the change they made is actually beneficial? and thinking further, how do we check that it works on every tool/model used by devs in the repo? does the change stay stable over time?
- nunez 6mo ago
  Given the scope that AGENTS has, I would use PRs to test those changes and discuss them like any other large-impact area of the codebase (like configs). If you wanted to be more “corporate” about it, then assuming that devs are using some enterprise wrapper around Claude or whatever, I would bake an instruction into the system prompt that ensures that AGENTS is only read from the main branch to force this convention. This is harder to guarantee since these tools are non-deterministic.
  - bisonbear 6mo ago
    PRs for AGENTS.md are necessary, but not sufficient, exactly because of non-determinism. You can LGTM the AGENTS.md change, but it's so hard to know what downstream behavioral effects it has. I feel like the only way to really know is by building a benchmark on your repo, and actually A/B testing the AGENTS.md change. I'm building something in the space - happy to share if it's something that sounds interesting to you

stronglikedan 6mo ago

Seems maybe you're just not the target audience for this article.

gck1 6mo ago

I'd also go even further and say that you likely should never install ANY skill that you didn't create yourself (i mean, guided claude to create it for you works too), or "forked" an existing one and pulled only what you need. Everyone's workflow is different and nobody knows which workflow is the right one. If you turn your harness into a junk drawer of random skills that get auto updated, you introduce yet another layer of nondeterminism into it, and also blow up your context window. The only skill you should probably install instead of maintaining it yourself is playwright-cli, but that's pretty much it.

hombre_fatal 6mo ago
I had an issue with playwright MCP where only one Claude Code instance could be using it at a time, so I switched to Claude's built-in /chrome MCP. In practice, I also find it more useful that the Chrome MCP uses my current profile since I might want Claude to look at some page I'm already logged in to. I'm not very sophisticated here though. I mainly use use browser MCP to get around the fact that 30% of servers block agent traffic like Apple's documentation.
- egeozcan 6mo ago
  I was using the built-in chrome skill but it was too unreliable for me. So I switched to playwright cli and I can also have it use firefox to get help debugging browser-specific issues.
- silverwind 6mo ago
  Would love if there is a way to parallelize playwright mcp using multiple agents and such, but it seems it's a fundamental limitation of that MCP that only on instance/tab can be controlled. Chrome MCP is much slower and by default pretty much unusable because Claude seems to prefer to read state from screenshots. Also, no Firefox/Safari support means no cross-browser testing. There appears to be https://github.com/sumyapp/playwright-parallel-mcp https://github.com/sumyapp/playwright-parallel-mcp which may be worth trying.
s900mhz 6mo ago
Yes this is the path I’m taking. Experiment, build your own toolbox whether it’s hand rolled skills or particular skills you pull out from other public repos. Then maintain your own set. You do not want to log in one day to find your favorite workflow has changed via updates. Then again this is all personal preference as well.

butlike 6mo ago

It's not as bucolic as this when trying to get an org on board. We're currently very open to using Claude, but the unknowns are still the unknowns, so the guardrails the `.claude` folder provides gives us comfort when gaining familiarity with the tool.

ymolodtsov 6mo ago

Peter Steinberger himself says he's just chatting with AI instead of coming up with crazy coding workflows.

abtinf 6mo ago

Seriously, just use plan mode first and you get like 90% of the way there, with CC launching subagents that will generally do the right thing anyway. IMHO most of this “customize your config to be more productive” stuff will go away within a year, obsoleted by improved models and harnesses. Just like how all the lessons for how to use LLMs in code from 1-2 years ago are already long forgotten.

JohnMakin 6mo ago
I loved all the dumb prompt “hacks” back then like “try saying please”
- imiric 6mo ago
  Modern "skills" and Markdown formats of the day are no different than "save the kittens". All of these practices are promoted by influencers and adopted based on wishful thinking and anecdata.
  - JohnMakin 6mo ago
    Uh, this couldn't be more false. I've implemented these from scratch at my company and rolled them out org-wide and I've yet to watch a youtube video and don't consume any influencers. Mostly by just using the tools and reading documentation - as any other technical tool. Perhaps your blanket statement could be wrong, and I would encourage you to let your mind be a bit more open. The landscape here is not what it was 6 months ago. This is an undeniable fact that people are going to have to come to terms with pretty soon. I did not want to be in this spot, I was forced to out of necessity, because the stuff does work.
    - imiric 6mo ago
      Great, so how do you know this stuff works? Did you evaluate it against other approaches? How do you know it's actually reliable? The Vercel team had some interesting findings[1]: > In 56% of eval cases, the skill was never invoked. The agent had access to the documentation but didn't use it. Others had different findings for commonly accepted practices[2], some you may have adopted from reading documentation, which surely didn't come from influencers. And yet others swear by magical Markdown documents[3]. So... who is the ultimate authority on what actually works, and who is just cargo culting the trendy practice of the week? And how is any of this different from what was being done a few years ago? [1]: https://vercel.com/blog/agents-md-outperforms-skills-in-our-agent-evals https://vercel.com/blog/agents-md-outperforms-skills-in-our-... [2]: https://arxiv.org/abs/2602.11988 https://arxiv.org/abs/2602.11988 [3]: https://soul.md/ https://soul.md/

keeganpoppen 6mo ago

this is true, but i think people are best off starting with SOME project that gives users an idea of how to organize and think about stuff. for me, this is gastown, and i now have what has gotta be the most custom gastown install out there. could not agree more that your ai experience must be that which you build for yourself, not a productized version that portends to magically agentize your life. i think this is the real genius of gastown— not how it works, but that it does work and yegge built it from his own mind. so i’ve taken the same lesson and run very, very far with it, while also going in a totally different direction in many ways. but it is a work of genius, and i respect the hell out of him for putting it out there.

dominotw 6mo ago

> empty AGENTS.md, zero skills which is basically every setup because claude sucks at calling skills and forget everything in claude.md with a few seconds.

girvo 6mo ago
Right? I laughed when I read this: >If you tell Claude to always write tests before implementation, it will. If you say “never use console.log for error handling, always use the custom logger module,” it will respect that every time. It just isn't true lol
silverwind 6mo ago
Yep, it regularily ignores CLAUDE.md files. It seems these files are not weighted high enough vs. the prompt.

bonoboTP 6mo ago

2 months ago I built (with Claude) a quite advanced Python CLI script and Claude Skill that searches and filters the Claude logs to access information from other sessions or from the same session before context compaction. But today Claude Code has a builtin feature to search its logs and will readily do it when needed. My point is, these custom things are often short lived band-aids, and may not be needed with better default harnesses or smarter future models.

nzoschke 6mo ago
This is very insightful thanks for sharing. I’ve been developing and working on dev tools for more than 15 years. I’ve never seen things evolve so rapidly. Experiment, have fun and get things done, but don’t get too sure or attached to your patches. It’s very likely the models and harnesses will keep improving around the gaps you see. I’ve seen most of my AGENTS.md directives and custom tools fade away too, as the agents get better and better at reading the code and running the tests and feeding back on themselves.