Broadsheet

This is the first part of a series looking at the structure of the Carthaginian army. Although Carthage has an (unfair!) reputation for being a country of “peaceful merchants who tended to avoid wars,”¹ Carthage was, I will argue, without question the second greatest military power the Mediterranean produced – eclipsed only by Rome. If we do not realize this, it is merely because Carthage had the misfortune to fight Rome ‘in the first round,’ as it were.

Carthage is, in particular, the only military power that ever manages to seriously challenge Rome on an even footing, blow for blow, after the Romans completed the conquest of Italy. The Carthaginian military system pushes Rome to the very brink of defeat twice, in contrast to the Hellenistic great powers, the heirs of Alexander, none of which ever force the Romans to ‘dig deep’ into their forces. Put another way: the Romans put Alexander’s heirs to bed mobilizing against them less than a third of the military force it took for Rome to match Carthage. The Carthaginians inflicted more casualties on the Romans in a single day than all of the successor states (a label which does not include Epirus, so no Pyrrhus here; worth noting the Carthaginians beat him too) managed in pitched battle combined. And they did this more than once; I’d hazard they managed it about seven times.²

So in this series, we are going to lay out the structure of Carthage’s armies (alas, we have very little information as to the structure of their navy), because as we’ll see, the Carthaginian military system was quite complex, drawing soldiers from all over the western Mediterranean.

Now there is an a bit of organizational trickiness here: Carthage drew forces from many different places at many different times. In practice, the Carthaginian military becomes visible to us as early as 480 (with the Battle of Himera) and seems to change significantly between this period and the army visible to us in the first book of Polybius, which fights the First Punic War (254-241) and the Mercenary War (241-237). Then the Carthaginian army undergoes another substantial shift visible to us, in terms of its composition, during the Barcid Conquest of Spain (237-218) such that the Carthaginian army that fights in the Second Punic War (218-201) looks very different again. And then Carthage loses its army and so its military forces from 201 to the end of the Carthaginian state in 146 look different again.

My solution here is to structure this treatment around the largest Carthaginian mobilizations, which were those during the Second Punic War: Carthaginian numbers peaked in 215 with something on the order of 165,000 men under arms.³ We’ll work through the components of that force (operating, as it did, in multiple theaters) and for each component of it, we can then note how – as best we can tell – that specific component changed over time.

I should also note what I am not doing here: this is not a full rundown of Carthage’s military history or the Punic Wars; rather it is an outline of the components of Carthage’s land forces. I think a treatment of the Punic Wars on a similar level to our “Phalanx’s Twilight, Legion’s Triumph” series is probably worth doing, but would be a much larger and more involved series than this, because the Punic Wars are quite long conflicts with many twists and turns and often multiple simultaneous theaters. One day!

But first, as always, raising large armies of mercenaries, subject conscripts, vassal warlords and allies is expensive! If you too want to help me invade Italy with a multi-ethnic army of diverse origins in a doomed effort to stop the Roman Republic, you can help by supporting this project over at Patreon. If you want updates whenever a new post appears or want to hear my more bite-sized musings on history, security affairs and current events, you can follow me on Bluesky (@bretdevereaux.bsky.social). I am also active on Threads (bretdevereaux) and maintain a de minimis presence on Twitter (@bretdevereaux).

(Bibliography Note: Any bibliography for the lay reader looking to get to grips with Carthage likely has to begin with D. Hoyos, The Carthaginians (2010) which provides a solid foundation on understanding the Carthaginian state and society. A solid overview of Carthaginian military history is provided by J.R. Hall, Carthage at War: Punic Armies c. 814-146 (2023). For specific periods in Carthaginian military history, note J.F. Lazenby, The First Punic War: A Military History (1996), then D. Hoyos, Truceless War (2007) on the Mercenary War and D. Hoyos, Hannibal’s Dynasty (2003) on the Carthaginian conquest of Spain, before going back to J.F. Lazenby for Hannibal’s War (1978) on the Second Punic War. G. Daly, Cannae: The experience of battle in the Second Punic War (2002) has, among other things, one of the better run-downs of the composition of Hannibal’s army. On the Gauls in Carthaginian armies, note L. Baray, Les Celtes d’Hannibal (2019), alas not translated. On the Numidians, a key component of Carthage’s army, see W. Horsted, The Numidians, 300 BC – AD 300 (2021), while on the Spanish warriors who fought for Carthage, see Quesada Sanz, F. Armas de la Antigua Iberia: De Tartesos a Numancia (2010) now available in translation as F. Quesada Sanz, Weapons, Warriors & Battles of Ancient Iberia (2023), trans. E. Clowes and P.S. Harding-Vera. You can also find what little we know about Balaerian slingers in the opening chapters of L. Keppie, Slingers and Sling Bullets in the Roman Civil Wars of the Late Republic, 90-31 BC (2023). Finally, one must note N. Pilkington, The Carthaginian Empire (2019), an often heterodox but equally sometimes persuasive reassessment of what we know of Carthage that is intensely skeptical of our literary source tradition and an essential read (for agreement and disagreement) if one is intending to get knee-deep in the scholarship.)

A Brief Chronology

First, before we get into the details, we should lay out the basic chronology of Carthaginian military history, because as we’re going to see, not only does Carthage draw upon a bunch of different sources of military manpower, those sources themselves change over time in their composition and role within the Carthaginian system.

Now we should start with some background here on the nature of Carthage and its control over its core territory in North Africa. Carthage was a Phoenician colony, founded in North Africa (in modern day Tunisia). The population was thus likely a mix of local Libyan peoples, Phoenician settlers and even other maritime peoples (Aegeans, e.g. Greeks). The Carthaginians themselves maintained a clear ideology of being Phoenicians, using a Punic language, worshiping Punic gods and making a clear connection to their mother-city of Tyre, however some modern DNA research has suggested the actual population of Phoenician colonies might have been more genetically diverse than we have generally supposed. Of course, not every resident of Carthage was likely to be a citizen and certainly the impression we get is that some Phoenician ancestry was a requirement for full citizenship.

Via Wikipedia, a decent-if-not-perfect map of Greek and Phoenician colonization. It is worth noting when looking at this map that the Etruscan were organized into states, but not united, while the Thracians, Dacians and Illyrians were non-state peoples at this time.

Carthage was hardly the only such colony in North Africa (Utica, Thapsus (in North Africa), Leptis, Leptiminus, etc. were all such colonies), but there was also a substantial local Libyan population and at least initially Carthage was subordinate to those peoples; we’re told that quite Carthage’s first few centuries after its founding (mid-eighth century) paid tribute to the locals, a relationship that inverted quite dramatically as Carthage became stronger. Carthage seems to begin projecting power overseas seriously in the mid-to-late-500s, though we cannot always see this early process as well as we’d like. By c. 500, Carthage seems to control Sardinia and the western coast of Sicily. Some sign of Carthage’s expanding control in North Africa comes when they are able to block Dorieus (a Spartan prince) from creating a Greek colony in North Africa and then shortly thereafter also destroy his effort to found a colony in western Sicily, between 515 and 510 or so. Unfortunately, we’re not really well informed at all about the armies they used to do this

Instead, Carthaginian armies first start to become really visible to us in the context of the running contest between Carthage and Syracuse for control over the rest of Sicily, which kicks off in the 480s. From the 480s to the 270s, Carthage fights a series of wars with the Greeks on Sicily, the latter generally organized around the largest and strongest Greek city there, Syracuse. There is a tendency for students to be surprised that Carthage – given its apparent power in the third century – is unable to overcome (or be overcome by) Syracuse, but it is worth remembering that Syracuse is a really big polis, on the same scale as Athens or Sparta. Recall that from 415 to 413, the Athenians throw the lion’s share of their military, at the height of their power at Syracuse and lose effectively all of it for their trouble, so Syracuse – at least when well led and organized – is a fairly major power (in as much as any power other than the Achaemenids can be major) in this period.

