When we use LLMs in a specialized domain, such as the operations of any reasonably-large organization, there is a lot of specialized vocabulary. Such words and specialized meanings will be foreign to an LLM because they aren't in its training set, making it harder for the LLM to be effective when doing tasks in that domain. One technique to aid this is to use an LLM to generate a glossary of the terminology in that domain, and make this glossary available for any LLMs doing work in those circumstances.

The sources for the LLM can be any material within the organization concerned such as documents, emails, and chat logs. In some cases getting transcripts of audio or video may be helpful, although most organizations generate enough text to do the job.

The glossary-generating LLM should look for single words, and phrases of several words that regularly hang out together to form a meaningful term. The generator should be asked to identify terms that are new to it, but also known terms that are being used in unfamiliar ways. The latter can often cause the most confusion.

Once we have a list of specialized vocabulary we can ask the agent to produce a glossary, with definitions for each term. Some terms may be used in different ways, in which case the LLM should provide alternative definitions, with a note as to what context the differences appear in. The LLM can be asked to follow the output format of a dictionary, with a focus on precision and conciseness.

Once we have a draft glossary, then human experts in that domain should review it, and amend it for cases where the LLM has got the wrong ends of sticks.

We then put the glossary somewhere where any other LLM can use it. It should be in a form that's easy for the LLM to consult, and minimize the tokens the LLM should consume in order to find meaning. We should set up a schedule to review and refresh the glossary at regular intervals, by agents and humans. We should keep it in version control, so we can see how it changes over time.

Large organizations often have subtly different definitions in different places, essentially following the Domain Driven Design notion of Bounded Context. Source code can be a particularly interesting bounded context, allowing folks to understand how terminology is used within a code base. Sometimes a single glossary can span several of bounded contexts, but at other times it's better to have separate glossaries for each one, allowing LLMs to consult whichever glossaries that are relevant to what they are doing. I'd urge everyone to resist any temptation to create a single, standard, glossary - I've yet to see that work. Often the value of a glossary isn't to nail down a single definition of a term, but instead to highlight its different usage in different contexts.

When there are different bounded contexts it can be interesting to compare different glossaries, or to get LLMs to compare glossaries and describe differences in usage. Comparing a source-code derived glossary to a human text can be particularly instructive.

If the glossary is large, it can be worthwhile to only include the terms and links to definitions as part of the initial context. The model can then use the links for only the full definitions it needs while working.

A glossary can be used in several ways within Agentic Engineering. Glossaries can inform generation of code, so that names within the generated software fit the particular vocabulary of the enterprise. Sensors in a harness can check for this usage, both in the internals of the software and in the user-interface.

When generating code or documents, we may introduce new bounded contexts. For example, internal names that may be used within an organization should not be exposed in a customer-facing UI, because such internal terms are likely to be only confuse a customer. In this case a customer has a different bounded context to the part of the enterprise serving them.

It's often useful for glossaries to include terms that should not be used, in which case it includes advice on what other term to use instead. Terms that are deprecated can be handled in this way, with glossary entries that indicate what period of time a term should be in effect.

In my conversations with people working with agents in large organizations, a common theme is the difficulty of specialized language. This encourages the activities of domain modeling, building ontologies, and constructing explicit context layers in enterprise data. Getting LLMs to generate a glossary is a simple, but useful, part of this work.

Sometimes when I read a post, I get the growing feeling that I'm reading the output of an LLM. I can't necessarily define why, although there are the common tells (it's not the em-dashes, it's the load-bearing tapestries). As I do this my desire to read on atrophies, sometimes to the point of revulsion

There are tools out there that claim to be able to tell the difference between LLM-written prose and the old-fashioned biological product. I'm wary of them, partly due skeptism about their accuracy, but also because it rather misses the point. The reaction to LLM-Voice is a human one, that sense that we are in an uncanny valley of prose. By the time I'd reach for a tool to tell me what I'm reading, it's already too late, even if it confidently tells me there's no LLM present.

