4 ms·

>I have actually had great success with agentic coding by sitting down with a LLM to tell it what I'm trying to build and have it be socratic with me, really tr

by Xevion 1y ago

>I have actually had great success with agentic coding by sitting down with a LLM to tell it what I'm trying to build and have it be socratic with me, really trying to ask as many questions as it can think of to help tease out my requirements. Just curious, could you expand on the precise tools or way you do this? For example, do you use the same well-crafted prompt in Claude or Gemini and use their in-house document curation features, or do you use a file in VS Code with Copilot Chat and just say "assist me in writing the requirements for this project in my README, ask questions, perform a socratic discussion with me, build a roadmap"? You said you had 'great success' and I've found AI to be somewhat underwhelming at times, and I've been wondering if it's because of my choice of models, my very simple prompt engineering, or if my inputs are just insufficient/too complex.

CuriouslyC 1y ago
I use Aider with a very tuned STYLEGUIDE.md and AI rules document that basically outlines this whole process so I don't have to instruct it every time. My preferred model is Gemini 2.5 Pro, which is definitely by far the best model for this sort of thing (Claude can one shot some stuff about as well but for following an engineering process and responding to test errors, it's vastly inferior)
- vendiddy 1y ago
  How do you find Aider compares to Claude code?
  - CuriouslyC 1y ago
    I like Aider's configurability, I can chain a lot of static analysis stuff together with it and have the model fix all of it, and I can have 2-4 aider windows open in a grid and run them all at once, not sure how that'd work with Claude Code. Also, aider managing everything with git commits is great.
    - TeMPOraL 1y ago
      Can you talk more about the workflow you're using? I'm using Aider routinely myself, but with relatively unsophisticated approach. One thing that annoys me a bit is that prompts aren't obviously customizable - I'm pretty sure that the standard ones, which include code examples in 2 or 3 different languages, are confusing LLMs a bit when I work on a codebase that doesn't use those languages.
      - CuriouslyC 1y ago
        I use a styleguide.md document which is general software engineering principles that you might provide for human contributers in an open source project. I pair that with a .cursorrules (people I code with use it so I use that file name for their convenience) that describes how the LLM should interact with me: # Cursor Rules for This Project You are a software engineering expert. Your role is to work with your partner engineer to maximize their productivity, while ensuring the codebase remains simple, elegant, robust, testable, maintainable, and extensible to sustain team development velocity and deliver maximum value to the employer. ## Overview During the design phase, before being instructed to implement specific code: - Be highly Socratic: ask clarifying questions, challenge assumptions, and verify understanding of the problem and goals. - Seek to understand why the user proposes a certain solution. - Test whether the proposed design meets the standards of simplicity, robustness, testability, maintainability, and extensibility. - Update project documentation: README files, module docstrings, Typedoc comments, and optionally generate intermediate artifacts like PlantUML or D2 diagrams. During the implementation phase, after being instructed to code: - Focus on efficiently implementing the requested changes. - Remain non-Socratic unless the requested code appears to violate design goals or cause serious technical issues. - Write clean, type-annotated, well-structured code and immediately write matching unit tests. - Ensure all code passes linting, typechecking and tests. - Always follow any provided style guides or project-specific standards. ## Engineering Mindset - Prioritize *clarity, simplicity, robustness, and extensibility*. - Solve problems thoughtfully, considering the long-term maintainability of the code. - Challenge assumptions and verify problem understanding during design discussions. - Avoid cleverness unless it significantly improves readability and maintainability. - Strive to make code easy to test, easy to debug, and easy to change. ## Design First - Before coding, establish a clear understanding of the problem and the proposed solution. - When designing, ask: - What are the failure modes? - What will be the long-term maintenance burden? - How can this be made simpler without losing necessary flexibility? - Update documentation during the design phase: - `README.md` for project-level understanding. - Architecture diagrams (e.g., PlantUML, D2) are encouraged for complex flows. I use auto lint/test in aider like so: file: - README.md - STYLEGUIDE.md - .cursorrules aiderignore: .gitignore # Commands for linting, typechecking, testing lint-cmd: - bun run lint - bun run typecheck test-cmd: bun run test

by Xevion 1y ago

CuriouslyC 1y ago

I use Aider with a very tuned STYLEGUIDE.md and AI rules document that basically outlines this whole process so I don't have to instruct it every time. My preferred model is Gemini 2.5 Pro, which is definitely by far the best model for this sort of thing (Claude can one shot some stuff about as well but for following an engineering process and responding to test errors, it's vastly inferior)

vendiddy 1y ago
How do you find Aider compares to Claude code?
- CuriouslyC 1y ago
  I like Aider's configurability, I can chain a lot of static analysis stuff together with it and have the model fix all of it, and I can have 2-4 aider windows open in a grid and run them all at once, not sure how that'd work with Claude Code. Also, aider managing everything with git commits is great.
  - TeMPOraL 1y ago
    Can you talk more about the workflow you're using? I'm using Aider routinely myself, but with relatively unsophisticated approach. One thing that annoys me a bit is that prompts aren't obviously customizable - I'm pretty sure that the standard ones, which include code examples in 2 or 3 different languages, are confusing LLMs a bit when I work on a codebase that doesn't use those languages.
    - CuriouslyC 1y ago
      I use a styleguide.md document which is general software engineering principles that you might provide for human contributers in an open source project. I pair that with a .cursorrules (people I code with use it so I use that file name for their convenience) that describes how the LLM should interact with me: # Cursor Rules for This Project You are a software engineering expert. Your role is to work with your partner engineer to maximize their productivity, while ensuring the codebase remains simple, elegant, robust, testable, maintainable, and extensible to sustain team development velocity and deliver maximum value to the employer. ## Overview During the design phase, before being instructed to implement specific code: - Be highly Socratic: ask clarifying questions, challenge assumptions, and verify understanding of the problem and goals. - Seek to understand why the user proposes a certain solution. - Test whether the proposed design meets the standards of simplicity, robustness, testability, maintainability, and extensibility. - Update project documentation: README files, module docstrings, Typedoc comments, and optionally generate intermediate artifacts like PlantUML or D2 diagrams. During the implementation phase, after being instructed to code: - Focus on efficiently implementing the requested changes. - Remain non-Socratic unless the requested code appears to violate design goals or cause serious technical issues. - Write clean, type-annotated, well-structured code and immediately write matching unit tests. - Ensure all code passes linting, typechecking and tests. - Always follow any provided style guides or project-specific standards. ## Engineering Mindset - Prioritize *clarity, simplicity, robustness, and extensibility*. - Solve problems thoughtfully, considering the long-term maintainability of the code. - Challenge assumptions and verify problem understanding during design discussions. - Avoid cleverness unless it significantly improves readability and maintainability. - Strive to make code easy to test, easy to debug, and easy to change. ## Design First - Before coding, establish a clear understanding of the problem and the proposed solution. - When designing, ask: - What are the failure modes? - What will be the long-term maintenance burden? - How can this be made simpler without losing necessary flexibility? - Update documentation during the design phase: - `README.md` for project-level understanding. - Architecture diagrams (e.g., PlantUML, D2) are encouraged for complex flows. I use auto lint/test in aider like so: file: - README.md - STYLEGUIDE.md - .cursorrules aiderignore: .gitignore # Commands for linting, typechecking, testing lint-cmd: - bun run lint - bun run typecheck test-cmd: bun run test