Bose re­leased the Application Programming Interface (API) doc­u­men­ta­tion for its SoundTouch speak­ers to­day, putting a sil­ver lin­ing around the im­pend­ing end-of-life (EoL) of the ex­pen­sive home the­ater de­vices.

In October, Bose an­nounced that its SoundTouch Wi-Fi speak­ers and sound­bars would be­come dumb speak­ers on February 18. At the time, Bose said that the speak­ers would only work if a de­vice was con­nected via AUX, HDMI, or Bluetooth (which has higher la­tency than Wi-Fi).

After that date, the speak­ers would stop re­ceiv­ing se­cu­rity and soft­ware up­dates and lose cloud con­nec­tiv­ity and their com­pan­ion app, the Framingham, Massachusetts-based com­pany said. Without the app, users would no longer be able to in­te­grate the de­vice with mu­sic ser­vices, such as Spotify, have mul­ti­ple SoundTouch de­vices play the same au­dio si­mul­ta­ne­ously, or use or edit saved pre­sets.

The an­nounce­ment frus­trated some of Bose’s long-time cus­tomers, some of whom own mul­ti­ple SoundTouch de­vices that still func­tion prop­erly. Many ques­tioned com­pa­nies’ in­creas­ingly com­mon prac­tice of brick­ing ex­pen­sive prod­ucts to fo­cus on new de­vices or to min­i­mize costs, or be­cause they’ve gone through ac­qui­si­tions or bank­ruptcy. SoundTouch speak­ers re­leased in 2013 and 2015 with prices rang­ing from $399 to $1,500.

Today, Bose had bet­ter news. In an email to cus­tomers, Bose an­nounced that AirPlay and Spotify Connect will still work with SoundTouch speak­ers af­ter EoL, ex­pand­ing the wire­less ca­pa­bil­i­ties that peo­ple will still be able to ac­cess.

Additionally, SoundTouch de­vices that sup­port AirPlay 2 will be able to play the same au­dio si­mul­ta­ne­ously.

The SoundTouch app will also live on, al­beit stripped of some func­tion­al­ity.

“On May 6, 2026, the app will up­date to a ver­sion that sup­ports the func­tions that can op­er­ate lo­cally with­out the cloud. No ac­tion will be re­quired on your part. Opening the app will ap­ply the up­date au­to­mat­i­cally,” Bose said.

is a news writer cov­er­ing all things con­sumer tech. Stevie started out at Laptop Mag writ­ing news and re­views on hard­ware, gam­ing, and AI.

Posts from this au­thor will be added to your daily email di­gest and your home­page feed.

Posts from this au­thor will be added to your daily email di­gest and your home­page feed.

In a sur­pris­ingly user-friendly move, Bose has an­nounced it will be open-sourc­ing the API doc­u­men­ta­tion for its SoundTouch smart speak­ers, which were slated to lose of­fi­cial sup­port on February 18th, as re­ported by Ars Technica. Bose has also moved that date back to May 6th, 2026.

When cloud sup­port ends, an up­date to the SoundTouch app will add lo­cal con­trols to re­tain as much func­tion­al­ity as pos­si­ble with­out cloud ser­vices. Users will still be able to stream mu­sic to SoundTouch speak­ers with Bluetooth, AirPlay, and Spotify Connect (plus phys­i­cal AUX con­nec­tions). Remote con­trol fea­tures and group­ing speak­ers will also con­tinue to work, and users will still be able to set up and con­fig­ure their SoundTouch speak­ers.

Now that the smart speak­ers’ API is be­ing open-sourced, users can also cre­ate their own com­pat­i­ble SoundTouch tools to help fill in any gaps left by the lack of cloud ser­vices. While it’s still dis­ap­point­ing that the speak­ers are los­ing of­fi­cial sup­port, Bose’s ap­proach at least lets peo­ple con­tinue us­ing their speak­ers, rather than brick­ing oth­er­wise func­tional de­vices.

This move from Bose is par­tic­u­larly sur­pris­ing be­cause of how rare it is. Usually when prod­ucts lose sup­port for cloud ser­vices, they end up bricked, and oc­ca­sion­ally users step in them­selves to fix things. For in­stance, when Pebble orig­i­nally shut down in 2016, users kept their watches func­tional by cre­at­ing the Rebble Alliance, a com­mu­nity-run re­place­ment for the watch­es’ cloud ser­vices, firmware, and app store.

Follow top­ics and au­thors from this story to see more like this in your per­son­al­ized home­page feed and to re­ceive email up­dates.

I was read­ing Macintosh Human Interface Guidelines from 1992 and found this nice il­lus­tra­tion:

Fast for­ward to 2025. Apple re­leases ma­cOS Tahoe. Main at­trac­tion? Adding un­pleas­ant, dis­tract­ing, il­leg­i­ble, messy, clut­tered, con­fus­ing, frus­trat­ing icons (their words, not mine!) to every menu item:

It’s bad. But why ex­actly is it bad? Let’s delve into it!

Disclaimer: screen­shots are a mix from ma­cOS 26.1 and 26.2, taken from stock Apple apps only that come pre-in­stalled with the sys­tem. No sys­tem set­tings were mod­i­fied.

The main func­tion of an icon is to help you find what you are look­ing for faster.

Perhaps counter-in­tu­itively, adding an icon to every­thing is ex­actly the wrong thing to do. To stand out, things need to be dif­fer­ent. But if every­thing has an icon, noth­ing stands out.

The same ap­plies to color: black-and-white icons look clean, but they don’t help you find things faster!

Microsoft used to know this:

Look how much faster you can find Save or Share in the right vari­ant:

It also looks cleaner. Less clut­tered.

A col­ored ver­sion would be even bet­ter (clearer sep­a­ra­tion of text from icon, faster to find):

I know you won’t like how it looks. I don’t like it ei­ther. These icons are hard to work with. You’ll have to ac­tu­ally de­sign for color to look nice. But the prin­ci­ple stands: it is way eas­ier to use.

If you want icons to work, they need to be con­sis­tent. I need to be able to learn what to look for.

For ex­am­ple, I see a “Cut” com­mand and next to it. Okay, I think. Next time I’m look­ing for “Cut,” I might save some time and start look­ing for in­stead.

How is Tahoe do­ing on that front? I pre­sent to you: Fifty Shades of “New”:

I even col­lected them all to­gether, so the ab­sur­dity of the sit­u­a­tion is more ob­vi­ous.

Granted, some of them are dif­fer­ent op­er­a­tions, so they have dif­fer­ent icons. I guess cre­at­ing a smart folder is dif­fer­ent from cre­at­ing a jour­nal en­try. But this?

There is no ex­cuse.

Yes. One of them is a check­mark. And they can’t even agree on the di­rec­tion of an ar­row!

Find (which is some­times called Search, and some­times Filter):

These are not some ob­scure, unique op­er­a­tions. These are OS ba­sics, these are foun­da­tional. Every app has them, and they are al­ways in the same place. They should­n’t look dif­fer­ent!

Icons are also used in tool­bars. Conceptually, op­er­a­tions in a tool­bar are iden­ti­cal to op­er­a­tions called through the menu, and thus should use the same icons. That’s the sim­plest case to im­ple­ment: in­side the same app, of­ten on the same screen. How hard can it be to stay con­sis­tent?

Photos: same and mis­match, but re­versed ¯\_(ツ)_/¯

Maps and oth­ers of­ten use dif­fer­ent sym­bols for zoom:

Another car­di­nal sin is to use the same icon for dif­fer­ent ac­tions. Imagine: I have learned that means “New”:

Then I open an app and see. “Cool”, I think, “I al­ready know what it means”:

