mlaretallack

Running 20 agents at the same time means a lot more task switching, its closer to team management, you may have one agent doing basic grunt work, so can be let alone, another one may be planning and designing, so needs a little bit more q&a, and others may be problem solving, and that does take a lot more supervision. But I have never felt like I have any free time, or down time, at the end of the day I feel far more mentily exhausted (in a good way) than any day before agentic development.

A lot of the tools we have to use are designed for meat proxy's (JIRA etc...) yes, you can allow the agents access to the task repo via api or MCP, but at the end of the day, the tool starts to become the bottleneck, Iike the idea of putting the tasks and issues into git, it means all info for why a change was made is in one place, accessable forever, just need to expand agents to non-software dev world.

Did not think I would like that, but really good, simple and easy summary.

The local councils (local Authority) usually get external companies to design the systems, but there are standard, off the shelf solutions that are specified to be used. These systems range from time synced junctions (with Vehicle attenuation) up to full Urban Traffic Control systems, the protocols used are mostly standard (UTMC), so the local Authority just needs to say what they need. For a UTC system it used to be that the council would run the instation, but with cloud computing, that's mostly run for them now as a hosted system. Usually this is all controlled by the standard local council procurement rules, and run by council employees not elected officials. The elected officials can say a scheme is needed and approve costs, but not who does it.

ASCT is standard practice (and has been standard practice) on most junctions in most towns and cities in the UK for over 20 years.

This is a general principal in the eng shop I work for, its written into every step, including the SCRUM etc.. What when well, why did it fail, what could be done better. Its all part of root cause analysis.

I personally use it for the agents I use, so why did it fail, what was the root cause, what can we do to prevent it again.

Very cool, Its interesting to see what happens to Antarctica.

Loads of them in the UK. Especially in villages where it would be too expensive to install a bridge. Just look at the Southampton to Weymouth line.

I hate to ask but what's a "sexy toasters."

Missing Kiro IDE/CLI/Web.

In Linux, when a shared lib is loaded by multiple processes, its loaded once and not duplicated in ram. Only if a memory page is modified by the process will the memory be duplicated. (Hope I have explained that correctly)

A while ago I created a telegram bridge for AWS Kiro CLI, this allows my to talk to the agent running on my server from anywhere. Any remote access to any of these agents is a massive game changer, it means that you don't need to hover infront of the pc while it works away at the problems. It changes your workflow, but I do find you need to force yourself to "turn off", its easy to do that with the PC, eg, just walk away, but when you can just "get the agent to do one more change" while waiting to pick the kids up or taking the dog for a walk, it can get difficult to stop.

Found out about this today, up until now 802.11p hardware is very expensive, and so you cannot easily do anything with V2x messages like CAM or SPAT, but the fact this was done with sub £20 hardware is really interesting.

100% agree, I find that sometimes I hit a dead end, but the things I build or learn on the way are usable at a later date.