21 ms·
There's no such thing as a small software team anymore
- davepeck 27d agoA 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.
- alansaber 27d agoAgent spam is definitely an excercise in diminishing returns
- gulugawa 27d agoI'm a 1 person dev team who wrote frontend code that outperforms React. Is was successful because I didn't use any sort of LLM assistance.
- ChrisMarshallNY 27d agoI’m a 1 person dev team that’s in the final stages of shipping a complete rewrite of a pretty big app (native frontend, server backend). It’s going to be very successful, because I used all sorts of LLM assistance (and because it’s adding onto a successful app that’s been shipping for two years). There’s absolutely no way that I could have managed this scale, on my own. There will be examples of both success and failure, with LLMs.
- shimman 27d agoThat's pretty impressive. I always like bespoke web utilities tailored for specific dev purposes. What approach are you taking? I'm about to start a mithril.js project, was always under the impression it was the most efficient approach. Are you doing something similar or different or are you referring to WASM?
- mickael-kerjean 27d agoSame as op, I rewrote away from react my Dropbox alternative (https://github.com/mickael-kerjean/filestash https://github.com/mickael-kerjean/filestash) in vanilla js a couple years back around the idea that components are plain exported functions like this: export default function component(render) { const $dom = xxxx render($dom); } example: https://github.com/mickael-kerjean/filestash/blob/master/public/assets/pages/ctrl_homepage.js https://github.com/mickael-kerjean/filestash/blob/master/pub... the only library in there is rxjs to manipulate events in a functional fashion with no imperative code and everything is composed from those simple component functions. The wasm is used mostly as an interface for plugins to both run apps to display various file types like RAW, PSD, TIFF, CDR, .... as those tend to have better support in C than other languages, and on the server side to have a safe environment to execute plugin code.
- chrismorgan 27d agoCompletely seriously, and I don’t think this is particularly controversial: outperforming React is not impressive. React was never particularly good at performance—VDOM is fundamentally overhead, and there are a variety of faster and lighter techniques employed by various competitors, and even among VDOM libraries it’s not as fast as it could be. React sold itself as fast initially, but what it was faster than (rebuilding the entire DOM on any update) was a strawman. It’s not hard to be faster than React while exposing broadly similar functionality. If you’re making something for your own usage only, it’s even easier to beat it.
- gulugawa 27d agoI actually agree with you. I was making the point that not using LLM assistance to code produces decent results. Also, I'm planning to release my changes as a framework that can be used for a variety of interactive websites.
- shimman 27d agoI don't disagree, I'm always curious if there are new techniques out there to adopt. It's just hard to find out about them because as you said, sometimes they are bespoke single use tools that aren't easily shared/discussed about.
- fhub 27d ago> So Uber’s approach to modularity may have seemed extreme at the time, but it could become the new normal. I doubt it. This seems to conflate code modularity with service modularity. Moving complexity from the codebase into operations is counterintuitive to at least the way I use LLMs.
- ch4s3 27d agoHow would the LLMs even appropriately build and manage context in such a setting?
- lofties 27d agoMy biggest issue with these type of posts is that they never answer the "why". Hell, they don't even ask the "why". > The more modular your code, the more agents you can run OK, but why would I want to run more agents? So I can be more productive? What does this productivity lead to? And are we actually being more productive? Take a look at Bun's repo on GitHub which seems to be fully automated. Well over 5000 PRs open. What's the use? How can we justify these 5000 PRs? Over the past years, software has become considerably more shit. Are these 5000 PRs improving the quality of software? Is the end-user reaping the rewards? Are they getting better software, cheaper? The answer to all of those is going to be "no". And let's take Uber for example. They have many teams, and many more times the services. Has ride hailing become cheaper? No. Has it become more efficient? No. Nothing is getting better, but at least we're all off worse!
- wseqyrku 27d ago> but why would I want to run more agents? Notice how difficult it is to turn off photo bursts in iPhone? Because that free cloud space needs to be filled fast. So ask your question again and you will find the answer very rapidly. They even gave it a cool name, "tokenmaxxing" what even the fuck.
- serious_angel 27d agoThank you. I do not believe the author has any idea what he is talking about, too. It's worth to also mention some basics: 1. Dependency on some outsourced LLM vendors (no Internet? No API response? Welp, you do you.); 2. Undefined amount of payments/paid subscriptions at vendors; 3. Undefined amount of tokens burnt on each prompt/iteration within undisclosed algorithms; 4. Absolutely no responsibility/copyright for the LLM output; 5. Privacy concerns on inside/company project source code uploaded; 6. Incremental eventual atrophy of developer's own skills; 7. Inhuman attitude for art, development, effort, purpose in general, since the models are built on stolen effort of other, now unknown, people...
- aussieguy1234 27d agoThere's another way to get this kind of parallelism without the mess of microservices. Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other.
- aryehof 27d ago> Build a well architected monolith and be super strict on single purpose and keeping modules separated from each other Isn’t the question how to keep likely dependent modules separated from each other in a monolith? You say “single purpose”, but how does that admonition work in the reality of a complex problem domain?
- synack 27d agoLibraries, not services.
- Ozzie-D 27d ago[flagged]
- burnto 27d agoWhy not just bake an agent into every service and chat with it? Sounds more fun at least.
- kstenerud 27d agoHundreds 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.
- gentooflux 27d agoThe agents are like ants, and ants build like crazy until the resources run out in winter. AI winter is going to be interesting, to say the least.
- bpodgursky 27d agoI don't say this to be mean, but you need to plan for a world where it's always summer. Maybe the valuations will collapse with OSS models but programming is never going back to normal.
- zx8080 27d ago> but programming is never going back to normal. Are you telling it's shit now? I'm just curious.
- throw123fgbkjgf 27d agoPretty 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.
- the_sleaze_ 27d agoused to work for a company and this is exactly what happened, each team lead pushed for their own little secret garden and fight over who had to add new things. Managing the kafka instance(s) to keep order turned into 2 people's full time jobs. They sold at absolute fire sale price not long ago
- raincole 27d agoYou can use this as a canary. The out-of-control factor = the number of parallel working agents : the number of human programmers. 1. If the factor > N, you're losing control and there will be no organizational wisdom passed down. 2. If your team can't function with the factor <= N, your architecture is way too complex. Choose N over your prior. My recommendation is 1.
- franciscop 27d agoI 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.
- openfront 27d ago> find the current tools (at least the ones I know) are a bit underwhelming for multi-threading Have you tried t3 code? It creates a separate worktree per agent, which makes running multiple agents at once much easier.
- talon8635 27d agoI am a team of one, and I don’t use agents
- marius_ 27d agoThere is no "small team" pushing 100PRs/day, agents or not.
- _345 27d agoI'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?
- squibonpig 27d agoI really don't think they can. I feel like if I rush a PR using AI, I can only just kinda hope the AI is good enough that my trust isn't misplaced. It becomes slightly less likely to be bad if you add a thorough AI review on top but it's just rolling the dice.
- somesortofthing 27d agoMicroservices can trample on each other just as easily as monolith internals can. If anything, the friction of reconciling changes in a monolith is useful signal that conflicting changes happened, and it takes slow and flaky e2e tests to replicate in microservices. It's not like you're resolving the merge conflicts by hand.
- samlinnfer 27d agoThousands of microservices = thousands deployments that can fail, that needs to kept compatible, that needs to be able to find each other, that needs to be monitored. This is just pushing the pain downwards.
- layoric 27d ago> If you have a large monolithic service where every change has to be coordinated carefully.. Microservices are WAY harder to coordinate for deployments. You end up with feature service dependencies, and you are back to the same coordination, but now harder to discover down stream dependencies..
- pqdbr 27d agoTotally agree. And having a Rails monolith that the LLM can see the entire context - even our marketing landing pages - is a blessing in AI era.
- lucianbr 27d agoI think microservices are supposed to be easier to deploy independently, that's the whole point. And if they are not, it means you're just doing it wrong. But in truth, all the projects with microservices I have seen in real life had deployment coordination problems, and looked to me like distributed monoliths. So maybe it's a 'no true scotsman' thing. Maybe they are always, or at least most of the time, harder. Makes it harder to justify using them.
- xboxnolifes 27d agoPeople do microservices (read: an API spread across multiple processes), but then make all of the mistakes that logically couple the service deployments together. They use shared databases instead of one per service, make breaking changes to API schema instead of non-breaking or versioning, use a shared library of schema definitions instead of having each service define their own data objects for API calls, and have startup logic that depends on another service being up.
- janalsncm 27d agoCall me old school but I feel like the solution to humans clogging up the slop cannon will be for AI generated code to look more human. That is, the code should be correct but also idiomatic.
- whatever1 27d agoWait 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.
- fra 27d agoI would take the other side of that bet. In five years, there won’t be more outages than today.
- whatever1 27d agoDeal. See you here 2031. If the site is still up.
- jaggederest 27d agoYou can already see a practical example of this in microsoft's issues with Azure. Too many services, too little understanding, everyone left who knows what is going on. There was an interesting article here a little while ago by one of the architects something like "how azure set a trillion dollars on fire" or something like that.
- BLKNSLVR 27d agoThe answer to all the questions, though, is more AI/LLM usage. Nobody got a freaking clue what the LLMs have done and why services are down? Diagnose it with LLM, and get the lights back on ASAP! I have a similar concern, though. To do my job, I need to understand "the thing". I could outsource the understanding process to AI, but then if I'm asked a question by a developer or tester then I'm essentially stumped / useless because I didn't spend the time to understand the thing, I handballed it. So I then ask the LLM the question I was asked, and pass the answer back (they could have done this themselves though, so where does that leave me? I'm either an AI wrangler, or replaced by someone else who wrangles AI replacing mutliple people in my role). Does my personally understanding the thing actually add value - do the seniors who know their systems add value - in the age of AI/LLM? Does "LLMs all the way down" solve the problems? With the existence of hallucinations I lean towards 'no', but again is that solved by adding layer(s) of LLMs to check for hallucinations?
- abigdog 27d agoHe misses the bit about Microservices where you need to integrate changes across services and avoid undocumented API spec from your changes blowing something up. Getting alignment and so on. There are probably agentic solutions but this article misses a lot of detail and doesn't even hand wave it.
- ulrikrasmussen 27d agoIs this satire? Changing your easy to maintain monolith architecture to a microservice architecture to enable parallel agent development, really? That's got to be some of the worst advice I'd heard in a long time. You will have conflicts during parallel work if people are changing features that are related. You will also get these conflicts with a microservice architecture and hundreds of independent repos, but now it is not a merge conflict because you touched the same syntax, it is a semantic conflict. And didn't Uber also have a famously slow and convoluted CI pipeline where it took an enormous amount of time and resources to build anything?
- naniel 27d agoi agree with this.. but also think it could stress a couple things more: - satisfying the needs of parallel agentic development is wholly aligned with the optimal DevSecOps CI/CS/CD WhateverTerm models out there. And that's rad, bc a lot of orgs have a reference frame to map to. - microservices, monoliths, monorepos, mammoths, whatever.. The code and services can be structured however, so long as the release capabilities are modular and governable/manageable/auditable/flexible/transparent/etc. A killer workflow allows for tight independent releases, but not chaotic, with proper add'l structure/scaffolding to satisfy that list above. Microservices and smaller repos can help with the context window bit initially, but you can rig up and kind of local llm-focused setup to allow for selective context and holistic context (across N repos or N projs within monorepo) - strategy: use the robots to fix the problems in your PDLC/CICD/ABC so that the robots can help you out more, and keep iterating on that
- jillesvangurp 27d agoAgentic coding puts a lot of pressure on team communication. Individuals produce more output. So there now is a lot more to discuss and synchronize on. This favors smaller teams that typically are responsible for more things. That doesn't necessarily mean fewer people. But I do think it favors having more smaller companies over fewer larger ones that are each able to specialize more. It also means that companies that currently outsource all their development or buy SAAS products now should consider in housing some things again. A lot of people worry about work disappearing. I think the opposite is going to happen: more work popping up in a lot of new places. Because doing that work is now feasible and doable. Staying on top of work done across many teams is going to be a huge challenge for larger companies and it's going to cause them to organize and hire very differently. Getting this wrong means teams diverge much quicker than they used to and everything gets misaligned much quicker. Some team might launch a product before some other team that was considering to do a similar thing is even aware that is happening. As most engineers might appreciate, the easiest way to tackle complexity is to just work on cohesiveness and coupling. Small teams with few dependencies working on a coherent thing will be much more effective than large orgs with a lot of inter team coupling and no coherent plan. I'm in my fifties so, I've been around for a while. I currently work in a very small company (3 people) so I'm used to doing things by myself. I also used to work in traditional teams inside large multinationals. Very different game. You spend non trivial amounts of time communicating with people in big organizations. And you basically only get responsibility for a tiny amount of functionality. I had to learn a lot after I left the safety of a big organization. When everything is your problem, you need to skill up in a hurry to deal with all the challenges effectively. In my current role, I do basically everything vaguely technical. And non technical as well. And it is more than ever since AI coding entered the mix last year. I stopped referring to myself as a backend person. Because I also do UI, devops, websites, IT infrastructure, etc. And a bit of sales, marketing, etc. I'd add management but we're such a small team that I suffer a little from impostor syndrome on that front. But I can do the job if I need to. I had a whole hiring plan that I developed three years ago that we never executed on. It had all the traditional dev team roles spelled out. That plan is obsolete. These roles will probably never be filled. I need different people though. I need more people like me that can do everything I do when I'm not around and people with complementary skills that are strong where I'm weak. But I have much less need for specialists. I mainly need generalists with attention to detail that can deliver complete working products and systems. I might want a product focused person but not a dedicated product manager. If you can specify it in an issue tracker, you can learn to prompt an AI as well. But I still need a good product plan and roadmap. In the same way, I expect designers to shape UI work directly and not via a separate UI team. I expect them to own the front end experience and drive it. I still need people that are strong in these roles. But not exclusively. Good small teams have less people than all the traditional roles you find in larger traditional teams. That calls for people with overlapping skills that can put on different hats as needed that complement each other.
- mdavid626 27d agoThen you’ll have “GitHub” uptime, breaking prod every day.
- pranavmalvawala 27d agoFunny take. Monoliths are actually better then microservices because of the context they carry. At the end developers are supposed to run a product, not to keep mindlessly running agents just because they can
- zkmon 27d agoI 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.
- atq2119 27d agoI want to agree with the sentiment. Then again, OpenMP has in fact used the term "team" in the this kind of sense for a long time.
- stymaar 27d ago> A small team today, running 20-100 agents in parallel, might generate 500 commits/200 pushes/100 PRs Who the fuck is writing the requirements in that story?! Setting aside the problem of pushing AI-generated code that nobody has read straight to production, the reason why you're pushing code to production in the first place is to implement a product that is solving a problem for your users. And the problem I have with the hypothethical workflow described above is: How is any product owner supposed to come up with hundreds of feature or improvement requests a week?
- whstl 27d agoJust ask AI to write Jira tickets and call it a day. The point isn’t to serve customers anymore, it’s to use AI for AI sake because investors want, because they have FOMO. I’m only half joking. I have seen PMs attempting that and getting fired. The investor thing is 100% true.
- lucfranken 27d agoThe reason micro services became fancy is because they could split up large groups of people. They could work on different parts more autonomously without all being dependent on each other. It has an overhead but as scaling the amount of people was worth it there was an advantage. Where did this work: where the interfaces between those groups of people were agreed upon. A team could call: finance->billTrip(TripObject) via an API and the finance team became independent. The micro services had an API which was documented. They could move from Stripe to SAP to a custom solution internally without bothering the other teams. Now we have AI. Those interfaces are still needed. But is there still an advantage to hard separating those interfaces in real micro services, with separate databases for each team, over http or other protocols? On some point it may. A service which needs to scale unlimited (like RenderThumbnails with hundreds of thousands of call per day) might have that. But if you send out 1000 invoices per day it might not be needed for that at all. In Rails they have active job for it for example. Same codebase but a scalable worker for longer running jobs. AI is capable of quickly keeping function calls consistent internally. So a hard coded API is way less useful now for those services which don’t need the scale. An interface could suffice just fine. No human would ever read the finance API anyway. Keeping consistency in the monolith part is way easier. That is statically testable, quicker testable and there are plenty of tools. All disadvantages on micro services on those calls are just a waste. One thing where I think hard boundaries are useful is on really blocking AI coding tools. With microservices you are able to physically prevent Claude or others to modify the other interfaces. That way it prevents hallucinations, quick fixes and other workarounds the tools like to do. Just because an AI wants to get sometime done it will sometimes skip corners. I see that as a current state which will be fixed quite soon. The models and their harnesses will become increasingly better in preventing stupid corner cutting to get the fix out. When that is done: why would you want more complexity with micro services instead of less? Instead of we all implementing microservices and other structures we should get the harnesses right to respect interfaces and boundaries. And in the micro services era we had meetings to sync the API’s between them. So maybe the AI’s should meet about the interfaces, with a good coffee.
- igor_nast 27d agoIf you want a truly free to use agentic IDE check shikigami.dev - free to use - not a vc baked, indie product
- norenX 27d ago[dead]
- ulrikrasmussen 27d agoI 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.
- arkh 27d ago> if you have thousands of microservices You just replaced ns memory accesses by ms API calls. Just the moment people were starting to maybe start thinking about performances again this train-wreck of power wastefulness had to appear.
- mystifyingpoi 27d ago> Fire up a coding agent for each one, tell it to “improve performance”, and there’s a good chance you ship significant improvements across all of them. But I can do this like what, once or twice? Maybe once every release? Then my agents finish "improving performance" and it's Monday 10am. What the fuck I'm supposed to do the rest of the week?
- elzbardico 27d ago> While I’m not saying every LLM user is an imbecile, they’re built to convince the mediocre and incurious that they’re remarkable, and it turns out that a great many of them run venture capital firms and Fortune 500 companies. > I also want to be clear that while there are sane and normal people who use these things, they’re mostly drowned out by a crowd of people that oscillate between bootlicking and regurgitating capitalist mythology in a way that makes it hard to trust anybody who spends significant amounts of time using an LLM. > One thing you’ll notice about the most moistened AI boosters is that they lack much degree of pride in their work. Everything they say must, at some point, compliment the mindless, unprofitable, unreliable tool underneath it — how “incredibly powerful” it is, how it’s “only getting better,” how it’s “only the beginning” of something that’s eaten over a trillion dollars and absorbed the majority of venture capital. Ed Zitron. The Revenge of the business idiot. https://www.wheresyoured.at/the-revenge-of-the-business-idiot/ https://www.wheresyoured.at/the-revenge-of-the-business-idio...
- keeda 27d agoOne of my predictions for software in the AI age is that we will end up with nano-services. The thinking is this: 1. LLMs perform best with tight, focused context. 2. Encapsulating specific well-defined functionality into a single service, tool or API inherently limits the amount of code it requires, and hence the context an LLM requires to reason about it. The smaller the codebase, the better an LLM will do with it. 3. Code is already increasingly written by swarms of agents that tend to step on each others' toes, and hence a way of isolating them would be great. 4. Combining the 3 points and taking them to the logical conclusion, we end up with nano-services. It's basically the Unix philosophy, just scaled up to distributed systems. For all its other issues, the core philosophy worked pretty well for Unix tools, so it should work well for nano-services too. Currently the "pipes" between these services are network calls, but they need not be. One could imagine an architecture where these components are composed either as direct function calls or remote network calls depending on access patterns and resource requirements for a given instance. Never worked with Elixir but I think that might fit the bill? Maybe every sufficiently complicated distributed system will end up re-inventing an ad hoc, informally-specified, bug-ridden, slow implementation of half of Elixir.
- julianfurchert 27d ago[dead]
- pheymann 26d agoThe potential I see with LLMs is that a single team or even IC can now deliver whole feature end to end. Having just more services only means I get bogged down in PR review by other teams. Or I lose time waiting on them to do the change. In other words, any gain I got I lose tenfold because of inter-team coordination. I think if you want to see delivery speed up focusing on what a team can own is more relevant than if you have merge conflicts.