In any case, the first Carthaginian-Greek war in Sicily begins in the 480s and ends with the Battle of Himera in 480. They’re then back at it from 409 to 405, then again from 398 to 396, then again from 383 to 381 (?), then again from 368 to 367, then again 345 to 341 and again from 311 to 306 and then finally from 278 to 276, Pyrrhus of Epirus shows up to campaign against Carthage on behalf of the Greeks. On the one hand, at any given time in these wars, territorial control often swings wildly between Carthage and Syracuse, but on the other hand zooming out, over the long-term relatively little changes and the whole thing resembles a stalemate: Carthage controls the west of the island, Syracuse the east and the settlements in the middle either manage in the fracture-zone between the powers or submit to one or the other.

Alongside the early phases of this running warfare on Sicily, Carthage is steadily subduing the area around it in North Africa, reducing the Libyan and Phoenician settlements in what is today Tunisia to semi-autonomous subjects. Those communities remained internally self-governing, but were in practice ruled by Carthage and we’ll talk about that relationship in the next post in the series. We can’t fully see this process clearly but by c. 400, Carthage clearly seems to have control over most of its immediate surroundings. Carthage also began interacting quite early with the Numidians, the Berber peoples to the west (generally divided into two kingdoms, Massaesylii and Massylii) sometimes recruiting them and sometimes fighting them. Certainly by the start of the third century if not earlier, Carthage is the dominant power in this relationship.

The Carthaginians are also clearly active in trade in Spain, though it is unclear to what degree the Phoenician settlements there fall under Carthaginian political control and when.

Thus even by c. 480, Carthage is one of the major imperial powers in the western Mediterranean, though hardly the only ‘major player’ and remains so, steadily growing in size and influence over the next several centuries. By c. 300, the Carthaginians have secured control over western Sicily, Corsica and Sardinia, have some small footholds in Spain and most importantly have secured control over most of what is today Tunisia (what the Romans would just call ‘Africa’) and have a dominant if frequently shifting position relative to the Numidians.

That set the stage for the major wars of the third century. Carthage was in a strong position in Sicily after the end of their war with Agathocles (in 306), leading to the Sicilians to appeal to Pyrrhus in the 270s. Pyrrhus, arriving in 278 was able to win significant victories and pin the Carthaginians back to their last major coastal base in Lilybaeum, but was unable to take it (being unable to break Carthaginian naval control) and subsequently forced out in 276 once his support among the Sicilian Greeks ebbed, suffering a nasty naval defeat on his way out for his trouble.

That left Carthage in a dominant position in Sicily (but still facing a potent foe in Syracuse) when in 264 a group of mercenaries (the Mamertines) leftover from Agathocles’ war who had seized Messina – under pressure from Syracuse – appealed to both Rome and Carthage for help. That led to a four(-ish) way war in which two of the sides (the Mamertines and Syracuse) rapidly found themselves rendered irrelevant. The result was the First Punic War (264-241) between Rome and Carthage, fundamentally a war for control over Sicily, although the Romans did invade North Africa (unsuccessfully) in 256.

Via Wikipedia, a rough map of Carthage’s territorial control at the beginning of the First Punic War, though I’d argue this probably overstates Carthaginian control in Spain somewhat (New Carthage isn’t even **founded** yet!)

Carthage loses the war, with Rome consolidating control over Sicily, only to be immediately beset by a new war, the Mercenary War (241-237), when a mutiny by Carthage’s unpaid mercenaries from the end of the First Punic War set off a general revolt of its subjects in North Africa. The Carthaginians win this war, particularly with the leadership of Hamilcar Barca, who is then too politically influential to be left in Carthage, so he is packed off with an army to go do stuff in Spain. The ‘stuff’ he does in Spain from 237 to his death in 228 is to subdue nearly the entire Mediterranean coast up to the Ebro River, with that task then completed by first his son-in-law, Hasdrubal the Fair and then Hamilcar’s eldest son Hannibal.

That sets the stage for ’round two’ with Rome, the Second Punic War (218-201), an absolutely massive war waged across Italy, Spain and Africa, which represents the peak military output of either Rome or Carthage (although the First Punic War, with its massive fleets, probably roughly matches it). Utterly defeated in 201, Carthage is shorn of its overseas empire and much of its more distant African holdings, essentially reduced to ‘merely’ controlling northern Tunisia. However, rapid Carthaginian economic recovery leads Rome to instigate a third war with Carthage, the Third Punic War (149-146). Unlike the previous two wars, this is not an even contest: Carthage by this point is much smaller and weaker a power than Rome. Determined Carthaginian resistance prolongs the war, but Rome is eventually able to seize the city and destroy the Carthaginian state in 146.

Via Wikipedia, a rough map of Carthaginian control at the start of the Second Punic War. This map **substantially** overstates Carthaginian control of the Spanish interior, however.

Now, one thing worth noting at the end of this brief, potted history is for nearly all of this period, we have only Greek sources (Romans, writing in Latin, only really come in with the Punic Wars and even then our earliest Roman sources – Fabius Pictor – are lost, so we get him processed through a Greek – Polybius). One of the features of the history we do have of Carthage that I suspect results from this is that Carthage seems to lose a lot. But it is, at least until 264, a strange sort of losing: Carthage shows up in our sources losing major battles but then one moves forward a few decades and Carthage’s empire is larger and more prosperous. And then Carthage loses another major battle and yet somehow, a few decades later Carthage is even more powerful.

So either Carthage is the world champion at failing upwards or there is something going on with our sources. And it isn’t hard to really guess what: our key source for Carthaginian history before 264 is Diodorus Siculus, that is, ‘Diodorus the Sicilian,’ a Sicilian Greek writing in the first century B.C. who thus very obviously has a side in Carthage’s long wars with the Sicilian Greeks. Even if Diodorus is doing his best to give us a straight story, which battles are his sources likely to remember or commemorate most prominently: the Time They Really Walloped the Carthaginians or perhaps smaller engagements that they lost? Thus while we cannot know for certain, I find that I suspect Carthage’s battle-record pre-264 is likely rather better than our sources suggest.

Post-264, it seems worth noting that while Carthage loses more often than they win against the Romans, they still manage to deliver Rome some pretty stunning defeats. The notion that Carthaginians are ‘peaceful merchants’ or just ‘unmilitary’ thus seems to be almost entirely empty, a nearly pure product of later stereotypes about ‘unmanly easterners’ rather than a conclusion justified by the evidence. At the very least, by the time Rome was ready to fight Carthage, the Carthaginians very much knew how to throw a punch – indeed, they would punch Rome far harder than any other foe.

That still provides some three hundred years where Carthage is a meaningful military power where we can see their military activities, so as you might imagine, the shape of the Carthaginian army changes a lot over that period.

Component Parts

The next thing we ought to do, to get an overall sense of the system, then, is to lay out the scale of Carthaginian forces at the height of the Second Punic War, representing the largest land mobilization that Carthage ever produced. The size of the mobilization is staggering, as is the diversity of how it was raised: like most imperial powers, Carthage’s army was a diverse medley of soldiers drawn from basically everywhere that Carthaginian power reached. The way these soldiers were incorporated into Carthage’s armies was in turn a product of what their relationship to the Carthaginian state was – citizens, subjects, vassals, allies, mercenary employees.

