Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I’m a solopreneur working on a fairly large number of independent projects.
I use Claude Code to initiate a project using Sahil’s ME skill pack and write a high-level spec to a Linear ticket. If/when I’m ready to work on that idea, I convert it to a project, decompose the top ticket into more issues. I also have Claude code add to each issue with deepseek, sonnet or opus tags based on which is most appropriate for the issue.
Then I fire up opencode and go through each ticket. Plan, then build. Every N issues I switch to opus and have it review the work done.
Enhancements and bug reports get filed in the project. Repeat as necessary. I work pretty sequentially. I’m quite happy with the operational success of my projects. They’re all being used.
I’ve expanded this process a few times but this baseline is where things shrink to. Sometimes I use open chamber but opencode cli works for me.
- I work as an AI Engineer for a firm. My role involves:
1. Helping develop strategies for incorporating AI into the company’s day-to-day operations. 2. Helping employees, including non-engineers, get up to speed with AI so they can be more productive.
My personal AI tech stack is:
1. Claude Code in the terminal (on a Mac) with Zed as my editor (Any editor would do). 2. Claude Desktop for Projects and CoWork. 3. ChatGPT Desktop.
It’s a simple and effective setup.
I don’t run a formal bootcamp, but I do help others in the company become AI-enabled. The biggest return on investment I’ve found is helping people develop a clear understanding of how to use the features in Claude Desktop effectively, particularly Projects vs. CoWork and when to use each. Building that foundational knowledge allows people to become productive almost immediately.
by rexposadas - I'm biased (I'm the creator) but I use Conductor every day. I've recently switched to Opus 4.8 (fast mode always on) as my default model but swap in GPT-5.5 quite a bit for reviewing Opus's work.
My flow is something like: - Create a new workspace for a specific bug/feature - Ramble into the input box. I use a goose neck microphone and Spokenly (with Parakeet as the model ) for local speech-to-text - Hit enter! I don't use plan mode. - Ask for a review from a different model (⌘⇧R) - Create a PR and run a /babysit loop - Run a local version of the app and click around, do a human review. If the LOC are negative we don't pay much attention to the code. If it's positive we do - Merge!
I often have 3-5 workspaces running like this. There's lots of room for improvement but it's been working quite well for me.
by Charlieholtz - I'm using VSCode with Github Copilot (Business) in Agent, and Ask mode with varying LLMs, depending on the complexity of the task. For a specific task, i create a markdown file with the requirements in tandem with the Agent, manually edit it where convenient. And then i let the Agent implement one feature or work unit after another, while micro managing it and making sure that i understand what it has written (not for really trivial stuff, where i don't care). This gives me a huge productivity boost, while the level of being in the loop is still bearable for me.
TBH, i'm wondering why i'm the only one saying he's using VSCode with GH Copilot. Isn't this the most frictionless tooling for an 'agentic engineer'? I get state-of-the-art LLMs while it's fully integrated into my IDE.
I still don't fully get what Claude Code or GH Copilot CLI would bring beyond that, since the Copilot plugin does also have CLI access.
by lagrange77 - I'm a contractor (AWS and web apps), so I get a lot of sometimes-ambiguous requests. I have a five-part workflow via Claude/Codex skills: discovery->implementation planning->implementation->verification->review
Each phase writes to `./.agents/plans/{plan-name}/` in the project root. All in Markdown. That way, the flow is agent-agnostic. Each phase artifact is immutable after being written.
More details:
First, I put all the information that I have (documents, client statements, any code, my own summary, etc.) into a document. Which I pass to the discovery planning skill.
The discovery phase more formally defines the project in terms of functional requirements, non-functional requirements, constraints, risks, and assumptions. This might take a few passes to get everything nailed down.
After that, I being a implementation planning phase using the discovery artifact (`discovery.md`). We define the work in terms of phases, where each phases has various tasks associated with it (all checkboxes). Again, usually requires a few passes.
After that, I have a clear idea of the work needed and can send an estimate to the client. Or, if it's a personal project, get started actually building it. I have another phase for actual implementation.
Verification and review are similarly defined. They can be done by any agent.
by dempedempe - There's lots of ways. You have to upskill through the stages IMO. Write code, write w/ agent, write w/ multi agents, write w/orchestrators.
My way is to just run a giant AI agent factory engine and make the agents full flow do everything. (plan long term, write prd, task, review).
Here's ~4000 commits in last month as an example, i have about ~10k ish including private/work stuff? https://github.com/portpowered/you-agent-factory/commits/mai...
The premise when you get to full automation generally is you go full industral engineering:
1. watch overall flow, improve process via continuous improvement
2. work via checklists and gates.
3. replace process with mechanisms as much as possible (code > agents)
4. optimal throughput is continual testing and iteration (CI, CD), coverage, full e2e tests, mock everything, general best practices really.
decent blog: https://openai.com/index/harness-engineering/
general points:
- build lots of linters
- document literally everything (arch, prd, best practices in repo)
- too many agents at the same time makes lots of code conflicts, so need to consider architecture of code how to maximize concurrency.
by aabdi - I am using Spec Driven Development approach implemented as a Claude Code plugin since Feb for all mid + size tasks. The idea is to write detailed specs first using agent help doing research and interviewing, decompose the task into smaller subtasks, write detailed spec for each task, implement each task separately. You can restart the session after every step in the workflow and after each subtask implementation since all requirements are materialized in specs. This helps to keep session context focused on a single task at time, improve adherence, reduce cost and allow to implement bigger tasks that are hard to implement with pure plan + code.
Discussion on hn: https://news.ycombinator.com/item?id=48231575
Repo: https://github.com/sermakarevich/sddw
Slides: https://docs.google.com/presentation/d/1SjKXF7hkoqyiN9-3tBGY...
- I've shifted to a "slow code" approach with AI, treating it more like a design partner than a code generator.
I mostly do TDD with TypeScript. I write the test, write the code myself (sometimes with the help of LLM), and then hand it to the LLM. Instead of asking it to write things for me, I use it to find edge cases, check if it's leak-proof, and verify efficiency.
For architecture questions, I debate with it for a while. I almost never ask for code without conversing 4-5 times first to push back on its assumptions. It's the best rubber-ducking partner I've had.
Personal plug: I wrote more about why/how I use AI to write slow, better code on my blog: https://nabraj.com/blog/ai-write-slow-better-code
by coffeecoders