Java developers no longer have to rely on Java framework-specific approaches to drive AI from their enterprise apps.

While it is true that Langchain4j empowered developers by disintermediating specific AI vendors, you still had a dependency on Langchain4j. And with Spring AI, well, of course you had a dependency on design choices made by Spring, if not on Spring itself.

Now, GitHub Copilot SDK for Java is the first truly framework agnostic way to drive AI from Java. And with its BYOK support, GitHub Copilot SDK for Java is also AI vendor neutral.

The GitHub Copilot SDK for Java is a client library that empowers your server-side Java code to create Copilot agent sessions, register tools, send prompts, and receive structured responses—all programmatically. It works in server environments, including Jakarta EE and Spring. If you’ve been building enterprise Java for any length of time, this SDK will feel like home: CompletableFuture, annotations, lambdas, virtual threads, it’s all here.

This post shows you how to use the SDK, walks through a complete Jakarta EE 11 sample application, and leaves you with concrete next steps to try it yourself. I chose Jakarta EE 11 for my demo because I was the lead release coordinator for that release. I believe in open standards as the best way to empower developers. For more on Jakarta EE 11 see this InfoQ article.

This sample app is an agent harness using Jakarta EE 11. But, of course, developers can build their own agent harness using the well-known Java frameworks and libraries of their choice.

Clone the sample app and try it yourself >

Where to get it

The SDK is available as a Maven dependency:

<dependency>
    <groupId>com.github</groupId>
    <artifactId>copilot-sdk-java</artifactId>
    <version>1.0.7-preview.1</version>
</dependency>

Prerequisites:

• JDK 17 or 25 (25 recommended — unlocks virtual threads and other modern features)
• Maven 3.9+
• A GitHub account with an active Copilot subscription
• The Copilot CLI installed locally at version 1.0.71 or later.

Walk through the sample app

The best way to see the SDK in action is to run this sample application.

Get the code

git clone https://github.com/microsoft/Build26-BRK206-your-agent-anywhere-multiclient-multidevice-with-github-copilot-sdk.git
cd Build26-BRK206-your-agent-anywhere-multiclient-multidevice-with-github-copilot-sdk/src/java-agent-orchestrator
mvn clean package liberty:run
# Open http://localhost:9080/index.xhtml

The Java demo is built on:

What the app does

The application is a real-estate lead-management agent pipeline. A customer submits an enquiry (“I’m looking for a 3-bedroom house in London under £800,000”), and the system spins up an isolated Copilot Agent on a virtual thread to process it through a pipeline:

The architecture uses Jakarta WebSocket to push real-time status updates from the server to the browser, so you can watch agents progress through phases as the model calls tools:

Submit multiple inquiries simultaneously to see concurrent virtual-thread agents in action. Each one processes independently with its own Copilot session.

SDK features in action

Let’s walk through the key SDK features as they appear in the sample code.

Defining tools with @CopilotTool

This is the headline API. If you’ve ever written a @GET endpoint in JAX-RS or an @MessageDriven bean, this will feel instantly familiar:

@CopilotTool(value = "Sets the current phase of the agent. Use this to report progress.",
             name = "set_current_phase")
public String setCurrentPhase(
        @CopilotToolParam("The phase to transition to (VALIDATING, SEARCHING, "
                + "WRITING_REPORT, REJECTED_GARBAGE, REJECTED_NO_MATCHES, or DONE)")
        String phaseName) {
    phase = Phase.valueOf(phaseName.trim().toUpperCase(Locale.ROOT));
    notifyUi();
    return "Phase set to " + phase.getLabel();
}

The @CopilotTool annotation declares the method as a tool the model can call. The @CopilotToolParam annotation describes each parameter so the model knows what to pass. The SDK handles all the JSON Schema generation, argument parsing, and dispatch. You just write a normal Java method.