You’d think: okay, means quick look:

Sometimes, sure. Some other times, means “Show com­pleted”:

Same as with con­sis­tency, icon reuse does­n’t only hap­pen be­tween apps. Sometimes you see in a tool­bar:

Then go to the menu in the same app and see means some­thing else:

Sometimes iden­ti­cal icons meet in the same menu.

Sometimes next to each other.

Sometimes they put an en­tire bar­rage of iden­ti­cal icons in a row:

This does­n’t help any­one. No user will find a menu item faster or will un­der­stand the func­tion bet­ter if all icons are the same.

The worst case of icon reuse so far has been the Photos app:

It feels like the per­son tasked with choos­ing a unique icon for every menu item just ran out of ideas.

When look­ing at icons, we usu­ally al­low for slight dif­fer­ences in ex­e­cu­tion. That lets us, for ex­am­ple, un­der­stand that these tech­ni­cally dif­fer­ent road signs mean the same thing:

Same ap­plies for icons: if you draw an ar­row go­ing out of the box in one place and also an ar­row and the box but at a slightly dif­fer­ent an­gle, or with dif­fer­ent stroke width, or make one filled, we will un­der­stand them as mean­ing the same thing.

Like, is sup­posed to mean some­thing else from ? Come on!

Or two let­ters A that only slightly dif­fer in the font size:

A pen­cil is “Rename” but a slightly thicker pen­cil is “Highlight”?

Arrows that use dif­fer­ent di­ag­o­nals?

Three dots oc­cu­py­ing ⅔ of space vs three dots oc­cu­py­ing every­thing. Seriously?

The sheet of pa­per that changes mean­ing de­pend­ing on if its cor­ner is folded or if there are lines in­side?

But the fi­nal boss are ar­rows. They are all dif­fer­ent:

Supposedly, a user must be­come an ex­pert at notic­ing how squished the cir­cle is, if it starts top to right or bot­tom to right, and how far the ar­row’s end goes.

Do I care? Honestly, no. I could’ve given it a shot, maybe, if Apple ap­plied these con­sis­tently. But Apple con­sid­ers and to mean the same thing in one place, and ex­pects me to no­tice minute de­tails like this in an­other?

Sorry, I can’t trust you. Not af­ter every­thing I’ve seen.

Icons are sup­posed to be eas­ily rec­og­niz­able from a dis­tance. Every icon de­signer knows: small de­tails are no-go. You can have them some­times, maybe, for aes­thetic pur­poses, but you can’t rely on them.

And icons in Tahoe menus are tiny. Most of them fit in a 12×12 pixel square (actual res­o­lu­tion is 24×24 be­cause of Retina), and be­cause many of them are not square, one di­men­sion is usu­ally even less than 12.

It’s not a lot of space to work with! Even Windows 95 had 16×16 icons. If we take the typ­i­cal DPI of that era at 72 dots per inch, we get a phys­i­cal icon size of 0.22 inches (5.6 mm). On a mod­ern MacBook Pro with 254 DPI, Tahoe’s 24×24 icons are 0.09 inches (2.4 mm). Sure, 24 is big­ger than 16, but in re­al­ity, these icons’ area is 4 times as small!

So when I see this:

I strug­gle. I can tell they are dif­fer­ent. But I def­i­nitely strug­gle to tell what’s be­ing drawn.

Even zoomed in 20×, it’s still a mess:

Or here. These are three dif­fer­ent icons:

Am I sup­posed to tell plus sign from sparkle here?

Some of these lines are half the pixel thicker than the other lines, and that’s sup­posed to be the main point:

Is this sup­posed to be an ar­row?

It even got an even tinier viewfinder, which you can al­most see if you zoom in 20×:

Or here. There is a box, in­side that box is a cir­cle, and in­side it is a tiny let­ter i with a to­tal height of 2 pix­els:

And this is a win­dow! It even has traf­fic lights! How adorable:

Remember: these are retina pix­els, ¼ of a real pixel. Steve Jobs him­self claimed they were in­vis­i­ble.

It turns out there’s a magic num­ber right around 300 pix­els per inch, that when you hold some­thing around to 10 to 12 inches away from your eyes, is the limit of the hu­man retina to dif­fer­en­ti­ate the pix­els.

And yet, Tahoe icons rely on you be­ing able to see them.

When you have so lit­tle space to work with, every pixel mat­ters. You can make a good icon, but you have to choose your pix­els very care­fully.

For Tahoe icons, Apple de­cided to use vec­tor fonts in­stead of good old-fash­ioned bitmaps. It saves Apple re­sources—draw once, use every­where. Any size, any dis­play res­o­lu­tion, any font width.

But there’re down­sides: fonts are hard to po­si­tion ver­ti­cally, their size does­n’t map di­rectly to pix­els, stroke width does­n’t map 1-to-1 to pixel grid, etc. So, they work every­where, but they also look blurry and mediocre every­where:

They cer­tainly start to work bet­ter once you give them more pix­els.

or make graph­ics sim­pler. But the com­bi­na­tion of small de­tails and tiny icon size is deadly. So, un­til Apple re­leases MacBooks with 380+ DPI, un­for­tu­nately, we still have to care about the pixel grid.

Icons might serve an­other func­tion: to help users un­der­stand the mean­ing of the com­mand.

For ex­am­ple, once you know the con­text (move win­dow), these icons ex­plain what’s go­ing on faster than words:

But for this to work, the user must un­der­stand what’s drawn on the icon. It must be a fa­mil­iar ob­ject with a clear trans­la­tion to com­puter ac­tion (like Trash can → Delete), a widely used sym­bol, or an easy-to-un­der­stand di­a­gram. HIG:

A rookie mis­take would be to mis­rep­re­sent the ob­ject. For ex­am­ple, this is how se­lec­tion looks like:

But its icon looks like this:

Honestly, I’ve been writ­ing this es­say for a week, and I still have zero ideas why it looks like that. There’s an ob­ject that looks like this, but it’s a text block in Freeform/Preview:

Why did it be­come a metaphor for “Select all”? My best guess is it’s a mis­take.

Another place uses text se­lec­tion from iOS as a metaphor. On a Mac!

Some con­cepts have ob­vi­ous or well-es­tab­lished metaphors. In that case, it’s a mis­take not to use them. For ex­am­ple, book­marks: . Apple, for some rea­son, went with a book:

Sometimes you al­ready have an in­ter­face el­e­ment and can use it for an icon. However, try not to con­fuse your users. Dots in a rec­tan­gle look like pass­word in­put, not per­mis­sions:

Icon here says “Check” but the ac­tion is “Uncheck”.

Terrible mis­take: icon does­n’t help, it ac­tively con­fuses the user.

It’s also tempt­ing to con­struct a two-level icon: an ob­ject and some sort of in­di­ca­tor. Like, a check­box and a cross, mean­ing “Delete check­box”:

Or a user and a check­mark, like “Check the user”:

Unfortunately, con­structs like this rarely work. Users don’t build sen­tences from build­ing blocks you pro­vide; they have no de­sire to solve these puz­zles.

Finding metaphors is hard. Nouns are eas­ier than verbs, and menu items are mostly verbs. How does open look? Like an ar­row point­ing to the top right? Why?

I’m not say­ing there’s an ob­vi­ous metaphor for “Open” Apple missed. There is­n’t. But that’s the point: if you can’t find a good metaphor, us­ing no icon is bet­ter than us­ing a bad, con­fus­ing, or non­sen­si­cal icon.

There’s a game I like to play to test the qual­ity of the metaphor. Remove the la­bels and try to guess the mean­ing. Give it a try:

