Ask HN: What is the AI setup for an experienced dev starting on a new project?

I have been working as a software developer for more than 20 years now. Been around the block a few times. Thanks to generous allowances in my current place, I've dipped my toes into LLM world and am quite impressed with it. However, we are on a legacy code base, LLM impact is limited in a sense. If I was to start a new project (let's say a web app with backend) - what is the state of the art for the setup? From Issue tracking, CI, automated deployments, agents, documentation etc - is there some blueprint I can just deploy and know that I am standing on the shoulders of giants?

What is your CI like? Do you auto deploy somewhere?

Your job as an experienced developer is to ship working code, the fact that AI tools are here doesn't change that. I would strive to create as minimal a set of artifacts for AI as possible. Observing where we are today with 6 months or 12 months ago means the state of the art is constantly shifting. Spending a lot of effort implementing some concept you've read about or watched others talk about online might not be useful in 6 months. Its hard to discern valuable content vs. stuff people are finding gets lots of clicks these days.

If what you're creating isn't shippable to a customer/user then really scrutinize it. Things like AI skills, AI task loops, etc. those are all throw-away artifacts, the equivalent of Jira tickets. If you can get AI to help delivery without them, do that. The AI lab companies want you to use tokens but if you can automate something without AI in the mix, since you're experienced I assume you know shell scripting, automation concepts, etc., then automate it to work without token use. This is especially if you are doing something solo - your process and workflow can change on a whim so the least amount of overhead is going to keep you lean and focused on shipping software.

Don't make the mistake of thinking CI/CD is more complicated than it is. It's just automated compilation & testing plus automated deployment. The jargon can be overwhelming. You can do this with forgejo actions. I'm also using self-hosted forgejo and I generated a token for CC to use to manage and setup everything for me.

When code is checked in, it tries to compile it to make sure there are no fundamental issues building the software. This, importantly, happens on not your computer. This helps protect against "it works on my machine" but fails for someone else. If you've got tests, and you should have tests, it will run them for you to make sure those complete as well. If both of those pass, it reaches the CD portion of the process and typically just zips up the working build and does whatever is needed for a deployment in your environment automatically. There are tons of other things you could do as well, like run a linting tool to make sure the code is all formatted consistently across the project or run security checks to make sure passwords or .env files aren't included by accident. But the core concept is build the project, test the project (with various different tools), if it passes deploy the project to some environment where you can see the changes. This drastically cuts down the feedback loop time and increases how fast you can iterate on changes.

For my setup, I've got forgejo hosted on my NAS along with various web apps as containers in podman which I use cloudflared tunnels to selectively make them public. I've got a Claude skill which knows about my hosting environment and can setup / manage new web projects for me. When I add a new web project, CC runs a script that CC built to configure the build, test and deploy actions. After that, any pull request to that new repo will automatically build and test and deploy automatically to a new subdomain. CC could call the APIs directly and handle everything without scripts, but that's where some of the non-deterministic aspects of LLMs might creep in. I want it to setup everything the same way every time so all the apps are consistent. So it uses pre-built scripts for those aspects with the direct API calls being an escape hatch if needed.

Thanks for that. Thats what I thought, but havent implemented.