Our sources, most particularly Polybius, provide us enough detail to get a pretty decent accounting of Carthage’s ‘peak’ mobilization, which comes in 215. Hannibal, of course, had a Carthaginian field army at that time in Italy – he had won the Battle of Cannae (216) the year before – but there were also Carthaginian armies in Spain, Sardinia and Africa, along with an active fleet. Carthage alone of the Mediterranean powers of the era seems to have been able to match Rome’s capacity for multi-theater warfare: whereas Hellenistic kingdoms could really only have one primary theater of war at a time, both Rome and Carthage could wage multiple parallel campaigns simultaneously and did so.

So let’s break down the evidence for what we have.

We can begin with Hannibal’s army in Italy, which Polybius tells us (3.114.5) consisted of 40,000 infantry and 10,000 cavalry for the Battle of Cannae (216). We can actually work backwards with just a little bit of guessing to break down this army into its unit composition: Hannibal crosses the Alps with 12,000 Africans, 8,000 Iberians, and 6,000 cavalry, taking some losses in the subsequent battles but also absorbing around 9,000 Gallic infantry and 5,000 Gallic cavalry. Figuring for attrition, the composition of Hannibal’s army at Cannae has to look at least something like around 10,000 African infantry, 6,000 Iberian infantry, around 8,000 mixed ‘lights’ (North African lonchophoroi, which means ‘javelin-men’ not ‘pikemen’ as it is sometimes mistranslated) and Balearian slingers and 16,000 Gallic infantry to make the total. Of the cavalry we might suspect around 5,000 of it was Gallic cavalry and the rest split roughly evenly between Numidian cavalry from Africa and Iberian cavalry (both of which we’re told Hannibal has).

We then need to modify that force for Hannibal’s losses at Cannae: he lost 4,000 Gauls, 1,500 Iberians and 200 cavalry, but was reinforced late in the year (Polyb. 3.117.6; Livy 23.13.7) with 4,000 more Numidian cavalry and 40 elephants. That leaves Hannibal in 215 with an army of roughly 50,000: 10,000 African infantry, 12,000 Gallic infantry, 4,500 Iberian infantry, 8,000 mixed ‘lights’ (lonchophoroi and Balearian slingers), around 5,000 Gallic cavalry and perhaps 10,000 other cavalry, of which we might guess that maybe 2/3rds were Numidian and 1/3rd Iberian.

At the same time in Italy there is a second Carthaginian army operating in Bruttium (modern Calabria; Hannibal is operating out of modern Apulia) under the command of Hanno with 17,000 infantry composed mostly of Roman socii that have defected to Hannibal, along with 1,200 cavalry, mostly Spanish and Numidian (Livy 24.15.2).

The thing is Hannibal does not have Carthage’s largest army. One of the mistakes students make in assessing the Second Punic War is focusing – as most modern treatments do – almost entirely on Hannibal. But for Carthage, getting reinforcements to Hannibal is very hard – Rome at this point has a strong navy so they can’t easily sail to Italy – but the war is also very active in Spain. Carthage had come to control the Mediterranean coast of Spain as a result of the conquests of Hamilcar Barca (we’ll discuss this more when we get to these guys in a couple of weeks) and Rome was seeking to tear that part of the empire away.

Carthage had three generals operating in Spain by 215 – Hasdrubal and Mago Barca (Hannibal’s brothers) and Hasdrubal Gisco. Livy reports the combined strength of all three at 60,000 (Livy 23.49) and once again with some careful tracking through Livy and Polybius we can basically break this force down to roughly 24,000 African infantry (a mix of Hannibal’s troops left behind and reinforcements brought by Mago), a touch less than 2,000 African cavalry, and the remainder – about 34,000 – mostly Iberian troops along with some small units of Gauls (300 from Liguria) and Balearian slingers (500). We can be fairly ‘rough’ with these numbers because we’re dealing with ‘paper strengths’ that are going to be off to some degree in any case – the point here is a rough approximation of an estimate, because our sources aren’t going to get better than that.

In addition, there was a Carthaginian army dispatched to Sardinia to try to retake it, a force Livy reports as being roughly the same size as the reinforcements Mago brought to Spain, which would mean 12,000 infantry and 1,500 cavalry, probably nearly all African (Livy 23.23.12).

Finally, Carthage maintained a force still in Africa. Hannibal had, at the war’s outset, transferred to Africa some 13,850 Iberian infantry, 870 Balearian slingers and 1,200 Iberian cavalry, while redeploying some 4,000 Metagonians (from what is today eastern Morocco) to Carthage as well.

Taking all of that together we can estimate very roughly (with some rounding) that Carthage has, under arms, in 215:

50,000 African infantry
17,000 Italian socii
12,000 Gallic infantry
52,000 Iberian infantry
10,000 various ‘lights’ (including at least 1,370 Balearian slingers)
21,000 cavalry of which probably roughly
- 5,000 are Gallic cavalry
- 5,000 are Iberian cavalry
- 11,000 are African and Numidian cavalry (with the Numidians probably the larger share)

For a total of roughly 162,000 men under arms. Notably missing from this total are any Carthaginian citizen troops, but for reasons I’ll get to below, I do think there probably were some in North Africa. For comparison, the peak mobilizations of the major successor states (the Seleucid and Ptolemaic kingdoms) are probably around 80,000 men. Carthage is doubling that mobilization and very nearly matching Rome’s own maximum mobilization (around 185,000 men).⁴

Carthaginian Citizen Soldiers

Now you may have noticed something a little odd for the Carthaginian army implied by the figures above: there aren’t any Carthaginians in it. And that tends to be one of the core things that folks ‘know’ about Carthaginian armies, which is that these were ‘mercenary’ armies, where Carthaginians only served as officers. That is, after all, more or less directly what Polybius tells us and historians ancient and modern tend to take Polybius at his word. And while Polybius is being more than a little sneaky with his description of Carthaginian armies as mercenary in nature, the idea that Carthaginians didn’t serve in quantity in Carthaginian armies is at least half true, but with important geographical and chronological limitations.

Here, we are interested in the Carthaginian citizens themselves. And we begin with the first exception to the idea that Carthaginian citizens didn’t fight, the chronological one: Carthaginian citizen armies are actually very common everywhere (that is, both at home and abroad) in the fifth and fourth century. Diodorus (11.22.2) reports ‘Phoenicians’ in the Carthaginian army for the Battle of Himera (480) which are likely Carthaginian citizen soldiers we hear of Carthaginian citizen soldiers in later Carthaginian expeditions to Sicily in 409 too. As late as 339, at the Battle of the Crimissus, the Carthaginian army includes, according to Diodorus, a Sacred Band of Carthaginian citizens several thousand strong (Diod. Sic. 16.80.4) which seems to be a picked force from a larger body of Carthaginian citizens, given that he describes its members as distinguished even among the citizens for valor, reputation and wealth.

Now in most treatments the next thing that will get said is that in the third century – when both the First (264-241) and Second (218-201) Punic Wars occur – the Carthaginians changed this policy and citizens stopped serving except as officers. But I think that perhaps misses what is really happening here and the reason has to do with the perspective of our sources: we have no Carthaginian sources or even North African sources. What we have are the reports primarily of Romans (who fought Carthage), Greeks on Sicily (who fought Carthage) and mainland Greeks like Polybius, who relied on the other two. My point is not necessarily that these sources are hostile to Carthage (though they are), but rather that their focus is directed. We are seeing Carthage like one would see a statute in a dark room lit entirely from one side: only half the statute will be illuminated.

Our sources are very interested in the armies that Carthage sends against Syracuse and Rome and almost entirely uninterested – or uninformed! – about the forces that Carthage might muster in other places. We only see Carthaginian North Africa clearly in brief snippets: when a Greek or Roman tries to invade it (310, 256, 204and 149) or in the context of a major revolt like the Mercenary War (241-237) which draws our sources attention.