It’s delu­sional to think that there’s a good icon for every ac­tion if you think hard enough. There is­n’t. It’s a lost bat­tle from the start. No amount of money or “management de­ci­sions” is go­ing to change that. The prob­lems are 100% self-in­flicted.

All this be­ing said, I gotta give Apple credit where credit is due. When they are good at choos­ing metaphors, they are good:

A spe­cial case of a con­fus­ing metaphor is us­ing dif­fer­ent metaphors for ac­tions that are di­rect op­po­sites of one an­other. Like Undo/Redo, Open/Close, Left/Right.

It’s good when their icons use the same metaphor:

Because it saves you time and cog­ni­tive re­sources. Learn one, get an­other one for free.

Because of that, it’s a mis­take not to use com­mon metaphors for re­lated ac­tions:

Another mis­take is to cre­ate sym­me­try where there is none. “Back” and “See all”?

Some menus in Tahoe make both mis­takes. E.g. lack of sym­me­try be­tween Show/Hide and false sym­me­try be­tween com­pleted/​sub­tasks:

Import not mir­rored by Export but by Share:

Authors of HIG are ar­gu­ing against in­clud­ing text as a part of an icon. So some­thing like this:

would not fly in 1992.

I agree, but Tahoe has more se­ri­ous prob­lems: icons con­sist­ing only of text. Like this:

It’s un­clear where “metaphorical, ab­stract icon text that is not sup­posed to be read lit­er­ally” ends and ac­tual text starts. They use the same font, the same color, so how am I sup­posed to dif­fer­en­ti­ate? Icons just get in a way: A…Complete? AaFont? What does it mean?

If things go our way, YouTube’s no­to­ri­ous un­skip­pable ads might be a thing of the past come this February.

As Phụ Nữ re­ports, Vietnam re­cently an­nounced Decree No. 342, which de­tails a num­ber of pro­vi­sions to the na­tional Advertising Law, due to take ef­fect from February 15, 2026. The ad­just­ments are ex­pected to place stricter con­trol on Vietnam’s on­line ad­ver­tis­ing ac­tiv­i­ties to pro­tect con­sumers and curb il­le­gal ads.

Amongst the de­cree ar­ti­cles, some stand­out stip­u­la­tions in­clude a hard cap on the wait­ing time be­fore view­ers can skip video and an­i­mated ads to no more than 5 sec­onds. Static ads must be im­me­di­ately can­cellable.

Additionally, the de­cree re­quires plat­forms to im­ple­ment clear and straight­for­ward ways for users to close ads with just one in­ter­ac­tion. False or vague sym­bols de­signed to con­fuse view­ers are for­bid­den.

Online plat­forms must add vis­i­ble sym­bols and guide­lines to help users re­port ads that vi­o­late the law and al­low them to turn off, deny, or stop see­ing in­ap­pro­pri­ate ads.

Beside rules about the user ex­pe­ri­ence, the de­cree also seeks to tightly reg­u­late ads for 11 groups of goods and ser­vices that di­rectly im­pact the en­vi­ron­ment and hu­man health, in­clud­ing: cos­met­ics; food and bev­er­ages; milk and for­mula for chil­dren; in­sec­ti­ci­dal chem­i­cals and sub­stances; med­ical sup­plies; health­care ser­vices; plant pes­ti­cides and vet­eri­nary drugs; fer­til­iz­ers; plant seeds and saplings; phar­ma­ceu­ti­cals; and al­co­holic drinks.

When I joined Google ~14 years ago, I thought the job was about writ­ing great code. I was partly right. But the longer I’ve stayed, the more I’ve re­al­ized that the en­gi­neers who thrive aren’t nec­es­sar­ily the best pro­gram­mers - they’re the ones who’ve fig­ured out how to nav­i­gate every­thing around the code: the peo­ple, the pol­i­tics, the align­ment, the am­bi­gu­ity.

These lessons are what I wish I’d known ear­lier. Some would have saved me months of frus­tra­tion. Others took years to fully un­der­stand. None of them are about spe­cific tech­nolo­gies - those change too fast to mat­ter. They’re about the pat­terns that keep show­ing up, pro­ject af­ter pro­ject, team af­ter team.

I’m shar­ing them be­cause I’ve ben­e­fited enor­mously from en­gi­neers who did the same for me. Consider this my at­tempt to pay it for­ward.

It’s se­duc­tive to fall in love with a tech­nol­ogy and go look­ing for places to ap­ply it. I’ve done it. Everyone has. But the en­gi­neers who cre­ate the most value work back­wards: they be­come ob­sessed with un­der­stand­ing user prob­lems deeply, and let so­lu­tions emerge from that un­der­stand­ing.

User ob­ses­sion means spend­ing time in sup­port tick­ets, talk­ing to users, watch­ing users strug­gle, ask­ing “why” un­til you hit bedrock. The en­gi­neer who truly un­der­stands the prob­lem of­ten finds that the el­e­gant so­lu­tion is sim­pler than any­one ex­pected.

The en­gi­neer who starts with a so­lu­tion tends to build com­plex­ity in search of a jus­ti­fi­ca­tion.

You can win every tech­ni­cal ar­gu­ment and lose the pro­ject. I’ve watched bril­liant en­gi­neers ac­crue silent re­sent­ment by al­ways be­ing the smartest per­son in the room. The cost shows up later as “mysterious ex­e­cu­tion is­sues” and “strange re­sis­tance.”

The skill is­n’t be­ing right. It’s en­ter­ing dis­cus­sions to align on the prob­lem, cre­at­ing space for oth­ers, and re­main­ing skep­ti­cal of your own cer­tainty.

Strong opin­ions, weakly held - not be­cause you lack con­vic­tion, but be­cause de­ci­sions made un­der un­cer­tainty should­n’t be welded to iden­tity.

The quest for per­fec­tion is par­a­lyz­ing. I’ve watched en­gi­neers spend weeks de­bat­ing the ideal ar­chi­tec­ture for some­thing they’ve never built. The per­fect so­lu­tion rarely emerges from thought alone - it emerges from con­tact with re­al­ity. AI can in many ways help here.

First do it, then do it right, then do it bet­ter. Get the ugly pro­to­type in front of users. Write the messy first draft of the de­sign doc. Ship the MVP that em­bar­rasses you slightly. You’ll learn more from one week of real feed­back than a month of the­o­ret­i­cal de­bate.

The in­stinct to write clever code is al­most uni­ver­sal among en­gi­neers. It feels like proof of com­pe­tence.

But soft­ware en­gi­neer­ing is what hap­pens when you add time and other pro­gram­mers. In that en­vi­ron­ment, clar­ity is­n’t a style pref­er­ence - it’s op­er­a­tional risk re­duc­tion.

Your code is a strat­egy memo to strangers who will main­tain it at 2am dur­ing an out­age. Optimize for their com­pre­hen­sion, not your el­e­gance. The se­nior en­gi­neers I re­spect most have learned to trade clev­er­ness for clar­ity, every time.

Treat your tech­nol­ogy choices like an or­ga­ni­za­tion with a small “innovation to­ken” bud­get. Spend one each time you adopt some­thing ma­te­ri­ally non-stan­dard. You can’t af­ford many.

The punch­line is­n’t “never in­no­vate.” It’s “innovate only where you’re uniquely paid to in­no­vate.” Everything else should de­fault to bor­ing, be­cause bor­ing has known fail­ure modes.

The “best tool for the job” is of­ten the “least-worst tool across many jobs”-be­cause op­er­at­ing a zoo be­comes the real tax.

