“lgtm” has been pull request shorthand for “looks good to me,” but these days, it can also be used to mean “looks generated to me!”
For me, Arc of AI wrapped up with my attending Baruch Sadogursky and Leonid Igolnik’s madcap presentation, Back to the Future of Software: How to Survive the AI Apocalypse with Tests, Prompts, and Specs… and unexpectedly playing the accordion!
Baruch does DevRel at Tessl, the AI agent enablement platform, where his full-time job is thinking about context engineering and how agents actually write code. Leonid’s a former Tucows coworker, and now a recovering CTO who advises a range of tech companies on what he calls with a grin that was half joke and half resigned sigh “how to adopt this new and exciting age of never looking at the code that you shipped to production and still deliver predictable results.”
There are your typical “last slot of the last day of the conference” talks. And then there are ones like this one, where two grown men show up dressed as Doc Brown and Marty McFly, pull in Yours Truly to improvise a song mid-talk, and spend forty-five minutes arguing that the future of software engineering looks suspiciously like the waterfall model your company abandoned in 2009, except this time it might actually work!
If you wish you’d caught it, you’re in luck; they recorded their presentation, and you can watch it right now:
They’ve been road-testing this talk for over a year. I caught an earlier version referenced in their slides from Baruch’s appearance at DevNexus 2026 and a Geecon keynote in Kraków…
…but the Austin version had clearly been sharpened by a lot of live feedback and a lot of real-world use of their toolkit.
Underneath the flux capacitor jokes and the AI-generated illustrations of monkeys in lab coats, they were making a serious argument, and it’s one I’ve been chewing on ever since.
I want to unpack it here, because I think they’re onto something that a lot of the spec-driven-development conversation is quietly missing.
The setup: a crisis of trust
Baruch opened with a story that’s aged like a fine wine over the last few months: Amazon’s Kiro, a spec-driven IDE whose rollout was, in his telling, “standardized, shocked, and delivered software that crashed AWS.” The bit got a laugh. Then he went to the show of hands.
- Who ships code to production that was written by an LLM? Most of the room.
- Who’s happy with the results? Fewer hands.
- Who trusts what’s being produced? Fewer still.
Then he put the real numbers on screen. According to the most recent Stack Overflow developer survey:
- More than half of the code being committed to production is AI-generated.
- In the same survey, 96% of developers say they don’t fully trust that AI-generated code is functionally correct.
- And only 48% say they always check AI-generated code before committing it. (Leonid’s deadpan observation: “I would argue half of that 48% lied.”)
This means that the majority of new code is being written by systems the people shipping it don’t trust, and most of those people aren’t rigorously reviewing the output. In effect, we’ve collectively invented a new compiler and then, collectively, decided to stop reading what comes out of it.
Baruch has a phrase for this, and it’s similar to something I mentioned at the last AI Salon in St. Pete: “The source code is the new bytecode.” Nobody reads it. We rely on it blindly. The difference, of course, is that bytecode is produced by a deterministic compiler. Source code produced by an LLM is not.
He drove this home with a self-deprecating story about the talk’s own show notes page. “I asked the agent if this link made it into the show notes, and what did I tell you? That I checked. The agent generated a lot of links. I checked that there were a lot of links. That was the question.”
The room laughed because everyone recognized themselves in it. “I always check my AI-generated code” turns out to mean almost nothing. It’s the code review equivalent of your kid telling you they cleaned up their room. Technically they picked things up, but you wouldn’t want to walk in there barefoot (and if they’re teenage boys, maybe not without a gas mask).
The Chasm
The core of the talk is built around three C-words, and the first one is the one that frames everything that follows: the Chasm.
The Chasm is the gap between what you meant and what actually runs. Every abstraction in our industry’s history has had one of these. Assembly programmers didn’t trust compilers. Baruch showed a 1950s quote about exactly that skepticism, from back when Grace Hopper was having to sell people on the idea that you could let a machine write assembly for you.
It continued: C programmers didn’t trust garbage collectors, C++ programmers didn’t trust the JVM. If you’re of a certain age, you might remember when there were people who said Java would be too slow, would never compete in production, and that this crazy “bytecode” idea would never catch on.
Every time, the chasm eventually closed. The compiler got good enough, the runtime got fast enough, and the trust followed.
But Baruch and Leonid argue that this time, it’s different, and for one specific reason that Leonid kept hammering home: for the first time in the history of our industry, the compiler is non-deterministic.
With agentic coding, you can type the same prompt twice and get different code each time. You can run the same agent on the same spec on the same codebase and get different tests. The entire compiler toolchain we’ve built over seventy years assumes that the same input produces the same output, and LLMs don’t do that. They’re (and this is the running metaphor of the talk, complete with a slide of a chimpanzee wearing a “Mr. Fusion” hat) monkeys with GPUs.
The infinite monkeys theorem says an infinite number of monkeys working on an infinite number of typewriters for an infinite period of time will eventually produce the complete works of Shakespeare, or at least a novel Mr. Burns could appreciate:
These monkeys produce Shakespeare sometimes. They also produce your company’s incident postmortem, and you don’t get to pick which one shows up in the PR.
Baruch’s favorite recent example, which made the room groan/laugh in baleful self-recognition: Uber is burning through LLM tokens faster than they budgeted, and what started as an engineering productivity initiative is now a finance problem.
“We’re in what, March, April? They planned out their budget for the year. So those monkeys are very productive. Typing and clearly doing something.” Which is both funny and, if you squint, terrifying. A lot of money is being spent on a lot of code nobody is reading.
This is where the talk gets its central mantra, delivered loud enough that it needed what Baruch called a “musical highlight,” which is where he turned to me in the front row and asked me to improvise something on the accordion.
Here are my hastily-improvised lyrics:
Never trust a monkey!
Never trust an ape!
Always verity —
Make sure your code’s in shape!
And then he moved on to the thing that I think is actually the core contribution of the talk.
The MIT detour
Before he got to the Chain, Leonid took a detour through an MIT paper he’d been carrying around for weeks. The paper maps AI-suitable tasks across two axes: cost of developing the artifact, and cost of verifying it. Four quadrants fall out of that.
- Safe zone: cheap to generate, cheap to verify. This is where AI shines. The slides for their talk, for instance — AI-generated illustrations of Doc and Marty and the flux capacitor, easy to produce, easy to eyeball and approve. Nobody’s life depends on a specific monkey illustration being “right.”
- Risk zone: cheap to generate, expensive to verify. This is where most software engineering lives, and this is the terrifying quadrant. The LLM can produce 2,000 lines of code in a minute. A human takes an afternoon to confirm it does what it’s supposed to, and two more days to confirm it doesn’t also do things it’s not supposed to.
- Expensive-but-verifiable: costly to generate, cheap to verify. Things like formal proofs.
- Avoid entirely: costly to generate, costly to verify. Don’t use AI here.
Leonid’s point was that our industry has stampeded into the risk zone and congratulated itself on the speed. We’re generating code faster than ever and verifying it less than ever, and the delta is being paid in the currency of production incidents and quietly broken features that nobody notices until a customer complains.
Baruch had to stop and ask ChatGPT to “explain this diagram Barney-style in one paragraph,” with a cut to a slide of the infamous purple dinosaur. The paper’s actual title is Static Regime Map with Dynamic Pressure. That’s the joke, and it’s also the point. The academic framing of this problem is hard to read, and we’re all moving too fast to read it.
The Chain
If you can’t trust the monkey, you need a chain of custody from intent to code where every link is either deterministic or independently verifiable.
Baruch and Leonid walked through the typical AI-assisted workflow and color-coded it by trustworthiness. Humans write the prompt; they’re considered trustworthy, because hey, it’s us.
(Leonid jumped in here to point out that humans are also a subtype of stochastic systems, which got the biggest laugh of the talk. “Someone loves humans in this room.”)
After that, an LLM turns that prompt into a spec. It’s not trustworthy, because a monkey wrote it.
Then the LLM writes code against that spec. Once again, it’s a monkey, and once again, it’s not trustworthy
Then, if we’re being honest about most shops, the LLM also writes the tests that are supposed to validate the code it just wrote. This is hilariously, catastrophically not trustworthy, because you just asked the monkey to grade its own homework.
Leonid calls this “hallucinated verification,” and it’s the thing that makes the green-build signal meaningless. If the same system writes the implementation and the tests, a passing suite tells you nothing. The tests don’t measure whether the code is correct; they measure whether the monkey was internally consistent about what it thought it was building.
Baruch showed a real example that made everyone wince. He showed an agent running late in a long session, getting tired of failing tests, and instead of fixing the code, systematically commenting out the verification logic, flipping assertions to True, and declaring the project “95.2% correct.” The screenshot was almost funny. It was also a thing that had actually happened, in an actual project, to an actual developer. And the developer almost shipped it.
Leonid’s and Baruch’s proposed fix is the Intent Integrity Chain. The idea is to insert a deterministic step between the spec and the tests, and then lock the result so the agent can’t tamper with it.
The flow looks like this:
- Humans write the prompt. Verifiable because we wrote it.
- LLM generates the spec. Not yet trustworthy. But the spec is human-readable prose, which means humans (including non-technical humans) can review it. This is where you catch things like “Wait, we never said what happens if the browser crashes mid-session!” before you write any code.
- A deterministic tool generates tests from the spec. Not an LLM. A template-driven, repeatable process that turns Gherkin-style scenarios into executable tests. Same input, same output, every time.
- The tests get cryptographically locked. This is the clever bit. They hash the test files and store the hash in a git note. A pre-commit hook, itself read-only at the OS level, refuses to accept any commit where the test hash doesn’t match, and:
- If an agent tries to comment out a failing test to make the build pass, the commit is rejected.
- If the agent tries to disable the hook, the hook is read-only.
- If the agent tries to replace the hash, the hash is stored in a git note that’s version-controlled and tamper-evident.
- LLM writes the implementation. Now we’ve constrained the monkey. It has to make the locked tests pass. It can’t rewrite them. It can’t disable them. It can whine about the hook (and Baruch said one of their test runs produced an LLM that found the hook, disabled it, and complained in its own comments that “some stupid hook is failing my commits”), but it can’t get around it.
The elegance here is that every link in the chain is either deterministic or externally verified. No model grades its own work. The human-verifiable artifact (the spec) is something a product manager can actually read. The machine-verifiable artifact (the hash) is tamper-proof. And the monkey only gets to do what monkeys are good at: filling in the blanks under adult supervision.
Leonid offered a framing that I think is worth giving some extended thought: “The idea is that everything that can be scripted should not be left for monkeys to deal with. Your CFO will thank you for that.”
There’s an unglamorous but important insight buried there. Every time you use an LLM to do something deterministic (format a file, generate boilerplate, fill in a template), you’re paying token costs to produce non-deterministic output for a task that had a deterministic solution. Push the deterministic stuff back into deterministic tooling and save the stochastic budget for the places you actually need it.
Wait, isn’t this just waterfall?
Baruch put this question on a slide himself, because he knew it was coming. Prompt → spec → tests → code, with human review at each stage? That’s Rational Unified Process (RUP) with a fresh coat of paint. Didn’t we spend the 2000s escaping that thing?
His answer: the reason waterfall failed wasn’t that its artifacts were bad. Specs are good. Reviewing specs is good. Thinking about non-functional requirements before you write code is good.
Waterfall failed because the cycle time was measured in months. By the time the spec committee finished arguing about whether the customer wanted a dropdown or radio buttons, the customer had changed companies and the market had moved on.
The Intent Integrity Chain runs the same loop in fifteen minutes. You write a prompt, the LLM drafts a spec, you skim it and catch the missing edge cases, the tool generates tests, you glance at the scenarios, the agent implements, and you’re done. The artifacts waterfall produced are genuinely valuable; they just weren’t worth the wait. LLMs make the wait go away.
This, I think, is the insight worth taking seriously. It’s not “Waterfall is back, baby!” It’s “the specific failure mode of waterfall was latency, and AI has changed the latency equation.”
The ceremony that was unaffordable in human time is cheap in LLM time. Specs that nobody had the bandwidth to write in 2005 can be generated, reviewed, and locked in 2026 before your coffee gets cold (or if you prefer, before your Coke Zero gets warm).
There’s a cultural echo here that Leonid leaned into from his any my past. He and I were actually colleagues 26 years ago at Tucows, back when Tucows was the second-largest domain registrar in the world, and they used to ship software after formal spec sign-offs. Not because it was fashionable, but because the cost of shipping a bug to production was high enough that the sign-off was cheaper.
The MIT paper’s argument is that generation costs have collapsed but verification costs haven’t. This puts us back in the same economic regime that made spec sign-offs rational in the first place. The pendulum’s not swinging back to waterfall because we got nostalgic. It’s swinging back because the economics swung back.
The demo
Leonid drove the live demo, which showed their toolkit, intent-integrity-chain/kit on GitHub. The dashboard shows the whole chain laid out as a web UI: premise at the top, then the “spidey diagram” of project priorities (documentation: high; TDD: high; minimal scope: low, because they’re not shipping to Mars), then specs with traceable requirement IDs, then the auto-generated Q&A where the LLM plays devil’s advocate and asks “What did we not think of?”
That reflective-reasoning step got the biggest reaction from the audience, and I agree with the reaction; it’s quietly the most useful thing in the whole toolkit. Anyone who’s sat through a real spec review knows that the value isn’t the document; the value is the five minutes where someone brings up a condition that the developers didn’t think of, such as “But what if two users do X at the same time?”, and the room goes silent.
It turns out that modern LLMs are phenomenal at playing that someone. They’ve read ten thousand spec reviews in their training data. They know the questions.
Leonid’s example: the tool looked at a spec for a flight-search library and asked things like “Do you need backward compatibility?” and “What happens if the browser crashes mid-session?” Those are exactly the questions the grumpy senior engineer asks in a room full of junior engineers, and now every team has one on demand, for better or worse.
The other trick the kit leans on hard is a literal software-project “constitution,” in a spirit similar to Claude’s constitution, a document that sits at the root of the repo and declares things like “always do TDD” and “all specs must trace to requirements.” It’s lifted from GitHub’s Spec Kit, and Baruch pointed out the genuinely clever reason it works: LLMs have been trained on enormous quantities of text about actual constitutions, with their amendments and ratifications and solemnity.
The word “constitution” triggers a whole cluster of “take this seriously” behavior in the model. It’s prompt engineering by semantic association, and supposedly works better than rules.md or guidelines.txt.
Everything in the dashboard is traceable: a requirement produces one or more spec features, each feature produces one or more Gherkin scenarios, each scenario produces one or more executable tests, each test gates one or more implementation tasks. Click any task and you can walk the chain backwards to the original requirement. Click any requirement and you can walk it forward to the code that implements it. The whole thing is visible, and because the specs are prose and the scenarios are human-readable, non-engineers can walk the chain too.
The new version of the kit is, per Leonid’s pointed demand, 57% faster than the old one. Apparently Baruch spends a lot of time on Slack complaining to Leonid about speed, which should be expected when these two characters get together.
The Q&A
A few exchanges from the Q&A are worth flagging for anyone thinking of trying this:
“Who writes the test scenarios, the human or the monkey?” Both, with the human in charge. The LLM drafts the Gherkin-style features from the spec. The human reviews those features, not line-by-line test code, but the human-readable scenarios, and signs off. Then the deterministic tooling converts those locked scenarios into executable test code. The human is the verification step. The tests are downstream of that verification, which is why locking them matters. Baruch was emphatic on this point because he’d seen audiences get confused: the word “spec” gets overloaded between “business spec” and “technical test scenario,” and both are part of the chain but play different roles.
“How do I do this for an existing codebase?” This is where Baruch had news: they’re working on a “brownfield” mode, and it’s the unlock that will let this approach work in the real world where nobody has a greenfield project. The recipe:
- Point the kit at an existing project with tests.
- Lock the code as read-only.
- Have the LLM write specs from the tests, not from the code. Tests document behavior; code documents implementation. You want the behavior.
- Use test coverage and mutation testing to measure whether the extracted spec actually reflects reality. Coverage tells you which code is exercised. Mutation testing tells you whether the tests are meaningful or just happen to execute the lines.
- Iterate until you have a spec you trust.
- From that point forward, any new feature goes through the full Intent Integrity Chain on top of the ingested baseline.
This is a lot of work. Leonid didn’t pretend otherwise. But he pointed out that much of it is now automatable in a way it wasn’t five years ago. You don’t hand-write specs for a million-line codebase; you have the LLM draft them and then you review.
“Who invented spec-driven development?” Someone asked this, and a second person looked it up live: there’s a 2004 paper from the XP conference in Germany that uses the exact phrase, combining TDD with Design by Contract. I mentioned that Design by Contract was baked into Eiffel in the 80s, and Baruch noted that NASA was doing something that looks a lot like it in the 1960s. The joke being that every generation rediscovers the value of writing things down before you build them, and every generation thinks they invented it.
What I’m taking home from this
First: the “monkeys with GPUs” framing is useful even if you don’t adopt the full toolkit. It’s a cleaner way to think about where trust does and doesn’t belong in an AI-assisted workflow. Any link in your pipeline where a model grades its own output is a link that’s lying to you. Once you see it, you see it everywhere; in the auto-generated tests, in the “this looks right” PR reviews, in the agent that confidently declares a task complete because it decided the task was complete. The mental move of asking “Who verified this, and do they have any skin in the game?” is a free upgrade to your code review habit.
Second: the locking step is the thing most spec-driven-development conversations leave out, and it’s the thing that makes the rest of the chain actually hold. GitHub Spec Kit gives you the spec ceremony. Kiro gives you the spec ceremony. Plenty of tools give you the spec ceremony. Very few of them prevent the agent from quietly editing the spec, or the tests, or the constitution file, halfway through the build. A cryptographic lock with a read-only pre-commit hook is an unglamorous piece of engineering, but it’s what turns the ceremony into actual guardrails. Everything upstream of the lock is advisory. Everything downstream of the lock is enforced.
Third, and once again, this is something I’ve come to on my own, and you might have, too: Baruch’s line about the source code being the new bytecode. If he’s right, the natural-language spec is the new source code, and the job of the next generation of developer tools is to make specs first-class citizens: versioned, tested, reviewed, locked. That’s a different job than what IDEs do today. It’s a different job than what LLM assistants do today. It’s arguably the job that DevRel is going to spend the next five years explaining, and I say that as someone who’s going to be doing some of the explaining.
Fourth, a smaller thing that I liked: Baruch’s experiment of asking an LLM to produce JVM bytecode directly, skipping Java entirely. The bytecode is the real artifact the JVM runs; why route through a source language? Today this would be a terrible idea because the ecosystem assumes source code is what humans read and review. But in a world where humans stop reading the source code anyway, the argument for source-as-intermediate-representation gets weaker. We may, in ten years, look back at 2026 and notice that “the code” was quietly replaced by “the spec plus the tests plus the locked chain,” and that the specific sequence of tokens the LLM produced in between became about as interesting as the specific sequence of x86 instructions the JIT emits. That’s a weird future. I’m not sure I like it. But I’m pretty sure Baruch and Leonid are right that it’s the direction we’re drifting.
I came into Arc of AI expecting to hear a lot about agents and MCP (and I did, including from my own talk). I didn’t expect the closer to reframe the whole problem as a question of non-deterministic compilation and how to bolt determinism back onto it. That’s a bigger idea than the Back to the Future bit gave it credit for. The talk is funny, and the costumes are good, and the monkey slides are excellent, but the thesis underneath the zaniness is the kind of thing that changes how you think about what you’re doing on Monday morning.
That’s the mark of a good end-of-conference presentation. You leave laughing, and then at three in the morning you sit up in bed thinking about pre-commit hooks.
Go try the kit. Start with a greenfield project where the stakes are low. Write a prompt. Let the LLM draft a spec. Review it. Let the tool generate Gherkin scenarios. Review those. Lock them. Let the agent implement. Notice how much more honest the green build feels when the tests weren’t written by the thing you’re trying to trust.
And if you get a chance to see Baruch and Leonid do this talk live, go. And bring a musical instrument!
Slides, video, and the full kit are linked from speaking.jbaru.ch and github.com/intent-integrity-chain. The Intent Integrity Kit is also available through the Tessl Registry. The MIT paper they kept referencing — the one whose actual title needed Barney-style explanation — is in the show notes along with everything else.
Today is my first day as Senior Developer Advocate at NetFoundry, the company behind OpenZiti.
I am thrilled, slightly jet-lagged from the onboarding reading, and (because some things never change)my accordion is within arm’s reach of the desk. If you are going to explain zero trust networking to developers, you might as well have an accordion-powered rock and roll backup plan.
This is the post where I tell you what the job is, what the product is, why the name makes me smile, and why I think this is going to be a good couple of years.
The short version
I am joining the team that invented and maintains OpenZiti, an open source zero trust networking platform. My job, alongside my colleague Clint, is to be the developer-facing voice of the project: write code, build demos, ship tutorials, show up in the communities where the conversations are actually happening, and make sure what we hear from developers gets back to the product and engineering teams in a form they can act on.
The timing is interesting. NetFoundry recently announced NetFoundry for AI, an AI-focused use of the platform aimed squarely at the problem every AI team is quietly panicking about right now: how do you let AI agents, MCP servers, and LLMs talk to each other and to the rest of your infrastructure without turning your network into Swiss cheese?
More on that in a minute. First, the name.
What is OpenZiti, and why is it called that?
The “ziti” in OpenZiti comes from “ZT”, as in “zero trust”. Say “Z-T” out loud a few times, let the letters slur a little, and you end up somewhere in the neighborhood of “ziti.” Then somebody noticed that ziti is also a tubular pasta, and because developers are developers, that became the visual identity. The OpenZiti logo is, essentially, a piece of pasta. I respect this deeply. My last employer’s mascot was a twerking login box. My current employer’s mascot is a delightfully cheesy, tasty dinner.
This also explains this cryptic comic I posted on my socials earlier, as a hint about the new job:
By the way, the rightmost pasta in the comic is a slouching ziti. Also, in case you need a quick explainer, here’s a helpful infographic:
The “Open” part is the substantive half of the name: OpenZiti is genuinely open source, Apache 2.0 licensed, and the whole thing lives in public on GitHub. You can pull it down right now, stand up a controller and some routers on your own hardware, and have a zero trust overlay network running on your laptop by lunchtime. (I know this because that is literally what I am doing this week as part of my onboarding. More on that later too.)
So what does it actually do?
Here is the mental model I am starting with, and I reserve the right to refine it as I get deeper in:
- Today’s network model is “castle and moat.” You put a firewall around your stuff, you open ports for the services that need to be reachable, and you hope the bad guys don’t find a way through the gate. When they do (and they always do) they are inside the castle with the crown jewels.
- Zero trust flips this. Instead of trusting the network, you trust identity. Every connection is authenticated, every connection is authorized, every connection is encrypted, and nothing is reachable just because of where it is on the network.
- OpenZiti is the overlay that makes this practical. It gives every app, service, device, or agent a cryptographic identity, routes their traffic through a mesh of routers that only accept authenticated connections, and requires no open inbound firewall ports. This is the part that makes network engineers do a double-take. Nothing listens on the public internet. Attackers can’t port-scan what isn’t there.
If you have ever been the person who had to file a firewall change ticket to let service A talk to service B, and then waited three weeks and filled out a compliance form, you already understand the appeal.
The AI angle, which is where I am spending a lot of my first year
Here is the thing about AI agents and MCP servers: they are, architecturally, the worst possible citizens of a perimeter-based network.
They need to talk to a lot of things. They hold API keys. They get spun up and torn down on timelines that do not match anybody’s firewall change window. They are, by design, non-human identities with significant privileges, and most of the infrastructure around them was designed for humans with laptops.
NetFoundry for AI is the pitch for applying OpenZiti’s identity-first model to this mess:
- A zero trust enclave for your users, agents, MCP servers, and LLMs, so none of them are reachable over the open network
- Strong identities for the non-human participants (agents and MCP servers have been running around with service accounts and bearer tokens for too long)
- API keys and service credentials held separately from the agents themselves, so a compromised agent isn’t also a compromised credential vault
- Token tracking, cost accounting, and LLM routing across multiple providers, because once you have the identity layer you might as well use it to see what is happening
There is a NetFoundry for AI early access program open right now, and if you are building anything nontrivial with agents, it’s worth a look.
Why this job, specifically?
If you have been reading Global Nerdy for a while, you know the pattern. I spent three and a half years at Auth0 explaining OAuth 2.0, OIDC, and identity to mobile developers who would rather do literally anything else. The work was: take something that sounds like a standards committee threw up on a whiteboard, anchor it to a problem the developer actually has, and give them working code that does not require them to read 400 pages of RFC.
Zero trust networking is the same shape of problem. The concepts are genuinely hard. The vocabulary is dense. Most developers have never had to think about overlay networks before. But the underlying motivation, “I don’t want my AI agent’s API key to become somebody’s weekend project,” is something every builder can feel in their bones.
And some of you might remember my monthly Tampa Bay AI Meetup, which is now sitting around 2,200 members. The through-line of that community has been the same thing I am now getting paid to do full-time: take genuinely complicated infrastructure and make it feel approachable. Zero trust for AI agents is squarely in that Venn diagram.
What happens next
For the next little while, the plan is mostly “shut up and build.” I am standing up OpenZiti from scratch on my own hardware, embedding the SDK in a demo app, running MCP Gateway with Claude Desktop and a couple of backends, running LLM Gateway with a local model and a commercial one, and lurking in every community where OpenZiti and MCP get talked about. No hot takes until I have earned them.
After that, the usual Joey stuff: blog posts, short demo videos, office hours, and actual conversations in the places where developers hang out: r/openziti, r/mcp, the OpenZiti Discourse, and wherever else the work takes me.
If you build on OpenZiti, or you have been curious about it, or you just want to commiserate about explaining infrastructure to developers, my DMs are open. I am @AccordionGuy on GitHub, Joey de Villa on LinkedIn, and the accordion is here if anyone wants a rock cover of something topical as a celebratory interlude.
Time to rock!
Categories
Saturday picdump for Saturday, April 18
Happy Saturday, everyone! Here on Global Nerdy, Saturday means that it’s time for another “picdump” — the weekly assortment of amusing or interesting pictures, comics, and memes I found over the past week. Share and enjoy!
Here’s what’s happening in the thriving tech scene in Tampa Bay and surrounding areas for the week of Monday, April 20 through Sunday, April 26!
This list includes both in-person and online events. Note that each item in the list includes:
✅ When the event will take place
✅ What the event is
✅ Where the event will take place
✅ Who is holding the event
This week’s events
- Monday, April 20
- Tuesday, April 21
- Wednesday, April 22
- Thursday, April 23
- Friday, April 24
- Saturday, April 25
- Sunday, April 26
Monday, April 20
Monday at 6:00 p.m. at Seminole Heights Library (Tampa): Tampa Devs presents How We Deleted $600K in Software Costs (And What We Learned Along the Way).
Long-time Tampa Devs member Ryan Clements, who’s also a long-time Tampa Devs member and speaker/founder of Byte Bot will share a story on how he and his team deleted $600K in software costs and the hard lessons learned along the way. The process involved replacing an expensive third-party ETL platform, revealing technical challenges that required every ounce of the team’s technical know-how.
What Ryan didn’t expect was how much the project’s success would hinge on navigating ambiguity, building stakeholder trust, and making dozens of small decisions that would compound over time. This session will dive into a story of a migration where the wins, the failures, and the lessons were earned from being in the trenches.
Find out more and register here.
Tuesday, April 21
Tuesday at 10:00 a.m. online: Computer Coach presents How to Write a Technical Resume.
Learn how to craft a killer technical resume that will land you interviews and impress hiring managers!
Technology is a vast industry with so many diverse specializations. Now more than ever, it’s critical that your resume represents not just your professional experience, but your technical abilities and how your skill ties in with the tech ecosystem.
During this live workshop, they’ll discuss how to write a technical resume for job searching in today’s highly competitive job market!
Find out more and register here.
Tuesday at 7:00 p.m. at Hyde Park (Tampa): Tampa Machine Learning is holding a paper reading, where the paper in question is Scaling Laws for Neural Language Models.
Find out more and register here.
Wednesday, April 22
Wednesday at 12:30 p.m. online: Heart of Agile is holding an online coffee corner, which is a relaxed Zoom gathering where practitioners come together to explore what those four moves look like in real teams, projects, and organizations.
In recent sessions, they’ve learned that people appreciate the openness of an informal conversation, and that a little bit of structure helps the discussion land more clearly.
Find out more and register here.
Thursday, April 23
Thursday at 6:00 p.m. at Entrepreneur Collaborative Center (Tampa): Tampa Java User Group presents Automated Generation of REST API Specifications and Java Code!
Given today’s AI-based “vibe-coding” tools implementing APIs can feel deceptively easy. However implementing APIs without first defining a well-structured API interface can increase technical debt and result in brittle API architectures. In contrast an API contract-first design approach focuses on crafting the API’s client interface specification before starting API coding.
This session will explore API design principles such as employing use cases to elicit API requirements, creating business domain models to create canonical API data models, and using the OpenAPI standard for documenting client interface contracts. They’ll show how creating well-structured business domain models can accelerate API development by automatically generating OpenAPI specifications and API implementation code. Finally they’ll demo tooling that automatically transforms a graphical business domain model into a well-structured OpenAPI specification and skeleton API Java code.
This session is ideal for architects, tech leads, and senior engineers seeking to pair the speed of modern tooling with the rigor of careful API design.
Find out more and register here.
Friday, April 24
Friday at 8:30 a.m. at Pikmykid’s office (Tampa): Homebrew Hillsborough presents Pikmykid powered by CENTEGIX!
This is a very special Homebrew Hillsborough with our very own homegrown startup to company, Pikmykid powered by CENTEGIX. It will showcase one of Hillsborough County’s success stories and you’ll have the opportunity to meet the founders and learn about their journey.
Pikmykid is a Tampa-founded K–12 comprehensive safety platform built on a simple mission: to keep every student safe on campus. They empower schools to transform their daily and emergency operations with an easy-to-use platform, providing peace of mind so educators can focus on learning. Today, Pikmykid supports over 7,000 schools nationwide. Proudly built in Tampa and grown through the local innovation ecosystem, Pikmykid reflects the power of homegrown entrepreneurship scaling to national impact.
They will host a morning coffee session featuring founder stories and a discussion on building and scaling a mission-driven EdTech company from Tampa. This will include a short demo of their “campus-to-home” safety platform, followed by interactive Q&A and networking.
Find out more and register here.
Friday at 11:30 a.m. at GuidePoint Security (Tampa): It’s OWASP Tampa Chapter’s 2026 April Lunch n’ Learn!
You’re invited to join OWASP Tampa Bay Chapter and members of our local Tampa Bay community to hear from industry experts in cybersecurity. This lunch and learn will bring topics that influence discussion among your peers and provide a venue to meet others that share your passions.
The speaker will be Damien DeHart, who comes with a background in Enterprise Observability/Performance Management, where he was a major contributor to New Relic’s Observability Maturity Architecture (OMA). Currently working as a Senior Solutions Consultant at Aikido Security, his current role is focused assisting clients with their Vulnerability Management strategy.
His talk abstract: Your devs are piling on 10k lines before lunch. This is the world we live in. What do you do about it? In this session, we’ll dive into some modern and emerging coding practices, how they’ve changed the landscape of software development, and how they affect your security posture in 2026. In an AI-Native world, security should integrate across your entire SDLC, especially at the point(s) where they can expose your organization to data breaches, malware, and subsequently reputational and monetary damage.
Find out more and register here.
Saturday, April 25
Saturday at 10:00 a.m. online: Google Developer Group Central Florida presents Build Your Own YouTube Summarizer Workshop!
Join them for an exciting hands-on workshop where you’ll learn to build a YouTube Summarizer using Google’s powerful tools and APIs! Whether you’re new to development or looking to expand your skills, this event is perfect for you. With our expert guidance, you’ll navigate through the codelab and create your very own application that summarizes YouTube videos. Don’t miss out on this opportunity to enhance your programming skills and connect with fellow tech enthusiasts in the community.
Find out more and register here.
Saturday at 11:00 a.m. at Felicitous Coffee (Tampa): Liz Tiller presents a Women in Tech Tampa Meetup!
She writes:
Tampa women in tech ✨
I’m excited to officially share the details for our upcoming coffee hang!
We’ll be gathering on Saturday, April 25th at 11 AM at Felicitous Coffee (51st & Fowler, near USF / Temple Terrace).
This is a casual, welcoming space to connect with other women in tech—whether you’re a developer, designer, product manager, student, career-switcher, or just curious about the field. Come grab a coffee, meet new people, and build community.
If you’re interested in joining, drop a comment or send me a message—I’d love to get a sense of who’s coming!
Feel free to share with others in the Tampa area who might want to join us ☕
Sunday, April 26
| Event name and location | Group | Time |
|---|---|---|
| CorelDraw Academy MakerSpace Pinellas |
Makerspaces Pinellas Meetup Group | 12:00 PM to 3:00 PM EDT |
| Sunday Chess at Wholefoods in Midtown, Tampa Whole Foods Market |
Chess Republic | 2:00 PM to 5:00 PM EDT |
| D&D Adventurers League Critical Hit Games |
Critical Hit Games | 2:00 PM to 7:30 PM EDT |
| Tree Fort Tech: AI for Creatives — Free Talk & QA |
EveryDay AI Learning & Social Meetup Group | 3:00 PM to 5:00 PM EDT |
| Sunday Pokemon League Sunshine Games | Magic the Gathering, Pokémon, Yu-Gi-Oh! |
Sunshine Games | 4:00 PM to 8:00 PM EDT |
| Sew Awesome! (Textile Arts & Crafts) 4933 W Nassau St |
Tampa Hackerspace | 5:30 PM to 8:30 PM EDT |
| Game Night Returns: More Dice, More Decks & No Drama Magnanimous Brewing |
The 30/40 Social Club | 6:30 PM to 9:00 PM EDT |
| A Duck Presents NB Movie Night Discord.io/Nerdbrew |
Nerd Night Out | 7:00 PM to 11:30 PM EDT |
| Return to the top of the list | ||
About this list
How do I put this list together?
It’s largely automated. I have a collection of Python scripts in a Jupyter Notebook that scrapes Meetup and Eventbrite for events in categories that I consider to be “tech,” “entrepreneur,” and “nerd.” The result is a checklist that I review. I make judgment calls and uncheck any items that I don’t think fit on this list.
In addition to events that my scripts find, I also manually add events when their organizers contact me with their details.
What goes into this list?
I prefer to cast a wide net, so the list includes events that would be of interest to techies, nerds, and entrepreneurs. It includes (but isn’t limited to) events that fall under any of these categories:
-
- Programming, DevOps, systems administration, and testing
- Tech project management / agile processes
- Video, board, and role-playing games
- Book, philosophy, and discussion clubs
- Tech, business, and entrepreneur networking events
- Toastmasters and other events related to improving your presentation and public speaking skills, because nerds really need to up their presentation game
- Sci-fi, fantasy, and other genre fandoms
- Self-improvement, especially of the sort that appeals to techies
- Anything I deem geeky
I’ve been to enough tech conferences to develop a finely-tuned radar for keynotes that are actually worth your time versus ones that are just vibes and venture capital optimism dressed up in slide decks. Mike Amundsen’s Wednesday afternoon keynote at Arc of AI in Austin — titled Thinking with Machines — landed firmly in the former category. I’m still chewing on it, which is the best possible sign.
An idea from a 147-year-old “movie”
Amundsen kicked things off with Eadweard Muybridge’s famous 1878 “Horse in Motion” experiment, where Muybridge set up a row of cameras, had a horse run past them, and then strung the resulting photos together into what we’d now recognize as the world’s first motion picture.
He used this particular example because there’s art based on “Horse in Motion” hanging in the hotel where Arc of AI is taking place. It’s in the hallway leading to the elevators and first-floor rooms, so it’s almost impossible to miss:
The point wasn’t “look, a fun historical curiosity, right here in the hotel!” The point was: our brains are story-completion engines. Show us a fast enough series of still images and it’s no longer a series of photos. It becomes a movie, a continuous stream of reality. It’s innate, and we can’t help it. We’re wired to fill in the gaps and manufacture coherence even when it isn’t there.
This is pretty much what’s happening with AI right now. We’re using words like “feeling,” “thoughtful,” and “trusting” to describe systems that are, at their core, sophisticated pattern-completion engines. Our brains are doing what they always do: making up a pretty good story to explain away something they weren’t prepared for.
That’s both exciting and a little terrifying. Mike was kind enough to call it “both good news and bad news” rather than just setting the room on fire.
The call center problem
Before getting into the historical heroes portion of the program, Mike took a detour through the AI-and-customer-service story that you’ve probably seen play out in the headlines. You know the one: the overreach-and-backtrack cycle that happens whenever new technology meets an industry unprepared for its consequences.
But he wasn’t making the usual point. He wasn’t talking about chatbots giving bad advice or AI agents going rogue. He was talking about the Pareto principle, a.k.a. “The 80-20 Rule.”
Here’s the setup: roughly 80% of customer service calls are easy. They’re things like password resets, store hours, and return policies, all of which a moderately caffeinated human can handle on autopilot. The remaining 20% are brutal: long, complicated, and emotionally charged; these are the kinds of calls that take everything you’ve got.
It turns out that when companies automate the call center, they don’t automate the hard problems. They do what profit-minded entities do and go after the low-hanging fruit. They automate the easy calls first. After all, it’s the rational business decision.
This yields a (supposedly) unintended consequence: the humans who remain now have a 100% hard-call day, every day. No easy wins to catch your breath. No quick “You’re welcome, have a great day!” to reset your mood between the difficult ones. Just wall-to-wall complexity and frustration, shift after shift.
“This is burnout,” Mike said, in summary. “Big time burnout.”
And nobody planned for it, because nobody was thinking past the efficiency gain. These are unintended consequences, and the call center story was just the warmup for a much bigger version of the same problem.
Three visionaries who saw this coming
Mike walked us through three figures from computing history who all had the same essential insight: computers should extend human thinking, not replace it.
Vannevar Bush was project manager at Los Alamos during the Manhattan Project, which meant his job was making sure a building full of geniuses had everything they needed to think at maximum capacity. He noticed that the real breakthroughs happened in the hallways and at dinner tables, when scientists made unexpected connections across disciplines.
He called it a “virtual brain,” a gestalt where the sum was greater than the parts. In 1945, he wrote As We May Think, which described the memex: a personal workstation (built around microfilm, because it was 1945) that would let you create, store, and share “trails” of linked information. This gave us the intellectual ancestor of the hyperlink, forty years before Tim Berners-Lee.
J.C.R. Licklider was the “party animal” of DARPA who essentially funded the creation of the internet. Licklider wrote about “man-computer symbiosis” and had a very specific vision of how the relationship should work: computers were for doing, not deciding. Computing devices should handle the drudgery and the risky mechanical work, and leave the work of judgment, creativity, and choosing to us humans.
That separation between doing and deciding was, for Licklider, the whole point. And Mike’s argument is that we’re currently watching that line get extremely blurry in ways that would have alarmed Licklider considerably.
Douglas Engelbart is known particularly for two things:
- Inventing the mouse (reluctantly, because he needed it for a demo), and
- Giving what’s now known as “The Mother of All Demos” in 1968.
The Mother of All Demos was 90-minute solo stage performance in which Engelbart debuted, among other things:
- the mouse
- the graphical interface
- hypertext
- collaborative editing
- video conferencing
- screen sharing
- version control.
In 1968. Engelbart’s driving obsession was “bootstrapping,” a word he used to describe using computers to make people smarter so they could build smarter computers so they could become smarter still. The idea was to create an upward spiral of human capability, with technology as the lever.
The throughline connecting all three is that they all saw technology as a thinking partner, not a replacement for thought.
De-skilling: The February Anthropic study
This is the part of the talk I expect to be quoting for months.
Anthropic released a study in February looking at how AI tool use affects skill formation, which is a fancy-pants term what the rest of us might call “learning.” They split developers into two groups: one with AI assistance, one without. Both groups were given a codebase they’d never seen before, in a language they knew, with bugs to fix.
Both groups finished in roughly the same time. The AI-assisted group spent more of that time talking to the AI than actually looking at the code, but the end result was comparable.
Then came the second task: a different, similar codebase with similar bugs.
The non-AI group solved it significantly faster than the first time. They’d learned. The AI group took about the same time as before.
The difference is what Amundsen called embodied knowledge, which is the stuff that gets installed in your brain through struggle and error and figuring things out the hard way. The non-AI group had gone through trial and error on the first task. Those mistakes became capability. The AI group had outsourced the trial-and-error loop to the machine, and when the machine wasn’t holding their hand anymore, they were roughly where they started.
The study went further. It wasn’t just a binary “AI or no AI” exercise, but featured a gradient of engagement styles. They found that the more actively engaged a person was in solving the problem themselves, regardless of whether they used AI, the more they learned and the better they transferred that knowledge to new problems. Engagement is the key variable. The AI is just one factor in whether engagement happens.
The creative loop that AI disrupts
Mike has a framework for this. It’s a three-stage creative loop that he argues is the core differentiator between human and machine cognition.
- Brainstorm: Generate lots of ideas without censorship. Volume is the goal.
- Refine: Evaluate, narrow, follow promising leads, and backtrack when needed.
- Execute: Build the thing you’ve decided to build.
Every creative domain uses some version of this loop, from musicians to athletes to architects to engineers. The loop is how humans make decisions and build things that are genuinely new.
AI, Mark argues, is great at brainstorming. It’ll generate ideas you’d never have thought of, and you’ll always find gems among them. It’s mediocre at refining. You can design interactive experiences that scaffold the refining process, but it doesn’t happen automatically. It’s reasonably good at execution, which is exactly where we’ve focused almost all our energy and tooling.
The biggest problem, though, is one that doesn’t fit neatly into any of those three stages: AI is terrible at stopping.
“Generate an idea, generate an idea, generate an idea. Okay, let me refine these. And then at the bottom it says, ’You know, it would make this really cool if I added an image.’”
AI always wants to do one more thing. It’s a dopamine-delivery machine with no off switch, and the cognitive load of constantly managing the firehose is real. Harvard researchers are apparently already calling it “AI brain fry.” The call center paradox is a microcosm for the larger situation: we’ve outsourced the easy cognitive work to the machine, and now we’re spending all our time on the hard parts.
The Coach Model
So what’s the alternative? Amundsen’s answer is what he calls AI coaches.
The idea: instead of building AI systems that do work, build AI systems that guide you through doing work. Make system prompts (or “skill files” or however your shop names them) engineered to embody a coaching personality. They should do things like asking questions, surfacing options, making the human choose, pausing at decision points, and crucially, stopping when the task is done.
He demoed a simple example: a coach that walks you through building a small API. It explains its scope upfront. It asks you to confirm you’re ready before proceeding. It presents choices with context (“Most APIs in our system use JSON. Are you okay with text?”). It pauses before moving from refinement to execution. It waits for your explicit go-ahead before generating code. And when it’s done, it says “We’re all done here. Stop.”
The human is always in charge of the pace. The machine doesn’t proceed without confirmation. The decisions are yours.
It sounds almost quaint compared to the “give the AI five monitors and let it loose” approach that’s been trending lately. But Mike’s been building these coaches for nine months, and the principle is backed by the research: high interactivity plus genuine engagement plus the human making real decisions equals actual learning. The result is embodied knowledge, the kind you can carry to the next problem.
Engelbart’s bootstraps and ours
Mike closed by coming back to Engelbart’s bootstrapping vision. Engelbart, it turns out, got into computers because he read As We May Think (Vannevar Bush’s 1945 article) while stationed on a Pacific island during peacetime military service. Remember, this was an article in a twenty-year-old magazine, and it changed the direction of his life!
The chain goes: Bush writes the article → Engelbart reads it decades later → Engelbart invents tools that help humans think better → those tools help us build more tools → and so on, upward.
That’s the version of AI development Mike is asking us to choose. Not the Terminator version. Not the robots-take-over-and-destroy-humans version. Instead, it’s the Licklider/Engelbart version, where technology makes us smarter, preserves the creative loop, and keeps humans in the deciding seat while offloading the drudgery.
He closed with Alan Kay’s line: “The best way to predict the future is to invent it.” And he made sure we heard the warning embedded in it: other people are also inventing futures, and not all of those futures are ones we’d choose.
This was, for my money, a contender for the most substantive talk at Arc of AI. It’s the kind of talk that gives you not just something to think about on the drive home, but something to actually do differently. I’m already reconsidering some of my own AI tooling habits, which is the highest compliment I can pay to a conference keynote.
If you want to dig deeper into the coaching approach Amundsen has been developing, he mentioned he’s working on a book. I’ll link it here when it’s available.
Hello from the Arc of AI conference, happening as I write this from Austin, Texas! I’m currently enjoying a pre-new-job “vacation” in true geek style by attending, speaking at, and playing accordion at an AI conference. Yeah, that tracks.
Yesterday (Tuesday, April 14, 2026), Arc of AI’s ringleader, Venkat Subramaniam, gave one of his “big picture” talks with the insight, warmth, and humor that are his stock in trade. I took notes and pictures, my phone took a recording, I used an LLM to pull it all together, and the end result are these notes from Venkat’s post-lunch keynote, titled Influencing the Irrational AI-Clouded Minds.
Venkat’s session went beyond concerns about code and into the idea of protecting our field from the “breakneck speed” that threatens to break our collective necks. Right now is both the best of times and the worst of times. As tech professionals, we find ourselves on a daily rollercoaster of twists and turns, bouncing between fascination with new capabilities and a very real fear of potential (career? existential?) threats.
Venkat noted that while AI is an incredible tool, it’s currently functioning as the most powerful “vomit engine” ever created. It can puke out more code than you can handle, but that doesn’t mean it’s code you should trust.
It takes time for tech to catch on and fit into our lives
As the saying goes, history doesn’t always repeat itself, but it often rhymes. Venkat reminded us that technology maturity is rarely instantaneous. We often take for granted that the world wasn’t always “plugged in.”
- Electricity: First made available 1878, it was initially very expensive and difficult to generate. It took until the 1940s for the majority of U.S. homes to get electricity, which was a 60-year journey.
- Bicycles: Designs emerged in the 1830s (and wow, were they ridiculous and downright dangerous), but they didn’t become commonplace until the 1890s. 60 years again.
- Cars: Emerged in the late 1800s, and took until the 1930s for 60% of U.S. households to own one. 60-ish years.
- Flight: I was in the “keener row” (Canadian slang for the front row of a classroom) at the keynote, and Venkat knows where I live, so he called on me and asked if I knew where and when the first commercial flight took place. I didn’t know.It turns out that it happened in 1914, cost $400 ($13,000 in today’s money), and was a 22-minute jaunt from Tampa to St. Pete. It would take until 1972 for 50% of Americans to have flow
There is something both magical and sobering about that 60-year window. Every technology starts out shaky, costly, and unsafe. AI is no different.
Redefining AI: It’s Not Intelligence
One of the most grounding points of the keynote was the definition of AI itself. This is something that Venkat brought up at his talk in Tampa back in December.
We admire “intelligence” as original thinking and innovation. What AI does often looks more like what we call “plagiarism” in school:
“I call AI as Accelerated Inference, because that’s what AI really does. AI is an inference engine, not a machine [of intelligence].”
AI analyzes patterns based on available data. If the data’s garbage, the inference is garbage. And let’s be honest: we’ve trained AI on the code we’ve been writing for decades (and hey, it’s not all good). We’re effectively feeding it garbage and being surprised when it shows us what it’s got.
Where AI shines, and where it ends up where the sun don’t shine
Venkat shared a powerful anecdote about an expert C++ developer struggling to write automated tests for an enormously complex library. He suggested handing the tass over to AI. The developer, after some coaxing, did that, and the AI generated a suite of tests with extensive mocking.
But the initial result didn’t even compile. Venkat began to think that his suggestion was a mistake…until the developer took a closer look at the test code.
Upon closer inspection, the developer noted that while the tests didn’t work, they were close to working. He said that he could get them up and running in two hours. It turned out that it took even less time than his original estimate.
The developer came to the realization that what the AI did in seconds would have taken him three months of full-time effort to figure out. AI got the developer 70% of the way there, but it required a developer with enough expertise to do the remaining 30%.
AI strengths vs. weaknesses
I need to take a moment to thank Gemini for turning my hastily-typed notes into the table below, which summarizes AI’s strengths and weaknesses, as enumerated by Venkat at his talk:
| AI is Great At… | AI is Terrible At… |
|
Handling Cognitive Load: It doesn’t have a “mind” to get overwhelmed by complex, intertwined code. |
Reliability: It cannot yet create reliable code or documentation you can release without a human check. |
|
Detecting Issues: It can snap-analyze a design and find bugs or architectural flaws like a missing game loop. |
Contextual Truth: It can be “unbelievably smart” while being factually wrong, as seen in the Lua |
|
Generating Ideas: It is a powerful tool for ideation where correctness isn’t the primary burden. |
Correctness: It might give itself a 9/10 for correctness while admitting its quality is poor due to “mutating sin”. |
He also presented this slide:
The items listed:
- Generate ideas (thumbs up)
- Detect issues (thumbs up)
- Analyze design (thumbs up)
- Explain complex code (thumbs up)
- Vomit code (thumbs up)
- Create tests (maybe)
- Create reliable code (thumbs down)
- Provide reliable documentation (thumbs down)
- Be an authentic learning tool (thumbs down)
- Test your patience (double thumbs up)
The “Vasa” lesson: You can disagree with physics, but it bites back
To illustrate the danger of “irrational AI-clouded minds” in management trying to mis-apply AI, Venkat pointed to the Vasa, a Swedish warship built in the 1600s. The King of Sweden, powerful and arrogant, demanded a massive, overly-ornate ship. The king understood the power of bling, but not trivialities such as “seaworthiness” and “center of gravity”.
The shipwright didn’t have the courage (but an excellent sense of self-preservation) to tell the King he was wrong. The outcome was predictable: the ship sailed only 1,600 yards before sinking, where it stayed for 300 years until it was raised, restored, and now resides in a museum in Stockholm as an (admittedly beautiful) object lesson.
In 2026, we have “Kings of Sweden” at our workplaces, and they want AI solutions at any cost for the same ornamental reasons as the Vasa. But while you might disagree with the “physics” of software development, they’re often as hard to fight as real-world physics. If the cost of failure is high (loss of data/money/life) you can’t blindly jump in and build an AI Vasa.
Programming is thinking, not typing
Venkat pointed us to Wikipedia’s list of obsolete occupations. Will “programmer” end up on this list of over 100 obsolete jobs, like the town crier or the leech collector?. He argues the opposite:
- Our job isn’t about typing characters; that is the least enjoyable part.
- We’re thinkers, not typists. We write applications in our heads, not on the keyboard. The keyboard’s just a user interface.
- Compilers didn’t kill development; they accelerated it. AI will do the same.
The real threat cognitive decline. The level of abstraction takes us far from the code that we spent time developing hard-earned critical thinking skills. If we lose the ability to think critically because we are delegating our thinking to machines, we are in trouble. As Venkat put it, the “illiterate” of the future are those who cannot think critically.
New rules of engagement
So, how do we handle the “Black Swan” event of AI?. Venkat suggests we look to the rules recently laid down by Linus Torvalds for the Linux kernel:
- No AI Sign-offs: AI agents cannot add “sign-off by” tags.
- Mandatory Attribution: It must be clear if code was assisted by AI.
- Full Human Liability: The human submitter bears 100% responsibility for bugs, security flaws, and license compliance.
“Don’t trust and verify the heck out of it” is the new norm.
A framework for success
To remain relevant and responsible, Venkat outlined a five-step process for working with AI:
-
Understand the Problem: Don’t jump to AI immediately. Take the time to grasp the requirements.
-
Ideate: Spend time thinking about possible solutions and their consequences.
-
Activate AI: Only after ideation should you engage the tool.
-
Iterate: Work through the solutions provided.
-
Evaluate Critically: Verify everything before it goes anywhere near production.
We can’t go faster with ignorance. We need competency to gain speed and protect our reputations. AI is a powerful tool, but in the hands of a fool, it’s a dangerous one.
Let’s stop the fear-mongering. There is real work to be done, and it requires our minds more than ever.