OpenCiv3 (formerly known by the co­de­name “C7”) is an open-source, cross-plat­form, mod-ori­ented, mod­ern­ized reimag­in­ing of Civilization III by the fan com­mu­nity built with the Godot Engine and C#, with ca­pa­bil­i­ties in­spired by the best of the 4X genre and lessons learned from mod­ding Civ3. Our vi­sion is to make Civ3 as it could have been, re­built for to­day’s mod­ders and play­ers: re­mov­ing ar­bitary lim­its, fix­ing bro­ken fea­tures, ex­pand­ing mod ca­pa­bil­i­ties, and sup­port­ing mod­ern graph­ics and plat­forms. A game that can go be­yond C3C but re­tain all of its game­play and con­tent.

OpenCiv3 is un­der ac­tive de­vel­op­ment and cur­rently in an early pre-al­pha state. It is a rudi­men­tary playable game but lack­ing many me­chan­ics and late-game con­tent, and er­rors are likely. Keep up with our de­vel­op­ment for the lat­est up­dates and op­por­tu­ni­ties to con­tribute!

New Players Start Here: An Introduction to OpenCiv3 at CivFanatics

NOTE: OpenCiv3 is not af­fil­i­ated with civ­fa­nat­ics.com, Firaxis Games, BreakAway Games, Hasbro Interactive, Infogrames Interactive, Atari Interactive, or Take-Two Interactive Software. All trade­marks are prop­erty of their re­spec­tive own­ers.

The OpenCiv3 team is pleased to an­nounce the first pre­view re­lease of the v0.3 “Dutch” mile­stone. This is a ma­jor en­hance­ment over the “Carthage” re­lease, and our de­but with stand­alone mode fea­tur­ing place­holder graph­ics with­out the need for Civ3 me­dia files. A lo­cal in­stal­la­tion of Civ3 is still rec­om­mended for a more pol­ished ex­pe­ri­ence. See the re­lease notes for a full list of new fea­tures in each ver­sion.

OpenCiv3 Dutch Preview 1 with the same game in Standalone mode (top) and with im­ported Civ3 graph­ics (bottom)

Download the ap­pro­pri­ate zip file for your OS from the Dutch Preview 1 re­lease

All of­fi­cial re­leases of OpenCiv3 along with more de­tailed re­lease notes can be found on the GitHub re­leases page.

64-bit Windows, Linux, or Mac OS. Other plat­forms may be sup­ported in fu­ture re­leases.

Minimum hard­ware re­quire­ments have not yet been iden­ti­fied. Please let us know if OpenCiv3 does not per­form well on your sys­tem.

Recommended: A lo­cal copy of Civilization III files (the game it­self does NOT have to run) from Conquests or the Complete edi­tion. Standalone mode is avail­able with place­holder graph­ics for those who do not have a copy.

Civilization III Complete is avail­able for a pit­tance from Steam or GOG

This is a Windows 64-bit ex­e­cutable. OpenCiv3 will look for a lo­cal in­stal­la­tion of Civilization III in the Windows reg­istry au­to­mat­i­cally, or you may use an en­vi­ron­ment vari­able to point to the files.

If it is blocked, you may need to un­block it by

Check the “Unblock” check­box near the bot­tom but­tons in the “Security” sec­tion

If your Civilization III in­stal­la­tion is not de­tected, you can set the en­vi­ron­ment vari­able CIV3_HOME point­ing to it and restart OpenCiv3

This is an x86-64 Linux ex­e­cutable. You may use an en­vi­ron­ment vari­able to point to the files from a Civilization III in­stal­la­tion. You can just copy or mount the top-level “Sid Meier’s Civilization III Complete” (Sans “Complete” if your in­stall was from pre-Com­plete CDs) folder and its con­tents to your Linux sys­tem, or in­stall the game via Steam or GOG.

Set the CIV3_HOME en­vi­ron­ment vari­able to point to the Civ3 files, e.g. ex­port CIV3_HOME=“/path/to/civ3”

From that same ter­mi­nal where you set CIV3_HOME, run OpenCiv3.x86_64

To make this vari­able per­ma­nent, add it to your .profile or equiv­a­lent.

This is a uni­ver­sal 64-bit ex­e­cutable, so it should run on both Intel and M1 Macs. You may use an en­vi­ron­ment vari­able to point to the files from a Civilization III in­stal­la­tion. You can just copy or mount the top-level “Sid Meier’s Civilization III Complete” (Sans “Complete” if your in­stall was from pre-Com­plete CDs) folder and its con­tents to your Mac sys­tem, or in­stall the game via Steam or GOG.

Download the zip; it may com­plain bit­terly, and you may have to tell it to keep the down­load in­stead of trash­ing it

Double click the zip file, and a folder with OpenCiv3.app and a json file will ap­pear

If you try to open OpenCiv3.app it will tell you it’s dam­aged and try to trash it; it is not dam­aged

To un­block the down­loaded app, from a ter­mi­nal run xattr -cr /path/to/OpenCiv3.app; you can avoid typ­ing the path out by typ­ing xattr -cr and then drag­ging the OpenCiv3.app icon onto the ter­mi­nal win­dow

Set the CIV3_HOME en­vi­ron­ment vari­able to point to the Civ3 files, e.g. ex­port CIV3_HOME=“/path/to/civ3”

From that same ter­mi­nal where you set CIV3_HOME, run OpenCiv3.app with open /path/to/OpenCiv3.app, or again just type open and drag the OpenCiv3 icon onto the ter­mi­nal win­dow and press en­ter

OpenCiv3 uses many prim­i­tive place­holder as­sets; load­ing files from a lo­cal Civilization III in­stall is rec­om­mended (see plat­form spe­cific setup in­struc­tions above)

Support for play­ing Civ3 BIQ or SAV files is in­com­plete; some files will not load cor­rectly and crashes may oc­cur

For Mac:

Mac will try hard not to let you run this; it will tell you the app is dam­aged and can’t be opened and help­fully of­fer to trash it for you. From a ter­mi­nal you can xattr -cr /path/to/OpenCiv3.app to en­able run­ning it.

Mac will crash if you hit but­tons to start a new game (New Game, Quick Start, Tutorial, or Load Scenario) be­cause it cant find our ‘new game’ save file we’re us­ing as a stand-in for map gen­er­a­tion. But you can Load Game and load c7-sta­tic-map-save.json or open a Civ3 SAV file to open that map

Other spe­cific bugs will be tracked on the GitHub is­sues page.

© OpenCiv3 con­trib­u­tors. OpenCiv3 is free and open source soft­ware re­leased un­der the MIT License.

Full list of pro­jects avail­able here.

La Suite numérique (La Suite for short) is a full blown open-source dig­i­tal work­space for on­line col­lab­o­ra­tion and team­work.

La Suite is built by French gov­ern­ment agen­cies DINUM and ANCT. It is also the prod­uct of a close eu­ro­pean col­lab­o­ra­tion with the Netherlands and German state.

Our code base is a 100% open source and MIT li­cenced.

Come say hello on Matrix

Experimental - This pro­ject is still in de­vel­op­ment, and not ready for the prime time.

A min­i­mal, se­cure Python in­ter­preter writ­ten in Rust for use by AI.

Monty avoids the cost, la­tency, com­plex­ity and gen­eral faff of us­ing a full con­tainer based sand­box for run­ning LLM gen­er­ated code.