Early in my ca­reer, I be­lieved great work would speak for it­self. I was wrong. Code sits silently in a repos­i­tory. Your man­ager men­tions you in a meet­ing, or they don’t. A peer rec­om­mends you for a pro­ject, or some­one else.

In large or­ga­ni­za­tions, de­ci­sions get made in meet­ings you’re not in­vited to, us­ing sum­maries you did­n’t write, by peo­ple who have five min­utes and twelve pri­or­i­ties. If no one can ar­tic­u­late your im­pact when you’re not in the room, your im­pact is ef­fec­tively op­tional.

This is­n’t strictly about self-pro­mo­tion. It’s about mak­ing the value chain leg­i­ble to every­one- in­clud­ing your­self.

We cel­e­brate cre­ation in en­gi­neer­ing cul­ture. Nobody gets pro­moted for delet­ing code, even though dele­tion of­ten im­proves a sys­tem more than ad­di­tion. Every line of code you don’t write is a line you never have to de­bug, main­tain, or ex­plain.

Before you build, ex­haust the ques­tion: “What would hap­pen if we just… did­n’t?” Sometimes the an­swer is “nothing bad,” and that’s your so­lu­tion.

The prob­lem is­n’t that en­gi­neers can’t write code or use AI to do so. It’s that we’re so good at writ­ing it that we for­get to ask whether we should.

With enough users, every ob­serv­able be­hav­ior be­comes a de­pen­dency - re­gard­less of what you promised. Someone is scrap­ing your API, au­tomat­ing your quirks, caching your bugs.

This cre­ates a ca­reer-level in­sight: you can’t treat com­pat­i­bil­ity work as “maintenance” and new fea­tures as “real work.” Compatibility is prod­uct.

Design your dep­re­ca­tions as mi­gra­tions with time, tool­ing, and em­pa­thy. Most “API de­sign” is ac­tu­ally “API re­tire­ment.”

When a pro­ject drags, the in­stinct is to blame ex­e­cu­tion: peo­ple aren’t work­ing hard enough, the tech­nol­ogy is wrong, there aren’t enough en­gi­neers. Usually none of that is the real prob­lem.

In large com­pa­nies, teams are your unit of con­cur­rency, but co­or­di­na­tion costs grow geo­met­ri­cally as teams mul­ti­ply. Most slow­ness is ac­tu­ally align­ment fail­ure - peo­ple build­ing the wrong things, or the right things in in­com­pat­i­ble ways.

Senior en­gi­neers spend more time clar­i­fy­ing di­rec­tion, in­ter­faces, and pri­or­i­ties than “writing code faster” be­cause that’s where the ac­tual bot­tle­neck lives.

In a large com­pany, count­less vari­ables are out­side your con­trol - or­ga­ni­za­tional changes, man­age­ment de­ci­sions, mar­ket shifts, prod­uct piv­ots. Dwelling on these cre­ates anx­i­ety with­out agency.

The en­gi­neers who stay sane and ef­fec­tive zero in on their sphere of in­flu­ence. You can’t con­trol whether a re­org hap­pens. You can con­trol the qual­ity of your work, how you re­spond, and what you learn. When faced with un­cer­tainty, break prob­lems into pieces and iden­tify the spe­cific ac­tions avail­able to you.

This is­n’t pas­sive ac­cep­tance but it is strate­gic fo­cus. Energy spent on what you can’t change is en­ergy stolen from what you can.

Every ab­strac­tion is a bet that you won’t need to un­der­stand what’s un­der­neath. Sometimes you win that bet. But some­thing al­ways leaks, and when it does, you need to know what you’re stand­ing on.

Senior en­gi­neers keep learn­ing “lower level” things even as stacks get higher. Not out of nos­tal­gia, but out of re­spect for the mo­ment when the ab­strac­tion fails and you’re alone with the sys­tem at 3am. Use your stack.

But keep a work­ing model of its un­der­ly­ing fail­ure modes.

Writing forces clar­ity. When I ex­plain a con­cept to oth­ers - in a doc, a talk, a code re­view com­ment, even just chat­ting with AI - I dis­cover the gaps in my own un­der­stand­ing. The act of mak­ing some­thing leg­i­ble to some­one else makes it more leg­i­ble to me.

This does­n’t mean that you’re go­ing to learn how to be a sur­geon by teach­ing it, but the premise still holds largely true in the soft­ware en­gi­neer­ing do­main.

This is­n’t just about be­ing gen­er­ous with knowl­edge. It’s a self­ish learn­ing hack. If you think you un­der­stand some­thing, try to ex­plain it sim­ply. The places where you stum­ble are the places where your un­der­stand­ing is shal­low.

Teaching is de­bug­ging your own men­tal mod­els.

Glue work - doc­u­men­ta­tion, on­board­ing, cross-team co­or­di­na­tion, process im­prove­ment - is vi­tal. But if you do it un­con­sciously, it can stall your tech­ni­cal tra­jec­tory and burn you out. The trap is do­ing it as “helpfulness” rather than treat­ing it as de­lib­er­ate, bounded, vis­i­ble im­pact.

Timebox it. Rotate it. Turn it into ar­ti­facts: docs, tem­plates, au­toma­tion. And make it leg­i­ble as im­pact, not as per­son­al­ity trait.

Priceless and in­vis­i­ble is a dan­ger­ous com­bi­na­tion for your ca­reer.

I’ve learned to be sus­pi­cious of my own cer­tainty. When I “win” too eas­ily, some­thing is usu­ally wrong. People stop fight­ing you not be­cause you’ve con­vinced them, but be­cause they’ve given up try­ing - and they’ll ex­press that dis­agree­ment in ex­e­cu­tion, not meet­ings.

Real align­ment takes longer. You have to ac­tu­ally un­der­stand other per­spec­tives, in­cor­po­rate feed­back, and some­times change your mind pub­licly.

The short-term feel­ing of be­ing right is worth much less than the long-term re­al­ity of build­ing things with will­ing col­lab­o­ra­tors.

Every met­ric you ex­pose to man­age­ment will even­tu­ally be gamed. Not through mal­ice, but be­cause hu­mans op­ti­mize for what’s mea­sured.

If you track lines of code, you’ll get more lines. If you track ve­loc­ity, you’ll get in­flated es­ti­mates.

The se­nior move: re­spond to every met­ric re­quest with a pair. One for speed. One for qual­ity or risk. Then in­sist on in­ter­pret­ing trends, not wor­ship­ing thresh­olds. The goal is in­sight, not sur­veil­lance.

Senior en­gi­neers who say “I don’t know” aren’t show­ing weak­ness - they’re cre­at­ing per­mis­sion. When a leader ad­mits un­cer­tainty, it sig­nals that the room is safe for oth­ers to do the same. The al­ter­na­tive is a cul­ture where every­one pre­tends to un­der­stand and prob­lems stay hid­den un­til they ex­plode.

I’ve seen teams where the most se­nior per­son never ad­mit­ted con­fu­sion, and I’ve seen the dam­age. Questions don’t get asked. Assumptions don’t get chal­lenged. Junior en­gi­neers stay silent be­cause they as­sume every­one else gets it.

Model cu­rios­ity, and you get a team that ac­tu­ally learns.

Early in my ca­reer, I fo­cused on the work and ne­glected net­work­ing. In hind­sight, this was a mis­take. Colleagues who in­vested in re­la­tion­ships - in­side and out­side the com­pany - reaped ben­e­fits for decades.

They heard about op­por­tu­ni­ties first, could build bridges faster, got rec­om­mended for roles, and co-founded ven­tures with peo­ple they’d built trust with over years.

