We are experimenting with this kind of development style and from my experience so far this shift a lot of the complexity of building into the story writing and manual testing phases.
As I will need to fully handover the task and let the agent(s) essentially one-shot the implementation I need to be way for specific and clear in giving it context and goals, otherwise I’m afraid it will start build code purely by accumulation creating a pile of unmanageable garbage.
Also changes which requires new UI components tend to require more manual adjustments and detailed testing on the UX and general level of polishing of the experience our users expect at this stage.
I’m starting to develop a feeling of tasks that can be done this way and I think those more or less represent 20 to 30% of the tasks in a normal sprint. The other 70% will have diminishing returns if not actually a negative return as I will need to familiarise with the code before being able to instruct AI to improve/fix it.
From your experience building this, what’s your take on:
1. How do your product helps in reducing the project management/requirements gathering for each individual tasks to be completed with a sufficient level of accuracy?
2. Your strong point seems to be in parallelisation, but considering my previous analysis I don’t see how this is a real pain for a small teams. Is this intended to be more of a tool for scale up with a stable product mostly in maintenance/enhancement mode?
3. Are you imagining a way for this tool to implement some kind of automated way of actually e2e test the code of each task?
Thanks! What tools have you been experimenting with?
Agreed. That this evolution pushes much of the work into describing desired outcomes and giving sufficient context.
To your questions:
Emdash helps reduce the setup cost of each environment by allowing you to open an isolated git worktree, copying over env variables and other desired context. And then preserving your conversation per task. That said, you still need to write clear goals and point it in the right direction.
I think it's less about team scale and more about individual throughput. My working mode is that I'm actively working on one or two tasks, switching between them as one runs. Then I have a long list of open tasks in the sidebar that are more explorative, quick reviews, issue creation etc. So for me it's not about one-shotting tasks, but instead about navigating between them easily as they're progressing
Automated e2e testing is tricky, particularly for rendering. I think roborev (https://github.com/roborev-dev/roborev) is moving in the right direction. Generating bug reports synchronously per commit and not just once you create a PR. I also think what https://cursor.com shipped today with computer-use agents testing interfaces is very interesting.
When Trump’s video about the Kirk assassination (https://www.youtube.com/watch?v=2yCu21pL73s) went viral, I noticed a wave of replies aggressively insisting the video was not AI-generated. I could feel those replies were mostly by bots as I've checked manually few accounts and most of them followed weirdly the same patter:
1. Created in 2013
2. Have between 7 and 10 subs
3. Have between 2 and 3 video playlist
4. Account bio extremely generic
After a few minutes spent manually checking I decided to build a tool that:
• Downloads all YouTube comments + replies
• Runs sentiment analysis on each
• Detects bot-like behavior using heuristics + LLMs
On this video, over 40% of comments look like bots, and they overwhelmingly argue the video wasn’t AI-generated.
I didn't went as far as trying to understand where these accounts are coming from, but my main goal was to confirm whether this was real coordination.
I'm not expert in data nor in python (I've mostly vibe-coded it). I’d love to get some help from folks how might be interested on these topic.
I remember a paper from last year in which they are suggesting that basically Blue Zones are made just by a combination of clerical error and pension fraud: https://www.biorxiv.org/content/10.1101/704080v3
As I will need to fully handover the task and let the agent(s) essentially one-shot the implementation I need to be way for specific and clear in giving it context and goals, otherwise I’m afraid it will start build code purely by accumulation creating a pile of unmanageable garbage.
Also changes which requires new UI components tend to require more manual adjustments and detailed testing on the UX and general level of polishing of the experience our users expect at this stage.
I’m starting to develop a feeling of tasks that can be done this way and I think those more or less represent 20 to 30% of the tasks in a normal sprint. The other 70% will have diminishing returns if not actually a negative return as I will need to familiarise with the code before being able to instruct AI to improve/fix it.
From your experience building this, what’s your take on:
1. How do your product helps in reducing the project management/requirements gathering for each individual tasks to be completed with a sufficient level of accuracy?
2. Your strong point seems to be in parallelisation, but considering my previous analysis I don’t see how this is a real pain for a small teams. Is this intended to be more of a tool for scale up with a stable product mostly in maintenance/enhancement mode?
3. Are you imagining a way for this tool to implement some kind of automated way of actually e2e test the code of each task?
reply