Recent Changes

Some thoughts on LLMs and Software Development

Thu 28 Aug 2025 10:10 EDT

I’m about to head away from looking after this site for a few weeks (part vacation, part work stuff). As I contemplate some weeks away from the daily routine, I feel an urge to share some scattered thoughts about the state of LLMs and AI.

                ❄                ❄                ❄                ❄

I’ve seen a few early surveys on the effect AI is having on software development, is it really speeding folks up, does it improve or wreck code quality? One of the big problems with these surveys is that they aren’t taking into account how people are using the LLMs. From what I can tell the vast majority of LLM usage is fancy auto-complete, often using co-pilot. But those I know who get the most value from LLMs reckon that auto-complete isn’t very useful, preferring approaches that allow the LLM to directly read and edit source code files to carry out tasks. My concern is that surveys that ignore the different work-flows of using LLMs will produce data that’s going to send people down the wrong paths.

(Another complication is the varying capabilities of different models.)

                ❄                ❄                ❄                ❄

I’m often asked, “what is the future of programming?” Should people consider entering software development now? Will LLMs eliminate the need for junior engineers? Should senior engineers get out of the profession before it’s too late? My answer to all these questions is “I haven’t the foggiest”. Furthermore I think anyone who says they know what this future will be is talking from an inappropriate orifice. We are still figuring out how to use LLMs, and it will be some time before we have a decent idea of how to use them well, especially if they gain significant improvements.

What I suggest, is that people experiment with them. At the least, read about what others are doing, but pay attention to the details of their workflows. Preferably experiment yourself, and do share your experiences.

                ❄                ❄               ❇                ❄

I’m also asked: “is AI a bubble”? To which my answer is “OF COURSE IT’S A BUBBLE”. All major technological advances have come with economic bubbles, from canals and railroads to the internet. We know with near 100% certainty that this bubble will pop, causing lots of investments to fizzle to nothing. However what we don’t know is when it will pop, and thus how big the bubble will have grown, generating some real value in the process, before that happens. It could pop next month, or not for a couple of years.

We also know that when the bubble pops, many firms will go bust, but not all. When the dot-com bubble burst, it killed pets.com, it killed Webvan… but it did not kill Amazon.

                ❄                ❄                ❄                ❄

I retired from public speaking a couple of years ago. But while I don’t miss the stress of giving talks, I do miss hanging out with my friends in the industry. So I’m looking forward to catching up with many of them at GOTO Copenhagen. I’ve been involved with the GOTO conference series since the 1990s (when it was called JAOO), and continue to be impressed with how they put together a fascinating program.

                ✢                ❄                ❄                ❄

My former colleague Rebecca Parsons, has been saying for a long time that hallucinations aren’t a bug of LLMs, they are a feature. Indeed they are the feature. All an LLM does is produce hallucinations, it’s just that we find some of them useful.

One of the consequences of this is that we should always consider asking the LLM the same question more than once, perhaps with some variation in the wording. Then we can compare answers, indeed perhaps ask the LLM to compare answers for us. The difference in the answers can be as useful as the answers themselves.

Certainly if we ever ask a hallucination engine for a numeric answer, we should ask it at least three times, so we get some sense of the variation. Furthermore we shouldn’t ask an LLM to calculate an answer than we can calculate deterministically (yes, I’ve seen this). It is OK to ask an LLM to generate code to calculate an answer (but still do it more than once).

                ❄                ❄                ❄                ❄

Other forms of engineering have to take into account the variability of the world. A structural engineer builds in tolerance for all the factors she can’t measure. (I remember being told early in my career that the unique characteristic of digital electronics was that there was no concept of tolerances.) Process engineers consider that humans are executing tasks, and will sometimes be forgetful or careless. Software Engineering is unusual in that it works with deterministic machines. Maybe LLMs mark the point where we join our engineering peers in a world on non-determinism.

                ❄                ❄                ❄                ❄

I’ve often heard, with decent reason, an LLM compared to a junior colleague. But I find LLMs are quite happy to say “all tests green”, yet when I run them, there are failures. If that was a junior engineer’s behavior, how long would it be before H.R. was involved?

                ❄                ❄                ❄                ❄

LLMs create a huge increase in the attack surface of software systems. Simon Willison described the The Lethal Trifecta for AI agents: an agent that combines access to your private data, exposure to untrusted content, and a way to externally communicate (“exfiltration”). That “untrusted content” can come in all sorts of ways, ask it to read a web page, and an attacker can easily put instructions on the website in 1pt white-on-white font to trick the gullible LLM to obtain that private data.

