LLMs are an extremely useful tool! We need look no further than the recent results on LLM assisted counterexample discovery (for e.g., the Jacobian conjecture) to disprove decades old questions in mathematical research. It should not be surprising that LLMs are useful for this purpose! It is possible (although not likely) that someone in some corner of the internet produced such counterexamples and never publicized them. So this could be a regurgitation. It is far more likely however that LLMs are simply capable of distilling our conceptual understanding and filling in gaps. 

In my day job, I have been making various use of LLMs for code generation, to assist in making connections between disparate ideas in math and engineering, and to do parts of my job I simply find tedious. In short I believe they have made me a more effective researcher and engineer. 

Should engineers become more concerned for their jobs? I would say no, but we should expect our roles to continue to change and adapt to new tools as they always have. To that end I have compiled a few of my thoughts on how a research engineer can use LLMs as a force multiplier and avoid becoming trapped by the appearance of productivity. 

LLM Assisted Productivity. It should be clear to anyone who has spent time using LLMs that they are often over-confident. This make it very easy to take their outputs as ground truth. The key mistake to avoid is trying to convince an LLM to fix a mistake that is already in the context window. This often leads to a cycle of the LLM claiming that it finally understands the issue and that it has been fixed once and for all. The easiest way out of this loop is to ditch your current context window. Once the LLM has reasoned itself into a corner, it will tend to have difficulty finding its way out. If you clear the context, the mistake is gone and you can start fresh. 

Keeping an eye on the prize. The ultimate goal in conducting research is to identify a useful question and answer it completely in a way that an audience familiar with the material can follow and ideally agree with. LLMs can be used at several points in this process, but there are several places that they should only be used with great care. Below are several areas the researcher should avoid overusing LLMs. 

• Problem statement identification requires close communication with stakeholders to understand the challenge and to capture the shape of the problem. Even well thought out attempts to generate novel problem statements with LLMs will likely fail due to identification of problem areas about which no one cares. 

• Market data should always be collected via statistically valid means. I've already seen several instances of engineers gathering "market research data" by querying LLMs on e.g. user opinions. LLMs are not (yet) your users! They can only vomit up opinions expressed by people or bots on the internet. They cannot represent the complexity of a user base encountering a new feature. 

Obviously, I also think there are areas where LLM assistance can make you much, much more productive. Broadly, any discrete well-formed problem is probably well suited to LLM assistance. Typical examples include:

• "please identify the atomic functionality in this codebase and generate unit tests"

• Code review (so long as there is enough .md content to describe your org's standards and practices),

• Identifying trig identities or other mathematical objects I don't want to Google 

• Gathering initial references in a literature review. Caution here is required; LLMs have improved, but will still make up references. Actually digesting the work is probably still part of your job. 

This is a web version of my Wireless @ VT Seminar talk from 2023. 

All resources in nature are limited, with constraints on electromagnetic spectrum only increasing. radar networks must consider how best to efficiently use this constrained resource. Since multiple radar devices may obtain duplicate or similar information on targets, how do they decide when to transmit updates? 

This work represents the first thrust applying Age of Information metrics to cognitive radar networks. 

My first major research thrust has been in the area of decentralized machine learning techniques, applied to networked cognitive radars. Breaking this down by term: 

• Decentralized implies that all learning is occurring within each entity. This contrasts with the centralized variant, where some central coordinator is in charge of the entire group. 

• Machine Learning is the name given to programming techniques that allow a computer to learn some aspect of a task or environment. ML is a very broad field. I have worked specifically in reinforcement learning which attempts to 

• Radars are systems that use reflected RF energy to track objects. 

• Cognitive radars establish some feedback cycle with their environment to modify their parameters and better track objects. 

• Networked cognitive radars use multiple cognitive radar devices spread throughout an area to take advantage of multiple perspectives of an object, with the goal of improving tracking.