Two build prerequisites for @CopilotTool. The annotation-based tool API is currently an experimental feature of the SDK, so you need to configure two things in your Maven build:

1. Enable experimental APIs: pass -Acopilot.experimental.allowed=true to the compiler. Without this flag, the annotation processor will refuse to generate the tool metadata. For more details on the experimental APIs see Copilot SDK documentation.
2. Register the annotation processor: add the SDK as an annotationProcessorPath so the compiler can find the @CopilotTool processor and generate the $$CopilotToolMeta classes at compile time.

Both are configured in the maven-compiler-plugin:

<plugin>
    <groupId>org.apache.maven.plugins</groupId>
    <artifactId>maven-compiler-plugin</artifactId>
    <version>3.15.0</version>
    <configuration>
        <compilerArgs>
            <arg>-Acopilot.experimental.allowed=true</arg>
        </compilerArgs>
        <annotationProcessorPaths>
            <path>
                <groupId>com.github</groupId>
                <artifactId>copilot-sdk-java</artifactId>
                <version>1.0.7-preview.1</version>
            </path>
        </annotationProcessorPaths>
    </configuration>
</plugin>

To register all annotated tools from an object:

List<ToolDefinition> annotatedTools = ToolDefinition.fromObject(this);

Inline lambda tools with ToolDefinition.from(...)

When you want a tool defined at the call site without a dedicated method, use the lambda style:

ToolDefinition reportIntentTool = ToolDefinition
        .from("report_intent",
              "Reports the current intent of the agent",
              Param.of(String.class, "intent", "Intent in max 4 words"),
              (String intent) -> {
                  currentIntent = intent;
                  addEvent(Instant.now(), "intent", "Intent updated", intent);
                  notifyUi();
                  return "ok";
              })
        .overridesBuiltInTool(true);

Notice .overridesBuiltInTool(true). This tells the SDK that our report_intent tool deliberately replaces a built-in tool of the same name. This is useful when you need custom behaviour for a tool the model already knows about.

Cross-class tool scanning

Tools don’t have to live in the same class as your agent logic. Here’s searchProperties defined in a separate CDI bean:

@ApplicationScoped
public class PropertyDatabase {

    @CopilotTool(value = "Searches the real estate listings database. "
                       + "Returns up to 10 matching properties.",
                 name = "search_properties")
    public List<Property> searchProperties(
            @CopilotToolParam("Property type substring (e.g. 'flat', 'house')") String type,
            @CopilotToolParam("City substring (e.g. 'London', 'Bristol')") String city,
            @CopilotToolParam("Minimum number of bedrooms (0 for no minimum)") int minBedrooms,
            @CopilotToolParam("Maximum price in GBP (0 for no maximum)") double maxPriceGbp) {
        // ... filter and return matching properties ...
    }
}

You would normally register these with ToolDefinition.fromObject(propertyDatabase). In the sample app, we use a lambda wrapper instead, because CDI client proxies can obscure the annotation metadata.

Customizing the system message

The SDK gives you fine-grained control over the system message. Use SystemMessageMode.CUSTOMIZE to replace specific sections while preserving the rest:

SystemMessageConfig systemMessage = new SystemMessageConfig()
        .setMode(SystemMessageMode.CUSTOMIZE)
        .setSections(Map.of(SystemMessageSections.IDENTITY,
            new SectionOverride()
                .setAction(SectionOverrideAction.REPLACE)
                .setContent("""
                    You are part of a real estate recommendation system.
                    You will receive enquiries from customers, and you must
                    carry out the following workflow...
                    """)));

The text block ("""...""") makes multi-line prompts readable without string concatenation. The IDENTITY section override replaces only the model’s self-description while leaving safety guardrails intact. If you prefer a simpler approach, SystemMessageMode.APPEND adds your content after the default system message without replacing anything.

The agentic loop: sendAndWait(...)

One line kicks off the full agentic loop:

session = client.createSession(sessionConfig).get();
// ...
AssistantMessageEvent result = session.sendAndWait(escapedEnquiry).get();

Behind .get(), the model reasons, calls your tools (potentially multiple times), and returns its final response. On a virtual thread, .get() is cheap. No platform thread is consumed while waiting. The SDK dispatches tool calls to your registered handlers automatically and feeds results back to the model until it’s done.

Real-time event handling with session.on(...)

Subscribe to session events to build responsive UIs:

sessionSubscription = session.on(event -> {
    captureSessionEvent(event);
    uiUpdateSocket.pushDetailUpdate(id);
});

Every tool call, every result, every assistant message fires an event. The sample app captures these events and pushes them to the browser via Jakarta WebSocket, so the pipeline dashboard updates in real time. You can use pattern matching to handle specific event types:

if (event instanceof AssistantMessageEvent msg) {
    finalReport = msg.getData().content();
} else if (event instanceof ToolExecutionStartEvent start) {
    // Tool is being invoked...
}

Headless client and permission handling

The client is configured for server-side operation:

copilotClient = new CopilotClient(
        new CopilotClientOptions()
                .setMode(CopilotClientMode.EMPTY)
                .setCopilotHome(copilotHome)
                .setExecutor(contextualVirtualThreadExecutor));

CopilotClientMode.EMPTY means no IDE integration — the client talks directly to the Copilot CLI. The custom Executor (discussed below) ensures tool callbacks run with container context.

For permission handling, the sample uses:

sessionConfig.setOnPermissionRequest(PermissionHandler.APPROVE_ALL);

APPROVE_ALL is appropriate for demos and development. In production, implement a real permission policy that validates which tools the model is allowed to invoke.

Jakarta EE integration patterns

The SDK is not a framework island. It composes naturally with Jakarta EE — and of course also with proprietary frameworks such as Spring.

The Executor parameter is the key integration point. Jakarta Concurrency (§5.2 in the 3.1 spec) requires that application-created threads be obtained from a ManagedThreadFactory so the container can:

1. Track the thread for lifecycle shutdown (@PreDestroy / server stop)
2. Apply concurrency constraints and policies
3. Propagate context automatically (without needing manual contextualRunnable)

Open Liberty 26.x supports virtual-thread ManagedThreadFactory via the virtual attribute in server.xml.

<managedThreadFactory jndiName="concurrent/virtualThreadFactory" virtual="true" />

Then, in AppState.java we inject the factory:

@Resource(lookup = "concurrent/virtualThreadFactory")
private ManagedThreadFactory virtualThreadFactory;

And use it to create the Executor we pass to the Copilot SDK.

// The ManagedThreadFactory (virtual=true) creates container-managed virtual
// threads that automatically propagate CDI, JNDI, and transaction context.
Executor managedVirtualExecutor = runnable ->
    virtualThreadFactory.newThread(runnable).start()

String copilotHome = Path.of(System.getProperty("user.home"), ".copilot").toString();
CopilotClientOptions copilotClientOptions = new CopilotClientOptions()
        .setMode(CopilotClientMode.EMPTY)
        .setCopilotHome(copilotHome)
        .setExecutor(managedVirtualExecutor);
copilotClient = new CopilotClient(copilotClientOptions);

This creates virtual threads that carry the container’s context. When the SDK dispatches a tool call to searchProperties(), that method can @Inject a JPA repository and query the database, because the container context is present on the callback thread.

Other integration patterns in the sample:

• CDI @ApplicationScoped for the singleton CopilotClient (one client per application lifecycle).
• Jakarta Faces f:websocket push for real-time browser updates via PushContext.
• Jakarta Data @Repository for type-safe database queries without raw JPA boilerplate.

Fine-grained tool access control with ToolSet. The SessionConfig lets you specify exactly which tools each session can access:

sessionConfig.setAvailableTools(new ToolSet()
        .addCustom("*")           // all registered custom tools
        .addBuiltIn("web_fetch")); // only the web_fetch built-in