This is particularly serious when it comes to agents acting in a browser. Read an attacker’s web page, and it could trick the agent to go to your bank account in another tab and “buy you a present” by transferring your balance to the kind attacker. Willison’s view is that “the entire concept of an agentic browser extension is fatally flawed and cannot be built safely”.

From Black Box to Blueprint

Thu 28 Aug 2025 07:24 EDT

A common enterprise problem: crucial legacy systems become “black boxes”—key to operations but opaque and risky to touch. Thiyagu Palanisamy and Chandirasekar Thiagarajan worked with a client to use AI-assisted reverse engineering to reconstruct functional specifications from UI elements, binaries, and data lineage to overcome analysis paralysis. They developed a methodical “multi-lens” approach—starting from visible artifacts, enriching incrementally, triangulating logic, and always preserving lineage. Human validation remains central to ensure accuracy and confidence in extracted functionality. This engagement revealed that turning a system from black box to blueprint empowers modernization decisions and accelerates migration efforts.

more…

Research, Review, Rebuild: Intelligent Modernisation with MCP and Strategic Prompting

Wed 27 Aug 2025 10:15 EDT

The Bahmni open-source hospital management system was began over nine years ago with a front end using AngularJS and an OpenMRS REST API. Rahul Ramesh wished to convert this to use a React + TypeScript front end with an HL7 FHIR API. In exploring how to do this modernization he used a structured prompting workflow of Research, Review, and Rebuild - together with Cline, Claude 3.5 Sonnet, Atlassian MCP server, and a filesystem MCP server. Changing a single control would normally take 3–6 days of manual effort, but with these tools was completed in under an hour at a cost of under $2.

more…

Building your own CLI Coding Agent with Pydantic-AI

Wed 27 Aug 2025 07:50 EDT

CLI coding agents are a fundamentally different tool to chatbots or autocomplete tools - they're agents that can read code, run tests, and update a codebase. Ben O'Mahony explains that while commercial tools are impressive, they don't understand the particular context of our environment and the eccentricities of our specific project. Instead we can build our own coding agent by assembling open source tools, using our specific development standards for: testing, documentation production, code reasoning, and file system operations.

more…

Chatting with Unmesh about building language with LLMs

Tue 26 Aug 2025 09:26 EDT

A few weeks ago, Unmesh Joshi and I started having a conversation about how he likes to grow a language of abstractions when working with an LLM. We thought this was a conversation that others might find interesting so we turned it into an article. We talk about how programming is about both building and applying abstractions and how the LLM helps us in different ways with each activity.

more…

Bliki: Expansion Joints

Mon 18 Aug 2025 00:00 EDT

Back in the days when I did live talks, one of my abilities was to finish on time, even if my talk time was cut at the last moment (perhaps due to the prior speaker running over). The key to my ability to do this was to use Expansion Joints - parts of the talk that I'd pre-planned so I could cover them quickly or slowly depending on how much time I had.

The way I'd do this would be to plan for some topics to be optional. The talk would work if I skipped over them, but I could also witter on about them for five (or ten) minutes. Ideally, each of these topics would get one slide, usually with a bunch of key phrases on it - the headings of what I'd talk about should I be talking about it. When I got to the slide, I'd look at how time was going with the talk. If (as was usually the case) I was running short of time, I could cover the slide in about thirty seconds, saying something like: “in doing this, there's a bunch of things you need to consider, but they are out of scope for today's talk”.

If, however, I did have time, I could then spend some time talking about them. The slide would be simple, and not provide much of a Visual Channel, but that wasn't so important, after all this material was optional in the first place.

The single flex-slide was my favorite Expansion Joint, as it was easy to use. Sometimes however my optional topic required a proper visual channel, necessitating dedicated slides. My solution here was good control over slide handling. Presentation tools include the ability to skip over slides while I'm talking, and I made sure I practiced how to use them so I could skip a bunch of slides without the audience knowing. It's crucial here that it's invisible to the audience, I find it looks sloppy if anyone says “in the interests of time I'll skip over these slides”. To do this, however, I do need access to my laptop while presenting, venues that only provide a clicker while loading the slides on some other machine lack that control. That started to happen in my last couple of years, much to my annoyance.

