Comment by MomsAVoxell
8 hours ago
We realized a few months ago, in my development group, that each one of us having an individually-tailored session asking AI questions is not as productive as if we all shared the same AI session, like a 'common terminal', because having individual sessions meant a fair bit of redundancy and overlap in our prompts - whereas now that we all share the same interface, the AI/ML is learning a lot faster and producing higher quality results from the perspective of team acceptance of the generated code.
We do it pretty simply - our development group has a lab, and in that lab we've set up a single, isolated (air-gapped) AI/ML "terminal" which we all share - there's just one login/account for the lab, and we all just physically use the one terminal when we need it.
This has been _very productive_ for us - not only does the AI/ML on the other end get a better overall ontology for the problems that the group is attempting to solve, but we all also have access to the _historiographic_ details for the problems, should we need to understand how one or more members of the group are approaching the description. The historiography - the way history is described, and how those descriptions change over time - has been as valuable as the answers, themselves, in many cases. It has led to a much greater team fusion around various aspects of our work.
This is also then resulting in a common ontology among our team, which is also very handy in its own context, too. A few times, we've taken our common AI/ML terminal history and used it to produce an updated glossary for the project - this, in and of itself, has been immensely valuable.
Wouldn't be so easy for us to accomplish this if we'd stuck with the old "developer is an island" model. Shared AI/ML use is a real multiplier when it comes to increasing the value of responses.
I would love to hear more about how you accomplish this.
If you have the time, I'm specifically interested in:
Are you really all only using a single agent/context window? Or do you still use a coding agent individually but have other domain, planning, etc conversations with the shared context?
What tooling and model(s) are you using to do this?
How big of a team are you doing it with?
How long did it take you to transition to this process before it felt good?
Note that this is a team method, not an individual one. For my personal (non-commercial) development work, I still use LLM one-on-one - but for commercial team work, this common terminal method has been a productive method, also.
We don’t use coding agents - these are incompatible with security and IT methods we already use very successfully to maintain stringent quality demands (our product target is heavy industrial/life-critical services) - we mostly interact with the LLM on existing codebases, and strictly in sandboxed scenarios through a robust and proven git workflow.
There is, literally, a single physical terminal which any and all of us use - think of the LLM like a refrigerator, not a footlocker. This machine is isolated from everything else in our lab, except the repo in focus. It is the only LLM interface for our projects, and it is a common lab resource - developers use it when they need to, communicating back to their main workstations through the git workflow.
Yes, there is only one context window, everyone looks through it. This reduces and massively simplifies the tooling load.
Tooling and models: Firefox for web-based queries, git and hermes for everything else, tmux for the front-end, and it is of course a virtual machine, anyone can remote to, share, observe, pair-program - and there are a set of models in use, for different types of problems encountered by the team members.
Everyone pair programs anyway already, and code reviews are treated as important as standups also, LLM or otherwise. No LLM code can be committed to upstream branches without at least 2 reviews within the team.
The team is about 12 members, mostly senior developers with decades of experience delivering safety-critical, realtime systems, give or take the odd intern or student being added/elsewise assigned over the past year.
It took, literally, a week before we sorted this out.
We all had LLM rigs in our home labs (and of course we all still do), but when it comes to maintaining the collective corpus, so to speak, we realized we would get more out of the LLM if we all spoke to the same endpoint.
I think it was important that our git flow was already circumspect; certainly we have been able to treat the LLM as we treat our interns - everyone has access to the common fridge/kitchen, so the intern/LLM learn how to cook faster/how to do things properly.
There are some other principles, which I will summarize, at play:
1. All AI/ML is to be contained - it is not just widespread installed in the environment. Humans are the best container for AI/ML. We (senior developers corps, anyway) all had the individual conclusion that this must be The Way™, as we all got bit by the AI/ML bug. The best way for humans to contain the LLM, is to discuss the LLM. Having the same common interface to the LLM, makes it a lot easier for humans to discuss what is going on with the LLM.
2. The AI/ML must be controlled precisely in order to apply it to the problem, properly. This takes real human experience. It is easier to do if the team shares the experience. Thus, we have the common historiography reviews, which we treat as just as important as team standups where other things are discussed. We discourage prompt copying - everyone still has their style - but instead we encourage standard terms and definitions; often-times, the history in the common LLM terminal is where a lot of us learn the real meanings for things.
3. Humans are still in the loop. Nobody is allowed to just say “the LLM wrote this code”. What is important to the team is, who reviewed it? Who reviewed it, again?
That has saved our ass so many times it’s just muscle memory now.
4. The best LLM is a local LLM. We now feel confident, as a team, to take on the task of training our own model and using it for broader development in future products. The process in place to do it properly is simply the general consensus being maintained by the common team reference.
Needless to say that this approach requires a healthy dose of maturity, individual hygiene, and trust between the team members.
Well, good software quality standards require this, anyway.
It’s not just an LLM problem - its also a SIL-4 problem.
Coding rules, coding standards, standard code review sessions, and the principle of shoulder-surfing/pair programming were all well and truly entrenched in the team before the LLM intern was hired, so to speak.
These are good methods to improve software quality standards anywhere, really.
Hiring is important!
As important as choosing where to work.
What do you think the last 10 years of “culture fitness” has been about?
Before the Singularity (before any mind can emerge, really) you need reliable neural protocols.
I really think it will happen eventually - religion and science merge under this idea that we are all participants in the mind of god who, until that realization and subsequent calibration, could not awaken.
Like the WoW storyline, basically. So the Earth as of today is like a sleeping god that hasn’t woken up yet, and our society is its dream.
Those who ignore the godhead, become its subjects. Those who confront it, become it. This is as true of any human organization, ever, as it is of humans today.
AI is just humans, organizing.
remember when we had an engineering discipline in our industry instead of this religious mumbo jumbo?
2 replies →
Is that what people mean when they say "AI Psychosis"?
2 replies →