4 ms·

> Every time I do something I add another layer of AI automation/enhancement to my personal dev setup with the goal of trying to see how much I can extend my ow

> Every time I do something I add another layer of AI automation/enhancement to my personal dev setup with the goal of trying to see how much I can extend my own ability to produce while delivering high quality projects Can you give some examples? What’s worked well?

jprokay13 1y ago
If you haven’t, adding in strict(er) linting rules is an easy win. Enforcing documentation for public methods is a great one imo. The more you can do to tell the AI what you want via a “code-lint-test” loop, the better the results.
- crgwbr 1y ago
  Honestly the same is true for human devs. As frustrating as strict linting can be for newer devs, it’s way less frustrating than having all the same issues pointed out in code review. That’s interesting because I’ve been finding that all sorts of stuff that’s good for AI is actually good for humans too, linting, fast easy to run tests, standardized code layouts, etc. Humans just have more ability to adapt to oddities at the moment, which leads to slack.
  - jprokay13 1y ago
    Yeah I find it pretty funny that so much of us (myself included) threw out strict documentation practices because “the code should be self documenting!” Now I want as much of it as I can get.
  - jaggederest 1y ago
    My rule of thumb is that if I get a nit, whitespace, or syntax preferences as a PR comment, that goes into the linter. Especially for systemic issues like e.g. not awaiting functions that return a promise, any kind of alphabetization, import styles, etc.
malux85 1y ago
For us it’s been auto-generating tests - we focus efforts on having the LLM write 1 test, manually verifying it. Then use this as context and tell the llm to extend to all space groups and crystal systems. So we get code coverage without all the effort, it works well for well defined problems that can be verified with test.
haiku2077 1y ago
- Extremely strict linting and formatting rules for every language you use in a project. Including JSON, YAML, SQL. - Using AI code gen to make your own dev tools to automate tasks. Everything from "I need a make target to automate updating my staging and production config files when I make certain types of changes" or "make an ETL to clean up this dirty database" to "make a codegen tool to automatically generate library functions from the types I have defined" and "generate a polished CLI for this API for me" - Using Tilt (tilt.dev) to automatically rebuild and live-reload software on a running Kubernetes cluster within seconds. Essentially, deploy-on-save. - Much more expansive and robust integration test suites with output such that an AI agent can automatically run integration tests, read the errors and use them to iterate. And with some guidance it can write more tests based on a small set of examples. It's also been great at adding formatted messages to every test assertion to make failed tests easier to understand - Using an editor where an AI agent has access to the language server, linter, etc. via diagnostics to automatically understand when it makes severe mistakes and fix them A lot of this is traditional programming but sped up so that things that took hours a few years ago now take literally minutes.
- handfuloflight 1y ago
  Even things that took days or weeks are being done in minutes now. And a few hours on top to ensure correctness.
- jay_kyburz 1y ago
  I worry that once I've done all that I won't have time for my actual work. I also have to investigate all these new AI editors, and sign up for the API's and work out which is best, then I have to learn how to prompt properly. I worry that messing with the AI is the equivalent of tweaking my colour schemes and choosing new fonts.
  - cartoonfoxes 1y ago
    Some of what I learned from a decade of keeping up with the perfusion of JS libraries and frameworks seems relevant to AI: - anything with good enough adoption is good enough (unless I'm an SME to judge directly) - build something with it before considering a switch - they're similar enough that what I learn in one will transfer to others - everything sucks compared with 2-3 years from now; switching between "sucks" and "sucks+" will look silly in retrospect

jprokay13 1y ago

If you haven’t, adding in strict(er) linting rules is an easy win. Enforcing documentation for public methods is a great one imo. The more you can do to tell the AI what you want via a “code-lint-test” loop, the better the results.

crgwbr 1y ago
Honestly the same is true for human devs. As frustrating as strict linting can be for newer devs, it’s way less frustrating than having all the same issues pointed out in code review. That’s interesting because I’ve been finding that all sorts of stuff that’s good for AI is actually good for humans too, linting, fast easy to run tests, standardized code layouts, etc. Humans just have more ability to adapt to oddities at the moment, which leads to slack.
- jprokay13 1y ago
  Yeah I find it pretty funny that so much of us (myself included) threw out strict documentation practices because “the code should be self documenting!” Now I want as much of it as I can get.
- jaggederest 1y ago
  My rule of thumb is that if I get a nit, whitespace, or syntax preferences as a PR comment, that goes into the linter. Especially for systemic issues like e.g. not awaiting functions that return a promise, any kind of alphabetization, import styles, etc.

malux85 1y ago

For us it’s been auto-generating tests - we focus efforts on having the LLM write 1 test, manually verifying it. Then use this as context and tell the llm to extend to all space groups and crystal systems. So we get code coverage without all the effort, it works well for well defined problems that can be verified with test.

haiku2077 1y ago

- Extremely strict linting and formatting rules for every language you use in a project. Including JSON, YAML, SQL. - Using AI code gen to make your own dev tools to automate tasks. Everything from "I need a make target to automate updating my staging and production config files when I make certain types of changes" or "make an ETL to clean up this dirty database" to "make a codegen tool to automatically generate library functions from the types I have defined" and "generate a polished CLI for this API for me" - Using Tilt (tilt.dev) to automatically rebuild and live-reload software on a running Kubernetes cluster within seconds. Essentially, deploy-on-save. - Much more expansive and robust integration test suites with output such that an AI agent can automatically run integration tests, read the errors and use them to iterate. And with some guidance it can write more tests based on a small set of examples. It's also been great at adding formatted messages to every test assertion to make failed tests easier to understand - Using an editor where an AI agent has access to the language server, linter, etc. via diagnostics to automatically understand when it makes severe mistakes and fix them A lot of this is traditional programming but sped up so that things that took hours a few years ago now take literally minutes.

handfuloflight 1y ago
Even things that took days or weeks are being done in minutes now. And a few hours on top to ensure correctness.
jay_kyburz 1y ago
I worry that once I've done all that I won't have time for my actual work. I also have to investigate all these new AI editors, and sign up for the API's and work out which is best, then I have to learn how to prompt properly. I worry that messing with the AI is the equivalent of tweaking my colour schemes and choosing new fonts.
- cartoonfoxes 1y ago
  Some of what I learned from a decade of keeping up with the perfusion of JS libraries and frameworks seems relevant to AI: - anything with good enough adoption is good enough (unless I'm an SME to judge directly) - build something with it before considering a switch - they're similar enough that what I learn in one will transfer to others - everything sucks compared with 2-3 years from now; switching between "sucks" and "sucks+" will look silly in retrospect