Where Does an IT Study Group's Value Sit Now?

Key points

- Generative AI lets an individual obtain overviews, setup steps, error investigation, and tool comparisons in a short time. The information-delivery role that study groups used to carry has become less valuable in relative terms.

- What has gained value instead is first-hand information: whether something runs in your own environment, where you get stuck, and what happens when you fold it into real work.

- This article looks at that shift through four sessions Miyako de IT, an IT engineer community in Kyoto, held between April and July 2026.

- The conclusion is a move from a place to be given answers toward a place to bring back what people actually tried.

ChatGPT, Claude, and Claude Code are now part of everyday work, and an individual can obtain technical overviews, setup steps, error investigation, and tool comparisons in a short time. What people once attended a study group to ask an expert about now finishes at their own desk more often than it used to.

That makes the information-delivery value of the traditional format—an expert holds knowledge and teaches it to participants—lower in relative terms. The assumption that the same content is available only in that room no longer holds.

Something else has gained value at the same time. Whether a tool actually runs in your own environment, where you get stuck, and what happens when you fold it into real work: this is first-hand information. Asking an AI rarely fills that gap, because the information does not exist until someone has actually done the work and brought back the result.

The central claim of this article is one sentence. In the AI era, an IT study group is moving from a place to be given answers toward a place to bring back what people actually tried. Rather than argue it in the abstract, we check it against four sessions Miyako de IT actually held.

When twelve people install at once, you see what one person cannot

On April 20, 2026, we held the Claude Code / OpenClaw hands-on study group at Taisho University Kyoto Academia in Higashiyama-ku, Kyoto. Twelve people took part. The format was to set up and try Anthropic's Claude Code and the open-source OpenClaw on the spot and compare them.

The part of that session most relevant here is not the headcount itself but the fact that twelve people installed these tools on their own machines, in the same room, at the same time.

Working alone, you observe exactly one success or one failure. What remains is the result under one set of conditions: your operating system, your existing development environment, your network, your account state. Whether that result is typical or specific to you is not something you can judge.

When twelve people try at once, results from multiple environments and multiple patterns line up within a couple of hours. On the day, some participants focused on Claude Code, some concentrated on installing OpenClaw, some aimed simply at finishing setup, and some worked on tasks close to their real jobs. In the second half, what each person had done and what they had found were shared naturally.

Participants shared impressions such as "setup is shorter with Claude Code" and "OpenClaw becomes an option when you want to swap the model or the environment." These are not the results of a controlled comparison; they are the impressions of the people who were in the room. Even so, they are the kind of information that is hard to obtain by reading documentation alone.

The point worth emphasizing is that the fact that not everyone gets the same result is itself where the community's value sits. If everyone converged on the same outcome, sharing a single set of instructions would be enough. Because results vary, you gain material for estimating which way your own conditions are likely to fall. Variation cannot be observed without a group of people present.

Not "what is an AI agent" but "how did you actually use it"

On May 30, 2026, we held the AI Agent Practice Lightning Talks in the Former Assembly Hall of the Former Main Building of the Kyoto Prefectural Government. About 30 people attended, including Kyoto Prefectural Government staff.

Listing the lightning-talk themes makes the character of the session clear.

• Making social-media operations more efficient with AI agents
• Using generative AI in preparation for selling a karakuri kit
• Deciding to keep a daily work log
• Improving day-to-day work with local LLMs
• Templates that speed up document production without lowering quality
• Building and using multi-agent setups
• Design work with Pencil and Claude Design
• Using AI to raise one's own capability
• Energizing Kameoka through AI vibe coding

Not one talk was a general explanation of what an AI agent is. What people shared was how they had actually folded these tools into a specific setting: social-media operations, work logs, document production, local LLMs, design, and regional activity.

In the talk on document production, for example, the approach shared was to complete a template and a structure first rather than asking AI to produce everything from scratch, which preserved the quality of the deliverable while cutting the time. That kind of point—which step comes first—is hard to see from a tool's specification alone. It stays with the person who has run the process several times.

Kyoto Prefecture's work on using AI agents in a public-sector setting was also introduced. When government staff, IT engineers, business operators, students, and creators talk in the same room, the differences in their constraints themselves become information.

Once you start making something, problems appear that knowledge does not cover

On May 28, 2026, we held An Introduction to Making Video with AI online via Google Meet. Eighteen people attended. The instructor was maki, a freelance web designer working in Kyoto.

The definition of AI video generation, the difference between text-to-video and image-to-video, the names of the major tools: up to that point, asking an AI returns an answer within minutes.

Once you start making something yourself, a different class of problem appears. How do you separate subject, motion, camera work, lighting, mood, background, and intended use across a prompt? Vague instructions rarely produce the intended video, and over-specifying can break the result. Where a person or a product has to stay visually consistent, image-to-video and reference images work better than text alone. Using the output at work means checking copyright, portrait rights, trademarks, and each tool's terms of use before publishing.

Every one of these turns on whether you have actually done it, not on whether you know about it. Acquiring knowledge and touching reality are separate activities. This session let participants experience that gap within two hours.