When creating talks, I was always worried that I would run out of things to say, even though experience told me I reliably crammed more stuff in than I could possibly cover. Expansion Joints helped with this, I could aggressively trim the core talk to less than I needed, and rely on the Expansion Joints to fill the gap. In practice I usually didn't need the Expansion Joints anyway, but their presence helped my confidence.

Using Expansion Joints was particularly important for me as I never rehearsed my talks. I was always someone whose ability to present was driven by adrenaline. Talking to a rubber duck just didn't work, the duck was clearly every bit as bored as I was. Consequently the first time I gave a talk, I was hazy as to how long it would take. Yet with Expansion Joints in place, I was able to finish a talk right on time.

Expansion Joints enabled me to give the same talk to different time slots. Sometimes I'd have thirty minutes, sometimes forty-five. With Expansion Joints, I didn't need to change my slides, particularly handy if a time cut (or more rarely a time increase) appeared at the last moment. (Although in my later years, I handled this by doing a Suite Of Talks.)

Talks that encourage audience interaction need these because we can never predict how much time the interaction will use up. Sometimes we get a steady stream of questions, other times (particularly in Scandinavia, or upper-Midwest America) a lack of questions had me blasting through the agenda. Any such talk needed a double-dose of this temporal ballast.

Expansion Joints are at their most useful in later parts of the talk, as it's then that I have the most information on how much time I have. Earlier ones can still be handy, particularly if they come after an interactive section when I'd like to rebase my timing.

Team OKRs in Action

Wed 13 Aug 2025 10:16 EDT

OKRs have become a popular way to connect strategy with execution in large organizations. But when they are set in a top‑down cascade, they often lose their meaning. Teams receive objectives they didn’t help create, and the result is weak commitment and little real change. Paulo Caroli describes how high‑performing teams can work in another way. They define their own objectives in an organization that uses a collaborative process to align the team’s OKRs with the broader strategy. With these Team OKRs in place, they create a shared purpose and become the base for a regular cycle of planning, check‑ins, and retrospectives.

more…

Quick but worthwhile links

Thu 07 Aug 2025 09:21 EDT

Abi Noda observes

Just met with a 2000+ eng company. Their developers are saving 2+ hours per week thanks to Copilot.

But they’re also losing:

• 3 hrs per week due to slow builds
• 4 hrs per week on dev environment toil
• 2 hrs per week waiting for code reviews

AI is not a silver bullet.

Nik Malykhin found it useful to get an AI assistant to write its own coding rules by analyzing his code, and then asking it to refine them as worked with it.

the central paradox of using AI assistants effectively: to offload cognitive work to an AI, you must first do the meta-cognitive work of codifying your own development philosophy and collaboration style.

I agree with Charity Majors that there is a valuable distinction between disposable versus durable code, and that makes a difference in how we use AI with it.

The difference between disposable code and durable code is not about whether the code was generated by AI or written by a human, or even how difficult it was to write. The cost is defined by the standards you are building to, and the rest of the software development lifecycle: how well you expect to maintain it, extend it, migrate it, understand its behavior, or fix it when it breaks. This is the expensive part of software development, the type that requires deep expertise and familiarity with your language and environment. Disposable code is cheap because you don’t even try to maintain it.

Jim Highsmith thinks that we should think of AI as Alternative Intelligence

It’s not fake intelligence, or artificial empathy, or HAL 9000 with manners. It’s something else. Something that thinks differently, not defectively.

Rod Johnson asserts that we know that memory is important to AI systems, but we forget that Domain Models are an important form of memory

Event Sourcing provides perfect episodic memory by storing the complete history of domain changes as immutable events. Every decision, every state transition, every business event is preserved with full context.

Repository patterns offer domain-focused memory interfaces that understand business concepts. A CustomerRepository knows how to retrieve customer information in ways that preserve business meaning, not just raw data.

Bounded contexts from Domain-Driven Design partition memory into semantic boundaries, preventing the concept pollution that plagues pure vector-based approaches.

Aggregates function as cohesive memory clusters with consistency boundaries—exactly what we need for reliable agent behavior.

The Reformist CTO’s Guide to Impact Intelligence

Wed 06 Aug 2025 09:23 EDT

The productivity of knowledge workers is hard to quantify and often decoupled from direct business outcomes. The lack of understanding leads to many initiatives, bloated tech spend, and ill-chosen efforts to improve this productivity. Sriram Narayan begins an article that looks at how to avoid this by developing an intelligence of the business impact of their work across a network connecting output to proximate and downstream impact.