Instead, it lets you safely run Python code writ­ten by an LLM em­bed­ded in your agent, with startup times mea­sured in sin­gle digit mi­crosec­onds not hun­dreds of mil­lisec­onds.

What Monty can do:

* Run a rea­son­able sub­set of Python code - enough for your agent to ex­press what it wants to do

* Completely block ac­cess to the host en­vi­ron­ment: filesys­tem, env vari­ables and net­work ac­cess are all im­ple­mented via ex­ter­nal func­tion calls the de­vel­oper can con­trol

* Call func­tions on the host - only func­tions you give it ac­cess to

* Run type­check­ing - monty sup­ports full mod­ern python type hints and comes with ty in­cluded in a sin­gle bi­nary to run type­check­ing

* Be snap­shot­ted to bytes at ex­ter­nal func­tion calls, mean­ing you can store the in­ter­preter state in a file or data­base, and re­sume later

* Startup ex­tremely fast (<1μs to go from code to ex­e­cu­tion re­sult), and has run­time per­for­mance that is sim­i­lar to CPython (generally be­tween 5x faster and 5x slower)

* Be called from Rust, Python, or Javascript - be­cause Monty has no de­pen­den­cies on cpython, you can use it any­where you can run Rust

* Control re­source us­age - Monty can track mem­ory us­age, al­lo­ca­tions, stack depth, and ex­e­cu­tion time and can­cel ex­e­cu­tion if it ex­ceeds pre­set lim­its

* Collect std­out and stderr and re­turn it to the caller

* Run async or sync code on the host via async or sync code on the host

What Monty can­not do:

* Use the stan­dard li­brary (except a few se­lect mod­ules: sys, typ­ing, asyn­cio, dat­a­classes (soon), json (soon))

* Use third party li­braries (like Pydantic), sup­port for ex­ter­nal python li­brary is not a goal

* de­fine classes (support should come soon)

* use match state­ments (again, sup­port should come soon)

In short, Monty is ex­tremely lim­ited and de­signed for one use case:

For mo­ti­va­tion on why you might want to do this, see:

In very sim­ple terms, the idea of all the above is that LLMs can work faster, cheaper and more re­li­ably if they’re asked to write Python (or Javascript) code, in­stead of re­ly­ing on tra­di­tional tool call­ing. Monty makes that pos­si­ble with­out the com­plex­ity of a sand­box or risk of run­ning code di­rectly on the host.

Note: Monty will (soon) be used to im­ple­ment code­mode in Pydantic AI

Monty can be called from Python, JavaScript/TypeScript or Rust.

uv add py­dan­tic-monty

from typ­ing im­port Any

im­port py­dan­tic_­monty

code = “”″

async def agent(prompt: str, mes­sages: Messages):

while True:

print(f’mes­sages so far: {messages}’)

out­put = await cal­l_llm(prompt, mes­sages)

if isin­stance(out­put, str):

re­turn out­put

mes­sages.ex­tend(out­put)

await agent(prompt, [])

type­_de­f­i­n­i­tions = “”″

from typ­ing im­port Any

Messages = list[dict[str, Any]]

async def cal­l_llm(prompt: str, mes­sages: Messages) -> str | Messages:

raise NotImplementedError()

prompt: str = ‘’