Real hardware does not return the answer the theory predicts

On July 27, 2026, we held part three of our quantum computing introductory series at Fushigina Yado in Shimogyo-ku, Kyoto. The instructor was Tetsuya Onogi of the Graduate School of Science, Osaka University. The second half was a hands-on lecture in which participants wrote quantum circuits in Qiskit and sent jobs to real IBM Quantum hardware.

What came through most strongly was the gap between theory and hardware.

In theory, a two-qubit Bell state yields only "00" and "11" as measured values, each about 50% of the time. On real hardware, "01" and "10" also appear, which the theory does not predict. In the execution example printed in the lecture materials, 4,096 shots broke down as 1,955 for "00," 85 for "01," 129 for "10," and 1,927 for "11," giving an accuracy of about 95%.

In the Grover search example, the correct answer "11" was observed 3,736 times out of 4,096 shots, about 91%. Random search without any information succeeds 25% of the time, so in this small example the correct answer became roughly 3.6 times easier to find. The remaining 9% or so that falls short of the theoretical 100% comes from hardware noise.

These figures come from execution examples printed in the lecture materials; they are not an aggregate across all participants on the day.

Read as theory, the point ends at a single sentence: quantum computers have noise. Send a circuit to real hardware and watch numbers that do not match the theory appear on your own screen, and the meaning of that sentence changes. Noise stops being a footnote and becomes a property of the device in front of you. The whole series is summarized in the complete guide to our quantum computing introductory series.

How we plan to design sessions from here

From these four sessions, we set out four points that guide how Miyako de IT designs its sessions. These are our own operating policies, not a universal answer for every community.

1. Touch it during the session

We protect time for participants to run things, even at the cost of cutting explanation. Install, write code, generate, break something, produce an error. An error on screen is not a failure; it is an observation available only in that room. A session where people listen and go home competes directly with asking an AI.

2. Have several people try the same task

One success does not establish reproducibility. The value lies in several people running the same task in different environments and lining the results up. That is exactly what happened in the Claude Code / OpenClaw session.

3. Share where you got stuck, not just what worked

What you tried, where it failed, and what you changed to make it work. Those three together are the most reusable form of information. If only the successes are shared, the next person who gets stuck at the same step has nothing to go on.

4. Carry it back to real work

Where would this go in your own organization? What will you try tomorrow? And if you decide not to use it, what is the reason? A decision not to adopt something is first-hand information too. Only when the discussion reaches this stage does "what I tried" become material for the next person.

What to ask an AI, and what to ask a person

The spread of AI has not removed the need to ask people. It has changed the kind of question worth asking a person.

The left column has documented answers that come back when you ask. The right column exists only inside people who have done the work, and the answer changes with the situation. Almost everything exchanged in the conversation after a study group, a lightning-talk session, or a co-working session belongs to the right column.

The timeline a local community can hold

Miyako de IT started in Kyoto in February 2019. As of 2026-08-17 it has held 154 completed events with 626 registered connpass members, over 7 years of operation. The member count is the number of connpass registrations and does not indicate the number of people who actually attend.

The property worth naming here is not scale but the timeline.

• You meet someone at a study group and see them again at the next co-working session
• You run into them again at an event on a different theme
• Six months later, they are the one presenting
• You can ask, "That thing you were trying before—how did it turn out?"

This is not a claim of superiority over large events. Large events have strengths of their own in reach and volume of information. The point here is a property that a local community tends to develop: it becomes easier to follow the same person's experiment over time. That is what running these sessions has felt like; we have not measured participant retention.

That fits with the right-hand column of the table above. "Are you still using it?" is the kind of question that is hard to ask unless you will meet the person again in six months. A single contact leaves little way to learn how they judged it later.

An overview of Miyako de IT and how to take part is in What Miyako de IT, the Kyoto IT engineer community, is, and the history of our sessions is in our community statistics.

The word "study group" is drifting away from what happens

Having written all of this, the term "study group" itself may stop matching reality.

What actually happens now is closer to this.

• A place to try things
• A place to compare
• A place to fail
• A place to ask for advice
• A place to watch other people's experiments
• A place to run into a technology you did not know about

Of these, "study" fits comfortably only around the last one. There is no urgency about renaming anything, but deciding automatically that a study group means a lecture format drops exactly the part that has gained value. We have also written about session formats in a guide to study group formats and about operations in common failures in running a community.

Summary

Generative AI has made it cheap to know about a technology. That raises the value of touching reality, actually trying things, comparing results across several people, and exchanging failures.

Miyako de IT will keep building, in Kyoto, a place to try things that do not have answers yet rather than a place to come and hear finished answers. Upcoming sessions are listed on our events page. If this would be your first time, the first-time guide is a good place to start.

Related articles

• AI Agent Practice Lightning Talks at the Former Kyoto Prefectural Assembly Hall
• Comparing Claude Code and OpenClaw Hands-On in Kyoto: Event Report
• An Introduction to Making Video with AI: Event Report
• Noise and Grover Search on Real IBM Quantum Hardware: Introductory Series Part 3
• What Miyako de IT, the Kyoto IT engineer community, is