But what do we see whenever the action shifts to North Africa? Citizen soldiers in Carthage’s armies. While Diodorus inserts into his narrative a line about how the Carthaginians were unprepared for fighting when Agathocles (tyrant of Syracuse) lands his army in Africa in 310, they quickly manage to put together a citizen soldier army – Diodorus says of some 40,000 soldiers, but Diodorus’ numbers here are often useless (Diod. Sic. 20.10.5-6). We don’t hear anything about citizen soldiers during Rome’s unsuccessful invasion in 256 (during the First Punic War), but when Carthage’s expeditionary army (returned from Sicily at the war’s end) revolts in 241, Carthage immediately raises a citizen army to put down the revolt and succeeds in doing so (Polyb. 1.73.1-2). Likewise, when P. Cornelius Scipio soon-to-be-Africanus lands in North Africa in 204, the Carthaginians raise citizen forces (alongside all of their other troops) to try to stop him and Carthaginian citizens formed a major part of Hannibal’s army at Zama (202; Polyb. 15.11.2-4), including both infantry and cavalry.

And of course, when Rome returned for the final act in the Third Punic War (149-146), Carthage – largely shorn of its empire – responded by mobilizing a citizen force to defend the city, alongside freed slaves (App. Pun. 93-5) and resisted fairly stoutly.

In short, with the exception of M. Atillius Regulus’ invasion of 256, every time Carthaginian Africa is ‘illuminated’ for us we see Carthaginian citizen forces. Now our sources often present these forces as basically ‘scratch’ forces, raised in a panic, but while the Carthaginians sometimes lose the battles that result, these armies are not a ‘rabble’ by any means. Carthaginian citizen forces were evidently sufficient to defeat their own mercenaries and the Libyan revolt in 241. At Zama (202), the Carthaginian citizens form the second rank of Hannibal’s army and while Polybius is quick to lean into stereotypes calling them cowards (for not reinforcing the first battle line, composed of mercenary troops), in practice what he actually describes is that the Carthaginian citizen line is able to throw the Roman hastati back and is only forced to retreat by the advance of Scipio’s second line of principes (Polyb. 15.13.5-8).

My suspicion is thus that Carthaginian citizen soldiers may have never fully gone away, but rather they may have been confined largely to operations in North Africa. It makes a degree of sense that the Carthaginians might want to wage their imperial wars almost entirely with auxiliary troops recruited from their dependencies (or paid for as mercenaries), with Carthaginian citizens serving only as generals and officers, while reserving their citizen soldiers for operations closer to home. And there must have been more of such operations than we are aware of. Remember: Carthaginian armies really only become fully visible to us as they interact with Greek and Roman armies, but obviously Carthage must have accomplished the subjugation of much of North Africa, must have managed to subordinate (if not subdue) the Numidians, must have been able to hold that control through military strength (for our sources are very clear that Carthaginian control was often resented) and finally must have been able to also deter the Saharan, Berber and Lybian peoples on their borders.

In short, there is almost certainly quite a lot of Carthaginian campaigning in Africa which we can’t see clearly and it is possible that Carthaginian citizen soldiers continued to be active in these operations throughout. In that case, Carthage may well have kept its citizenry in some degree of readiness for war, which may explain why substantial bodies of Carthaginian citizen soldiers seem to be available and militarily effective so quickly when Carthage’s core territory in Africa is threatened. That said, short of some very convenient (and very unlikely) Punic inscriptions showing up, this remains merely a hypothesis; our sources offer no hint of this and indeed Polybius states the opposite, that the Carthaginian citizenry was broadly demilitarized.

Carthaginian Arms and Tactics

Of course, if Carthaginian citizens did sometimes fight, that raises a key question: how did Carthaginian citizens fight? With what arms and tactics?

The first answer is that our evidence is infuriatingly limited here. After all, Carthaginian citizen soldiers do most of their fighting visible to us relatively early where our main sources are writers like Diodorus, who – because he is writing a universal history covering everything from the earliest mythology (he includes the Fall of Troy) down to his own day (mid-first century B.C.) – rarely gives a lot of details. Normally we might supplement this with visual evidence in artwork or equipment deposited in graves, but there is very, very little of this. That point has sometimes been taken to reflect Carthage’s ‘unmilitary’ character, but it is worth noting that prior to 146, we have similarly little archaeological or representational evidence of the Roman Republic’s armies and no one accuses the Romans of being ‘unmilitary’ in character.

What evidence we do have suggests that the Carthaginians largely fought as heavy infantrymen in a manner not too different from Greek hoplites. Now I want to caveat that immediately to say this doesn’t mean they fought as hoplites – it is certainly possible but by no means necessarily or certain that the Carthaginians might have adopted weapons or tactics from the Greeks. The Levant had its own infantry traditions on which the Carthaginians might have drawn which included heavy armor and large shields. At the same time, as noted, it seems like Phoenician colonies drew in a lot of Aegean (read: Greek) settlers, so it would hardly be shocking of the Carthaginians did adopt Greek armaments.

However, I want to pause for a moment to draw one point of important clarification: at no point did any Carthaginian or any soldier in Carthaginian service that we know of, fight in a Macedonian-style pike phalanx. The idea that the Carthaginians adopted this style of fighting is based entirely on old mistranslation of lonchophoroi as ‘pikemen’ when in fact the lonche is a light spear and these are light infantry javelin-men fighting in support of African heavy infantry. We’ll talk more about them next week.

We have a few small engravings (small engraved impression seals called ‘scarabs’) from Carthage and Phoenician settlements in Sardinia, which depict soldiers and they show men with large apparently circular shields and spears.⁵ Numidian royal monuments, which may be drawing on Carthaginian material culture (it would have been high status) feature large round shields as a design motif and one intriguing monument, a statue base excavated in Rome, has been supposed by Ann Kuttner to possibly be a Numidian comission showing Numidian arms (or perhaps the captured arms of Carthaginians?) and shows a large round shield of the same type seen on their royal monumnets, alongside tube-and-yoke cuirasses (two of which are set up as trophies) and plumed helmets of the pilos/konos type (a kind of Hellenistic Greek helmet).⁶ And our literary sources regularly describe the Carthaginians as forming heavy infantry battle lines (using the word φάλαγξ, phalanx, to describe them) and report Carthaginians as wearing helmets and armor, with large shields and spears.⁷

Via the British Museum (inv. 127214), a fifth century Phoenician scarab showing a warrior wearing a cuirass, greaves, a helmet, a large (round?) shield and carrying a spear, found in Sardinia. While the curator’s description assumes this warrior is Greek, Carthaginian seems far more likely given the find location, art-style and equipment.

On that basis, both Gregory Daly and Joshua Hall (both op. cit.) conclude that the Carthaginians must have fought rather a lot like Greek hoplites and I think this is both basically correct and probably the best we can do. By the Punic Wars, we have hints that Carthaginian troops (both citizen and subject from North Africa) may also be adopting Italic equipment, which I’ll get into more in the next post: by the end of the Second Punic War and certainly by the Third Punic War, Carthaginian soldiers may have looked actually quite ‘Roman’ in their kit.

All of that said, as is obvious from the forces Carthage arrayed for the Punic Wars, Carthaginian armies included far more than just citizen soldiers – indeed, many Carthaginian armies evidently included few if any Carthaginian citizens outside of the officer corps. So to better understand Carthage’s armies, we are going to have to branch out to think about their other forces, which we’ll begin to do next week.