This is an important production concern. Rather than exposing every built-in tool (file system access, shell execution, etc.), you explicitly opt in to only what the agent needs. In the sample app, we allow all custom tools plus web_fetch so the agent can look up real-time property information during the Search phase.

Summary

Here’s what we covered:

• Java-native API: CompletableFuture, annotations, lambdas, and virtual threads make the SDK feel like idiomatic Java, not a ported-from-another-language afterthought.
• Three tool-definition styles: annotations for enterprise patterns, lambdas for inline convenience, JSON Schema for full control.
• System message customization: section-level overrides give you precise control over agent behaviour.
• The agentic loop in one line: sendAndWait(...) handles the full tool-calling loop automatically.
• Real-time event streaming: session.on(...) enables responsive UIs and observability.
• Headless server-side operation: no IDE required; runs anywhere the Copilot CLI is available.
• Natural composition with Jakarta EE: CDI, JPA, WebSocket, and virtual threads all work together through the Executor integration point.

What to try next

• Explore the BYOK support. The GitHub Copilot SDK can be used directly against model providers, for example OpenAI, Azure, Anthropic, or OpenAI-compatible endpoints, by passing a provider/ProviderConfig with your own baseUrl + apiKey (or bearer token). No Copilot subscription required.
• Clone the sample app and run it locally. Submit multiple enquiries simultaneously to see virtual threads in action.
• Swap the model. Try session.setModel(...) to experiment with different Copilot models.
• Add your own tool. Define a new @CopilotTool method (a mortgage calculator, a school-district lookup) and watch the agent discover and use it.
• Deploy to Azure. Open Liberty runs great on Azure App Service, AKS, or Azure Container Apps. See the Jakarta EE on Azure guidance at https://aka.ms/java/ee.

The Copilot SDK for Java puts the full power of GitHub Copilot behind your Java code with no IDE required and no framework lock-in.

The post Using the GitHub Copilot SDK for Java appeared first on The GitHub Blog.

There’s been lots of rancor online about whether you should read and review LLM-authored code. I wanted to share a project we’ve been using in production for months where I rarely review any of it: ShellSyntaxTree.

ShellSyntaxTree is a parser that attempts to create AST representations of both bash and PowerShell commands using a shared tree representation and parser abstractions, albeit with slightly different grammars to accommodate the quirks between the scripting languages.

SST is an essential tool for powering one of my other projects: Netclaw - a “claw”-style autonomous AI assistant. We use SST to power Netclaw’s approval system for requesting humans to authorize commands: netclaw.dev/architecture/security-model.

SST isn’t a security tool, but it sits inside a security decision. Netclaw auto-approves commands by matching them against pre-approved patterns - git pull, gh pr view - and SST is the layer that extracts those patterns from the raw command string. Get the parse wrong and Netclaw can auto-approve commands the user hasn’t blessed or prompt for commands the user already has.

The screenshot above is a live example of that: SST parsing echo NO_LOG_FILE for the approval prompt, separating the echo verb from the NO_LOG_FILE input. The challenge we’re always working on is determining parsing rules for safely extracting arbitrary command patterns that can be automatically approved later or in some cases, automatically denied / always prompted / etc.

How can we consistently recognize and distinguish the echo command verb from the NO_LOG_FILE input? That’s the kind of improvement we’re always trying to make to SST.

No Reviews, No Manual Coding

Codex has been running headlessly for about 2.5 days on SST with a goal to improve our existing bash and PowerShell syntax representation to include things like loops, inline variables, heredocs, pipe operators, etc.

I spend a lot of time working on the specifications, mining examples and counter-examples out of Netclaw instance logs, and defining some test infrastructure running large corpuses of commands through SST with their expected parse results.

But I feel free to leave the agents implementing SST unattended and trust them to make good decisions for three reasons:

• SST has really good constraints that make its mission highly focused, even though the range of scenarios it has to cover is unbounded;
• On the spectrum of how “verifiable” a piece of software is, SST sits on the very high end - and it’s partly due to SST’s focus that makes this so; and
• SST has an extremely powerful and fast feedback loop because I also own its primary consumer, Netclaw. Any faults undetected via the original verification system get added back into the suite, making it somewhat antifragile.

LLMs Perform Best on Narrow, Detailed Missions

An essential ingredient for having a project where the LLM can competently implement it with little oversight is narrow focus.

I designed ShellSyntaxTree with an LLM-achievable mission intentionally, by making the following design decisions early:

• It makes zero promises about safety or about what’s in the environment. “What is this command and how is it structured?” is all that SST is designed to do. Netclaw handles the policy layer by gradually accumulating approval data from the human-in-the-loop over time.

• When a command reaches a threshold where it’s too complex to analyze (i.e. relies on external variables, other forms of dynamic execution) it barfs and warns the caller that this can’t be analyzed
• Unified consumer-facing model for both Bash and PowerShell parsing + abstract syntax tree representation but allow different grammars for bash and PowerShell.

This acts both as a conformance mechanism for the LLM to bridge SST’s parsing grammars back into a unified representation but also as a pressure-relief valve in the event that PowerShell / bash / anything else we want to analyze in the future have idiosyncratic differences that can’t be easily modeled using a unified model.

This is important: don’t back the LLM into a corner.

Avoiding the question of “is this command safe to run?” and “how is this command connected to every facet of the runtime environment?” keeps SST’s mission very achievable via static analysis, which is the goal.

We’re not trying to understand what the command does, we’re trying to isolate and determine what are the key commands and how do they work?

Verification, Not Testing

I don’t need to look at most of ShellSyntaxTree’s code because it’s one of the rare projects where it lives in an extremely highly verifiable space.

What’s the difference between verification and testing? Verification tries to be exhaustive by design; testing is meant to be indicative.

We extracted thousands of LLM-invoked commands from Netclaw instances, sanitized and generalized them, and turned that into a training corpus for the original bash parser.

For PowerShell we synthesized the corpus using the same types of use cases modeled in bash originally, but reconstituted as PowerShell invocations. We support both PowerShell Core (7.1+) and the older PowerShell distribution bundled directly into Windows (5.1).

We run thousands of these commands through the AST for both PowerShell and bash and ask “can we accurately detect what this command is trying to do and does it emit the correct-looking AST representation?”

If we find outliers and we make modifications to the parser, the entire back-catalog gets regression tested too. This ensures that there aren’t wide swings in behavior.

ShellSyntaxTree benefits from being cheap to verify - the parser can roll through thousands of these cases in under a minute.

It’s not possible to cover every possible combination of shell commands anyone could ever construct, but that’s not what we’re aiming for: recognizing and parsing allowable patterns in each scripting language is sufficiently ambitious for us.

You can even extend verification to things like the consumer API itself. In the .NET space there’s a number of ways of doing this - over on the Akka.NET project we essentially print the entire public API surface for each runtime we support and then use the Verify library to snapshot-test it: github.com/akkadotnet/akka.net/blob/dev/src/core/Akka.API.Tests/CoreAPISpec.cs

Quick Feedback Loops

Each time we tinker with the ShellSyntaxTree parser, we dogfood pre-release builds of SST back into local builds of Netclaw and measure “what sorts of commands could Netclaw reliably recognize?”

This includes both “things that shouldn’t have been approved” / “things that should have been auto-approved based on prior human approvals.”

We do see regressions; we do see new cases; and we see lots of success with the prior SST improvements that we made.

In any case, we can analyze these failures quickly - a day or two of heavy agentic coding / debugging / research is all it takes to surface some new and interesting patterns. We feed these back into the same process that produces each update of ShellSyntaxTree and it gets more and more robust each time.