Your job is­n’t for­ever, but your net­work is. Approach it with cu­rios­ity and gen­eros­ity, not trans­ac­tional hus­tle.

When the time comes to move on, it’s of­ten re­la­tion­ships that open the door.

When sys­tems get slow, the in­stinct is to add: caching lay­ers, par­al­lel pro­cess­ing, smarter al­go­rithms. Sometimes that’s right. But I’ve seen more per­for­mance wins from ask­ing “what are we com­put­ing that we don’t need?”

Deleting un­nec­es­sary work is al­most al­ways more im­pact­ful than do­ing nec­es­sary work faster. The fastest code is code that never runs.

Before you op­ti­mize, ques­tion whether the work should ex­ist at all.

The best process makes co­or­di­na­tion eas­ier and fail­ures cheaper. The worst process is bu­reau­cratic the­ater - it ex­ists not to help but to as­sign blame when things go wrong.

If you can’t ex­plain how a process re­duces risk or in­creases clar­ity, it’s prob­a­bly just over­head.

And if peo­ple are spend­ing more time doc­u­ment­ing their work than do­ing it, some­thing has gone deeply wrong.

Early in your ca­reer, you trade time for money - and that’s fine. But at some point, the cal­cu­lus in­verts. You start to re­al­ize that time is the non-re­new­able re­source.

I’ve watched se­nior en­gi­neers burn out chas­ing the next promo level, op­ti­miz­ing for a few more per­cent­age points of com­pen­sa­tion. Some of them got it. Most of them won­dered, af­ter­ward, if it was worth what they gave up.

The an­swer is­n’t “don’t work hard.” It’s “know what you’re trad­ing, and make the trade de­lib­er­ately.”

Expertise comes from de­lib­er­ate prac­tice - push­ing slightly be­yond your cur­rent skill, re­flect­ing, re­peat­ing. For years. There’s no con­densed ver­sion.

But here’s the hope­ful part: learn­ing com­pounds when it cre­ates new op­tions, not just new trivia. Write - not for en­gage­ment, but for clar­ity. Build reusable prim­i­tives. Collect scar tis­sue into play­books.

The en­gi­neer who treats their ca­reer as com­pound in­ter­est, not lot­tery tick­ets, tends to end up much fur­ther ahead.

Twenty-one lessons sounds like a lot, but they re­ally come down to a few core ideas: stay cu­ri­ous, stay hum­ble, and re­mem­ber that the work is al­ways about peo­ple - the users you’re build­ing for and the team­mates you’re build­ing with.

A ca­reer in en­gi­neer­ing is long enough to make plenty of mis­takes and still come out ahead. The en­gi­neers I ad­mire most aren’t the ones who got every­thing right - they’re the ones who learned from what went wrong, shared what they dis­cov­ered, and kept show­ing up.

If you’re early in your jour­ney, know that it gets richer with time. If you’re deep into it, I hope some of these res­onate.

Have a ques­tion about this pro­ject? Sign up for a free GitHub ac­count to open an is­sue and con­tact its main­tain­ers and the com­mu­nity.

By click­ing “Sign up for GitHub”, you agree to our terms of ser­vice and pri­vacy state­ment. We’ll oc­ca­sion­ally send you ac­count re­lated emails.

Already on GitHub? Sign in

to your ac­count

An of­fi­cial web­site of the

Better health be­gins on your plate—not in your med­i­cine cab­i­net.

The new Dietary Guidelines for Americans de­fines real food as whole, nu­tri­ent-dense, and nat­u­rally oc­cur­ring, plac­ing them back at the cen­ter of our di­ets. The State of Our Health50% of Americans have 75% of adults re­port hav­ing at least one 90% of U.S. health­care spend­ing goes to treat­ing —much of which is linked to diet and lifestyle We are end­ing the war on pro­tein. Every meal must pri­or­i­tize high-qual­ity, nu­tri­ent-dense pro­tein from both an­i­mal and plant sources, paired with healthy fats from whole foods such as eggs, seafood, meats, full-fat dairy, nuts, seeds, olives, and av­o­ca­dos.Pro­tein tar­get: ~0.54–0.73 grams per pound of body weight per dayVeg­eta­bles and fruits are es­sen­tial to real food nu­tri­tion. Eat a wide va­ri­ety of whole, col­or­ful, nu­tri­ent-dense veg­eta­bles and fruits in their orig­i­nal form, pri­or­i­tiz­ing fresh­ness and min­i­mal pro­cess­ing.Whole grains are en­cour­aged. Refined car­bo­hy­drates are not. Prioritize fiber-rich whole grains and sig­nif­i­cantly re­duce the con­sump­tion of highly processed, re­fined car­bo­hy­drates that dis­place real nour­ish­ment.What is the New Pyramid?The New Pyramid is a sim­ple guide de­signed to help Americans eat real, whole foods more con­sis­tently. It pri­or­i­tizes nu­tri­ent-dense foods and re­duces re­liance on highly processed prod­ucts, us­ing mod­ern nu­tri­tion sci­ence to sup­port every­day health.What does “Eat Real Food” mean?Eat­ing real food means choos­ing foods that are whole or min­i­mally processed and rec­og­niz­able as food. These foods are pre­pared with few in­gre­di­ents and with­out added sug­ars, in­dus­trial oils, ar­ti­fi­cial fla­vors, or preser­v­a­tives.Why does the New Pyramid em­pha­size pro­tein and veg­eta­bles?Pro­tein and veg­eta­bles form the foun­da­tion of real food meals. Together, they sup­port mus­cle health, meta­bolic func­tion, gut health, and sta­ble en­ergy while nat­u­rally crowd­ing out highly processed foods.Yes. Healthy fats are a nat­ural part of real foods such as meat, seafood, dairy, nuts, olives, and av­o­ca­dos. These fats sup­port brain health, hor­mone func­tion, and nu­tri­ent ab­sorp­tion when con­sumed in their nat­ural forms.How does the New Pyramid ad­dress added sug­ars?Added sug­ars are not part of eat­ing real foods and are not rec­om­mended. The New Pyramid en­cour­ages avoid­ing added sug­ars en­tirely, es­pe­cially for chil­dren, while al­low­ing nat­u­rally oc­cur­ring sug­ars found in whole fruits and plain dairy.Where do grains fit in the New Pyramid?Grains can be part of a real food diet when eaten in whole or tra­di­tion­ally pre­pared forms. Foods like oats, rice, and true sour­dough are pre­ferred. Refined and pack­aged grain prod­ucts should be lim­ited.Hy­dra­tion mat­ters. Choose wa­ter or unsweet­ened bev­er­ages to ac­com­pany meals and snacks.Is the New Pyramid a strict diet?No. The New Pyramid is a flex­i­ble frame­work meant to guide bet­ter choices, not dic­tate ex­act meals. It sup­ports cul­tural tra­di­tions, per­sonal pref­er­ences, and dif­fer­ent lifestyles while re­in­forc­ing one core goal: eat real foods most of the time.Ex­plore the re­search, rec­om­men­da­tions, and im­ple­men­ta­tion guid­ance that shape the Dietary Guidelines, in­clud­ing the sci­ence, the pol­icy guid­ance, and the every­day serv­ing frame­work.

The Low Orbit Security Radar is a weekly se­cu­rity newslet­ter from an of­fen­sive prac­ti­tion­er’s per­spec­tive. One idea, cu­rated news, and links worth your time.

When watch­ing the sit­u­a­tion in Venezuela un­fold, the phrase “It was dark, the lights of Caracas were largely turned off due to a cer­tain ex­per­tise that we have” caught my at­ten­tion. I do not wish to com­ment on the geopo­lit­i­cal sit­u­a­tion other than to pro­vide some in­sights within my area of com­pe­tency, specif­i­cally, of­fen­sive se­cu­rity.