m = py­dan­tic_­monty.Monty(

code,

in­puts=[‘prompt’],

ex­ter­nal_­func­tions=[‘cal­l_llm’],

scrip­t_­name=‘agent.py’,

type­_check=True,

type­_check­_s­tubs=type­_de­f­i­n­i­tions,

Messages = list[dict[str, Any]]

async def cal­l_llm(prompt: str, mes­sages: Messages) -> str | Messages:

if len(mes­sages) < 2:

re­turn [{‘role’: ‘system’, ‘content’: ‘example re­spon­se’}]

else:

re­turn f’ex­am­ple out­put, mes­sage count {len(messages)}′

async def main():

out­put = await py­dan­tic_­monty.run_­mon­ty_a­sync(

m,

in­puts={‘prompt’: ‘testing’},

ex­ter­nal_­func­tions={‘cal­l_llm’: cal­l_llm},

print(out­put)

#> ex­am­ple out­put, mes­sage count 2

if __name__ == ‘__main__’:

im­port asyn­cio

asyn­cio.run(main())

Use start() and re­sume() to han­dle ex­ter­nal func­tion calls it­er­a­tively, giv­ing you con­trol over each call:

im­port py­dan­tic_­monty

code = “”″

data = fetch(url)

len(data)

m = py­dan­tic_­monty.Monty(code, in­puts=[‘url’], ex­ter­nal_­func­tions=[‘fetch’])

# Start ex­e­cu­tion - pauses when fetch() is called

re­sult = m.start(in­puts={‘url’: ’https://​ex­am­ple.com’})

print(type(re­sult))

Both Monty and MontySnapshot can be se­ri­al­ized to bytes and re­stored later. This al­lows caching parsed code or sus­pend­ing ex­e­cu­tion across process bound­aries:

im­port py­dan­tic_­monty

# Serialize parsed code to avoid re-pars­ing

m = py­dan­tic_­monty.Monty(‘x + 1’, in­puts=[‘x’])

data = m.dump()

# Later, re­store and run

m2 = py­dan­tic_­monty.Monty.load(data)

print(m2.run(in­puts={‘x’: 41}))

#> 42

# Serialize ex­e­cu­tion state mid-flight

m = py­dan­tic_­monty.Monty(‘fetch(url)’, in­puts=[‘url’], ex­ter­nal_­func­tions=[‘fetch’])

progress = m.start(in­puts={‘url’: ’https://​ex­am­ple.com’})

state = progress.dump()

# Later, re­store and re­sume (e.g., in a dif­fer­ent process)

pro­gress2 = py­dan­tic_­monty.Mon­tyS­nap­shot.load(state)

re­sult = pro­gress2.re­sume(re­turn_­value=‘re­sponse data’)

print(re­sult.out­put)

#> re­sponse data

use monty::{Mon­tyRun, MontyObject, NoLimitTracker, StdPrint};

let code = r#”

def fib(n):

if n

MontyRun and RunProgress can be se­ri­al­ized us­ing the dump() and load() meth­ods:

use monty::{Mon­tyRun, MontyObject, NoLimitTracker, StdPrint};

// Serialize parsed code

This is a demo for how you can turn an ESP32-S3 mi­cro­con­troller into a tiny in­stant-on PC with its own shell, ed­i­tor, com­piler, and on­line apps in­staller. Something like Raspberry Pi, mi­nus the over­head of a full server/​desk­top grade OS. I think ESP32 is un­der­rated in hobby maker com­mu­nity for this PC-like use case. This demo uses BreezyBox, my mini-shell ESP-IDF com­po­nent.

First of all, see­ing is be­liev­ing (click to watch the video):

It started as a “cyberdeck” style craft­ing pro­ject. Then I got car­ried away with the soft­ware part. I chose ESP32-S3 for the base plat­form. It has the nos­tal­gic ap­peal of the DOS era PCs, with sim­i­lar re­sources, and el­bow-deep-in-bytes cod­ing ex­pe­ri­ence, plus mod­ern wire­less comms.

ESP32-S3 can do every­thing those PCs did and more, but that is in­con­ve­nient out of the box, be­cause that is not the com­mer­cial use case it is po­si­tioned for. It also forces away the code bloat. If you are like me, and love small el­e­gant things, and tech­nol­ogy that punches way above its weight, you ought to try it!

So any­way, I de­cided to try and pack­age some key miss­ing parts: a ba­sic vterm, the cur­rent work­ing di­rec­tory (CWD) track­ing, a few fa­mil­iar UNIX-like com­mands, and an app in­staller. Believe it or not, the rest is al­ready there in ESP-IDF com­po­nents, in­clud­ing the elf_loader with dy­namic link­ing.

The re­sult is called “BreezyBox”, by anal­ogy with the BusyBox com­mands suite. The name is just a light joke, it is not meant to be a full clone. You can im­port it with one com­mand in your ESP-IDF pro­ject, and if you have some stdio go­ing, even at “Hello World” level, it should mostly just work. I call it a “mini shell”, a naïve user might call it an OS (it is not, it runs on FreeRTOS), and you can also call it the user­land layer.

The BreezyBox com­po­nent leaves the dis­play and other board con­fig­u­ra­tion de­tails to the user’s firmware pro­ject, pro­vid­ing mainly the vterm/​vfs fea­tures, and some shell com­mands. This par­tic­u­lar ex­am­ple/​demo pro­ject sup­ports only one spe­cific dev board: Waveshare ESP32-S3-Touch-LCD-7B (no af­fil­i­a­tion). But you can see how all the parts con­nect, and adapt it to your dis­play/​board, or just copy some code snip­pets from here.

I sug­gest just fork it, clone it, and try to make it work on your board. Mine was about 40€; you can start with some ran­dom $10 two inch LCD S3 dev board if you like. Hint: LVGL text la­bel con­trol is the eas­i­est path to std­out on LCD that works al­most every­where. You can also start with a head­less board over USB con­sole, that takes zero code, and gives you free ANSI codes in stan­dard IDF Monitor in VSCode (or in Tabby).

You do not have to write your own font ren­derer like I did here; that was just to push past 30 FPS on a dis­play slightly too large for this chip.

This is free soft­ware un­der MIT License.

The best help is cur­rently more test­ing be­yond “works on my com­puter”, more shared ex­am­ples and fun use cases:

More ELF apps — see the ex­am­ples at my breezyapps repo, they are su­per easy to fol­low. Even a care­fully writ­ten stdlib C pro­gram with no plat­form-spe­cific bits may work some­times, also with some ANSI codes. But be sure to ver­ify on the ac­tual ESP32-S3: the mem­ory is tight, the larger PSRAM re­quires align­ment, and there are other lim­its and quirks. You can pub­lish and in­stall the apps us­ing your own repo.

More full ex­am­ple firmware repos­i­to­ries: for dif­fer­ent boards, with dif­fer­ent styles. Maybe you pro­vide the ba­sic LVGL text la­bel ex­am­ple on some pop­u­lar board. Maybe you pre­fer C++ to plain C. Maybe you em­brace the GUI. Maybe you port some retro games. Maybe you even make it work on P4, or C6 (RISC-V, a com­pletely dif­fer­ent CPU). Maybe you at­tach some cool gad­gets to it. Maybe you build an ex­tra cool cy­berdeck case. Or maybe you re­pro­duce the ex­act same thing, and just share your setup ex­pe­ri­ence and hands-on im­pres­sions.

It would be so cool to see more peo­ple us­ing BreezyBox, and to have more ready-to-clone ex­am­ples for every­one!

I don’t post a lot. But when I do, it’s be­cause I think few peo­ple are say­ing out loud what I’m notic­ing.

I’ve been build­ing a prod­uct from the ground up. Not the “I spun up a Next.js tem­plate” kind of ground up. I mean from net­work con­fig­u­ra­tion to prod­uct de­sign to pric­ing de­ci­sions. Truly end to end. And I’ve been do­ing it us­ing fron­tier mod­els and cod­ing agents for hours and hours every sin­gle day, both on this pro­ject and in my full time work. I’ve been try­ing to stay away from the chaos and the hype, fil­ter­ing hard for what is ac­tu­ally valu­able.

Since December 2025, things have dra­mat­i­cally changed for the bet­ter. Many have no­ticed. Few are draw­ing the right con­clu­sions.

Antirez likes to call it “automated pro­gram­ming”, and I re­ally like that fram­ing. It cap­tures the essence far bet­ter than the shal­low, al­most dis­mis­sive la­bel of “vibe cod­ing”. Automation was at the core of most of the work and cul­tural rev­o­lu­tions of hu­man his­tory. The print­ing press, the loom, the as­sem­bly line. This one does­n’t dif­fer much.

Most of my work is still there. I still have to deeply think about every im­por­tant as­pect of what I want to build. The ar­chi­tec­ture, the trade offs, the prod­uct de­ci­sions, the edge cases that will bite you at 3am. What’s gone is the tear­ing, ex­haust­ing man­ual labour of typ­ing every sin­gle line of code.

At this point in time, mod­els and tools, when put in a clean and ma­ni­a­cally well set up en­vi­ron­ment, can truly make the dif­fer­ence. I can be the ar­chi­tect with­out the wear­ing act of lay­ing every sin­gle brick and spread­ing the mor­tar. I can de­sign the dress with­out the act of cut­ting and sewing each in­di­vid­ual piece of fab­ric. But I can do all of this with the ex­pe­ri­ence on my back of hav­ing laid the bricks, spread the mor­tar, cut and sewn for twenty years. If I don’t like some­thing, I can go in, un­der­stand it and fix it as I please, in­struct­ing once and for all my setup to do what I want next time.

Automated pro­gram­ming es­pe­cially al­lows me to quickly build the tools I need so fast that every black­smith that ever ex­isted on this earth would envy me deeply. Finally able to re­ally fo­cus on the things they have in mind. Finally ded­i­cat­ing more time of their craft to the art they con­ceive, not the sweat of the forge.

It’s been months now that I have this thought crys­tal­lized in my mind. It is so clear to me that I gen­uinely don’t un­der­stand why every­one is not scream­ing it to the world.

We can fi­nally get rid of all that mid­dle work. That adapt­ing layer of garbage we blindly ac­cepted dur­ing these years. A huge amount of frame­works and li­braries and tool­ing that has com­pletely pol­luted soft­ware en­gi­neer­ing, es­pe­cially in web, mo­bile and desk­top de­vel­op­ment. Layers upon lay­ers of ab­strac­tions that ab­stract noth­ing mean­ing­ful, that solve prob­lems we should­n’t have had in the first place, that cre­ate ten new prob­lems for every one they claim to fix.

Think about what hap­pened. We, as an in­dus­try, looked at the gen­uine com­plex­ity of build­ing soft­ware and in­stead of sharp­en­ing our think­ing, we bought some­one else’s think­ing off the shelf. We wrapped every­thing in frame­works like wrap­ping a bro­ken leg in silk. It looks nice. The leg is still bro­ken.

In my mind, be­sides the self de­clared ob­jec­tives, frame­works solve three prob­lems. Two ex­plicit and one ob­vi­ous but never de­clared.

“Simplification”. Software en­gi­neers are scared of de­sign­ing things them­selves. They would rather ac­cept some­one else’s struc­ture, de­spite hav­ing to force fit it into their prod­uct, rather than tak­ing the time to start from the goal and work back­wards to cre­ate the per­fect suit for their idea. Like an ar­chi­tect blindly ac­cept­ing an­other ar­chi­tec­t’s blue­prints and ap­ply­ing them re­gard­less of the con­text, the needs, the ter­rain, the new tech­no­log­i­cal pos­si­bil­i­ties. We de­cided to re­move com­plex­ity not by sharp­en­ing our men­tal mod­els around the prod­ucts we build, but by buy­ing a one size fits all de­sign and ap­ply­ing it every­where. That is not sim­pli­fi­ca­tion. That is in­tel­lec­tual sur­ren­der.

Automation. This is the only point I can ac­tu­ally, more or less, un­der­stand and buy. Boilerplate is bor­ing work. I hate it. And I es­pe­cially hate us­ing li­braries that I then need to study, keep up­dated, be aware of vul­ner­a­bil­i­ties for, just for the pur­pose of re­mov­ing the cre­ation of du­pli­cated but nec­es­sary code. Think about ORMs, CRUD man­age­ment, code gen­er­a­tion, API doc­u­men­ta­tion and so on. The grunt work that no­body wants to do but every­body needs done. Fair enough. But hold that thought, be­cause this is ex­actly the point where every­thing changes.

Labour cost. This is the quiet one. The one no­body puts on the con­fer­ence slide. For com­pa­nies, it is much bet­ter hav­ing Google, Meta, Vercel de­cid­ing for you how you build prod­uct and ship code. Adopt their frame­work. Pay the cost of lock in. Be en­chanted by their cloud man­aged so­lu­tion to host, de­ploy, store your stuff. And you un­lock a fea­ture that has noth­ing to do with en­gi­neer­ing: you no longer need to hire a soft­ware en­gi­neer. You hire a React Developer. No need to train. Plug and play. Easy to re­place. A cog in a ma­chine de­signed by some­one else, main­tain­ing a sys­tem ar­chi­tected by some­one else, solv­ing prob­lems de­fined by some­one else. This is not en­gi­neer­ing. This is op­er­at­ing.

In my opin­ion Software en­gi­neer­ing, the true one, is back again.

I am not speak­ing out of my lungs only. I’ve been de­vel­op­ing this way al­most flaw­lessly for over two years at this point. But the true rev­o­lu­tion hap­pened clearly last year, and since December 2025 this is ob­vi­ous to any­one pay­ing at­ten­tion. From now on it will be even more so.

We have the chance again to get rid of use­less com­plex­ity and keep work­ing on the true and wel­come com­plex­ity of our ideas, our fea­tures, our prod­ucts. The com­plex­ity that mat­ters. The com­plex­ity that is ac­tu­ally yours.

Automation and boil­er­plat­ing have never been so cheap to over­come. I’ve been ba­si­cally never writ­ing twice the same line of code. I’m in­stantly build­ing small tools I need, pur­pose built, ex­actly shaped around the prob­lem at hand. I don’t need any fancy monorepo man­ager. A sim­ple Makefile cov­ers 100% of my needs for 99% of my use cases. When things will get very com­pli­cated, and if they get very com­pli­cated, I’ll think about it. But only then. Not a sec­ond be­fore. This is en­gi­neer­ing. You solve the prob­lem you have, not the prob­lem some­one on a con­fer­ence stage told you that you’ll even­tu­ally have.

Agents are re­ally well pre­pared when it comes to ba­sic tools. Tools that have been around not for months, but lit­er­ally for decades. Bash was born in 1989, just pre­ced­ing me by two months. The most mediocre model run­ning at this time knows bash bet­ter than any per­son in the world. Bash is the uni­ver­sal adapter. It is not a co­in­ci­dence that cod­ing agents are shift­ing from com­plex and ex­pen­sive MCP con­fig­u­ra­tions to a sim­ple agent loop with bash as a way to in­ter­act, lit­er­ally, with the world. The old­est tool turned out to be the most fu­ture proof. There’s a les­son in there if you care to lis­ten.

Really think about it.

Why do you ever need, for most of the use cases you can think of, a use­less, ex­pen­sive, flawed, of­ten vul­ner­a­ble frame­work, and the pa­rade of li­braries that comes with it, that you prob­a­bly use for only 10% of its ca­pa­bil­i­ties? With all the costs as­so­ci­ated with it. From the “least” ex­pen­sive: op­er­a­tional costs like keep­ing every­thing up­dated be­cause they once again found a crit­i­cal vul­ner­a­bil­ity in your Next.js ver­sion. To the most ex­pen­sive one: the cost to your Design Choices. The in­vis­i­ble cost. The one you pay every day with­out even re­al­iz­ing it, be­cause you’ve been pay­ing it so long you for­got what free­dom felt like.

If you keep ac­cept­ing this trade off, you are not only los­ing the biggest op­por­tu­nity we’ve seen in soft­ware en­gi­neer­ing in decades. You are prob­a­bly not rec­og­niz­ing your own lazi­ness in once again buy­ing what­ever the hy­per­scalers have de­cided for you. You’re let­ting Google and Meta and Vercel be your ar­chi­tect, your de­signer, your thinker. And in ex­change, you get to be their op­er­a­tor.

The tools are here. The mod­els are here. The rev­o­lu­tion al­ready hap­pened and most peo­ple are still dec­o­rat­ing the old house.

Stop wrap­ping bro­ken legs in silk. Start build­ing things that are yours.

This is a vo­cal tech­nique ref­er­ence cov­er­ing 21 tech­niques across five cat­e­gories. It’s de­signed as a learn­ing com­pan­ion — whether you’re a be­gin­ner find­ing your voice or an ex­pe­ri­enced singer ex­pand­ing your toolkit.

The sticky bar be­low the ti­tle lets you jump be­tween sec­tions. Each col­ored dot matches its cat­e­gory:

— ways to shape and color your sound

How to read the table

Each row is one tech­nique. Hover the tech­nique name to see a short de­scrip­tion. The dif­fi­culty dots (● ○ ○ ○ ○) show how ad­vanced it is, from 1 to 5.

Some tech­niques show small dashed chips be­neath the name — these are pre­req­ui­sites. The chip color tells you which cat­e­gory the pre­req­ui­site be­longs to. Hover a chip to see what that tech­nique sounds like, or click it to jump straight to its row in the table.

Techniques marked with ⚠️ warn­ings can cause dam­age if done in­cor­rectly. The golden rule: if it hurts, stop. Work with a vo­cal coach for any­thing rated 4–5 dots.

Use EN / DA to switch lan­guage and the theme but­ton to cy­cle through five color schemes: Dark, Light, Midnight, Forest, and Ember. Your choices are saved au­to­mat­i­cally.

Nogle teknikker viser små sti­plede chips un­der navnet — det er forud­sæt­ninger. Chipfarven fortæller hvilken kat­e­gori forud­sæt­nin­gen hører til. Hold musen over en chip for at se hvad teknikken ly­der som, eller klik for at hoppe di­rekte til den i tabellen.

I hope this guide helps you on your vo­cal jour­ney. If you have sug­ges­tions, found a bug, or just want to say hi — I’d love to hear from you.

Check your pos­ture — feet shoul­der-width, shoul­ders back and down, chin level.

Release ten­sion — roll your neck, shrug and drop shoul­ders, shake out your arms.

No cold starts — never belt, dis­tort, or push range with­out warm­ing up first.

Breathing (1 min) — Inhale 4 counts into belly/​sides/​back. Exhale on “Sss” for 15–20 sec­onds. Repeat 3x. This ac­ti­vates your sup­port sys­tem.

Lip Trills (1 min) — Blow air through closed lips to make them vi­brate. Slide up and down your range. Keeps every­thing re­laxed and con­nected.

Humming (1 min) — Hum on “Mmm” through 5-note scales, as­cend­ing. Feel the buzz in your face (mask res­o­nance). Keep jaw and tongue loose.

Vowel Slides (1 min) — Sing “Mee-Meh-Mah-Moh-Moo” on a sin­gle note, then move up by half steps. Opens the vo­cal tract grad­u­ally.

Sirens (1 min) — Slide from bot­tom to top and back on “Woo” or “Wee.” Full range, gen­tle, no push­ing. This bridges your reg­is­ters.

Straw phona­tion — Sing through a straw (or into a cup of wa­ter with a straw). Creates back-pres­sure that bal­ances air­flow and fold clo­sure. Best warm-up tool avail­able.

Tongue trills — Roll your tongue on “Rr” while singing scales. Releases tongue ten­sion (a com­mon prob­lem).

Arpeggios — 1-3-5-8-5-3-1 on “Nay” or “Gee” to work through your pas­sag­gio (break area).

A dome-shaped mus­cle be­neath your lungs. When you in­hale, it flat­tens down­ward, pulling air in. You don’t di­rectly “sing from your di­aphragm” — you use it to con­trol the rate of ex­ha­la­tion. Think of it as an air pres­sure reg­u­la­tor, not a sound source.

Two small folds of tis­sue in your lar­ynx. When air passes through, they vi­brate and cre­ate sound. Thicker vi­bra­tion = chest voice. Thinner vi­bra­tion = head voice. Partial clo­sure = falsetto/​breathy. The space be­tween them is called the glot­tis.

Your “voice box.” It can move up (bright, thin sound) or down (dark, warm sound). For most singing, a neu­tral or slightly low­ered lar­ynx is ideal. A high lar­ynx un­der pres­sure = strain. Learn to keep it sta­ble — yawn­ing gen­tly while singing helps find the right po­si­tion.

Abdominals — Control ex­ha­la­tion pres­sure. They don’t push air out — they slow the col­lapse of the rib cage.

Intercostals — Muscles be­tween your ribs. Keep your ribs ex­panded dur­ing singing. This is “appoggio” (leaning into the breath).

Back mus­cles — Often for­got­ten. Your lower back ex­pands when breath­ing cor­rectly. Engage it for sup­port.

Stand with feet shoul­der-width apart. Knees slightly bent (not locked). Shoulders re­laxed, back and down. Chest com­fort­ably open. Head bal­anced on top of the spine — not jut­ting for­ward. Imagine a string pulling you up from the crown of your head.

Hydration — Drink wa­ter con­sis­tently through­out the day, not just be­fore singing. Your vo­cal folds need sys­temic hy­dra­tion.

Steam in­hala­tion — Breathe steam for 10 min­utes be­fore heavy singing. This di­rectly hy­drates the folds.

Rest — Your voice needs re­cov­ery time. Avoid talk­ing loudly af­ter in­tense ses­sions.

Din “stemmeboks.” Den kan bevæge sig op (lys, tynd lyd) eller ned (mørk, varm lyd). Til de fleste for­mer for sang er en neu­tral eller let sæn­ket strube ideel. En høj strube un­der pres = be­last­ning. Lær at holde den sta­bil — at gabe blidt mens du syn­ger hjælper med at finde den rette po­si­tion.

Common ad­vice that’s mis­lead­ing, in­com­plete, or out­right harm­ful. If some­one tells you any of these, be skep­ti­cal.

You can’t di­rectly con­trol your di­aphragm — it’s an in­vol­un­tary mus­cle on the in­hale. What peo­ple mean is: use your ab­dom­i­nal and in­ter­costal mus­cles to con­trol ex­ha­la­tion. Saying “sing from your di­aphragm” is like say­ing “digest from your stom­ach.” Technically in­volved, but not how you’d teach it.

“Drink tea with honey to fix your voice”

Tea and honey never touch your vo­cal folds — they go down your esoph­a­gus, not your tra­chea. They can soothe throat ir­ri­ta­tion and feel nice, but they don’t “fix” or “coat” your cords. What ac­tu­ally helps: steam in­hala­tion and sys­temic hy­dra­tion (water, hours in ad­vance).

The sound is­n’t pro­duced in your chest. “Chest voice” refers to the thick vo­cal fold vi­bra­tion pat­tern that cre­ates sym­pa­thetic res­o­nance you feel in your up­per torso. The sound is al­ways made at the vo­cal folds in your lar­ynx.

“Falsetto is only for men”

Everyone with vo­cal folds can pro­duce falsetto — it’s a mode of vi­bra­tion where the folds don’t fully close. Women use it too, though the tim­bral dif­fer­ence from head voice may be less dra­matic.

They give you a dam­aged voice. The “rasp” from smok­ing and al­co­hol comes from swollen, ir­ri­tated, de­hy­drated folds. Healthy vo­cal dis­tor­tion uses the false folds and ary­tenoids — struc­tures above the true cords. One is con­trolled art, the other is per­ma­nent dam­age.

The ex­act op­po­site. High notes re­quire less air, not more. Pushing more air at higher pitches forces the folds apart and cre­ates strain. Think “less air, more com­pres­sion” — let the folds do the work.

Artificial vi­brato (jaw wob­ble, di­aphragm pulse) sounds un­nat­ural and cre­ates ten­sion. Real vi­brato emerges nat­u­rally when breath sup­port is solid and the throat is re­laxed. If you don’t have vi­brato yet, the fix is bet­ter tech­nique — not man­u­fac­tur­ing it.

“You’re ei­ther born with it or you’re not”

Singing is a mo­tor skill. Some peo­ple have nat­ural ad­van­tages (vocal fold length, res­o­nance cav­ity size), but tech­nique, pitch ac­cu­racy, tone qual­ity, and range are all train­able. Most “natural” singers prac­ticed ob­ses­sively as chil­dren.

Your vo­cal folds are tis­sue. They need in­creased blood flow and grad­ual stretch­ing be­fore heavy use — just like any other mus­cle. Cold singing is the fastest path to strain, nod­ules, and he­m­or­rhages.

Pain means dam­age. Unlike skele­tal mus­cles, vo­cal folds don’t grow stronger from mi­cro-tears. Pain, burn­ing, or per­sis­tent hoarse­ness = stop im­me­di­ately. Rest. If it lasts more than a few days, see an ENT spe­cial­ist.

Du kan ikke di­rekte kon­trollere dit mellemgulv — det er en ufriv­il­lig muskel ved in­dånd­ing. Det folk mener er: brug dine mave- og in­terkostal­muskler til at kon­trollere udåndin­gen. At sige “syng fra mellemgul­vet” er som at sige “fordøj fra maven.”

This guide uses tra­di­tional vo­cal ter­mi­nol­ogy (chest voice, head voice, mixed voice, etc.) be­cause it’s the most widely un­der­stood frame­work world­wide. However, the most sci­en­tif­i­cally val­i­dated sys­tem is Complete Vocal Technique (CVT), de­vel­oped by Cathrine Sadolin at the Complete Vocal Institute in Copenhagen.

CVT is built on laryn­go­scopic imag­ing, EGG mea­sure­ments, and peer-re­viewed acoustic re­search. Here’s how the two frame­works re­late.

CVT clas­si­fies all singing into four modes based on vo­cal tract con­fig­u­ra­tion — not felt vi­bra­tion:

Support — Coordinated ab­dom­i­nal, waist, so­lar plexus, and back mus­cle en­gage­ment to con­trol air pres­sure and air­flow. (This guide: Breath Support)

Necessary Twang — Narrowing the epiglot­tic fun­nel for clearer, more ef­fi­cient sound. CVT con­sid­ers this foun­da­tional for all healthy singing, not just a style. (This guide: Twang)

Avoid pro­trud­ing jaw & tight­ened lips — These trig­ger un­con­trolled vo­cal cord con­stric­tion, es­pe­cially in up­per reg­is­ter. (Not ex­plic­itly cov­ered in this guide)

“Overdrive” in CVT is a clean mode, not dis­tor­tion

Vowel rules: CVT re­stricts spe­cific vow­els per mode. Traditional ped­a­gogy uses gen­eral vowel mod­i­fi­ca­tion. Both work, but CVT is more pre­cise.

Metal & Density: CVT uses “degree of metal” (0–100%) and “density” (fuller vs. re­duced) as pa­ra­me­ters. Traditional ped­a­gogy does­n’t have these con­cepts.

“Overdrive” means dif­fer­ent things: In this guide, over­drive = heavy vo­cal dis­tor­tion (like gui­tar over­drive). In CVT, Overdrive = a clean, shouty vo­cal mode.

Learn more: com­plete­vo­calin­sti­tute.com

Look for ex­pand­able an­no­ta­tions on tech­nique cards through­out this guide.

The fun­da­men­tal modes of vo­cal fold vi­bra­tion. Every sound you make lives some­where on this spec­trum. Master these be­fore any­thing else.

Ways of us­ing your reg­is­ters to cre­ate spe­cific sounds. These de­fine gen­res and artis­tic iden­tity.

Textures and col­ors you add to your base tone. These are the sea­son­ing — use them de­lib­er­ately, not as de­faults.

Decorative tech­niques that add flair, per­son­al­ity, and mu­si­cal­ity to your phras­ing.

The foun­da­tion every­thing else rests on. Control here is the dif­fer­ence be­tween am­a­teurs and pro­fes­sion­als.

Recent posts:

04 Aug 2025 »

When to Hire a Computer Performance Engineering Team (2025) part 1 of 2

17 Mar 2024 »

The Return of the Frame Pointers

19 Mar 2022 »

Why Don’t You Use …

Blog in­dex

About

RSS

Recent posts:

04 Aug 2025 »

When to Hire a Computer Performance Engineering Team (2025) part 1 of 2

17 Mar 2024 »

The Return of the Frame Pointers

19 Mar 2022 »

Why Don’t You Use …

Blog in­dex

About

RSS

The stag­ger­ing and fast-grow­ing cost of AI dat­a­cen­ters is a call for per­for­mance en­gi­neer­ing like no other in his­tory; it’s not just about sav­ing costs — it’s about sav­ing the planet. I have joined OpenAI to work on this chal­lenge di­rectly, with an ini­tial fo­cus on ChatGPT per­for­mance. The scale is ex­treme and the growth is mind-bog­gling. As a leader in dat­a­cen­ter per­for­mance, I’ve re­al­ized that per­for­mance en­gi­neer­ing as we know it may not be enough — I’m think­ing of new en­gi­neer­ing meth­ods so that we can find big­ger op­ti­miza­tions than we have be­fore, and find them faster. It’s the op­por­tu­nity of a life­time and, un­like in ma­ture en­vi­ron­ments of scale, it feels as if there are no ob­sta­cles — no ar­eas con­sid­ered too dif­fi­cult to change. Do any­thing, do it at scale, and do it to­day.

Why OpenAI ex­actly? I had talked to in­dus­try ex­perts and friends who rec­om­mended sev­eral com­pa­nies, es­pe­cially OpenAI. However, I was still a bit cyn­i­cal about AI adop­tion. Like every­one, I was be­ing bom­barded with ads by var­i­ous com­pa­nies to use AI, but I won­dered: was any­one ac­tu­ally us­ing it? Everyday peo­ple with every­day uses? One day dur­ing a busy pe­riod of in­ter­view­ing, I re­al­ized I needed a hair­cut (as it hap­pened, it was the day be­fore I was due to speak with Sam Altman).

Mia the hair­styl­ist got to work, and ca­su­ally asked what I do for a liv­ing. “I’m an Intel fel­low, I work on dat­a­cen­ter per­for­mance.” Silence. Maybe she did­n’t know what dat­a­cen­ters were or who Intel was. I fol­lowed up: “I’m in­ter­view­ing for a new job to work on AI dat­a­cen­ters.” Mia lit up: “Oh, I use ChatGPT all the time!” While she was cut­ting my hair — which takes a while — she told me about her many uses of ChatGPT. (I, of course, was a cap­tive au­di­ence.) She de­scribed uses I had­n’t thought of, and I re­al­ized how ChatGPT was be­com­ing an es­sen­tial tool for every­one. Just one ex­am­ple: She was wor­ried about a friend who was trav­el­ling in a far-away city, with lit­tle time­zone over­lap when they could chat, but she could talk to ChatGPT any­time about what the city was like and what tourist ac­tiv­i­ties her friend might be do­ing, which helped her feel con­nected. She liked the mem­ory fea­ture too, say­ing it was like talk­ing to a per­son who was liv­ing there.

I had pre­vi­ously chat­ted to other ran­dom peo­ple about AI, in­clud­ing a re­al­tor, a tax ac­coun­tant, and a part-time bee­keeper. All told me en­thu­si­as­ti­cally about their uses of ChatGPT; the bee­keeper, for ex­am­ple, uses it to help with small busi­ness pa­per­work. My wife was al­ready a big user, and I was us­ing it more and more, e.g. to san­ity-check quotes from trades­peo­ple. Now my hair­styl­ist, who rec­og­nized ChatGPT as a brand more read­ily than she did Intel, was prais­ing the tech­nol­ogy and teach­ing me about it. I stood on the street af­ter my hair­cut and let sink in how big this was, how this tech­nol­ogy has be­come an es­sen­tial aide for so many, how I could lead per­for­mance ef­forts and help save the planet. Joining OpenAI might be the biggest op­por­tu­nity of my life­time.

It’s nice to work on some­thing big that many peo­ple rec­og­nize and ap­pre­ci­ate. I felt this when work­ing at Netflix, and I’d been miss­ing that hu­man con­nec­tion when I changed jobs. But there are other fac­tors to con­sider be­yond a well-known prod­uct: what’s my role, who am I do­ing it with, and what is the com­pen­sa­tion?

I ended up hav­ing 26 in­ter­views and meet­ings (of course I kept a log) with var­i­ous AI tech gi­ants, so I learned a lot about the en­gi­neer­ing work they are do­ing and the en­gi­neers who do it. The work it­self re­minds me of Netflix cloud en­gi­neer­ing: huge scale, cloud com­put­ing chal­lenges, fast-paced code changes, and free­dom for en­gi­neers to make an im­pact. Lots of very in­ter­est­ing en­gi­neer­ing prob­lems across the stack. It’s not just GPUs, it’s every­thing.

The en­gi­neers I met were im­pres­sive: the AI gi­ants have been very se­lec­tive, to the point that I was­n’t to­tally sure I’d pass the in­ter­views my­self. Of the com­pa­nies I talked to, OpenAI had the largest num­ber of tal­ented en­gi­neers I al­ready knew, in­clud­ing for­mer Netflix col­leagues such as Vadim who was en­cour­ag­ing me to join. At Netflix, Vadim would bring me per­for­mance is­sues and watch over my shoul­der as I de­bugged and fixed them. It’s a big plus to have some­one at a com­pany who knows you well, knows the work, and thinks you’ll be good at the work.

Some peo­ple may be ex­cited by what it means for OpenAI to hire me, a well known fig­ure in com­puter per­for­mance, and of course I’d like to do great things. But to be fair on my fel­low staff, there are many per­for­mance en­gi­neers al­ready at OpenAI, in­clud­ing vet­er­ans I know from the in­dus­try, and they have been busy find­ing im­por­tant wins. I’m not the first, I’m just the lat­est.

AI was also an early dream of mine. As a child I was a fan of British SciFi, in­clud­ing Blake’s 7 (1978-1981) which fea­tured a sar­cas­tic, opin­ion­ated su­per­com­puter named Orac. Characters could talk to Orac and ask it to do re­search tasks. Orac could com­mu­ni­cate with all other com­put­ers in the uni­verse, del­e­gate work to them, and con­trol them (this was very fu­tur­is­tic in 1978, pre-In­ter­net as we know it).

Orac was con­sid­ered the most valu­able thing in the Blake’s 7 uni­verse, and by the time I was a uni­ver­sity en­gi­neer­ing stu­dent I wanted to build Orac. So I started de­vel­op­ing my own nat­ural lan­guage pro­cess­ing soft­ware. I did­n’t get very far, though: main mem­ory at the time was­n’t large enough to store an en­tire dic­tio­nary plus meta­data. I vis­ited a PC ven­dor with my re­quire­ments and they laughed, telling me to buy a main­frame in­stead. I re­al­ized I needed it to dis­tin­guish hot ver­sus cold data and leave cold data on disk, and maybe I should be us­ing a data­base… and that was about where I left that pro­ject.

Last year I started us­ing ChatGPT, and won­dered if it knew about Blake’s 7 and Orac. So I asked:

ChatGPT’s re­sponse nails the char­ac­ter. I added it to Settings->Personalization->Custom Instructions, and now it al­ways an­swers as Orac. I love it. (There’s also sur­pris­ing news for Blake’s 7 fans: A re­boot was just an­nounced!)

I am now a Member of Technical Staff for OpenAI, work­ing re­motely from Sydney, Australia, and re­port­ing to Justin Becker. The team I’ve joined is ChatGPT per­for­mance en­gi­neer­ing, and I’ll be work­ing with the other per­for­mance en­gi­neer­ing teams at the com­pany. One of my first pro­jects is a multi-org strat­egy for im­prov­ing per­for­mance and re­duc­ing costs.

There’s so many in­ter­est­ing things to work on, things I have done be­fore and things I haven’t. I’m al­ready us­ing Codex for more than just cod­ing. Will I be do­ing more eBPF, Ftrace, PMCs? I’m start­ing with OpenAI’s needs and see­ing where that takes me; but given those tech­nolo­gies are proven for find­ing dat­a­cen­ter per­for­mance wins, it seems likely — I can lead the way. (And if every­thing I’ve de­scribed here sounds in­ter­est­ing to you, OpenAI is hir­ing.)

I was at Linux Plumber’s Conference in Toyko in December, just af­ter I an­nounced leav­ing Intel, and dozens of peo­ple wanted to know where I was go­ing next and why. I thought I’d write this blog post to an­swer every­one at once. I also need to fin­ish part 2 of hir­ing a per­for­mance en­gi­neer­ing team (it was al­ready drafted be­fore I joined OpenAI). I haven’t for­got­ten.

It took months to wrap up my prior job and start at OpenAI, so I was due for an­other hair­cut. I thought it’d be neat to ask Mia about ChatGPT now that I work on it, then re­al­ized it had been months and she could have changed her mind. I asked ner­vously: “Still us­ing ChatGPT?”. Mia re­sponded con­fi­dently: “twenty-four seven!”

I checked with Mia, she was thrilled to be men­tioned in my post. This is also a per­sonal post: no one asked me to write this.

Rebecca Guy, se­nior pol­icy man­ager at the Royal Society for the Prevention of Accidents, said: “Regular vi­sion checks are a sen­si­ble way to re­duce risk as we age, but the pri­or­ity must be a sys­tem that sup­ports peo­ple to drive safely for as long as pos­si­ble, while en­sur­ing timely ac­tion is taken when health or eye­sight could put them or oth­ers in dan­ger.”

Browse by range of dat­ing or by cat­e­gory, New Testament — Apocrypha — Gnostics — Church Fathers — Other, or use the search box.

Acts of Peter and the Twelve

Discourse on the Eighth and Ninth

On the Origin of the World

Also avail­able on the Early Christian Writings CD-ROM

Special Features

Please book­mark the site for fu­ture ref­er­ence.

Let your friends know about the site too.

Early Christian Writings is the most com­plete col­lec­tion of Christian texts be­fore the Council of Nicaea in 325 AD. The site pro­vides trans­la­tions and com­men­tary for these sources, in­clud­ing the New Testament, Apocrypha, Gnostics, Church Fathers, and some non-Chris­t­ian ref­er­ences. The “Early Christian Writings: New Testament, Apocrypha, Gnostics, Church Fathers” site is copy­right © Peter Kirby . Permission is given to link to any HTML file on the Early Christian Writings site.

Please buy the CD to sup­port the site, view it with­out ads, and get bonus stuff!

Gospels

Gospel Fragments

Apostolic Acts

Acts of Peter and the Twelve

Martyrologies

Fifth and Sixth Books of Esra

Dialogues with Jesus

Apocalypses

Acts

Acts of Peter and the Twelve

More Nag Hammadi

Discourse on the Eighth and the Ninth

Apostolic Fathers

Quoted Authors

More Quoted Authors

Pagan and Jewish

Jewish/Christian

I was good at DevOps. This is­n’t a story about es­cap­ing a job I hated. I spent five years as a DevSecOps en­gi­neer at two large fi­nan­cial ser­vices com­pa­nies. I built things I was proud of. I learned a ton. I was re­spected by my team.

But some­where around year four, some­thing shifted. The work did­n’t change. I did. After five years, I made a change that sur­prised every­one who knew me: I left for a sales-ad­ja­cent role. Today, I’m one year into work­ing as a Solutions Engineer at Infisical, and I want to share what I’ve learned. I think there are other DevOps en­gi­neers out there who might be feel­ing the same thing I felt, even if they can’t quite name it yet.

For a long time, I could­n’t pin­point what was wrong. The job was fine. I was good at it. But I started dread­ing the mo­not­ony of it all.

Part of it was rep­e­ti­tion. My days had be­come pre­dictable: check the dash­boards, re­spond to tick­ets, de­bug what­ever broke overnight, push some Terraform, go home. Maintain the HashiCorp Vault clus­ters, man­age the se­crets pipelines, an­swer the same sup­port ques­tions. Repeat. The work that used to feel en­gag­ing had be­come rou­tine.

Part of it was stag­na­tion. When I first started, I was learn­ing con­stantly. Vault ar­chi­tec­ture, PKI fun­da­men­tals, se­crets ro­ta­tion, the pol­i­tics of plat­form adop­tion in a large en­ter­prise. But once I’d mas­tered the core toolset and code­base, the learn­ing curve flat­tened. I was­n’t be­ing chal­lenged any­more. I was just keep­ing things run­ning.

And part of it was iso­la­tion. Most days, it was just me and my pipelines. My pri­mary re­la­tion­ships were with CI/CD tools and YAML files. The hu­mans I did in­ter­act with were usu­ally frus­trated. They needed some­thing from me, or some­thing I owned was block­ing them. I missed work­ing with peo­ple, not just un­block­ing them from be­hind a ticket queue.

I did­n’t have a word for what I was look­ing for. I just knew that what I was do­ing was­n’t it any­more.

I had no idea Solutions Engineering was a real ca­reer path.

I knew sales ex­isted. I vaguely knew there were “technical sales” peo­ple. But I as­sumed those were sales­peo­ple who’d learned enough tech­ni­cal vo­cab­u­lary to get by, not en­gi­neers who ac­tu­ally stayed tech­ni­cal while work­ing with cus­tomers.

Some friends in sales pointed it out to me. They’d watched me get an­i­mated when­ever some­one asked how some­thing worked, and one of them even­tu­ally said: “You know there’s a job where you ex­plain tech­ni­cal stuff to peo­ple all day and help them solve prob­lems, right?”

I’d never con­sid­ered any­thing sales-ad­ja­cent be­cause I as­sumed it meant leav­ing the tech­ni­cal world. But the more I learned about SE, the more I re­al­ized it might solve every­thing I was miss­ing. New prob­lems to solve every day. Constant learn­ing. And more peo­ple.

I ended up join­ing Infisical. There’s some irony there: I spent years man­ag­ing HashiCorp Vault, and now I work for a Vault com­peti­tor. But that back­ground is ex­actly why the role made sense. I knew the space. I knew the pain points. I knew what it felt like to be the en­gi­neer on the other side, eval­u­at­ing these tools.

The biggest change is the sim­plest one: I talk to peo­ple now. A lot of peo­ple. Every day.

In a sin­gle week, I might have a dis­cov­ery call with a fin­tech startup, demo to a plat­form team at an aero­space com­pany, help a health­care or­ga­ni­za­tion trou­bleshoot their Kubernetes de­ploy­ment, and run a work­shop for a man­u­fac­tur­ing com­pa­ny’s se­cu­rity team. Fintech to aero­space to health­care to man­u­fac­tur­ing, all with com­pletely dif­fer­ent stacks and prob­lems.

And it’s not all over Zoom. I get to visit cus­tomers on-site, sit down with their teams face to face, and ac­tu­ally un­der­stand how they work. Over time, you build real re­la­tion­ships with these peo­ple. You be­come their trusted tech­ni­cal ad­vi­sor, not just a ven­dor they talk to once. That’s some­thing I never ex­pe­ri­enced in DevOps, where my “customers” were in­ter­nal teams who mostly just wanted me to un­block them.

The con­trast with my DevOps days is stark. Monday morn­ing used to mean check­ing dash­boards, then the ticket queue, then the same Slack ques­tions I’d an­swered last week. Now Monday morn­ing might mean prep­ping for a demo with a com­pany I’ve never spo­ken to, or help­ing a long-time cus­tomer work through a new chal­lenge. I gen­uinely don’t know what most days will look like un­til they start.

One thing I did­n’t ex­pect: I’m not just talk­ing to cus­tomers. I’ve be­come a bridge be­tween the peo­ple us­ing our prod­uct and the peo­ple build­ing it. Every cus­tomer con­ver­sa­tion sur­faces pain points, fea­ture gaps, edge cases our docs don’t cover. I take that back to en­gi­neer­ing and prod­uct. I’m ac­tu­ally in­flu­enc­ing what we build next, which is some­thing I never had in DevOps. I was al­ways down­stream of de­ci­sions, not shap­ing them.

My biggest fear go­ing in was that I’d lose my tech­ni­cal edge. That I’d be­come “the sales guy” and slowly for­get how things ac­tu­ally worked.

That did­n’t hap­pen. As an SE, I’m ex­posed to every­thing. Customers run­ning Kubernetes, ECS, Lambda, bare metal, air-gapped en­vi­ron­ments. AWS, Azure, GCP, hy­brid se­tups. CI/CD in Jenkins, GitHub Actions, GitLab, CircleCI. I have to un­der­stand their en­vi­ron­ment well enough to ac­tu­ally help them, so the learn­ing is con­stant. The stag­na­tion I felt in DevOps? Gone.

But all those years in DevOps weren’t just back­ground. They’re the rea­son I’m use­ful in this role.

I get on calls and prospects de­scribe prob­lems I’ve lit­er­ally lived. They talk about the pain of man­ag­ing se­crets at scale, and I can say “yeah, I’ve been there” and ac­tu­ally mean it. That shared ex­pe­ri­ence changes the dy­namic com­pletely. I’m not a sales­per­son try­ing to man­u­fac­ture ur­gency. I’m an en­gi­neer who dealt with the same prob­lems and found some­thing that helped.

Is it all up­side? No. Demoing is a skill I had to build from scratch. The con­text-switch­ing is in­tense. The stress is dif­fer­ent, more hu­man, more am­bigu­ous. But it’s the kind of chal­lenge that makes me bet­ter, not the kind that grinds me down.

This path is­n’t for every­one. If you love go­ing deep on a sin­gle sys­tem and op­ti­miz­ing it over years, SE might feel too scat­tered. If you gen­uinely pre­fer work­ing alone with your tools, the con­stant hu­man in­ter­ac­tion might drain you.

But if any of this res­onates, if you’re good at DevOps but feel stuck, if the work has be­come repet­i­tive, if you miss col­lab­o­rat­ing with peo­ple, if you find your­self en­er­gized when ex­plain­ing tech­ni­cal con­cepts or help­ing some­one work through a prob­lem, Solutions Engineering might be worth ex­plor­ing.

I did­n’t know this role ex­isted un­til some­one pointed it out to me. Now, one year in, I can’t imag­ine go­ing back. Not be­cause DevOps is bad. It’s crit­i­cal work, and the peo­ple who do it well de­serve more credit than they get.

But for me, it was miss­ing some­thing I did­n’t know how to name un­til I found it: the chance to be tech­ni­cal and con­nected. To keep learn­ing, to solve new prob­lems every day, and to do it along­side peo­ple in­stead of be­hind a queue.

If you’re a DevOps en­gi­neer feel­ing some­thing sim­i­lar, even if you can’t quite ar­tic­u­late it, maybe this is what you’re look­ing for too.

I did­n’t know this role ex­isted un­til some­one pointed it out to me. Consider this me point­ing it out to you. We’re hir­ing at Infisical.