Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- Ghostty with Claude Code. That's pretty much it.
For each new feature, I open a worktree, spar with Claude to work up a gherkin spec with @todo on each story. Each agent pushes commits to a WIP PR in GitHub where I review and leave comments or questions. Once the spec is done we mainly interact on the PR. @todo becomes @wip and @done as the agent progresses. I really like gherkin for agentic engineering, it's very clarifying.
I have about 2-4 agents running at a time. Large test suite, linters and formatters enforced on push.
by nimonian - sameby MaieuticMD26
- At the moment I predominantly work with Python and hence PyCharm as the main IDE. However, I've built this plugin https://plugins.jetbrains.com/plugin/31117-agent-cli to render agentic CLIs as an editor tab in PyCharm and also some notification hooks so I don't have to switch windows and it's easy to jump around the code while the agent is doing its work.
Besides that I have a collection of custom skills (plan for JIRA tickets, github PR creation, code review, etc), a set of MCPs (most are for internal tooling) and most of the time I use Claude Code.
- Thanks man, I was looking for something like this for a while!by vb-8448
- Will try this out, I'm just running claude in terminal panes stacked on the right hand side. Cheers!by dansult
- I use Claude Code, flow for reusable skills/prompts, and leaf for reading Markdown comfortably in the terminal.
- Claude Code
- flow: https://github.com/RivoLink/flow
- leaf: https://github.com/RivoLink/leaf
- GNOME Terminal
It's a pretty terminal-first workflow.
by RivoLink - Assuming you have a SOTA model - the thing I'd teach them is minimalism.
- Minimal tooling - Minimal system prompt - Folders + files + text
AI driven development has turned the whole development job into knowing what questions to ask + complexity reduction.
First ask the model how to do something / what options there are to do something - not just to do something. Creating moments to teach that is a challenge in itself.
After its answered go tell it to do the thing.
If they're serious though, the next step is to teach them to always ask if there is a simpler alternative with fewer dependencies.
Anything with a too magical UI is going to give them the wrong 'model' in their mind on how to think about the tool.
A bit of a hidden aspect many people seem to miss, the tone you take with the model is absolutely critical. Ask a bunch of psychology questions before having it write javascript or propose a tech stack is going to get you different results.
Finally, the semi obvious hack (and which something like claude will do automatically when in team mode) - have the model talk to another instance of itself. The model can translate your ramblings into coherent specs in the right tone and feeding that back into itself in a new session gets you the good results. Its also part of why the "first write a plan" works because it fills the context with the right tone and clear instructions.
by athrowaway3z - 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.
- Sahil’s ME skill pack seems to be this: https://github.com/slavingia/skillsby alok-g
- 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 - Hey -- we've loved using Conductor here at Digits. I've been using it since February and only recently swapped to using Orca for Remote SSH and perf improvements. Looking forward to your general release of Conductor Cloud!
I've been wondering, since you're building desktop software, how do you get AI to test your changes? Boot the whole app? Run the frontend/UI with a mock backend?
by phildenhoff - 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 - You aren't the only one. There are many people using Github Copilot.
Github Copilot CLI is for automation. For example, in a Rust project, I use it to audit for security, documentation gaps, and test issues crate by crate. This can take an hour and I look at the suggested stories it writes afterwards to triage for implementation.
by outside1234 - 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 - Have you been able to build anything substantial with AI factory itself? I have done some of these experiments myself on these sort of things and found they ended up often being less effective than using the latest tools in harnesses like claude code.
But curious if you've found it to be a big unlock. I have been doing some of this industrial engineering myself.
by ianm218 - Genuinely curious - in your case, where do the requirements for what needs to be built come from?
In every project I've touched, business requirements are always the bottleneck - so I've never been able to wrap my head around what kind of requirements can be fed into a setup like this at high enough volume to justify it.
by alex_c - 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...
- Naive question: how much time do you spend doing so vs. Doing the actual work yourself?by madduci
- I do the same, and faced the issue that claude/codex loose context when doing subtasks (and subagent don't have plan mode).
So I've built Agentbox to be able to launch from claude/codex multiple VMs with claude/codex (can also mix). The parent agent watch for prompts and questions, enforce /review, /simplify, that the sub agents file a PR and wait for bugbot comments etc.
This way the parent agent running in a /goal don't loose context, enforce a good workflow, manage the backlog and parallelize/merge back the work on the main repo
https://github.com/madarco/agentbox MIT license
by madarco - I would love to see examples for various types of specs written, as in actual texts of the specs for various types of it.
It would also help to understand how are changes to specs handled? Is the agent given both old and new versions to figure out the updates needed?
Thanks.
by alok-g - Similar with a todo.md in the project which outlines work to be done.. this gets combined with developer and/or user documentation which outlines features and how they're expected to work. I'll iterate with the agent on the planning and documentation through several times until the documentation and plan look good. The only gotcha I've had a couple times is I'll have the testing and spec before implementation and sometimes the agent will try to edit tests rather than making the implementation match spec/tests.
I'm definitely baby sitting the process more than vibe coding, and review each cycle's results. As for languages, mostly TS/JS and Rust with a bit of C# here and there depending on what I need. Claude Code's Opus does a pretty good job with Rust, so for anything personal, I've just gone with it.
Work has been limited to working out specific problems, or a small utility/library that I can pull in, but on my own system, separate from work resources.
by tracker1 - Genuine question, I'm trying to adopt specs and AI DLC in my team so we can use it as an enhancement and improve our development and the biggest pain right now for us is managing all those md artifacts.
I'm curious how do you manage them? Do you preserve them for the future or delete as soon as task was accomplished? If you're deleting those artifacts after job being done - do you summarize those specs into the Jira ticket or whatever system you use.
- Imm overwhelmed with a variety of SDD tools out there.
Github spec kit, spec-kitty, symphony, GSD, this.
How do people decide on the framework other than try them all.
p.s. found this mind-boggling list of them all https://github.com/cameronsjo/spec-compare
by vladgur - 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