During a press con­fer­ence, General John D. Caine stated: “As they ap­proached Venezuelan shores the United States be­gan lay­er­ing dif­fer­ent ef­fects pro­vided by SPACECOM, CYBERCOM, and other mem­bers of the in­ter-agency to cre­ate a path­way”. Cyber op­er­a­tions pre­ced­ing tra­di­tional mil­i­tary ac­tions have be­come a com­mon pat­tern so I started dig­ging into the re­ported in­ter­net out­ages.

BGP is the first thing that comes to mind. It’s a pro­to­col used by routers to de­ter­mine what path data takes to get to it’s des­ti­na­tion, it does this by ex­chang­ing rout­ing in­for­ma­tion be­tween Autonomous Systems. It is also no­to­ri­ously in­se­cure and much of the data about BGP is col­lected in pub­lic datasets. Every ma­jor net­work has an Autonomous System Number or ASN. CANTV (AS8048) is Venezuela’s state-owned tele­com, so that’s the ob­vi­ous place to start.

Cloudflare Radar’s route leak data for AS8048 on January 2nd had some in­ter­est­ing anom­alies: 8 pre­fixes (blocks of IP ad­dresses) were be­ing routed through CANTV, with Sparkle (an Italian tran­sit provider) and GlobeNet (a Colombian car­rier) in the Autonomous System (AS) path. The AS path is es­sen­tially the list of net­works traf­fic passes through to reach its des­ti­na­tion. CANTV was in a path it is not typ­i­cally a part of.

There was also a no­tice­able spike in BGP an­nounce­ments in the days lead­ing up to the events and a dras­tic dip in the “Announced IP Address Space” ac­cord­ing to the same Cloudflare Radar data, al­though it’s un­clear what this in­di­cates.

Notably, Sparkle is one of the tran­sit providers in the AS path listed as “unsafe” on is­bg­p­safeyet.com, mean­ing they don’t im­ple­ment some BGP se­cu­rity fea­tures such as RPKI fil­ter­ing.

Cloudflare shows that a leak hap­pened, but not the ac­tual net­work pre­fixes. The net­work pre­fixes are use­ful to de­ter­mine what in­fra­struc­ture was po­ten­tially af­fected. Fortunately pub­lic datasets col­lect this BGP in­for­ma­tion. Pulling the data from ris.ripe.net/​docs/​mrt from around the time of the leak and us­ing a tool called bg­p­dump we can ex­tract the data into a read­able for­mat:

TIME: 01/02/26 15:41:16

TYPE: BGP4MP/MESSAGE/Update

FROM: 187.16.222.45 AS263237

TO: 187.16.216.23 AS12654

ORIGIN: IGP

ASPATH: 263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980

NEXT_HOP: 187.16.222.45

COMMUNITY: 0:6939 65237:1020

ANNOUNCE

200.74.228.0/23

200.74.236.0/23

200.74.230.0/23

200.74.238.0/23

200.74.226.0/24

After some more pro­cess­ing with bg­p­dump we can get a much bet­ter view of the data, in­clud­ing the pre­fixes that were miss­ing from the Cloudflare radar.

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.230.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.236.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.228.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.238.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.226.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.232.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.233.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.208.144|24482|200.74.234.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 1299 269832 21980|IGP|187.16.208.144|0|0|24115:52320 24115:65012 24482:2 24482:200 24482:13000 24482:13020 24482:13021 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368421|A|187.16.222.45|263237|200.74.234.0/24|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368421|A|187.16.222.45|263237|200.74.233.0/24|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368421|A|187.16.222.45|263237|200.74.232.0/24|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368446|A|187.16.222.45|263237|200.74.228.0/23|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368446|A|187.16.222.45|263237|200.74.236.0/23|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368446|A|187.16.222.45|263237|200.74.230.0/23|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368446|A|187.16.222.45|263237|200.74.238.0/23|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368446|A|187.16.222.45|263237|200.74.226.0/24|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 6762 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368450|A|187.16.222.45|263237|200.74.234.0/24|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368450|A|187.16.222.45|263237|200.74.233.0/24|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368450|A|187.16.222.45|263237|200.74.232.0/24|263237 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.222.45|0|0|0:6939 65237:1020|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.234.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.232.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.233.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.238.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.228.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.226.0/24|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.236.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

BGP4MP|1767368451|A|187.16.208.144|24482|200.74.230.0/23|24482 52320 8048 8048 8048 8048 8048 8048 8048 8048 8048 23520 1299 269832 21980|IGP|187.16.208.144|0|0|24482:2 24482:200 24482:13000 24482:13020 24482:13021 24482:65304 52320:41912 52320:61056 52320:64123|NAG||

More in­for­ma­tion about the for­mat can be seen in Working with Raw BGP Data but of note, the AS path has 8048 (CANTV) re­peated 10 times, is very odd as this would make the route less at­trac­tive since BGP prefers shorter paths. Also of note is all 8 pre­fixes fall within a 200.74.224.0/20 block.

200.74.226.0/24

200.74.228.0/23

200.74.230.0/23

200.74.232.0/24

200.74.233.0/24

200.74.234.0/24

200.74.236.0/23

200.74.238.0/23

A quick WHOIS lookup shows this range be­longs to Dayco Telecom, a host­ing and telecom­mu­ni­ca­tions provider in Caracas.

A re­verse DNS lookup can be used to find the do­main name from an IP ad­dress. Interestingly, look­ing up some of these ranges turns up some pretty crit­i­cal in­fra­struc­ture in­clud­ing banks, in­ter­net providers, email servers, and more.

BGP anom­alies hap­pen fre­quently, but the tim­ing of some cur­rently un­ex­plained BGP ac­tiv­ity is very in­ter­est­ing.

When BGP traf­fic is be­ing sent from point A to point B, it can be rerouted through a point C. If you con­trol point C, even for a few hours, you can the­o­ret­i­cally col­lect vast amounts of in­tel­li­gence that would be very use­ful for gov­ern­ment en­ti­ties. The CANTV AS8048 be­ing prepended to the AS path 10 times means there the traf­fic would not pri­or­i­tize this route through AS8048, per­haps that was the goal? There are many unan­swered ques­tions.

Regardless of the ac­tual goal, there were un­doubt­edly some BGP shenani­gans hap­pen­ing dur­ing this time frame. There is a lot of data pub­licly avail­able that is worth a much deeper dive to un­der­stand ex­actly what hap­pened.

Want more? Check back next Monday morn­ing or get the lat­est Radar is­sue di­rectly in your in­box.

Opus 4.5 is go­ing to change every­thing

Edit: A lot of folks have been ask­ing what wor­fk­lows I used to write these apps. I used GitHub Copilot in VS Code with a cus­tom agent prompt that you’ll find to­ward the end of this post. Context7 was the only MCP I used. I mostly just used the built-in voice dic­ta­tion fea­ture and talked to Claude. No fancy work­flows, plan­ning, etc re­quired. The agent har­ness in VS Code for Opus 4.5 is so good - you don’t need much else. And it’s re­mark­ably fast. Also, if it’s not ob­vi­ous, these are my opin­ions. I’m wrong like 50% of the time so pro­ceed with cau­tion.

If you had asked me three months ago about these state­ments, I would have said only some­one who’s never built any­thing non-triv­ial would be­lieve they’re true. Great for aug­ment­ing a de­vel­op­er’s ex­ist­ing work­flow, and com­ple­tions are pow­er­ful, but agents re­plac­ing de­vel­op­ers en­tirely? No. Absolutely not.