In a 2005 Y Combinator “class photo”, Altman and Swartz are standing next to each other. Despite the fact that Altman was sporting a reasonable number of popped polo collars (zero), Swartz was clearly the better-dressed of the two.^* ↩︎
* Aaron would’ve loved this footnote. Christ, I miss him.
With rare exceptions, I continue to think it’s a sign of deep C-suite dysfunction when a company has multiple “CEOs”. When it actually works — like at Netflix, with co-CEOs Ted Sarandos and Greg Peters (and previously, Sarandos and Reed Hastings before Hastings’s retirement in 2023) — the co-CEOs are genuine partners, and neither reports to the other. There is generally only one director of a movie, but there are exceptions, who are frequently siblings (e.g. the Coens, the Wachowskis, the Russos). A football team only has one head coach. The defensive coordinator is the “defensive coordinator”, not the “head coach of defense”. It’s obvious that Fidji Simo reports to Sam Altman, and thus isn’t the “CEO” of anything at OpenAI. But OpenAI does have applications, and surely is creating more of them, so being in charge of applications is being in charge of something real. By any reasonable definition, AGI has not yet been achieved, and many top AI experts continue to question whether LLM technology will ever result in AGI. So Simo changing her title to (or Altman changing her title to) “CEO of AGI deployment” is akin to changing her title to “CEO of ghost busting” in terms of its literal practical responsibility. ↩︎︎

Everybody seems to agree we’re in the middle of something, though what, exactly, seems to be up for debate. It might be an unprecedented revolution in productivity and capabilities, perhaps even the precursor to a technological “singularity” beyond which it’s impossible to guess what the world might look like. It might be just another vaporware hype cycle that will blow over. It might be a dot-com-style bubble that will lead to a big crash but still leave us with something useful (the way the dot-com bubble drove mass adoption of the web). It might be none of those things.

Many thousands of words have already been spent arguing variations of these positions. So of course today I’m going to throw a few thousand more words at it, because that’s what blogs are for. At least all the ones you’ll read here were written by me (and you can pry my em-dashes from my cold, dead hands).

Terminology, and picking a lane

But first, a couple quick notes:

I’m going to be using the terms “LLM” and “LLMs” almost exclusively in this post, because I think the precision is useful. “AI” is a vague and overloaded term, and it’s too easy to get bogged down in equivocations and debates about what exactly someone means by “AI”. And virtually everything that’s contentious right now about programming and “AI” is really traceable specifically to the advent of large language models. I suppose a slightly higher level of precision might come from saying “GPT” instead, but OpenAI keeps trying to claim that one as their own exclusive term, which is a different sort of unwelcome baggage. So “LLMs” it is.

And when I talk about “LLM coding”, I mean use of an LLM to generate code in some programming language. I use this as an umbrella term for all such usage, whether done under human supervision or not, whether used as the sole producer of code (with no human-generated code at all) or not, etc.

I’m also going to try to limit my comments here to things directly related to technology and to programming as a profession, because that’s what I know (I have a degree in philosophy, so I’m qualified to comment on some other aspects of LLMs, but I’m deliberately staying away from them in this post because I find a lot of those debates tedious and literally sophomoric, as in reminding me of things I was reading and discussing when I was a sophomore).

If you’re using an LLM in some other field, well, I probably don’t know that field well enough to usefully comment on it. Having seen some truly hot takes from people who didn’t follow this principle, I’ve thought several times that we really need some sort of cute portmanteau of “LLM” and “Gell-Mann Amnesia” for the way a lot of LLM-related discourse seems to be people expecting LLMs to take over every job and field except their own.

No silver bullet

A few years ago I wrote about Fred Brooks’ No Silver Bullet, and said I think it may have been the best thing Brooks ever wrote. If you’ve never read No Silver Bullet, I strongly recommend you do so, and I recommend you read the whole thing for yourself (rather than just a summary of it).

No Silver Bullet was published at a time when computing hardware was advancing at an incredible rate, but our ability to build software was not even close to keeping up. And so Brooks made a bold prediction about software:

There is no single development, in either technology or management technique, which by itself promises even a single order-of-magnitude improvement within a decade in productivity, in reliability, in simplicity.

To support this he looked at sources of difficulty in software development, and assigned them to two broad categories (emphasis as in the original):

Following Aristotle, I divide them into essence—the difficulties inherent in the nature of the software—and accidents—those difficulties that today attend its production but that are not inherent.

A classic example is memory management: some programming languages require the programmer to manually allocate, keep track of, and free memory, which is a source of difficulty. And this is accidental difficulty, because there’s nothing which inherently requires it; plenty of other programming languages have automatic memory management.

But other sources of difficulty are different, and seem to be inherent to software development itself. Here’s one of the ways Brooks summarizes it (emphasis matches what’s in my copy of No Silver Bullet):

The essence of a software entity is a construct of interlocking concepts: data sets, relationships among data items, algorithms, and invocations of functions. This essence is abstract, in that the conceptual construct is the same under many different representations. It is nonetheless highly precise and richly detailed.

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation. We still make syntax errors, to be sure; but they are fuzz compared to the conceptual errors in most systems.

If this is true, building software will always be hard. There is inherently no silver bullet.

And to drive the point home, he also explains the diminishing returns of only addressing accidental difficulty:

How much of what software engineers now do is still devoted to the accidental, as opposed to the essential? Unless it is more than 9/10 of all effort, shrinking all the accidental activities to zero time will not give an order of magnitude improvement.

This is a straightforward mathematical argument. If its two empirical premises—that the accidental/essential distinction is real and that the accidental difficulty remaining today does not represent 90%+ of total—are true, then the conclusion which rules out an order-of-magnitude gain from reducing accidental difficulty follows automatically.

I think most programmers believe the first premise, at least implicitly, and once the first premise is accepted it becomes very difficult to argue against the second. In fact, I’d personally go further than the minimum required for Brooks’ argument. His math holds up as long as accidental difficulty doesn’t reach that 90%+ mark, since anything lower makes a 10x improvement from eliminating accidental difficulty impossible. But I suspect accidental difficulty, today, is a vastly smaller proportion of the total than that. In a lot of mature domains of programming I’d be surprised if there’s even a doubling of productivity still available from a complete elimination of remaining accidental difficulty.

There’s also a section in No Silver Bullet about potential “hopes for the silver” which addresses “AI”, though what Brooks considered to be “AI” (and there is a tangent about clarifying exactly what the term means) was significantly different from what’s promoted today as “AI”. The most apt comparison to LLMs in No Silver Bullet is actually not the discussion of “AI”, it’s the discussion of automatic programming, which has meant a lot of different things over the years, but was defined by Brooks at the time as “the generation of a program for solving a problem from a statement of the problem specifications”. That’s pretty much the task for which LLMs are currently promoted to programmers.

But Brooks quotes David Parnas on the topic: “automatic programming always has been a euphemism for programming with a higher-level language than was presently available to the programmer.” And Brooks did not believe higher-level languages on their own could be a silver bullet. As he put it in a discussion of the Ada language:

It is, after all, just another high-level language, and the biggest payoff from such languages came from the first transition, up from the accidental complexities of the machine into the more abstract statement of step-by-step solutions. Once those accidents have been removed, the remaining ones are smaller, and the payoff from their removal will surely be less.

Many people are currently promoting LLMs as a revolutionary step forward for software development, but are doing so based almost exclusively on claims about LLMs’ ability to generate code at high speed. The No Silver Bullet argument poses a problem for these claims, since it sets a limit on how much we can gain from merely generating code more quickly.