more…

How far can we push AI autonomy in code generation?

Tue 05 Aug 2025 09:53 EDT

Birgitta Böckeler reports on a series of experiments we did to explore how far Generative AI can currently be pushed toward autonomously developing high-quality, up-to-date software without human intervention. As a test case, we created an agentic workflow to build a simple Spring Boot application end to end. We found that the workflow could ultimately generate these simple applications, but still observed significant issues in the results—especially as we increased the complexity. The model would generate features we hadn't asked for, make shifting assumptions around gaps in the requirements, and declare success even when tests were failing. We concluded that while many of our strategies — such as reusable prompts or a reference application — are valuable for enhancing AI-assisted workflows, a human in the loop to supervise generation remains essential.

more…

Partner with the AI, throw away the code

Thu 31 Jul 2025 10:16 EDT

Matteo Vaccari shows why the common metric of AI code acceptance has big hole. An LLM can be helpful even if you throw away its code.

more…

Who is LLM

Tue 22 Jul 2025 13:38

It's become a common habit for developers to give Large Language Models (LLMs) a persona when working with them. I describe four of them, a stubborn donkey, a genie, a slot machine, and Uriah Heep.

more…

Generative AI in software and essaying

Mon 21 Jul 2025 14:58 EDT

Korny Sietsma has a great example of how using an LLM for coding is very helpful but with limitations…

and a thoughtful general essay on why the hype and the immovable skeptics are both missing the train.

While here, a professor of poetry ponders (gift link) on the value and limits of AI with writing:

One of the real challenges here is the way that A.I. undermines the human value of attention, and the individuality that flows from that.

What we stand to lose is not just a skill but a mode of being: the pleasure of invention, the felt life of the mind at work.

Three worthwhile articles yesterday

Thu 10 Jul 2025 10:58 EDT

Three articles I enjoyed yesterday:

Stephen O’Grady talks about how Gen AI tools break two common constants with developer tools: they are willing to flit between Gen AI tools and they are willing to pay for them. This implies that it’s not too late for new tools to appear, and that enterprise adoption will be slowed by a lack of consensus on which direction to go.

Pete Hodgson continues his excellent writing on Gen AI by proposing an approach to leading engineers towards an AI-assisted future, centered around a the concept of aligned autonomy. He advocates an explicit experimentation phase, followed by supporting adoption and measuring their impact.

Charity Majors reflects on her career. I really resonated with her words: “I think I’m less interested in my own happiness (whatever that means) than I am interested in doing work that feels worth doing.”

I still care about the code

Wed 09 Jul 2025 10:33 EDT

Even with LLMs, Birgitta Böckeler still cares about the code: “LLMs are NOT compilers, interpreters, transpilers or assemblers of natural language, they are inferrers.

more…

LLMs bring new nature of abstraction

Tue 24 Jun 2025 10:02 EDT

Like most loudmouths in this field, I’ve been paying a lot of attention to the role that generative AI systems may play in software development. I think the appearance of LLMs will change software development to a similar degree as the change from assembler to the first high-level programming languages. The further development of languages and frameworks increased our abstraction level and productivity, but didn’t have that kind of impact on the nature of programming. LLMs are making that degree of impact, but with the distinction that it isn't just raising the level of abstraction, but also forcing us to consider what it means to program with non-deterministic tools.

more…

Expert Generalists: first three characteristics

Wed 18 Jun 2025 09:13 EDT

As computer systems get more sophisticated we've seen a growing trend to value deep specialists. But we've found that our most effective colleagues have a skill that comes from spanning many specialties. We are thus starting to explicitly recognize this as a first-class skill of “Expert Generalist”. This is the first installment of an article detailing how we think about this skill, starting with the first three characteristics of an Expert Generalist.

more…

Autonomous coding agents: A Codex example

Wed 04 Jun 2025 09:50 EDT

In the past few weeks, multiple “autonomous background coding agents” have been released. Birgitta Böckeler tried out giving a task to OpenAI Codex to see what she could learn. Here she describes one particular Codex run, to help us look behind the scenes, and make some observations about its contribution to our work.

more…

Should I still use analytics?

Tue 03 Jun 2025 09:23 EDT

I set up Google Analytics on my site in 2010, and since then use it to track page views to my site. I only care about page views, which I find useful to figure out which pages get the most traffic. It’s interesting data, and sometimes rather useful. But Google collects much more information than just page views, and it’s tracking is more intrusive than I would like. But I had other things I’d rather spend to spend my time on, so doing anything about it never made it high enough up my todo list.