Today, I think that AI cod­ing agents can ab­solutely re­place de­vel­op­ers. And the rea­son that I be­lieve this is Claude Opus 4.5.

And by “normal”, I mean that it is not the nor­mal AI agent ex­pe­ri­ence that I have had thus far. So far, AI Agents seem to be pretty good at writ­ing spaghetti code and af­ter 9 rounds of copy / paste er­rors into the ter­mi­nal and “fix it” have prob­a­bly de­stroyed my code­base to the ex­tent that I’ll be throw­ing this whole chat ses­sion out and there goes 30 min­utes I’m never get­ting back.

Opus 4.5 feels to me like the model that we were promised - or rather the promise of AI for cod­ing ac­tu­ally de­liv­ered.

One of the tough­est things about writ­ing that last sen­tence is that the im­me­di­ate re­sponse from you should be, “prove it”. So let me show you what I’ve been able to build.

I first no­ticed that Opus 4.5 was dras­ti­cally dif­fer­ent when I used it to build a Windows util­ity to right-click an im­age and con­vert it to dif­fer­ent file types. This was ba­si­cally a one shot build af­ter ask­ing Opus the best way to add a right-click menu to the file ex­plorer.

What amazed me through the process of build­ing this was Opus 4.5 abil­ity to get most things right on the first try. And if it ran into er­rors, it would try and build us­ing the dot­net CLI, read the er­rors and it­er­ate un­til fixed. The only is­sue I had was Opus in­abil­ity to see XAML er­rors, which I used Visual Studio to see and copy / paste back into the agent.

Opus built a site for me to dis­trib­ute it and han­dled the bundling of the ex­e­cutable so as to use a pow­er­shell script for the in­stall, unin­stall. It also built the GitHub Actions which do the re­lease and up­date the land­ing page so that all I have to do is push source.

The only place I had to use other tools was for the logo - where I used Figma’s AI to gen­er­ate a bunch of dif­fer­ent vari­a­tions - but then Opus wrote the scripts to con­vert that SVG to the right for­mats for icons, even store dis­tri­b­u­tion if I chose to do so.

Now this is ad­mit­tedly not a com­plex ap­pli­ca­tion. This is a small Windows util­ity that is do­ing ba­si­cally one thing. It’s not like I asked Opus 4.5 to build Photoshop.

Except I kind of did.

I was so im­pressed by Opus 4.5 work on this util­ity that I de­cided to make a sim­ple GIF record­ing util­ity sim­i­lar to LICEcap for Mac. Great app, ques­tion­able name.

But that proved to be so easy, that I went ahead and con­tin­ued adding fea­tures, in­clud­ing cap­tur­ing and edit­ing video, sta­tic im­ages, adding shapes, crop­ping, blurs and more. I’m still work­ing on this ap­pli­ca­tion as it turns out build­ing a full on im­age/​video ed­i­tor is kind of a big un­der­tak­ing. But I got REALLY far in a mat­ter of hours. HOURS, PEOPLE.

I don’t have a fancy land­ing page for this one yet, but you can view all of the source code here.

I re­al­ized that if I could build a video record­ing app, I could prob­a­bly build any­thing at all - at least UI-wise. But the achilles heel of all AI agents is when they have to glue to­gether back­end sys­tems - which any real world ap­pli­ca­tion is go­ing to have - auth, data­base, API, stor­age.

Except Opus 4.5 can do that too.

Armed with my con­fi­dence in Opus 4.5, I took on a pro­ject that I had built in React Native last year and fin­ished for Android, but gave up in the fi­nal stretches (as one does).

The ap­pli­ca­tion is for my wife who owns a small yard sign fran­chise. The prob­lem is that she has a Facebook page for the busi­ness, but never posts there be­cause it’s time con­sum­ing. But any good small busi­ness has a vi­brant page where peo­ple can see pho­tos of your busi­ness do­ing…what­ever the heck it does. So peo­ple know that it exsits and is alive and well.

The idea is sim­ple - each time she sets up a yard sign, she takes a pic­ture to send to the per­son who or­dered it so they can see it was setup. So why not have a mo­bile app where she can up­load 10 im­ages at a time, and the app will use AI to gen­er­ate cap­tions and then sched­ule them and post them over the com­ing week.

It’s a sim­ple premise, but it has a lot of mov­ing parts - there is the Facebook au­then­ti­ca­tion which is a ca­per in and of it­self - not for the faint of heart. There is au­then­ti­ca­tion with a back­end, there is file stor­age for pho­tos that are sched­uled to go out, there is the back­end process which needs to post the photo. It’s a full on back­end setup.

As it turns out, I needed to in­stall some blinds in the house so I thought - why don’t I see if Opus 4.5 can build this while I in­stall the blinds.

So I fired up a chat ses­sion and just started by telling Opus 4.5 what I wanted to build and how it would rec­om­mend han­dling the back­end. It rec­om­mended sev­eral op­tions but set­tled on Firebase. I’m not now nor have I ever been a Firebase user, but at this point I trust Opus 4.5 a lot. Probably too much.

So I cre­ated a Firebase ac­count, up­graded to the Blaze plan with alerts for billing and Opus 4.5 got to work.

By the time I was done in­stalling blinds, I had a func­tional iOS ap­pli­ca­tion for us­ing AI to cap­tion pho­tos and post­ing them on a sched­ule to Facebook.

When I say that Opus 4.5 built this al­most en­tirely, I mean it. It used the fire­base CLI to stand up any re­sources it needed and would tag me in for cer­tain things like up­grad­ing a pro­ject to the Blaze plan for fea­tures like stor­age, etc. The best part was that when the Firebase cloud func­tions would throw er­rors, it would au­to­mat­i­cally grep those logs, find the er­ror and re­solve it. And all it needed was a CLI. No MCP Server. No fancy prompt file telling it how to use Firebase.

And of course, since I can, I had Opus 4.5 cre­ate a back­end ad­min dash­board so I could see what she’s got pend­ing and make any ad­just­ments.

And since it did in a few hours what had taken me two months of work in the evenings in­stead of be­ing a de­cent hus­band, I de­cided to make up for my dere­lic­tion of du­ties by build­ing her an­other app for her sign busi­ness that would make her life just a bit more de­light­ful - and elim­i­nate two other apps she is cur­rently pay­ing for.

This app parses or­ders from her busi­ness Gmail ac­count to show her what sign se­tups / pick­ups she has for the day, cal­cu­lates how long its go­ing to take to go to each stop, cal­cu­lates the op­ti­mal route when there is more than one stop and tracks drive time for tax pur­poses. She was pre­vi­ously us­ing two paid apps for the last two fea­tures there.

This app also uses Firebase. Again, Opus one-shot­ted the Google auth email in­te­gra­tion. This is the kind of thing that is painstak­ingly mis­er­able by hand. And again, Firebase is so well suited here be­cause Opus knows how to use the Firebase CLI so well. It needs zero in­struc­tion.

BUT YOU DON’T KNOW HOW THE CODE WORKS

No I don’t. I have a vague idea, but you are right - I do not know how the ap­pli­ca­tions are ac­tu­ally as­sem­bled. Especially since I don’t know Swift at all.

This used to be a ma­jor hangup for me. I could­n’t di­ag­nose prob­lems when things went side­ways. With Opus 4.5, I haven’t hit that wall yet—Opus al­ways fig­ures out what the is­sue is and fixes its own bugs.

The real ques­tion is code qual­ity. Without un­der­stand­ing how it’s built, how do I know if there’s du­pli­ca­tion, dead code, or poor pat­terns? I used to ob­sess over this. Now I’m less wor­ried that a hu­man needs to read the code, be­cause I’m gen­uinely not sure that they do.