This is an antifragile, rapid development process that helps keep Netclaw’s policy layer and SST’s syntactic analysis layer more robust.

Should You Be Reviewing LLM-Authored Code?

ShellSyntaxTree is a great example of a project that would not exist if I had to read the code. Yes, I have written an AST parser / lexer / interpreter by hand before and I really enjoyed it - but:

• My understanding of the extent and full syntax of bash or PowerShell is not nearly comprehensive enough to model it exhaustively and I have NO INTEREST in learning it.
• I would never have had the time or interest to implement this by hand were it not for LLMs implementing it for me.

This is not a toy application. Netclaw has thousands of active installations that all depend on SST. I apply the requisite level of quality control to ensure that SST produces robust and complete analysis of shell commands to the extent that is feasible within SST’s constraints.

Me reviewing AST parsing and testing code would add approximately zero value to SST. What I do look at, are the following two things:

• Does the consumer guide for SST make sense / are the ASTs ergonomic enough that an external consumer could actually make use of them? This is a “developer experience” exercise, not quality assurance.
• Is SST working within its constraints? Is Netclaw asking me to approve things that should already be approved because it can’t understand the command syntax?

This is product management, not software development. And this presents a really exciting frontier for software developers - the ability to escape “output volume constraints” that were previously limited by our time, attention, and typing speed.

But to answer the broader question: you should definitely be reading most LLM-authored code in order to understand what it does.

SST’s mission is simple and I understand what it does, but I’m not going to treat reviewing its internal plumbing like looking at a regular expression - yeah, I kind of get it, but I would never intentionally sit here and practice getting good at writing them by hand.

Writing end-user applications is a different animal: you have user data, secrets, connections to external and internal systems, and lots of other auxiliary concerns that are difficult to verify affordably.

SST is the rare exception to a lot of these rules, but the three lessons I spelled out above (narrow focus + constraints, inexpensive to verify, fast feedback loops) are what make “fully unattended coding” possible - and unfortunately, at least for now, that doesn’t apply to the vast majority of software projects.

Two parting thoughts I’ll leave you with:

• Verifying your software might be easier than you think - you’ll never know until you try. You don’t have to go full TLA+ right away, but maybe something simpler like property-based testing or writing simple verification programs (“make sure all links on our web app and transactional emails aren’t broken for authenticated users” - you can 100% make this verifiable). The more you can verify, the less risk you need to take on personally as a reviewer.
• You should still be reading what LLMs can produce, because there are important things that fall outside of the verifiable space. Does the DX make sense? Is the UI easy to follow? How easy is it to access this popular piece of functionality inside our application? This is not the same as code review - this is that “product manager”-type work I described earlier. This is still absolutely crucial for humans to do.

You can rage online at how the software industry is changing and how we’re all going to hell if we don’t keep LGTM-ing code, but the sensible goal is to need as little human code review as possible, preferably none.

SST is the rare project where this is possible to a large extent today. Having more intelligent, capable large language models helps - having robust verification systems and fast feedback loops is better.

This story originally appeared in The Algorithm, our weekly newsletter on AI. To get stories like this in your inbox first, sign up here.

Last week, I headed 30 miles south of San Francisco to a hotel in Mountain View, California, to join some of the most accomplished, and some of the most promising, AI researchers in the world. I was hosting roundtable interviews and speaking at a media training for a convening of the Schmidt Sciences AI2050 program, an initiative funded by Eric and Wendy Schmidt that supports academics whose work involves AI. The fellows list is a who’s who of AI luminaries, and though not all of them made it out to the Bay, every time I turned a corner I saw a scientist whom I’d interviewed previously or whose research I admired. (Full disclosure: I received a science communication award funded by Schmidt Sciences in 2024.) 

