AI and Software Engineering at HIT Strategies
How we approach AI tooling, risk, and engineering accountability
This is the first of a two-part series on the topic of AI. Here, we focus on how AI shows up in our engineering process, such as the way we build and maintain the internal tools our research team relies on. The harder, more consequential question which is whether and how AI should touch the research itself will be the subject of our next post.
Artificial Intelligence (AI) is becoming increasingly integral to how research firms operate. At HIT Strategies, we think clients, our peers, and prospective partners deserve a clear account of how we actually use these tools and where they show up in our work.
A Quick Vocabulary Breakdown
“AI” has become a catch-all term that often obscures more than it clarifies. It’s worth drawing a few distinctions up front. To note, these categories are not airtight, they overlap in practice, and many products combine several approaches. The technology is also evolving faster than the vocabulary used to describe it, so any taxonomy is essentially a snapshot. Still, at a broad level, we can distinguish a few major categories and concepts.
Large Language Models (LLMs): These are the underlying technology and are systems trained on enormous text corpora to generate and work with language. Modern systems are not strictly limited to text and can also process and generate images, audio, and video. You’ll increasingly see practitioners use terms like “foundation models” or “multimodal models” to capture this broader capability, though “LLM” remains the most common shorthand. Current examples include Anthropic’s Claude Opus 4.7, OpenAI’s GPT-5.5, Google’s Gemini 3.1 Pro, and Meta’s Llama family.
Chatbots and Consumer Assistants: These are the products most people picture when they hear “AI” as it relates to tools like ChatGPT, Claude, and Gemini. They wrap one or more LLMs in a conversational interface where users type prompts and receive responses. The same underlying model may power multiple products, and a single product may switch between different models depending on the task or request.
Coding Assistants: These are LLMs embedded directly into software development environments. They suggest code, explain unfamiliar functions, and help engineers work more efficiently. Modern tools increasingly blur into more autonomous territory: carrying out multi-step changes, navigating different parts of a codebase, and iterating toward a working result with much less back-and-forth prompting. But still, they remain tightly scoped. The engineer initiates the work, reviews the output, and decides what is ultimately accepted. This is the category of AI I use daily as a software engineer at HIT Strategies.
Agentic Systems: Larger AI configurations that pursue a defined objective through multi-step actions: planning, executing tasks, making decisions, and using tools with reduced human oversight at each step. Rather than producing a single response to a prompt, these systems operate more like automated workflows where they plan steps, take actions, incorporate feedback, and adjust their approach along the way.
For example, an agent might analyze a dataset end-to-end—selecting transformations, generating outputs, and iterating on its own results—or make coordinated changes across different parts of a system. Because these systems act across multiple steps without continuous human review, errors can compound and decisions become harder to trace, resulting in a more complex and layered risk profile. In practice, the boundary between these concepts is not fixed. Coding assistants are gaining more autonomy, and consumer tools increasingly incorporate similar multi-step capabilities. But the distinction remains useful for conversation. The answer to “do you use AI?” depends entirely on which of these systems are being referenced. A coding assistant helping a developer write a database query is a very different proposition from an agentic system independently analyzing survey responses. Conflating them makes it difficult to have a serious conversation about risk.
The Concerns We Take Seriously
Before describing what we do, it’s worth being direct about what we’re weighing up against when using AI tools.
The frontier of AI development is dominated by a small number of well-capitalized firms, and that concentration of capability raises real questions about market power and accountability. LLMs inherit patterns from the data they’re trained on, and without proper vetting and care, those patterns can be presented with a veneer of objectivity. This includes political and racial biases that shape which communication styles and cultural norms are treated as “professional” or “authoritative” standards. Those standards can often reflect historically white institutional expectations rather than genuinely neutral criteria or responses. Separately, the compute infrastructure required to train and run these systems carries real environmental costs. And the question of how training data was gathered—what was taken from the public web, from whom, and with what consent—remains concerningly unresolved. In many ways, this is a familiar problem: technological innovation outpacing policy and regulation.
These concerns are not abstract, and they shape how we approach this technology. At the same time, opting out entirely isn’t a viable posture for a research firm in 2026. Public interest research is structurally underfunded relative to commercial market research. Cost has always been the gatekeeper that determines which communities get studied, which questions get asked, and whose voices get amplified. Tools that meaningfully lower that cost without compromising rigor are worth taking seriously, especially for the kinds of organizations and candidates we serve. The question, then, is how to engage with these tools thoughtfully, with clear boundaries.
How We Actually Use AI in Software Engineering
AI-assisted coding is now commonly leveraged across most industries. If you’ve used a software product built or updated in the last two years, an AI assistant likely helped write it. Within engineering, this is no longer controversial; it’s simply where the field is as it adopts useful advancements.
Our trajectory has tracked the broader public opinion industry. We started with GitHub Copilot when it was one of the first widely adopted coding assistants. We then moved to Cursor as the tooling matured and developed. And for the past six to eight months, our primary tool has been Anthropic’s Claude Code. We continue to experiment with OpenAI’s Codex and Google’s Gemini CLI, and other tools as they evolve.
What does AI-assisted engineering with coding assistants actually look like in practice?
An engineer describes a goal—this might be a new function, a bug fix, a change to existing behavior, or a larger update spanning multiple parts of a system. The assistant proposes an approach, generates code, and can carry out multi-step changes across the codebase, iterating toward a working result. It’s also useful earlier in the process for sketching architectures, exploring tradeoffs, and helping break problems down.
In this model, the role of the engineer shifts toward conductor and operator. Rather than working line by line, the engineer sets direction, evaluates outputs, and decides where to go deeper. Some changes are reviewed in detail; others are accepted more quickly when they are well scoped and low risk. The responsibility becomes less about writing every line and more about containing complexity, ensuring the system behaves as intended so that the pieces fit together, and the right boundaries are in place. I sometimes joke that my job now involves babysitting robots all day. It’s more fun than it sounds, I promise. More importantly, no code ships without human judgment, though that judgment increasingly operates at multiple levels of abstraction. These coding assistants significantly accelerate routine work and take on the more tedious aspects of writing code. However, they do not replace judgment about architecture, design, or what to build in the first place—arguably the most creative and consequential parts of software engineering.
At HIT Strategies, AI-assisted engineering helps us build and maintain our internal research tools. That does not mean an AI system is independently operating on respondent data, making analytical decisions, or generating findings. Where AI-generated code is used in research systems, it becomes part of software that we design, own, review, test, and govern.
Those tools themselves are fairly conventional in structure: web-based interfaces and backend pipelines that support the core work of research. They help our team draft questionnaires, process and structure incoming data, and produce the reports and deliverables our clients ultimately see. AI can assist in building and improving these systems, but it is not a substitute for the methodological judgment or oversight that defines the research process.
The Principles Guiding Our Approach
Here are a few things we hold to when engaging with AI tools:
Tool-agnostic. We are not tied to any single company or vendor. We’ve changed primary tools more than once as the landscape has evolved, and we expect to continue reevaluating capabilities, needs, and constraints. We actively monitor alternatives to ensure what we’re using remains the right fit for our work and our principles.
Honest cost–value assessment. We are spending both our clients’ money and our own. Tools that aren’t earning their keep are phased out quickly.
Human oversight at the point of integration. AI-generated code is not treated as self-validating. Engineers are responsible for evaluating outputs, testing behavior, and deciding what is safe to incorporate. The level of review varies with the scope and risk of the change, but accountability remains with the engineer.
There is a hard separation between engineering and research. AI assists in how we build tools, but it does not independently conduct research (e.g., survey design), make analytical decisions (e.g., analyses), or generate findings (e.g., insights or recommendations). The boundary between engineering assistance and research methodology is deliberate.
What’s Next for Us
Engineering is the easier case. The harder question—and the one with much higher stakes—is whether and how AI should be used in the research process itself—specifically in making sense of data, creating meaning, and interpreting results. That is where the potential is significant, but so are the risks. Applying these tools at that level raises fundamental questions about judgment, accountability, and where human expertise must remain central. We’re approaching those questions deliberately defining boundaries, testing ideas, and learning from early exploration. We’ll share more as that thinking evolves.
 | A guest post by
|