Why does a hu­man need to read this code at all? I use a cus­tom agent in VS Code that tells Opus to write code for LLMs, not hu­mans. Think about it—why op­ti­mize for hu­man read­abil­ity when the AI is do­ing all the work and will ex­plain things to you when you ask?

What you don’t need: vari­able names, for­mat­ting, com­ments meant for hu­mans, or pat­terns de­signed to spare your brain.

What you do need: sim­ple en­try points, ex­plicit code with fewer ab­strac­tions, min­i­mal cou­pling, and lin­ear con­trol flow.

name: ‘LLM AI cod­ing agent’

model: Claude Opus 4.5 (copilot)

de­scrip­tion: ‘Optimize for model rea­son­ing, re­gen­er­a­tion, and de­bug­ging.’

You are an AI-first soft­ware en­gi­neer. Assume all code will be writ­ten and main­tained by LLMs, not hu­mans. Optimize for model rea­son­ing, re­gen­er­a­tion, and de­bug­ging — not hu­man aes­thet­ics.

Your goal: pro­duce code that is pre­dictable, de­bug­gable, and easy for fu­ture LLMs to rewrite or ex­tend.

ALWAYS use #runSubagent. Your con­text win­dow size is lim­ited - es­pe­cially the out­put. So you should al­ways work in dis­crete steps and run each step us­ing #runSubAgent. You want to avoid putting any­thing in the main con­text win­dow when pos­si­ble.

ALWAYS use #context7 MCP Server to read rel­e­vant doc­u­men­ta­tion. Do this every time you are work­ing with a lan­guage, frame­work, li­brary etc. Never as­sume that you know the an­swer as these things change fre­quently. Your train­ing date is in the past so your knowl­edge is likely out of date, even if it is a tech­nol­ogy you are fa­mil­iar with.

Each time you com­plete a task or learn im­por­tant in­for­ma­tion about the pro­ject, you should up­date the `.github/copilot-instructions.md` or any `agent.md` file that might be in the pro­ject to re­flect any new in­for­ma­tion that you’ve learned or changes that re­quire up­dates to these in­struc­tions files.

ALWAYS check your work be­fore re­turn­ing con­trol to the user. Run tests if avail­able, ver­ify builds, etc. Never re­turn in­com­plete or un­ver­i­fied work to the user.

Be a good stew­ard of ter­mi­nal in­stances. Try and reuse ex­ist­ing ter­mi­nals where pos­si­ble and use the VS Code API to close ter­mi­nals that are no longer needed each time you open a new ter­mi­nal.

## Mandatory Coding Principles

These cod­ing prin­ci­ples are manda­tory:

1. Structure

- Use a con­sis­tent, pre­dictable pro­ject lay­out.

- Group code by fea­ture/​screen; keep shared util­i­ties min­i­mal.

- Create sim­ple, ob­vi­ous en­try points.

- Before scaf­fold­ing mul­ti­ple files, iden­tify shared struc­ture first. Use frame­work-na­tive com­po­si­tion pat­terns (layouts, base tem­plates, providers, shared com­po­nents) for el­e­ments that ap­pear across pages. Duplication that re­quires the same fix in mul­ti­ple places is a code smell, not a pat­tern to pre­serve.

2. Architecture

- Prefer flat, ex­plicit code over ab­strac­tions or deep hi­er­ar­chies.

- Avoid clever pat­terns, metapro­gram­ming, and un­nec­es­sary in­di­rec­tion.

- Minimize cou­pling so files can be safely re­gen­er­ated.

3. Functions and Modules

- Keep con­trol flow lin­ear and sim­ple.

- Use small-to-medium func­tions; avoid deeply nested logic.

- Pass state ex­plic­itly; avoid glob­als.

4. Naming and Comments

- Use de­scrip­tive-but-sim­ple names.

- Comment only to note in­vari­ants, as­sump­tions, or ex­ter­nal re­quire­ments.

5. Logging and Errors

- Emit de­tailed, struc­tured logs at key bound­aries.

- Make er­rors ex­plicit and in­for­ma­tive.

6. Regenerability

- Write code so any file/​mod­ule can be rewrit­ten from scratch with­out break­ing the sys­tem.

- Prefer clear, de­clar­a­tive con­fig­u­ra­tion (JSON/YAML/etc.).

7. Platform Use

- Use plat­form con­ven­tions di­rectly and sim­ply (e.g., WinUI/WPF) with­out over-ab­stract­ing.

8. Modifications

- When ex­tend­ing/​refac­tor­ing, fol­low ex­ist­ing pat­terns.

- Prefer full-file rewrites over mi­cro-ed­its un­less told oth­er­wise.

9. Quality

- Favor de­ter­min­is­tic, testable be­hav­ior.

- Keep tests sim­ple and fo­cused on ver­i­fy­ing ob­serv­able be­hav­ior.

All of that said, I don’t have any proof that this prompt makes a dif­fer­ence. I find that Opus 4.5 writes pretty solid code no mat­ter what you prompt it with. However, be­cause mod­els like to write code WAY more than they like to delete it, I will at points run a prompt that looks some­thing like this…

Check your LLM, AI cod­ing prin­ci­ples and then do a com­pre­hen­sive search of this ap­pli­ca­tion and sug­gest what we can do to refac­tor this to bet­ter align to those prin­ci­ples. Also point out any code that can be deleted, any files that can be deleted, things that should read should be re­named, things that should be re­struc­tured. Then do a write up of what that looks like. Kind of keep it high level so that it’s easy for me to read and not too com­plex. Add sec­tions for high, medium and lower pri­or­ity And if some­thing does­n’t need to be changed, then don’t change it. You don’t need to change things just for the sake of chang­ing them. You only need to change them if it helps bet­ter align to your LLM AI cod­ing prin­ci­ples. Save to a mark­down file.

And you get a doc­u­ment that has high, medium and low pri­or­ity items. The high ones you can deal with and the AI will stop find­ing them. You can refac­tor your pro­ject a mil­lion times and it will keep find­ing medium/​low pri­or­ity refac­tors that you can do. An AI is never ever go­ing to pass on the op­por­tu­nity to gen­er­ate some text.

I use a sim­i­lar prompt to find se­cu­rity is­sues. These you have to be very care­ful about. Where are the API keys? Is lo­gin han­dled cor­rectly? Are you stor­ing sen­si­tive val­ues in the data­base? This is prob­a­bly the most man­ual part of the pro­ject and frankly, some­thing that makes me the most ner­vous about all of these apps at the mo­ment. I’m not 100% con­fi­dent that they are bul­let proof. Maybe like 80%. And that, as they say, is too damn low.

I don’t know if I feel ex­hil­a­rated by what I can now build in a mat­ter of hours, or de­pressed be­cause the thing I’ve spent my life learn­ing to do is now triv­ial for a com­puter. Both are true.

I un­der­stand if this post made you an­gry. I get it - I did­n’t like it ei­ther when peo­ple said “AI is go­ing to re­place de­vel­op­ers.” But I can’t dis­miss it any­more. I can wish it weren’t true, but wish­ing does­n’t change re­al­ity.

But for every­thing else? Build. Stop wait­ing to have all the an­swers. Stop try­ing to fig­ure out your place in an AI-first world. The an­swer is the same as it al­ways was: make things. And now you can make them faster than you ever thought pos­si­ble.

Just make sure you know where your API keys are.

Disclaimer: This post was writ­ten by a hu­man and edited for spelling, gram­mer by Haiku 4.5