But last month I finally did something, having come across some information that did I thought did what I wanted. Essentially I want things set up so that I don’t need to bother with a cookie banner because I only track things that are trackable when someone says “deny all”. Based on some google documentation, I changed my google analytics fragment to:

<script async src="https://www.googletagmanager.com/gtag/js?id=G-6D51F4BDVF"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('consent', 'default', {
    'ad_user_data': 'denied',
    'ad_personalization': 'denied',
    'ad_storage': 'denied',
    'analytics_storage': 'denied',
    'wait_for_update': 500,
  });
  gtag('js', new Date());

  gtag('config', 'G-6D51F4BDVF');
</script>

As I understand the documentation, this should turn off the most problematic tracking, but still send a page view event. I took a look at it the following day, and everything seemed to be ok, but now, a couple of weeks later, page views reported by Google Analytics have dropped drastically. Not to zero, but to near zero.

I’ve spent a bit of time trying to figure out what’s happening. I used google tag assistant and it indicates the page view events are being sent correctly. But that doesn’t explain why I’m not seeing the page views in my Google data.

I’m not sure what to do next. I don’t want to spend too much time on this, after all I’d rather work on writing and editing. I did consider other services to do the tracking, but it looks we’re talking about $100s a month - and it’s just not worth that much to me. There are open source setups I could try an configure on my server, but again that’s effort I don’t really want to go into. Maybe I just live without analytics data.

Bliki: Say Your Writing

Wed 28 May 2025 09:50 EDT

Here's one of the best tips I know for writers, which was told to me by Bruce Eckel.

Once you've got a reasonable draft, read it out loud. By doing this you'll find bits that don't sound right, and need to fix. Interestingly, you don't actually have to vocalize (thus making a noise) but your lips have to move. ¹

This advice is for those who, like me, strive to get a conversational tone to their writings. A lot of people are taught to write in a different way than they speak, but I find prose much more engaging with this conversational tone. I imagine I'm sitting in pub, explaining the concepts to my companions. I've heard people say that when reading my work, they can hear me speaking it - which is exactly the effect I'm after.

Too often I read prose that feels flabby. Two kinds of flab stand out: corporate prose and academic prose. I often tell people that if they read their prose and it sounds like it could have come from Accenture ² , then they are doing it wrong. And, of course, the passive voice is rarely preferred. Speaking makes this flab noticeable, so we can cut it out.

In my case I find I constantly (silently) speak the words as I'm writing.

Interviewed by James Lewis at goto Copenhagen

Fri 23 May 2025 13:48 EDT

At goto copenhagen last year, my friend James Lewis interviewed me and Goto have just released the video. I talk about when I learned about iterative design from Kent Beck, the dangers of product owners interfering with business-developer communication, and writing the agile manifesto. During this he specifically asked about my essay Is Design Dead. There's also a some audience questions asking if pair programming is a bad thing for introverts like us (no), and (inevitably) the role of LLMs for programmers today.

more…

Refresh of Agile Threat Modeling

Tue 20 May 2025 09:20 EDT

Threat modeling is a systems engineering practice where teams examine how data flows through systems to identify what can go wrong - a deceptively simple act that reveals security risks that automated tools cannot anticipate. Often this is done by security analysts as a separate or upfront activity, but Jim Gumbley wrote an article in 2020 explaining how it could be done by teams through small and regular work.

Now Gayathri Mohan has joined Jim to rewrite the article, incorporating what both have them learned about doing and teaching this practice in the last few years. In particular they have extended their approach to perform threat modeling with platform teams.

more…

Building Custom Tooling with LLMs

Wed 14 May 2025 10:10 EDT

Tools that treat diagrams as code, such as PlantUML, are invaluable for communicating complex system behavior. But Unmesh Joshi often wished for an extension to walk through these diagrams step-by-step. Yet, extending established tools like PlantUML often involves significant initial setup - parsing hooks, build scripts, viewer code, packaging - enough “plumbing” to deter rapid prototyping.

He narrates now he used an LLM to build a small extension adding step-wise playback to PlantUML sequence diagrams. This illustrates how syntax design, parsing, SVG generation, build automation, and an HTML viewer were iteratively developed through a conversation with an LLM - turning tedious tasks into manageable steps.

more…