Working with AI, with your eyes open.

We help you understand those choices alongside the technology: what it can do, where it needs supervision, and whether it belongs in the work at all.

Start with the thing you are actually using

AI is a broad label. A language model, an image generator, a fraud-detection model and a piece of software that calls several tools are different things. It helps to name the system before deciding what to expect from it.

A language model is trained to model patterns in sequences of language. Modern transformer architectures use attention to relate parts of a sequence, and additional training can shape how a model responds to instructions. Training on feedback is a separate step from making the original model larger. [1, 2]

The model is also only part of an application. The surrounding software may supply documents, choose tools, enforce permissions, route requests and decide what actions are permitted. Those are engineering decisions, and they belong in the explanation a client receives. This is how we frame a project in practice; AI applications vary a great deal in how they are put together.

Prediction is worth taking seriously

In *The World in the Words*, Mike develops an argument about the depth of information contained in language and what a model might learn by predicting it. The essay uses the image of a cartographer learning a landscape from descriptions. It is an authored argument about language and intelligence. It makes no promise that any particular answer is correct.

There is research relevant to the question. In a controlled Othello sequence-modeling experiment, researchers found an internal representation of board state. That finding is about a specific synthetic task, and it does not establish that every language model has an accurate general model of reality. [3]

Interpretability work also investigates mechanisms inside deployed language models. Anthropic's 2025 account reports selected examples of planning, conceptual representations and reasoning failures, and describes limits to what its methods can reveal. Useful capability and incomplete understanding can coexist. [4]

We want to remain curious about the mechanisms and precise about what a particular system has demonstrated. Either way, the thing we intend to build still has to be tested.

Decide what happens when it is wrong

For a project, we would make the task and its consequences explicit. A draft a person will review needs different boundaries from an action that changes customer records. We would agree what should be checked, who can reject the result and how the ordinary work continues when the tool is not useful.

That might involve a small evaluation set from representative work, an approval step, a restricted set of available actions or a non-AI fallback. These are design choices to investigate once we understand the business; we don't promise a fixed architecture before then.

A useful review also considers the effort of checking, correcting and maintaining the output. A faster first draft is one outcome among several that matter.

The people are part of the design

Our training work helps people develop a usable way of working. We don't pressure anyone to sound enthusiastic. We can combine education with practical changes to tools, development environments and workflows.

We would ask what employees are gaining, what they are giving up, how their responsibilities change and whether they can question the system. We would also ask who benefits outside the immediate team, who bears a mistake and what knowledge the organization needs to retain.

Those questions do not settle every ethical disagreement. They make it possible to discuss the actual choice, rather than attaching "ethical" to the product as a reassurance.

Information, creative work and wider costs

A project should have a clear account of what information it uses, where that information goes and who is allowed to access it. Creative ownership, licensing, attribution, supplier dependence and resource use can also matter. We help bring those questions into the requirements and involve relevant specialists where the decision needs expertise beyond our role.

We do not offer a universal moral certificate, and convenience doesn't make a tool harmless. We can help compare approaches and describe the trade-offs without reducing every consideration to the purchase price.

Leaving generative AI out is an available choice

We can build software without generative AI in its operation, including discussing on-premises deployment where it fits the requirements. Restrictions on using AI during development are separate and affect the estimate. We will clarify both before agreeing on the work.

The appropriate result may be a bounded use of AI, conventional software, a workflow change or a decision to leave a process alone. Understanding the situation comes before choosing the technology.

Talk it through

You do not need a settled position on AI to have a useful conversation. Bring the task, the questions and the parts you are uncomfortable with. We can work through them together.

Sources

1. Vaswani et al., *Attention Is All You Need* (2017).
2. Ouyang et al., *Training language models to follow instructions with human feedback* (2022).
3. Li et al., *Emergent World Representations: Exploring a Sequence Model Trained on a Synthetic Task* (2022; revised 2024).
4. Anthropic, *Tracing the thoughts of a large language model* (2025).