I'm also suspicious of my own ability to accurately recognize LLM voice. Language changes over time, so a common sign of age is complaining about the language of the youngs. I'm inclined to bristle at prose that talks about “adopting a new sales motion,” or “a sharp round-up of news”. But I've heard these constructs coming out of human mouths, so that's more a generational difference rather than between carbon and silicon. (And as a transplanted Brit, don't get me started on Americanisms, I'm sure I'll get used to them momentarily.)

Right now I urge authors to be extra-wary of LLM-Voice. In particular I strongly recommend that authors should not fall into the trap of getting the LLM to write a draft. Even if it's edited by a human, it's very hard to expel the LLM-Voice - thus causing the uncanny valley reaction. 1 Even accepting suggestions of rephrasing is dangerous. I have heard of people using LLMs to develop outline and structure, that may be ok, but only as far as an outline. 2 Authors should fill the prose themselves.

Say Your Writing is even more important in the age of LLMs. I habitually speak the words in my head and then write them down (and then edit what I've just written). This advice is particularly important to anyone who has any desire to communicate regularly with writing. Like many things, learning to be a good writer relies on lots of practice. It's a skill worth the time to acquire, but surrendering to an LLM will undermine any progress.

In time it may be that LLMs will be so good that we can't tell the difference. In many ways, that's more worrying. Like most writers, I find writing an almost-essential tool for thinking. Often it's only by writing something down, that I can really get my thoughts on a topic into coherence. I've often started an essay knowing I don't really understand something, but the act of wrestling with the words forces me to overcome my confusions. As more people delegate writing to LLMs they will also delegate thinking and comprehension to LLMs. I don't want to do that, where's the fun of writing then?

Although avoiding LLM-Voice is a general rule, it isn't an absolute one. An important example is that of Jim Highsmith (who contributes to this site). He finds working with an LLM is essential to his writing to overcome the bane of Parkinson's disease. I'll gladly deal with LLM-Voice in order to continue imbibing my old friend's wisdom.

A more awkward case is that of translation. Many of my colleagues aren't comfortable in English, it is their second or fourth language. Some have found LLM translation an important part to their communication with those of us who know rather less Marathi. But I also would prefer rather a genuine human's clunky prose to the smooth but soulless LLM.

There are situations where it would be reasonable for even a native Englishman to let LLMs write the prose. Such as if I'm writing a form letter to an official, or preparing a report I suspect no-one will ever read 3. Maybe most documentation in the future will only be read by LLMs, and they won't have my uncanny valley worries. But if I want to communicate with humans, my humanity has to shine (or at least ooze) out of my prose.

A Sensible Default is a practice that, absent some overriding context, should be used when carrying out a certain kind of task. In software development such sensible defaults might include things like “use version control”, “separate UI logic from domain logic”, “automate deployment pipelines”.

The term “sensible default” is a deliberate contrast to “best practice”. Folks dislike calling things “best practice” because that term implies a general presumption that the best practice is something we should always expect to do. A “sensible default”, however, is something that should be reassessed in a new context, something that can (and should) be overridden when circumstances change.

I first heard the term when it was popularized within Thoughtworks by Evan Bottcher. He got the name from talking to James Ross, and found the phrasing appealing as carried the nuance he was seeking, a known-good starting point.

A sensible default is what we'd expect you to do, the practices to apply, if there are no hard constraints in the environment. Do these practices, or do better, and be prepared to explain why you've chosen some other way.

-- Evan Bottcher

Thoughtworks has since made much of this concept, including publishing a playbook of the ones we use. We expect people to be familiar with these defaults, ready to use them when starting any new piece of work. They are our defaults because we've used them in many situations and found them to be effective. But teams should also be familiar with their limitations, and able to judge whether they should be changed depending on the particular circumstances. As the twelfth agile principle says: “At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” We also reassess these defaults regularly - this is the heart of the Thoughtworks Technology Radar.

Searching on the web led me to a post from Steve Bennett on Sensible Defaults. The post was written at about the time Evan talked to James. I do not know whether it was where James got the name from, or whether it appeared in parallel.

The difference between a medicine and a poison is dosage.

Often we talk about certain habits, in programming or life, are good or bad. But few things are simple binaries. Some vary with context: reading a book is a good thing sitting in my garden, but not while driving my car. But another variable is dosage: a little pain-killer salves my headache, but too much will kill me.

The importance of dosage was noticed by a 16th century Swiss physician called Paracelsus. His quote was originally in German “Alle Dinge sind Gift, und nichts ist ohne Gift; allein die Dosis macht, dass ein Ding kein Gift ist.” which (according to Wikipedia) translates as “All things are poison, and nothing is without poison; the dosage alone makes it so a thing is not a poison.” It's also known as “The dose makes the poison” or if you prefer your sayings in Latin “dosis sola facit venenum”.

In programming, global data is a good example of the Paracelsus Maxim (as I like to call it). A little global data, especially when immutable, can be a handy way of propagating information that may needed anywhere in a program, but it quickly becomes dangerous if there is a lot of it about.

This kind of thing crops up in lots of places. So when thinking about when things are good or bad, we should always ask “in what contexts” and “in what doses”?

Vibe coding is building a software application by prompting an LLM, telling it what to build, trying it out, prompting for changes - but without looking at any of the code that the LLM generates. This technique can be used by people without any knowledge of programming. However the resulting software often shows problems with maintainability, correctness, and security - so is best used for disposable software written for a limited audience.

The term was coined in February 2025 by Andrej Karpathy, an experienced programmer, in a post on X:

There's a new kind of coding I call “vibe coding”, where you fully give in to the vibes, embrace exponentials, and forget that the code even exists. It's possible because the LLMs (e.g. Cursor Composer w Sonnet) are getting too good. Also I just talk to Composer with SuperWhisper so I barely even touch the keyboard. I ask for the dumbest things like “decrease the padding on the sidebar by half” because I'm too lazy to find it. I “Accept All” always, I don't read the diffs anymore. When I get error messages I just copy paste them in with no comment, usually that fixes it. The code grows beyond my usual comprehension, I'd have to really read through it for a while. Sometimes the LLMs can't fix a bug so I just work around it or ask for random changes until it goes away. It's not too bad for throwaway weekend projects, but still quite amusing. I'm building a project or webapp, but it's not really coding - I just see stuff, say stuff, run stuff, and copy paste stuff, and it mostly works.

-- Andrej Karpathy

The key point about vibe coding is “forget that the code even exists”. This is what gives it much of its usefulness, but also its limitations.

Since the November Inflection many programmers are getting LLMs to write all their code, commenting that they may never write a line of code directly again. However they do care about this code, reviewing it, paying attention to its internal structure. In that case, they aren't forgetting the code exists, so it's really a different thing that I call Agentic Engineering. Sadly the term “vibe coding” really caught on, so many people use it to mean agentic engineering. However I feel that despite this rapid Semantic Diffusion, it's worth trying to keep the concepts of vibe coding and agentic engineering separate, as they are both different to use and different in their consequences.

Because a vibe coder doesn't look at the code, they don't need programming skills, so it's perfect for someone with no programming knowledge to build applications for their own use. Experienced programmers may also find it handy for rapid development of disposable software or prototypes.

Vibe coding is still new, so we are exploring its limitations, and those limitations change as the sophistication of models and their harnesses change. These limitations do introduce considerable risks, particularly if the vibed software is used widely or has access to sensitive information.

Perhaps the most serious risk is that of security. LLMs are inherently vulnerable as they provide a large attack surface for predators. Vibe coded applications can often expose sensitive information or worse, credentials to attack deeper into an organization's systems. Even non-programmers need to be aware of the Lethal Trifecta.

With little attention to the code, vibed software can rapidly produce many lines of code of a very low quality. Such code makes it difficult, even for an LLM, to modify and enhance the software in the future. While it's possible that growing LLM capabilities will allow it to work with even the largest bowls of spaghetti software, thus far it seems clear that well-structured software makes life easier for LLMs too.

LLMs are famous for habit of hallucinating incorrect facts and presenting these with great confidence. This habit also leads them to create software that behaves incorrectly - and those errors may not be manifest to the user. Furthermore the non-determinism of LLMs means that it's likely that asking an LLM to enhance some software could easily lead it to introduce errors, even in parts of the code that shouldn't change due to the new request. We should thus treat LLM-generated software with skepticism, it can still be useful, but we need to be aware of the risks.

On the whole vibe coding software is best used for disposable software that's only used by its author or a close group of collaborators who understand and accept the risks involved. Code that is more complex, more widely-used, and with more consequences to its risks should not be forgotten about.

When we need an LLM to perform a complex task, we often need to feed it a lot of context. Coming up with a design for a new feature requires descriptions of how we want the feature to appear to the user, guidelines on how it should be implemented, information on external systems to consult, and so on. All this can be several pages of markdown. The obvious way to do this is for a human to write this context, but an alternative is to use an LLM to write this context after interviewing a human.

The way I can do this is to prompt the LLM to interrogate me. It should ask me all the questions it needs to create this appropriate context. I can feed much of the information it needs, and tell it other sources it needs to consult if it can't figure those out itself. Once it's done, it can then create the context report for another session (perhaps with another model) to carry out the next step.

I first saw a decent description of this approach in Harper Reed's blog. A striking element of his approach is insisting that the LLM ask only one question at a time. (When I tried it, I found it needed to be frequently reminded of this.)

Another way to use an interrogatory LLM is to give it a document, such as a software specification, that captures knowledge about a domain - and then ask the LLM to interview a human expert to determine if the document is accurate. This is an alternative to getting the human expert to read the document to review it. People often find reviewing hard, so a conversation with an LLM might be more fruitful, particularly if the document isn't well-written.

Naturally we can use both of these, using one interrogatory LLM to build a document, then using other interrogatory LLMs to review it with other experts.

The above is getting an LLM to create or assess context for a particular use of an LLM. But the technique is more broadly applicable. I've become a natural writer, someone who finds the process of writing an essential part of thinking. To really understand something, I need to write about it. But different people are different. Many folks find writing hard, often very hard. This can be a real problem when we need to get information out of someone's head into a form that other humans can consume. Maybe such people would find it easier to ask an LLM to interview them than to write a document themselves. Certainly the result will have that tang of AI-writing that folks like me shudder at - but that's better than not having the information itself, either due to rushed writing or no writing at all.

In the early 1960s, Fred Brooks managed the development of IBM's System/360 computer systems. After it was done he penned his thoughts in the book The Mythical Man-Month which became one of the most influential books on software development after its publication in 1975. Reading it in 2026, we'll find some of it outdated, but it also retains many lessons that are still relevant today.

The book contains Brooks's law: “Adding manpower to a late software project makes it later.” The issue here is communication, as the number of people grows, the number of communication paths between those people grows exponentially. Unless these paths are skillfully designed, then work quickly falls apart.

Perhaps my most enduring lesson from this book is the importance of conceptual integrity

I will contend that conceptual integrity is the most important consideration in system design. It is better to have a system omit certain anomalous features and improvements, but to reflect one set of design ideas, than to have one that contains many good but independent and uncoordinated ideas.

He argues that conceptual integrity comes from both simplicity and straightforwardness - the latter being how easily we can compose elements. This point of view has been a strong influence upon my career, the pursuit of conceptual integrity underpins much of my work.

The anniversary edition of this book is the one to get, because it also includes his even-more influential 1986 essay “No Silver Bullet”.