i too have discovered that feature chats are surely a winner (as well as a pre-requirement for parallelization)
in a similar vein, i match github project issues to md files committed to repo
essentially, the github issue content is just a link to the md file in the repo
also, epics are folders with links (+ a readme that gets updated after each task)
i am very happy about it too
it's also very fast and handy to reference either from claude using @
.ie: did you consider what has been done @
other major improvements that worked for me were
- DOC_INDEX.md build around the concept of "read this if you are working on X (infra, db, frontend, domain, ....)"
- COMMON_TASKS.md (if you need to do X read Y, if you need to add a new frontend component read HOW_TO_ADD_A_COMPONENT.md )
common tasks tend to be increase quality when they are epxpressed in a checklist format
i suppose, gradually and the suddenly?
each "fix" to incorrect reasoning/solution doesn't just solve the current instance, it also ends up in a rule-based system that will be used in future
initially, being in the loop is necessary, once you find yourself "just approving" you can be relaxed and think back
or, more likely, initially you need fine-grained tasks; as reliability grows, tasks can become more complex
"parallelizing" allows single (sub)agents with ad-hoc responsibilities to rely on separate "institutionalized" context/rules, .ie: architecture-agent and coder-agent can talk to each others and solve a decision-conflict based on wether one is making the decision based on concrete rules you have added, or hallucinating decisions
i have seen a friend build a rule based system and have been impressed at how well LLM work within that context
I'm commenting while agents run in project trying to achieve something similar to this.
I feel like "we all" are trying to do something similar, in different ways, and in a fast moving space (i use claude code and didn't even know subagents were a thing).
My gut feeling from past experiences is that we have git, but now git-flow, yet: a standardized approach that is simple to learn and implement across teams.
Once (if?) someone will just "get it right", and has a reliable way to break this down do the point that engineer(s) can efficiently review specs and code against expectations, it'll be the moment where being a coder will have a different meaning, at large.
So far, all projects i've seen end up building "frameworks" to match each person internal workflow. That's great and can be very effective for the single person (it is for me), but unless that can be shared across teams, throughput will still be limited (when compared that of a team of engs, with the same tools).
Also, refactoring a project to fully leverage AI workflows might be inefficient, if compared to a rebuild from scratch to implement that from zero, since building docs for context in pair with development cannot be backported: it's likely already lost in time, and accrued as technical debt.
The debate around preserving Venice's lagoon as a body of water linked to the open sea has been ongoing for centuries. A public authority to oversee these issues, the Magistrato alle Acque [1], was established in 1501, and large-scale public works were mandated around the same time (i.e., rerouting rivers to prevent the lagoon from silting up).
The reasons for this have evolved over time. It began to protect waterways that enabled local commerce, and expanded alongside Venice's dominance across the Mediterranean Sea. This led to the identity of a city that celebrated its "Wedding of the Sea" every year [2].
As a modern-day example of this, UNESCO has enlisted `Venice and its Lagoon` in its World Heritage list [3], stating:
```
Criterion (v): In the Mediterranean area, the lagoon of Venice represents an outstanding example of a semi-lacustral habitat which has become vulnerable as a result of irreversible natural and climate changes. In this coherent ecosystem where the muddy shelves (alternately above and below water level) are as important as the islands, pile-dwellings, fishing villages and rice-fields need to be protected no less than the palazzi and churches.
```
In the present day, when Venice is mainly seen as a tourist attraction, it's easy to underestimate this. However, locals still draw a firm line between those who live in the city and the "campagnoli" (people from the countryside).
Any plan to sever this historical link between Venice and the sea would be a tough sell, regardless of its economic or technical feasibility.
In Venice, the small local population amidst a substantial influx of tourists fosters a tighter community.
Actually, lots of extremely local communities gather around social hubs, typically squares featuring bars where people routinely visit for breakfast, brunch, and aperitifs. It doesn't take long to gain recognition and differentiate yourself from a tourist; alcohol often facilitates conversation, too :).
If you want to see this in action, there are a fair number of sagre (these are summer festivals typical of small towns and villages throughout Italy, but not so much in the cities) that unfold right in the heart of Venice each year!
(Try searching for Festa de san piero de casteo or Sagra di san giacomo dall'orio and look at some pictures)
Moreover, as Venice doesn't have cars (and boats just work in a different way), you're likely to follow the same few paths to and from work. This familiarity aids in establishing recognition on the street.
Being young can be beneficial when integrating with locals, thanks to the significant student population residing in the city (relative to the number of permanent residents). However, it's hardly an impediment; it's common to see people of all ages enjoying drinks during aperitivo. YMMV depending on your level of introversion or extroversion.
Nightlife after midnight is concentrated in a few places, and again it won't take long to recognize the same faces, nor to be recognized too.
Overall, as a single data-point, during my seven years there, I found Venice's social dynamics to touch a sweet spot in its unique blending of small-town camaraderie and large-scale artistic events.
in a similar vein, i match github project issues to md files committed to repo
essentially, the github issue content is just a link to the md file in the repo also, epics are folders with links (+ a readme that gets updated after each task)
i am very happy about it too
it's also very fast and handy to reference either from claude using @ .ie: did you consider what has been done @
other major improvements that worked for me were - DOC_INDEX.md build around the concept of "read this if you are working on X (infra, db, frontend, domain, ....)" - COMMON_TASKS.md (if you need to do X read Y, if you need to add a new frontend component read HOW_TO_ADD_A_COMPONENT.md )
common tasks tend to be increase quality when they are epxpressed in a checklist format