In chapter 2 of The Mythical Man-Month, Brooks suggested as a scheduling guideline that five-sixths (83%) of time on a “software task” would be spent on things other than coding, which puts a pretty low cap on productivity gains from speeding up just the coding. And even if we assume LLMs reduce coding time to zero, and go with the more generous No Silver Bullet formulation which merely predicts no order-of-magnitude gain from a single development, that’s still less than the gain Brooks himself believed could come from hiring good human programmers. From chapter 3 of The Mythical Man-Month:

Programming managers have long recognized wide productivity variations between good programmers and poor ones. But the actual measured magnitudes have astounded all of us. In one of their studies, Sackman, Erikson, and Grant were measuring performances of a group of experienced programmers. Within just this group the ratios between best and worst performances averaged about 10:1 on productivity measurements and an amazing 5:1 on program speed and space measurements!

(although I’m personally skeptical of the “10x programmer” concept, the software industry overall does seem to accept it as true)

Anecdote time: much of what I’ve done over my career as a professional programmer is building database-backed web applications and services, and I don’t see much of a gain from LLMs. I suppose it looks impressive, if you’re not familiar with this field of programming, to auto-generate the skeleton of an entire application and the basic create/retrieve/update/delete HTTP handlers from no more than a description of the data you want to work with. But that capability predates LLMs: Rails’ scaffolding, for example, could do it twenty years ago.

And not just raw code generation, but also the abstractions available to work with, have progressed to the point where I basically never feel like the raw speed of production of code is holding me back. Just as Fred Brooks would have predicted, the majority of my time is spent elsewhere: talking to people who want new software (or who want existing software to be changed); finding out what it is they want and need; coming up with an initial specification; breaking it down into appropriately-sized pieces for programmers (maybe me, maybe someone else) to work on; testing the first prototype and getting feedback; preparing the next iteration; reviewing or asking for review, etc. I haven’t personally tracked whether it matches Brooks’ five-sixths estimate, but I wouldn’t be at all surprised if it did.

Given all that, just having an LLM churn out code faster than I would have myself is not going to offer me an order of magnitude improvement, or anything like it. Or as a recent popular blog post by the CEO of Tailscale put it:

AI’s direct impact on this problem is minimal. Okay, so Claude can code it in 3 minutes instead of 30? That’s super, Claude, great work.

Now you either get to spend 27 minutes reviewing the code yourself in a back-and-forth loop with the AI (this is actually kinda fun); or you save 27 minutes and submit unverified code to the code reviewer, who will still take 5 hours like before, but who will now be mad that you’re making them read the slop that you were too lazy to read yourself. Little of value was gained.

More simply: throwing more patches into the review queue, when the review queue still drains at the same rate as before, is not a recipe for increased velocity. Real software development involves not just a review queue but all the other steps and processes I outlined above, and more, and having an LLM generate code more quickly does not increase the speed or capacity of all those other things.

So as someone who accepts Brooks’ argument in No Silver Bullet, I am committed to believe on theoretical grounds that LLMs cannot offer “even a single order-of-magnitude improvement … in productivity, in reliability, in simplicity”. And my own experience matches up with that prediction.

Practice makes (im)perfect

But enough theory. What about the empirical actual reality of LLM coding?

Every fan of LLMs for coding has an anecdote about their revolutionary qualities, but the non-anecdotal data points we have are a lot more mixed. For example, several times now I’ve been linked to and asked to read the DORA report on the “State of AI-assisted Software Development”. And initially it certainly seems like it’s declaring the effects of LLMs are settled, in favor of the LLMs. From its executive summary (page 3):

[T]he central question for technology leaders is no longer if they should adopt AI, but how to realize its value.

And elsewhere it makes claims like (page 34) “AI is the new normal in software development”.

But then, going back to the executive summary, things start sounding less uniformly positive:

The research reveals a critical truth: AI’s primary role in software development is that of an amplifier. It magnifies the strengths of high-performing organizations and the dysfunctions of struggling ones.

And then (still on page 3):

The greatest returns on AI investment come not from the tools themselves, but from a strategic focus on the underlying organizational system: the quality of the internal platform, the clarity of workflows, and the alignment of teams. Without this foundation, AI creates localized pockets of productivity that are often lost to downstream chaos.

Continuing on to page 4:

AI adoption now improves software delivery throughput, a key shift from last year. However, it still increases delivery instability. This suggests that while teams are adapting for speed, their underlying systems have not yet evolved to safely manage AI-accelerated development.

“Delivery instability” is defined (page 13) in terms of two factors:

Change fail rate: “The ratio of deployments that require immediate intervention following a deployment.”
Rework rate: “The ratio of deployments that are unplanned but happen as a result of an incident in production.”

Later parts of the report get into more detail on this. Page 38 charts the increase in delivery instability, for example. And elsewhere in the section containing that chart, there’s a discussion of whether increases in throughput (defined by DORA as a combination of lead time for changes, deployment frequency, and failed deployment recovery time) are enough to offset or otherwise make up for this increase in instability (page 41, emphasis added by me):

Some might argue that instability is an acceptable trade-off for the gains in development throughput that AI-assisted development enables.

The reasoning is that the volume and speed of AI-assisted delivery could blunt the detrimental effects of instability, perhaps by enabling such rapid bug fixes and updates that the negative impact on the end-user is minimized.

However, when we look beyond pure software delivery metrics, this argument does not hold up. To assess this claim, we checked whether AI adoption weakens the harms of instability on our outcomes which have been hurt historically by instability.

We found no evidence of such a moderating effect. On the contrary, instability still has significant detrimental effects on crucial outcomes like product performance and burnout, which can ultimately negate any perceived gains in throughput.

And the chart on page 38 appears to show the increase in instability as quite a bit larger than the increase in throughput, in any case.

Curiously, that chart also claims a significant increase in “code quality”, and other parts of the report (page 30, for example) claim a significant increase in “productivity”, alongside the significant increase in delivery instability, which seems like it ought to be a contradiction. As far as I can tell, DORA’s source for both “productivity” and “code quality” is perceived impact as self-reported by survey respondents. Other studies and reports have designed less subjective and more quantitative ways to measure these things. For example, this much-discussed study on adoption of the Cursor LLM coding tool used the results of static analysis of the code to measure quality and complexity. And self-reported productivity impacts, in particular, ought to be a deeply suspect measure. From (to pick one relevant example) the METR early-2025 study (emphasis added by me):

This gap between perception and reality is striking: developers expected AI to speed them up by 24%, and even after experiencing the slowdown, they still believed AI had sped them up by 20%.

LLM coding advocates have often criticized this particular study’s finding of slower development for being based on older generations of LLMs (more on that argument in a bit), but as far as I’m aware nobody’s been able to seriously rebut the finding that developers are not very effective at self-estimating their productivity. So to see DORA relying on self-estimated productivity is disappointing.

The DORA report goes on to provide a seven-part “AI capabilities model” for organizations (begins on page 49), which consists of recommendations like: strong version control practices, working in small batches, quality internal platforms, user-centric focus… all of which feel like they should be table stakes for any successful organization regardless of whether they also happen to be using LLMs.

Suppose, for sake of a silly example, that someone told you a new technology is revolutionizing surgery, but the gains are not uniformly distributed, and the best overall outcomes are seen in surgical teams where in addition to using the new thing, team members also wash their hands prior to operating. That’s not as extreme a comparison as it might sound: the sorts of practices recommended for maximizing LLM-related gains in the DORA report, and in many other similar whitepapers and reports and studies, are or ought to be as fundamental to software development as hand-washing is to surgery. The Joel Test was recommending quite a few of these practices a quarter-century ago, the Agile Manifesto implied several of them, and even back then they weren’t really new; if you dig into the literature on effective software development you can find variations of much of the DORA advice going all the way back to the 1970s and even earlier.

