Join the discussion
Write your take first — we'll ask for email only when you're ready to publish.
- Hacker News
- I saw the `require('gulp')` and the memories def came back. That's def how we used to do code ~10 years ago. I still don't like the multi-threaded PER PROJECT too much, I prefer having 2 projects and switching context window, I find the current tools (at least the ones I know) are a bit underwhelming for multi-threading. But I'm also trying to upgrade my knowledge.
A good way I've found, since I do a lot of OSS and have my own libraries, when I find a bug in one of those libraries I can work on the same project on the main window while fixing the library on another window. I normally need to tell the main one "let's skip this for now, I'm fixing the library" meanwhile or similarly.
by franciscop - I hope people don't call automations as "teams". If you are calling it a team just because it "does" work, then CPU cores and threads are also a team, though not so probabilistic (intelligent). They do get the work done.by zkmon
- I'm really skeptical you can ship ~10 PRs a day per person unless these PRs are tiny pieces of one feature or all of them are tiny bugs that are each a 3 line fix that you could review instantly. Otherwise how can you confirm that the AI even did the right fix or feature correctly? That you even wanted that feature done that way?by _345
- Pretty sure Uber ended up with thousands of microservices because they used to tie owning a service to perf and promo, and were trying to cut down the number for years. It's hilarious to see this interpreted as an intentional choice.
- I have already commented about this is probably the worst advice I have heard in a long time, and I would definitely not let this guy anywhere near a codebase I had to maintain.
But this is also essentially blogspam. The author intentionally includes two screenshots which add absolutely nothing to their point and which are too small to read. When you click the second one, you are not taken to a larger version, you are taken to the frontpage of his company website which features the same screenshot.
- Wait two years until we have sufficient churn of senior talent in the teams. Then all of the services will have outages daily.
Only the seniors who know their systems are keeping the lights on today by keeping bs commits out.
Once they burnout and quit, nobody will have a freaking clue what the LLMs have done and why services are down.
by whatever1 - A wise troll once said:
> best weapon against complexity spirit demon is magic word: "no"
In counterpoint, I believe small teams can remain small. Small teams can ship simple monoliths with high velocity, commit count, and quality. Service orientation didn’t suddenly become low-cost because of agents; the boundaries between multiple services that version and deploy independently are still tricky beasts to wrangle. And it’s not clear why “running more agents” is inherently desirable or impactful; my small team’s (admittedly anecdotal) experience is that the value quickly saturates.
by davepeck - Hundreds of bots modifying thousands of microservices may sound good on the surface, but all those thousands of microservices make up an architecture and a product.
Agents aren't very good at carrying the entire model in their context, so when they reason about a small piece of code, they often come up with something that hurts other parts of the code (especially as the KLOCs pile up). The complexity hasn't been replaced, only moved. And guess what's going to happen when all of these microservices become even more of a moving target than they already are?
AI is capable of improving productivity, but this approach sounds more like a nightmare in the making.
by kstenerud