It’s a weird time for university AI researchers, who make up most of the AI2050 group. In the past four years, AI research has reoriented around large language models, and its cutting edge has moved from academic institutions to private companies. Universities simply can’t afford the GPUs required to train and run frontier models, and even if they could, Anthropic and OpenAI aren’t letting anyone else see the inner details of Claude or ChatGPT.

In a conversation over lunch, Nika Haghtalab, a computer science professor at UC Berkeley, said that being an AI academic these days was like being a biologist in a world in which private companies had exclusive control over the gene-editing tool CRISPR. Experts outside the frontier labs can study how ChatGPT and Claude behave, but they can’t do any detailed research on the design and training of those tools, nor can they steer that design or training themselves.

 The AI2050 program does offer fellows some funding that they can use to buy GPUs, which some researchers I spoke with said was a major benefit of participating in the program. But money remains a pressing concern, especially given the reduction of federal scientific funding in the United States. Even for researchers who don’t run local models themselves, the cost of repeatedly querying OpenAI’s, Anthropic’s, and Google’s models in order to study them rigorously can be prohibitive.

Rather than focusing on advancing capabilities, many fellows aim their attention at questions that are unlikely to be addressed by Anthropic or OpenAI. “I try not to work on problems that I think are gonna be solved by a tech company,” says Anjalie Field, a computer science professor at Johns Hopkins. Companies need to make money, and research questions that have little promise of profit might not be worth investing in—especially if their answers might make the companies look bad. Recently, for example, Field conducted a study in which she found that language models give less sophisticated responses to prompts that are phrased in ways more commonly used by women than by men. It’s difficult to imagine that kind of research coming out of Anthropic or OpenAI.

There’s also a huge group of AI academics who don’t work with LLMs at all. Many of them are scientists who build specialized AI models that can analyze data, make useful predictions, or even simulate entire physical systems. Those researchers aren’t necessarily competing with the frontier labs—Google DeepMind’s AlphaFold team, which built a Nobel Prize–winning model that predicts the structures of proteins, was disbanded last month. But they face plenty of their own challenges. At the convening, several voiced concerns about how the widespread ignorance of non-LLM AI was affecting their work. Researchers who build specialized AI tools to help address climate change, for example, sometimes struggle to advocate for their work when so many people believe that “AI” means “energy-guzzling LLMs.”

All these challenges are changing the landscape of academia: Several prominent academics have recently taken leave from their universities to join frontier labs, and many AI2050 fellows hold industry positions alongside their academic jobs. And in the past six months, yet another threat has emerged. OpenAI’s models have solved a number of real research problems in mathematics, and some experts are worried that humans might not have a future in pure math. One fellow I spoke with said that she was concerned about the mental health of her mathematician peers.

But it’s not all doom and gloom. For one thing, empirical science may prove much more difficult to automate than mathematics, because collecting data is an intrinsically slow process. And some researchers see AI mathematicians and scientists as a boon rather than a threat—including Tim Dettmers, a computer scientist at Carnegie Mellon who works to make AI models faster and cheaper to run. AI scientists won’t replace humans, Dettmers says. On the contrary, they could make human scientists far more efficient, so that he and his peers have the chance to pursue all the wild and inspired ideas they might otherwise never have gotten around to.

And scientists are a resilient sort. The very resource constraints that prevent them from training frontier models also push them to discover new ways to make models smaller and more efficient, or to explore completely new architectures. If the next big AI breakthrough comes not from a major company but from a scrappy academic lab, I won’t be shocked.

Bluesky has added a new feature that lets you hide reposts from a specific person in your feeds. The tool might be helpful if you want to stop seeing reposts from that one person who clogs up your feed with reposts of things you don't care about. If you follow me, I may be that person, I'm sorry. I try not to be.

You can hide reposts from individual users by going to their profile, clicking the three dots button, and selecting the option to "Hide reposts in feeds." (X offers a similar toggle.)

Bluesky also says that it's launching a beta feature that will automatically add post numbers to threads. For long threads, it could be a useful w …

Read the full story at The Verge.