For a more recent data point, I’ve seen a lot of people talking about and linking me to CircleCI’s 2026 “State of Software Delivery” which, like the DORA report, claims an uneven distribution of benefits from LLM adoption, and even says (page 8) “the majority of teams saw little to no increase in overall throughput”. The CircleCI report also raises a worrying point that echoes the increase in “delivery instability” seen in the DORA report (CircleCI executive summary, page 3):

Key stability indicators show that AI-driven changes are breaking more often and taking teams longer to fix, making validation and integration the primary bottleneck.

CircleCI further reports (page 11) that, year-over-year, they see a 13% increase in recovery time for a broken main branch, and a 25% increase for broken feature branches. And (page 12) they also say failures are increasing:

[S]uccess rates on the main branch fell to their lowest level in over 5 years, to 70.8%. In other words, attempts at merging changes into production code bases now fail 30% of the time.

For comparison, their own recommended benchmark of success for main branches is 90%.

The cost of these increasing failures and the increasing time to resolve them is quantified (emphasis matches the report, page 14):

For a team pushing 5 changes to the main branch per day, going from a 90% success rate to 70% is the difference between one showstopping breakage every two days to 1.5 every single day (a 3x increase).

At just 60 minutes recovery time per failure, you’re looking at an additional 250 hours in debugging and blocked deployments every year. And that’s at a relatively modest scale. Teams pushing 500 changes per day would lose the equivalent of 12 full-time engineers.

The usual response to reports like these is to claim they’re based on people using older LLMs, and the models coming out now are the truly revolutionary ones, which won’t have any of those problems. For example, this is the main argument that’s been leveled against the METR study I mentioned above. But that argument was flimsy to begin with (since it’s rarely accompanied by the kind of evidence needed to back up the claim), and its repeated usage is self-discrediting: if the people claiming “this time is the world-changing revolutionary leap, for sure” were wrong all the prior times they said that (as they have to have been, since if any prior time had actually been the revolutionary leap they wouldn’t need to say this time will be), why should anyone believe them this time?

Also, I’ve read a lot of studies and reports on LLM coding, and these sorts of findings—uneven or inconsistent impact, quality/stability declines, etc.—seem to be remarkably stable, across large numbers of teams using a variety of different models and different versions of those models, over an extended period of time (DORA does have a bit of a messy situation with contradictory claims that “code quality” is increasing while “delivery instability” is increasing even more, but as noted above that seems to be a methodological problem). The two I’ve quoted most extensively in this post (the DORA and CircleCI reports) were chosen specifically because they’re often recommended to me by advocates of LLM coding, and seem to be reasonably pro-LLM in their stances.

The other expected response to these findings is a claim that it’s not necessarily older models but older workflows which have been obsoleted, that the state of the art is no longer to just prompt an LLM and accept its output directly, but rather involves one LLM (or LLM-powered agent) generating code while one or more layers of “adversarial” ones review and fix up the code and also review each other’s reviews and responses and fixes, thus introducing a mechanism by which the LLM(s) will automatically improve the quality of the output.

I’m unaware of rigorous studies on these approaches (yet), but several well-publicized early examples do not inspire confidence. I’ll pick on Cloudflare here since they’ve been prominent advocates for using LLMs in this fashion. In their LLM rebuild of Next.js:

We wired up AI agents for code review too. When a PR was opened, an agent reviewed it. When review comments came back, another agent addressed them. The feedback loop was mostly automated.

But their public release of it, vetted through this process and, apparently, some amount of human review on top, was initially unable to run even the basic default Next.js application, and also was apparently riddled with security issues. From one disclosure post (emphasis added by me):

AI is now very good at getting a system to the point where it looks complete.

One specific problem cited was that the LLM rebuild simply did not pull in all the original tests, and therefore could miss security-critical cases those tests were checking. From the same disclosure post:

The process was feature-first: decide which viNext features existed, then port the corresponding Next.js tests. That is a sensible way to move quickly. It gives you broad happy-path coverage.

But it does not guarantee that you bring over the ugly regression tests, missing-export cases, and fail-open behavior checks that mature frameworks accumulate over years.

So middleware could look “covered” while the one test that proves it fails safely never made it over.

For example, Next.js has a dedicated test directory (test/e2e/app-dir/proxy-missing-export/) that validates what happens when middleware files lack required exports. That test was never ported because middleware was already considered “covered” by other tests.

On the whole, that post is somewhat optimistic, but considering that the Next.js rebuild was carried out by presumably knowledgeable people who presumably were following good modern practices and prompting good modern LLMs to perform a type of task those LLMs are supposed to be extremely good at—a language and framework well-represented in training data, well-documented, with a large existing test suite written in the target language to assist automated verification—I have a hard time being that optimistic.

And though I haven’t personally read through the recent alleged leak of the Claude Code source, I’ve read some commentary and analysis from people who have, and again it seems like a team that should be as well-positioned as anyone to take maximum advantage of the allegedly revolutionary capabilities of LLM coding isn’t managing to do so.

So the consistent theme here, in the studies and reports and in more recent public examples, is that being able to generate code much more quickly than before, even in 2026 with modern LLMs and modern practices, is still no guarantee of being able to deliver software much more quickly than before. As the CircleCI report puts it (page 3):

The data points to a clear conclusion: success in the AI era is no longer determined by how fast code can be written. The decisive factor is the ability to validate, integrate, and recover at scale.

And if that sounds like the kind of thing Fred Brooks used to say, that’s because it is the kind of thing Fred Brooks used to say. Raw speed of generating code is not and was not the bottleneck in software development, and speeding that up or even reducing the time to generate code to effectively zero does not have the effect of making all the other parts of software development go away or go faster.

So at this point it seems clear to me that in practice as well as in theory LLM coding does not represent a silver bullet, and it seems highly unlikely to transform into one at any point in the near future.

On being left behind

When expressing skepticism about LLM coding, a common response is that not adopting it, or even just delaying slightly in adopting it, will inevitably result in being “left behind”, or even stronger effects (for example, words like “obliterated” have been used, more than once, by acquaintances of mine who really ought to know better). LLMs are the future, it’s going to happen whether you like it or not, so get with the program before it’s too late!

I said I’ll stick to the technical mode here, but I’ll just mention in passing that the “it’s going to happen whether you like it or not” framing is something I’ve encountered a lot and found to be pretty disturbing and off-putting, and not at all conducive to changing my mind. And milder forms like “It’s undeniable that…” are rhetorically suspect. The burden of proof ought to be on the person making the claim that LLMs truly are revolutionary, but framing like this tries to implicitly shift that burden and is a rare example of literally begging the question: it assumes as given the conclusion (LLMs are in fact revolutionary) that it needs to prove.

Meanwhile, I see two possible outcomes:

The skeptical position wins. LLM coding tools do not achieve revolutionary silver-bullet status. Perhaps they become another tool in the toolbox, like TDD or pair programming, where some people and companies are really into them. Perhaps they become just another feature of IDEs, providing functionality like boilerplate generators to bootstrap a new project (if your favorite library/framework doesn’t provide its own bootstrap anyway).
The skeptical position loses. LLM coding tools do achieve true revolutionary silver-bullet status or beyond (consistently delivering one or more orders of magnitude improvement in software development productivity), and truly become a mandatory part of every working programmer’s tools and workflows, taking over all or nearly all generation of code.

In the first case, delayed adoption has no downside unless someone happens to be working at one of the companies that decide to mandate LLM use. And they can always pick it up at that point, if they don’t mind or if they don’t feel like looking for a new job.

As to the second case: based on what I’ve argued above about the status and prospects of LLMs up to now, I obviously think that continuing the type of progress in models and practices that’s been seen to date does not offer any viable path to a silver bullet. Which means a truly revolutionary breakthrough will have to be something sufficiently different from the current state of the art that it will necessarily invalidate many (or perhaps even all) prior LLM-based workflows in addition to invalidating non-LLM-based workflows.

And even if that doesn’t result in a completely clean-slate starting point with everyone equal—even if experience with older LLM workflows is still an advantage in the post-silver-bullet world—I don’t think it can ever be the sort of insurmountable advantage it’s often assumed to be. For one thing, even with vastly higher average productivity, there likely would not be sufficient people with sufficient pre-existing LLM experience to fill the vastly expanded demand for software that would result (this is why a lot of LLM advocates, across many fields, spend so much time talking about the Jevons paradox). For another, any true silver-bullet breakthrough would have to attack and reduce the essential difficulty of building software, rather than the accidental difficulty. Let us return once again to Brooks:

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

Much of the skill required of human LLM users today consists of exactly this: specifying and designing the software as a “conceptual construct”, albeit in specific ways that can be placed into an LLM’s context window in order to have it generate code. In any true silver-bullet world, much or all of that skillset would have to be rendered obsolete, which significantly reduces the penalty for late adoption if and when the silver bullet is finally achieved.

Power to the people?

Aside from impact on professional programmers and professional software-development teams, another claim often made in favor of LLM coding is that it will democratize access to software development. With LLM coding tools, people who aren’t experienced professional programmers can produce software that solves problems they face in their day-to-day jobs and lives. Surely that’s a huge societal benefit, right? And it’s tons of fun, too!

Setting aside that the New York Times piece linked above was written by someone who is an experienced professional, I’m not convinced of this use case either.

Mostly I think this is a situation where you can’t have it both ways. It seems to be widely agreed among advocates of LLM coding that it’s a skill which requires significant understanding, practice, and experience before one is able to produce consistent useful results (this is the basis of the “adopt now or be left behind” claim dealt with in the previous section); strong prior knowledge of how to design and build good software is also generally recommended or assumed. But that’s very much at odds with the democratized-software claim: that someone with no prior programming knowledge or experience will simply pick up an LLM, ask it in plain non-technical natural language to build something, and receive a sufficiently functional result.

I think the most likely result is that a non-technical user will receive something that’s obviously not fit for purpose, since they won’t have the necessary knowledge to prompt the LLM effectively. They won’t know how to set up directories of Markdown files containing instructions and skill definitions and architectural information for their problem. They won’t have practice at writing technical specifications (whether for other humans or for LLMs) to describe what they want in sufficient detail. They won’t know how to design and architect good software. They won’t know how to orchestrate multiple LLMs or LLM-powered agents to adversarially review each other. In short, they won’t have any of the skills that are supposed to be vital for successful LLM coding use.

There’s also the possibility that “natural” human language alone will never be sufficient to specify programs, even to much more advanced LLMs or other future “AI” systems, due to inherent ambiguity and lack of precision. In that case, some type of specialized formal language for specifying programs would always be necessary. Edsger W. Dijkstra, for example, took this position and famously derided what he called “the foolishness of ‘natural language programming’”, which is worth reading for some classic Dijkstra-isms like:

When all is said and told, the “naturalness” with which we use our native tongues boils down to the ease with which we can use them for making statements the nonsense of which is not obvious.

Another possible outcome for LLM coding by non-programmers is the often-mentioned analogy to 3D printing, which also was hyped up as a great democratizer that would let anyone design and make anything, but never delivered on that promise and, at the individual level, became a niche hobby for the small number of enthusiasts who were willing and able to put in the time, money, and effort to get moderately good at it.

But the nightmare result is that non-programmer LLM users will receive something that seems to work, and only reveals its shortcomings much later on. Given how often I see it argued that LLMs will democratize coding and write utility programs for people working in fields where privacy and confidentiality are both vital and legally mandated, I’m terrified by that potential failure mode. And I think one of the worst possible things that could happen for advocates of LLM adoption is to have the news full of stories of well-meaning non-technical people who had their lives ruined by, say, accidentally enabling a data breach with their LLM-coded helper programs, or even “just” turning loose a subtly-incorrect financial model on their business. So even if I were an advocate of LLM coding, I’d be very wary of pushing it to non-programmers.

But ultimately, the only situation in which LLMs could meaningfully democratize access to software development is one where they achieve a true silver bullet, by significantly reducing or removing essential difficulty from the software development process. And as noted above, LLM advocates seem to believe that even in the silver-bullet situation there would still be such a gap between those with pre-existing LLM usage skills and those without, that those without could never meaningfully catch up. Although I happen to disagree with that belief, it remains the case that advocates can’t have it both ways: either LLM coding will be an exclusive club for those who built up the necessary skills, XOR it will be a great democratizer and do away with the need for those skills.

Takeaways

I’m already over 6,000 words in this post, and though I could easily write many more, I should probably wrap it up.

If I had to summarize my position on LLM coding in one sentence, it would be “Please go read No Silver Bullet”. I think Brooks’ argument there is both theoretically correct and validated by empirical results, and sets some pretty strong limits on the impact LLM coding, or any other tool or technique which solely or primarily attacks accidental difficulty, can have.

Of course, limits on what we can do or gain aren’t necessarily the end of the world. Many of the foundations of computer science, from On Computable Numbers to Rice’s theorem and beyond, place inflexible limits on what we can do, but we still write software nonetheless, and we still work to advance the state of our art. So the No Silver Bullet argument is not the same as arguing that LLMs are necessarily useless, or that no gains can possibly be realized from them. But it is an argument that any gains we do realize are likely going to be incremental and evolutionary, rather than the world-changing revolution many people seem to be expecting.

Correspondingly, I think there is not a huge downside, right now, to slow or delayed adoption of LLM coding. Very few organizations have the strong fundamentals needed to absorb even a relatively moderate, incremental increase in the amount of code they generate, which I suspect is why so many studies and reports find mixed results and lots of broken CI pipelines. Not only is there no silver bullet, there especially is no quick or magical gain to be had from rushing to adopt LLM coding without first working on those fundamentals. In fact, the evidence we have says you’re more likely to hurt than help your productivity by doing so.

I also don’t think LLMs are going to meaningfully democratize coding any time soon; even if they become indispensable tools for programmers, they are likely to continue requiring users to “think like a programmer” when specifying and prompting. We would be much better served by teaching many more people how to think rigorously and reason about abstractions (and they would be much better served, too) than we would by just plopping them as-is in front of LLMs.

As for what you should be doing instead of rushing to adopt LLM coding out of fear that you’ll be left behind: I think you should be listening to what all those whitepapers and reports and studies are actually telling you, and working on fundamentals. You should be adopting and perfecting solid foundational software development practices like version control, comprehensive test suites, continuous integration, meaningful documentation, fast feedback cycles, iterative development, focus on users, small batches of work… things that have been known and proven for decades, but are still far too rare in actual real-world software shops.

If the skeptical position is wrong and it turns out LLMs truly become indispensable coding tools in the long term, well, the available literature says you’ll be set up to take the greatest possible advantage of them. And if it turns out they don’t, you’ll still be in much better shape than you were, and you’ll have an advantage over everyone who chased after wild promises of huge productivity gains by ordering their teams to just chew through tokens and generate code without working on fundamentals, and who likely wrecked their development processes by doing so.

Or as Fred Brooks put it:

The first step toward the management of disease was replacement of demon theories and humours theories by the germ theory. That very step, the beginning of hope, in itself dashed all hopes of magical solutions. It told workers that progress would be made stepwise, at great effort, and that a persistent, unremitting care would have to be paid to a discipline of cleanliness. So it is with software engineering today.