Panels themselves are useful. The way we keep running them often is not.

They get sold as discussion, insight, community wisdom, and multiple viewpoints. Then you sit there for forty five minutes and get a reputation display with microphones. Everyone looks serious, everyone says familiar things, one or two mildly spicy lines get remembered, and the audience goes home with very little they can use once the conference badge comes off.

That is the part that bothers me.

This is not meant to be a rant about why panels are bad. I am writing this because good panels are genuinely useful and security conferences do not get enough of them. I also want this to be something organizers can send to moderators and panelists before the session, so expectations are set properly before everybody lands on stage and hopes the format will somehow rescue weak preparation.

It is also not me standing outside the mess and handing out wisdom to others. Think of it more as a cheat sheet built over years of being a panelist, moderator, and at times helping shape the session itself. Some of it comes from panels that went well. Some of it comes from sessions that were average, messy, or a complete waste of everybody’s time. That mix is exactly why I trust these points more than neat theory.

A panel does not exist to put multiple important people on one stage.
It exists to help the audience understand a topic better.

That is the standard.

If the audience leaves with a clearer way to think, a better decision process, a sharper question to ask at work, or even one tradeoff they had not considered before, the panel did its job.

If the audience leaves with nothing more than “that sounded important,” then it did not.

There is also a distinction I wish more conferences took seriously.

A panel can create spectacle. A panel can create understanding. Sometimes those overlap, though they are not the same outcome. Gossip-worthy and learning-worthy are very different things.

I am not against disagreement. Good disagreement is one of the main reasons panels work at all. It brings out detail, tradeoffs, incentives, and thought process. Manufactured heat gives you clips and corridor gossip and very little else.

The goal is not to script harmony. The goal is to avoid avoidable stupidity.

What a panel owes the audience

A panel owes the audience more than opinion.

This sounds obvious, though many conference panels are built as if the audience paid to watch senior people freestyle in public.

People come to a panel because they expect the format to do something a solo talk cannot do as well. They want contrast. They want multiple lived realities in one place. They want to understand why a pentester, a CISO, a founder, an engineer, and a regulator can all look at the same problem and still not land in the same place.

A good panel should give them at least one of these:

• a framework they can reuse
• a process they can steal
• a tradeoff they had not seen properly before
• a better vocabulary for the problem
• a mistake they can avoid without having to suffer for it personally

If none of that happened, then maybe the panel was energetic, maybe it was fashionable, maybe the photos looked good, though it was not useful.

Organizers

Panels usually fail before they start, and a lot of that sits with organizers.

Organizers decide whether the topic even deserves a panel. They decide who gets invited, who moderates, what the expected direction is, and whether the whole thing still has enough substance left after everyone adds their boundaries and restrictions.

A lot of conference pain starts the same way. The conference has a broad topic, a few known names, one empty slot in the schedule, and somebody says, “let’s make it a panel.” That is how you end up with five people on stage who broadly agree, speak in safe abstractions, and walk away thinking it went fine.

It probably did go fine. Fine is not the standard. Useful is the standard.

Before inviting panelists

• Decide whether the topic truly suits a panel. Some topics need multiple viewpoints. Some need one good speaker. Some need a debate. Some need a workshop.
• Define what the audience should leave with. A short alignment call about a week before the session helps everyone lock on to the intended takeaway and cuts down the usual drift.
• Identify what kinds of perspectives are actually needed. Role matters. Incentive matters. Lived experience matters. Job title alone is weak material.

Before finalizing the panel

• Choose for viewpoint range, not just fame, seniority, or recognisable names.
• Pick the right panelists. A panel full of interchangeable bios gives repeated answers with different company logos.
• Pick a moderator who is respected by the panelists. This role may need to interrupt, paraphrase, redirect, and occasionally save the session from collapse.
• Identify likely overlap, likely friction, and likely silence. All three matter.
• Avoid a yes-panel. If everyone thinks roughly the same way, the room goes flat very quickly.
• Avoid a manel. By 2026, an all-male panel usually says more about lazy curation than lack of available expertise, and the audience gets a narrower discussion because of it.
• If a panel seat is tied to sponsorship, ensure the person selected is still a practitioner who meets the same utility standard as every other panelist. That serves the audience better and usually reflects better on the sponsor too.
• Collect boundaries early. No company internals, no naming customers, no politics, no legal landmines, no customer support disguised as a question. Fine. Get that out early.
• Assess whether those limitations weaken the panel too much. If most of the useful part of the topic is off limits, then maybe the panel should not happen.

Before the event

• Align moderator and panelists on scope.
• Share the intended audience level.
• Make clear what success looks like for the session.
• Prefer useful disagreement over staged controversy.
• Ensure everyone knows the panel exists to serve the audience, not sponsor optics, ego, or conference vanity.

Organizers are also responsible for something very basic and very overlooked.

Pick someone as moderator who the panelists will actually respect.

A moderator sometimes has to stop someone, cut through rambling, summarise what was said, or push a lazy answer into a useful one. That only works if the room accepts that person has the standing to do it.

Moderators

This is the role people underestimate the most.

A lot of conferences treat moderators like event furniture. Someone who introduces people, reads questions, smiles at the audience, and says “great point” every few minutes.

That is not moderation. Moderation is extraction.

The moderator is responsible for getting signal out of the room.

When I moderate, I usually do a quick background search on the panelists first. I do not mean some deep dossier. I just want to know who is on stage, what they are known for, what incentives they operate under, and how the room is likely to behave.

Are these people complementary? Are they likely to support each other? Are they naturally adversarial? Are they going to politely agree for forty minutes because nobody wants to poke the wrong thing?

A CISO and a pentester are not just different titles. They may be solving for completely different outcomes. An employee and an entrepreneur may sound aligned on the surface while carrying very different biases underneath. That is useful material if the moderator sees it and useless noise if they do not.

Then I prepare guiding questions.

Not a rigid script. Guiding questions.

Their job is to keep the panel on course and help bring out contrast where contrast is useful.

The first question matters a lot more than people think. The answer to it often sets the tone for the rest of the panel. Once the first person answers, everyone else starts tuning their own response based on what has already been said, how safe or sharp the room feels, and whether the discussion is going to reward specifics or generic wisdom.

That is why the first answer can define the whole flow.

I also like making one thing explicit at the start. I am moderating, and I come with two authorities.

First, I will stop you if you ramble. Second, I will ask questions in the spirit of what we discussed earlier even if the exact wording changes on stage.

That is not rudeness. That is hygiene.

What moderators should actually do

Before the panel:

• review panelists, likely perspectives, and likely constraints
• understand where they complement each other and where they may clash
• prepare guiding questions and likely follow ups
• decide what the audience should leave with

At the start:

• state your role clearly
• set expectations on time, rambling, and direction
• make it clear that wording may change while the spirit stays intact

During the panel:

• keep the conversation on course
• turn broad opinions into examples, tradeoffs, or decisions
• stop rambling when needed
• rebalance airtime when one person starts treating the panel like a solo talk
• listen for the real tension in the room and pull it forward
• protect the audience from jargon fog, vague abstractions, and self promotional drift

There is one more thing moderators should do regularly and most do not.

Paraphrase.

Periodically, the moderator should summarise what has just been said so the audience gets the gist of the discussion. Sometimes that is after a long answer. Sometimes after each speaker. Sometimes after the whole question has gone around the room.

This matters because useful points often come out scattered. One panelist gives the constraint, another gives an example, the third gives the tradeoff, and unless somebody ties it together the audience has to do all the assembly work themselves.

A good moderator should be able to say, “What I am hearing is this,” and then hand the room a cleaner version of its own thinking.

That does not just help the audience. It also helps the next speaker respond with more precision.

The moderator is not just a traffic controller. The moderator is the audience’s proxy and sometimes their translator.

Panelists

Panelists have an easier job than moderators in some ways, though they still manage to mess it up quite creatively.

As a panelist, I usually do a bit of recon on the other people on stage. I come in with a clear and fairly well-researched view, though I still look for the connective tissue between what I want to say and what the others on stage bring. Knowing what is there to respect in the other person helps a lot.

It tells me where they have depth. It tells me where I should defer. It tells me where I can bring their expertise into the conversation rather than pretending I need to own every inch of the stage.

That matters.

A specific compliment, a deliberate pointer to another panelist’s strength, or even a simple “this part is more in your lane than mine” can make the whole panel function better. It turns the room into a conversation instead of a line of people waiting for their turn to speak.

Sometimes it is useful to take a slightly opposing stand even when you and the other person are not actually that far apart. I do not mean fake opposition. I mean useful opposition, enough to bring out the detail that would otherwise stay buried under polite agreement.

Sometimes you agree. Sometimes you sharpen. Sometimes you pull the other side into the room because the audience needs to hear the tradeoff more clearly.

That is fine.

Disagreement for theatre is not.

A panelist has a responsibility to the audience to leave them with something useful. A thought process. A decision model. A caution. A lesson learned the hard way. A practical way of seeing the problem.

Being experienced may explain why you got invited. It does not automatically make you useful on stage.

Doing the work and unpacking the work are two different skills. Panels expose that difference in public, and not always gently.

What panelists should do

Before the panel:

• review the moderator, topic, and other panelists
• understand where your view overlaps and where it differs
• declare your boundaries early
• decide what useful value you want to leave with the audience

During the panel:

• listen to what was said before answering
• adjust your response to the room instead of repeating a prepared paragraph
• acknowledge other panelists where their expertise adds value
• disagree when it improves clarity
• avoid disagreement that exists only for performance
• share examples, processes, tradeoffs, and lessons, not just broad principles

For the audience:

• leave them with something they can use
• add insight, not just opinion
• remember that your responsibility is to the room, not just your employer, your personal brand, or your comfort

Respect does not make a panel soft. Usually it makes it sharper.

Two other formats worth using properly

Not every discussion session has to be a standard panel.

Sometimes the conference wants interactivity more than polished viewpoints. Sometimes the topic benefits from open contribution more than curated stage authority. In those cases, two other formats are worth calling out because they often get used casually without enough thought behind them.

AMA, Ask Me Anything

An AMA works when the point is access.

Here, the value is not that the panelists debate each other in a structured way. The value is that the audience gets direct access to people with deep experience and can ask what they actually care about. In that sense, the panelists are there more as subject matter anchors than as a set of people expected to carry a flowing discussion among themselves.

That changes the expectation.

For an AMA, the organizer and moderator should optimize for openness, range of questions, and enough structure that the session does not collapse into chaos or become a customer support desk. The panelists still need to be useful, though the real engine of the session is the audience.

A good AMA needs:

• panelists who are genuinely open to questions
• a moderator who can cluster similar questions and keep the pace moving
• enough boundaries declared early so the audience knows what is fair game
• enough honesty to say “I do not know” when that is the real answer

If an AMA is too tightly controlled, it stops being an AMA. If it is too loose, one person hijacks the room and everyone else pays for it.

Birds of a Feather, BoF

A BoF is even more different.

This is not really a panel in the classic sense. There may be a few practitioners up front, though they are not the only voices that matter. The point of a BoF is that the room itself is part of the discussion. Questions can come from anywhere. Answers can come from anywhere. The person on stage is not always the person with the best answer, and that is perfectly fine.

In a BoF, the moderator carries a different kind of burden. They are not just steering a set of panelists. They are holding the room together. They need to cut people down when they ramble, keep the discussion moving, bring quieter voices in when needed, and make sure one loud participant does not turn the session into a hostage situation.

A good BoF accepts that expertise is distributed across the room.

That is also why the physical setup matters. A raised stage sends the wrong signal. BoFs usually work better in smaller rooms, with everyone at roughly the same sitting level and without a theatrical separation between “the experts” and “the audience.” The format works best when the room feels like collective discussion, not a downgraded panel with extra interruptions.

A good BoF needs:

• a smaller room where discussion feels manageable
• seating that signals equality, not hierarchy
• a moderator who is comfortable controlling flow without controlling content
• participants willing to contribute constructively rather than perform expertise
• enough shared respect that disagreement does not become noise

BoFs can be excellent when the topic benefits from community experience rather than fixed stage authority. They can also become messy very quickly if the moderator is weak or the room is too big.

The reason I want to mention both AMA and BoF here is simple. Some conferences force everything into the panel format because it is familiar. That is a mistake. Sometimes what you actually want is audience access. Sometimes what you actually want is community discussion. Picking the right format is half the work.

When a panel should probably not happen

Not every topic deserves a panel just because the conference website has spare space.

Sometimes the best thing an organizer can do is admit the format is wrong.

A panel probably should not happen when:

• the topic is better explained by one strong speaker
• the panelists are too constrained to say anything meaningful
• everyone on stage broadly agrees and brings little variation in viewpoint
• the moderator lacks enough subject fluency to steer the room
• the only real purpose is to showcase names, sponsors, or optics
• the topic is so broad that forty five minutes can only produce slogans

Choosing the wrong format is forgivable. Pretending the audience got value anyway is where the nonsense starts.

The minimum standard

A good panel does not need fake fireworks. It does not need forced confrontation. It does not need someone trying to manufacture a viral clip from a conference chair.

It needs an organizer who has thought about why the panel should exist. It needs a moderator willing to maintain direction and extract clarity. It needs panelists who understand that stage time is a responsibility, not a medal.

If those three things are present, a panel can be one of the most useful sessions at a conference.

If they are not, then what you usually get is a live reminder that many people can hold a microphone without actually holding a thought.

I say all this with some affection for the format and enough self-awareness to admit I have probably been part of a few average panels too. That is partly why I care. Panels are not hard because the format is cursed. They are hard because they require preparation, articulation, listening, restraint, and just enough ego control from multiple people at the same time.

That, apparently, is a very premium ask in our industry.

Still, when they work, they are worth it.

And when they do not, at least the conference photographer gets a nice collection of serious faces for next year’s brochure.

Credit where due, Avkash Kathiriya helped sharpen parts of this piece. The views are mine, though their input improved the framing in a few places.

Quick reference checklist

For organizers

Before inviting panelists:

• decide whether the topic truly suits a panel
• define what the audience should leave with
• identify what kinds of perspectives are actually needed

Before finalizing the panel:

• choose for viewpoint range, not just title or fame
• pick a moderator respected enough to interrupt and steer
• identify likely overlap, friction, and silence
• avoid a yes-panel
• avoid a manel
• do not hand out panel seats as sponsor rewards
• collect boundaries and limitations early
• assess whether those limitations weaken the panel too much

Before the event:

• align moderator and panelists on scope
• share the intended direction and audience level
• make clear what success looks like for the session
• prefer useful disagreement over staged controversy

For moderators

Before the panel:

• review panelists and their likely constraints
• understand where they complement or conflict
• prepare guiding questions and likely follow ups
• decide what the audience should leave with

At the start:

• state your role clearly
• set expectations on time, rambling, and direction
• establish that you may rephrase questions to keep the discussion useful

During the panel:

• track who is dominating, who is underused, and where the real tension lies
• summarise when answers become long or unclear
• paraphrase periodically so the audience gets the gist
• turn broad opinions into specific tradeoffs or examples
• keep the discussion aligned to audience value, not stage comfort

For panelists

Before the panel:

• review the topic, moderator, and other panelists
• understand where your perspective overlaps or differs
• declare any boundaries early
• decide what useful value you want to leave with the audience

During the panel:

• listen to what was said before answering
• adjust your answer to the room instead of repeating prepared lines
• acknowledge other panelists where their expertise adds value
• disagree when it improves clarity
• avoid disagreement that exists only for performance
• share examples, processes, tradeoffs, and lessons

For the audience:

• leave them with something they can use
• add insight, not just opinion
• remember that the room matters more than your stage image

What has become clearer to me over time is that the question of whether AI is useful has been declared settled. Not because everyone arrived at the same conclusion, but because enough capital has been deployed that the direction is being pushed across the industry. Mandatory bundling is becoming the norm, and opting out is slowly turning into the harder choice. As I have said time and again, AI systems are nondeterministic systems so now the more useful question is what kind of work should stay fuzzy, what kind of work should harden into structure, and what this shift is going to do to the people building and operating these systems.

The Engineer

For a long time, software hired as if every layer of work needed a full engineer. In most traditional industries, that is not how labor is distributed. You have a smaller number of people who design, reason, and make trade-offs. Then you have a much larger base doing repeatable execution, assembly, operation, inspection, and support.

In computing, we ended up stuffing an unusually large range of work under the word engineer.

Some of that was real complexity.
Some of that was title inflation.
Some of that was the simple fact that software kept printing money for long enough that we could afford to be imprecise.

With AI, a lot of the work now being squeezed is not the part that requires deep engineering judgment. It is the repeatable production layer. The layer that can take instructions, generate drafts, translate between formats, fill gaps, produce boilerplate, and keep the machine moving. It is fluid enough to appear fuzzy, yet patterned enough to be reproduced by a stochastic parrot.

That does not mean engineering disappears. The people who understand constraints, trade-offs, system boundaries, failure modes, long-term ownership, and more importantly what should be automated versus what should remain under direct control become even more important.

The worker-grade layer gets compressed. The actual engineer becomes more visible. That is uncomfortable for an industry that has spent years pretending those two things were always the same.

AI can replace a lot of motion. It does not replace the person who knows which motion matters.

To be clear, I do not mean this as a sneer at execution work. Every industry needs execution. Every functioning system rests on it. My point is about structure. We hired as though the entire software pipeline needed expensive generalists at every step. AI is now exposing how much of that pipeline was repetitive production work wrapped in engineer-shaped titles.

That may be good for efficiency.
It may be terrible for ego.
Those two outcomes often travel together.

LLMs Should Help Design Their Own Exit

This also changes how I think about LLM-native systems.

If you take theory of constraints seriously, LLMs themselves are often a major constraint. They are expensive, externally controlled, non-deterministic, rate-limited, policy-bound, and subject to changes in price, performance, and availability that you do not control. That leaves them as obvious bottlenecks.

Which means a well-designed LLM-based system should not aim to make itself permanently dependent on LLMs.

It should aim to reduce that dependency over time.

Use the model to explore. Use the model to classify messy inputs. Use the model to suggest structure where structure does not yet exist. But once the workflow stabilizes, the system should start extracting patterns, encoding logic, narrowing prompts, introducing deterministic checks, and shrinking the amount of fresh reasoning it needs on every pass.

In other words, a good LLM system should help design its own partial exit.

That sounds less glamorous than endless agent loops and autonomous everything. It also sounds more like engineering.

The goal should not be to keep the LLM at the center forever just because it can be. The goal should be to keep it only where uncertainty genuinely remains.

If an LLM sits forever at the center of a stable workflow, either the workflow is not stable, or we have been lazy about encoding what we learned.

Now, I should concede the obvious counterpoint. Some domains stay fuzzy for a long time. Research, discovery, language-heavy interfaces, messy support contexts, broad synthesis tasks, exploratory analysis over ugly inputs, these may keep benefiting from a probabilistic layer at their core. That is fine. The world contains genuinely messy problems.

The mistake is assuming all problems deserve to stay messy just because the model makes messy look productive.

There is also a strange shift happening in how we treat reproducibility. In most parts of engineering, reproducibility was the goal. We built shared libraries, open source modules, and common abstractions so that once something worked, it could be relied on and reused without rethinking it every time.

With LLMs, we are drifting toward accepting non-reproducibility as a feature. Outputs vary. Behavior shifts. Prompts evolve. We sometimes even celebrate this variability as creativity, as if unpredictability is inherently valuable in places where consistency used to matter.

That is a step back for large parts of engineering.

Reproducibility is what allowed systems to scale. It is what allowed teams to collaborate without constantly second-guessing outcomes. Moving away from that without a clear boundary risks turning engineering problems into artistic ones, where results are appreciated but not guaranteed.

There are places where that is fine. Exploration, ideation, early drafts. But once something works, the expectation should still be the same as before. Capture it. Stabilize it. Make it repeatable.

Otherwise, we are reintroducing uncertainty into places where we had already learned how to remove it.

Artificial Scarcity, Real Capacity

Another thing I find odd in these conversations is how quickly people slip into zero-sum thinking.

As if reducing LLM usage in one workflow somehow means betraying the future.
As if every token not spent is a missed opportunity.
As if the only way to justify AI is to trap ourselves into permanent dependence on it.

Part of this mindset has been deliberately shaped by the LLM kingpins themselves. They do not just cap usage. They cap it by hour, by window, by quota, by visible counters that keep reminding you what you have consumed and what remains. In the name of capacity management, they create a kind of artificial scarcity that trains users into a very specific reflex: if I do not use this now, I am wasting it. The meter itself becomes part of the product psychology.

That is a clever business move. It also nudges people toward unhealthy ways of thinking about systems.

If I can phase out LLM dependency from one system faster, I do not become anti-AI. I become free to build more systems.

More importantly, I become free to push that capacity toward problems outside our own little software bubble. IT is, at its core, a support industry. The work we do is supposed to help the rest of the world function better, not just help us build more elaborate mirrors of ourselves. The real world outside tech is still messy, slow, understaffed, overloaded, and full of systems that could genuinely benefit from better tooling. If we stop obsessing over petty quotas and platform counters, the capabilities we have now could speed up work in many of those places. IT does not stand alone. It depends on electricity, logistics, manufacturing, governance, and a hundred other systems that existed before it and can still function without it, however slowly. IT multiplies capability. It does not create reality from scratch. That includes AI. Without these systems, work may slow down, but it still continues. We would do well to get off our high horse and remember that the point of better tools is to help other systems move better, not to trap ourselves inside our own fantasy of importance.

Remember, the total usage of LLMs at an organization level may still rise. Very likely, it will. But that does not mean every individual workflow must remain hostage to a model forever. We are not holding hostages here. We are augmenting people, compressing ambiguity, and then hopefully learning enough to reduce the amount of ambiguity that needs to be paid for next time.

What follows is a better distribution of capability.

This is why I do not buy the doom framing that every bit of deterministic replacement somehow kills value. When a workflow matures past the need for heavy inference, graduating it into a more stable form is a sign of success.

If we save model usage here, we can spend it there.
If we encode knowledge here, we can explore more over there.
If we stop renting repeated thought in one part of the system, we can afford more first-draft thinking elsewhere.

That is how healthy capacity expansion works.

Cycles, Control, and Ownership

This also keeps bringing me back to cycles of computing. We keep oscillating between convenience and control, centralization and local capability, managed comfort and self-inflicted responsibility. LLM APIs sit very firmly on the convenience side of that cycle. They are useful. They are impressive. They are also expensive, externally governed, behaviorally fluid, and very much subject to someone else’s roadmap, policy, or sudden urge to rename the model family again.

Building around such a layer is fine when you understand the bargain.

Building your core around it while pretending the bargain does not exist turns into a form of emotional outsourcing.

Now, to be fair, the answer is not to throw LLMs out of the window and go back to chiseling software into rocks. That would satisfy a certain kind of internet purist and create a very boring kind of pain. Some domains really are open-ended enough that keeping an LLM in the loop makes sense. Research assistants, language interfaces, exploratory analysis, summarization over ugly corpora, and translation between human messiness and machine structure can remain probabilistic for a long time because the problem itself remains probabilistic.

So the useful boundary for me is not between AI and no AI.

I think the boundary is closer to this: where does ambiguity genuinely remain, and where have we simply been too lazy, too rushed, or too enchanted by convenience to encode what we already know?

That distinction matters.

Because the moment you blur it, every problem starts looking like a prompt problem.

This is also why learning to code matters more in the age of AI. Programming was never just about typing syntax into a machine. It was about learning how systems behave, where assumptions hide, how edge cases creep in, what should be abstracted, what should remain explicit, and what must remain under direct human control. If you do not understand those things, then AI becomes a magic trick. A very useful magic trick sometimes, but still one that leaves you unable to tell the difference between generated motion and actual control.

That is also where vibe coding fits for me. It is real. It is useful. It is fun. It can get you surprisingly far surprisingly quickly. I have used it myself. I would be lying if I claimed some monk-like purity here. But it works best as an entry point, not as governance. It is a way to discover the shape of a thing. Ownership still has to follow.

Vibes are great for finding a path. They are terrible as a maintenance strategy.

There is another layer to this that I find harder to ignore now. LLMs are also useful mirrors. Pattern matching, approximation, confidence with patchy grounding, convincing reconstruction in place of certainty. A lot of human thinking looks less pristine under that light. I explored that more personally in What LLMs Teach Me About My Own Brain. Engineering, then, is deeper than simply thinking hard. It is building the scaffolding that compensates for how unreliable thinking can be when left floating on its own.

Maybe that is why this whole wave has felt both exciting and vaguely personal.

The machine guesses. We guess. Good engineering knows when to stop guessing.

Where I Land Right Now

So where does that leave me?

Probably somewhere less fashionable than the current extremes. I do not buy the fantasy that AI will make understanding obsolete. I also have little patience for the opposite fantasy where every worthwhile thing must remain hand-crafted by grumpy purists defending Makefiles with ancestral passion.

I think LLMs are best treated as a phase in many workflows.

Use them to explore.
Use them to compress uncertainty.
Use them to help you get from blank page to first structure.

Then extract the pattern.
Encode the logic.
Constrain the behavior.
Move what you can into deterministic systems.
Keep the fuzzy layer where the world is actually fuzzy.

That approach gives you something more valuable than speed alone. It gives you a path from assistance to ownership. And ownership, inconvenient as it can be, is still where engineering earns its keep.

The more useful question for me now is different. How much of our system should remain guesswork once we know better?

That is the question I want to keep asking. Of products. Of teams. Of my own habits. Of every workflow that starts with wonder and quietly hardens into dependency.

If we get this part right, AI becomes one more way to reach structure faster and reduce dependence with intent. And if we get it wrong, we will keep renting the same thinking over and over, calling it progress because the response time was good. Which, to be fair, is a very modern way to make an old mistake.

Somehow, that simple clause of “no obligation” became invisible in practice. We built a culture that holds unpaid volunteers to the same standards as billion dollar corporations. If a small library misbehaves, the question is rarely “why didn’t the company test this?” It becomes “why didn’t the maintainer fix it yet?”

Every vulnerability becomes a headline, every maintainer becomes a villain, and every apology is demanded in triplicate.

The Misuse of Accountability

Even when multi billion dollar corporations rely on volunteer built tools, they often behave as if maintainers owe them service level agreements. When a flaw shows up, too many organizations treat disclosure like a hot potato. They drop it back with a deadline and call it responsibility.

Disclosure norms were built to pressure corporations that had budgets, release teams, and legal cover. In many cases, they did work. But the same process, applied to individuals, creates a strange distortion. Volunteers do not have a QA department. They do not have a security team. They do not have a manager who can reshuffle priorities because a PR crisis is brewing.

Finding a bug and forcing a deadline without offering help is not responsibility. It is arrogance dressed up as process.

If you benefit, contribute. Money helps, but so do patches, testing, triage, and plain empathy.

This is also why I like Dan Lorenc’s thread. It adds nuance. It is not always a pure “funding problem.” Sometimes money exists, but it does not flow to the right place, or it arrives with strings attached.

The Myth of Free Labor

We repeat “open source is free” so often that we forget what “free” actually means. Free to use is not the same as free of responsibility for how you use it. No one forces you to adopt someone’s code. There is no sales pitch, no NDA, no onboarding call where you get a false sense of safety.

You chose it.

If it breaks, you are still responsible for your own house.

And because humans love easy targets, we aim at the maintainer. It is simpler than admitting that an entire corporate ecosystem depends on unvetted, unpaid work.

Somehow, “thank you for sharing” quietly became “you owe us uptime.”

A great example of this tension shows up in Salvatore Sanfilippo’s reflection, the creator of Redis. He stepped away from his company when his role became more about business than technology. His story captures an essential truth: not every developer wants to scale, monetize, or manage teams. Some want to build, learn, and share. That motivation gets flattened when we treat every open source repo as a pipeline to profit.

The Many Faces of Open Source

Open source is not a single identity. It is a crowded room of very different people wearing the same label.

1. The Job Seeker: writes to demonstrate competence and land opportunities.
2. The Builder: shares for joy, curiosity, and the urge to tinker.
3. The Business: balances openness with sustainability and a clear support model.
4. The Idealist: believes software should belong to everyone.
5. The “I do not care” Hacker: publishes code because sharing is easier than maintaining it privately.

And yet, the world lumps them together. When something breaks, nobody pauses to ask which one wrote the code. The job seeker did not sign up for audits. The hobbyist did not promise support. The idealist did not agree to SLAs. The hacker did not intend to scale.

But liability finds everyone equally.

The Cost of Uniform Expectations

This flattening is why many developers quietly stop sharing.

The corporate user wants stability.
The individual creator wants freedom.
The regulator wants control.
The community wants trust.

Trying to satisfy them all with one set of expectations guarantees that no one wins.

Look at the Google Play ecosystem.

In its early days, it was a wild bazaar where anyone could upload an app. It was chaotic, but it was also full of creativity.

Now, in the name of safety, even developers who do not distribute through the Play Store can be pushed into verification requirements just to exist in the same ecosystem. The same company that once welcomed every developer is now too busy managing its own scale.

I am not arguing against safety. I am arguing that control grows faster than empathy. Once systems scale, they tend to protect themselves first.

The Corporate Blind Spot

Take FFmpeg, the backbone of modern multimedia.

When vulnerabilities appear, organizations that depend on it often expect volunteers to fix them, on a schedule the volunteers did not agree to. The organization did not write the code. They discovered a flaw. But instead of contributing patches or funding maintenance in a direct and sustained way, they set timelines and demand compliance.

To be fair, some large companies do fund open source security work. Google, for example, runs a Patch Rewards Program and an Open Source Security Rewards initiative. Those are real efforts, and they help.

But they also highlight the uncomfortable pattern. We have normalized a world where finding flaws is organized, incentivized, and celebrated, while fixing and maintaining is treated as optional charity.

If the intent is truly to strengthen open source, another approach is direct ownership of the problem. Fork critical components, patch them, maintain them, and upstream what you can. Large organizations already do this when it matters enough, like Blink (a WebKit fork) and BoringSSL (an OpenSSL fork).

Money alone is not the solution. Ownership and effort are.

I argued something adjacent to this a decade ago in The Glorification of Pentesters.

Back then, the industry celebrated the people who broke things while ignoring the ones who built them.

Today, the pendulum swings even further. We glorify the breakers, then we burden the builders with the aftermath. It feels like a loop we never escaped.

Dead on Arrival, by Design

A friend once told me:

Treat open source as dead on arrival.

Write it. Release it. Move on.

If people use it, good for them. If they do not, good for you.

The moment you start worrying about its afterlife, you lose your freedom.

That cynical wisdom makes more sense every year. We conditioned ourselves to believe open source should pay. Maybe it can, but only for those who want that path. Not everyone wants to run a company around their repo.

Some people want to share and disappear.

Choice, Not Compliance

Maybe the answer is to formalize that choice.

If you want enterprise adoption and enterprise money, then choose the enterprise path. Publish SBOMs. Ship reproducible releases. Run updates like a product. Put support behind a paid model.

If you do not want that, choose the free path. No guarantees, no obligations, just pure sharing.

Let corporations pay for the privilege of expecting things.

And let’s be honest, donations are not only money. They can be money, code, time, documentation, testing, triage, and community management. If you have contributed none of these, you do not get to demand anything.

You can use the software, sure. You just do not get to act entitled.

Even if you have contributed, your expectations should still be lower than what you would demand from a paid vendor. Open source is generosity, not service.

The irony is that by piling expectations on maintainers, we made them the weak link in the system.

Attackers do not need to go after fortified corporations anymore. They go after the unpaid volunteer whose code runs inside those corporations. By placing so much responsibility in the hands of individuals with no safety net, we turned open source developers into attack surfaces.

Not because they did something wrong, but because everyone else offloaded risk onto them and called it collaboration.

If we truly care about security, we should start by protecting the people who make the tools we depend on, not punishing them for being human.

This tension is not new. The OpenSSF statement on sustainable stewardship calls it out clearly: open infrastructure is not free, and pretending it is only worsens fragility. The Software Maxims piece, “Not a Supplier”, makes the same argument from another angle: open source authors are not vendors, and treating them as such is both wrong and short sighted.

Together, they point to one reality. The current system rewards intermediaries more reliably than it rewards creators.

The Paradox of Reach

Of course, freedom comes with a price.

Software that rejects support and commercial polish rarely gets adopted widely. Corporations avoid GPL like licenses because they demand reciprocity. Reach often comes from compromise.

You either give up some freedom for visibility, or you give up reach for peace.

Neither choice is wrong. The problem is pretending they are the same.

That famous XKCD comic #2347 about a single unpaid maintainer holding up the modern world stopped being funny years ago. It is now documentation.

Maybe This Is the Balance

So perhaps the path forward is not “fixing open source.” It is accepting its duality.

Open source is both chaos and order.
Generosity and exhaustion.
Freedom and frustration.

Maybe the only sustainable model is honesty. Developers declare what they can give, users respect those limits, and organizations stop outsourcing morality to volunteer time.

Freedom does not mean free of consequence.
It means knowing which consequences you accept.

Practical notes

If you build open source for fun: Ship what you can, say “no” early, and write your boundaries down. Your repo is not a contract.

If you build open source to make money: Treat it like a product. Offer clear paid support, clear release practices, and clear expectations, then let the free tier remain genuinely free.

If you are an organization: Assume responsibility by default. Fund the maintainers, contribute code and testing, or maintain your own fork. Do not outsource operational risk to unpaid goodwill.

We were a small firm. For a long time we had been asking our SaaS vendor for one small feature. Not a roadmap revolution, just one capability that would make daily work less annoying.

We were not a flagship customer. We were not the account that makes a salesperson show up with a deck and free cookies. So the feature kept landing in the same place, the polite back burner.

Then renewal season came close enough that it started showing up in meetings.

At some point we said, before the annual renewal hits, let us try something. A weekend, Cursor, and a couple of LLM chats later, we had the feature we needed and the narrow workflow we actually used. Good enough to replace a license.

I have heard variations of this from other people too. Different tools, different vendors, same pattern. A small slice built internally, not because someone wanted to start a rebellion, but because the economics suddenly made sense.

The counterpoint is always the same.

Vendors are specialists. They can do it better.

They often can. At least, they can build a broader, more polished product for a wider audience.

But that is not the only question.

The question is whether you need the broader product, or whether you need a reliable path through a small part of it.

This is where the internet conversation gets messy. Social media is a terrible place for nuance, and LinkedIn is where nuance goes to die a slow death in front of a ring light.

My blog is my own space, so I can say this the way I want to. This is my take. It might be flawed, but it is mine.

The part everyone argues about, and the part that matters

When people claim they “cloned” a product, they often mean very different things:

1. A UI lookalike
2. A workflow replica that solves one internal problem
3. A full replacement with all the guarantees

Most of the interesting stories today are category two, even when the posts pretend they are category three.

And category two is enough to create pressure.

Most “AI clones” are not trying to replace the product.
They are trying to replace one workflow inside the product.

That is the part worth debating.

Cloning itself is not new. Students have been building clones forever as a way to learn. What is new is the speed. A narrow workflow used to be weeks of work. Now it can be a weekend decision.

Suites lose to slices

Most organizations do not use the full suite they pay for.

They use a portion. A path. A handful of screens. A set of actions that happen every day.

The rest is “nice to have,” or “maybe we will use it later,” or “it came in the package so we pretend it is strategic.”

So when workflow replication becomes cheap, the default conversation changes.

Before, it was “do we buy this product or not.”

Now it becomes “which parts are worth buying, and which parts are cheaper to build ourselves.”

That shift is brutal for business models that depend on bundling.

Vendors sell the bundle.
Internal teams fund the slice.

The ownership tax scales with scope

Yes, if you build internal tools, you own them.

Documentation, stewardship, support rotation, updates, and the occasional “why is this on fire” moment.

But the ownership tax scales with what you build.

A vendor has to maintain the full suite. You do not.

If you replicate a narrow workflow, you are not signing up to maintain 100 percent of the product. You are maintaining the slice you actually use.

This matters because the vendor’s codebase is not “feature logic plus some glue.” A lot of it exists to support the vendor’s business model and the vendor’s constraints:

• Multi tenant isolation
• Generic access control for every possible org shape
• Audit trails and reporting for every compliance checkbox
• Backwards compatibility for old customers
• Integration marketplaces
• Onboarding, training, and support processes
• Billing, entitlements, packaging logic
• “Works everywhere” engineering

Internal tooling can be brutally honest:

• One tenant by definition
• One identity system
• One environment
• One workflow that actually matters
• The freedom to say “we fix what we hit”

If your internal workflow needs a tracker, you integrate the one tracker. If you only care about Jira, you integrate Jira. If your team only wants one notification path, you build one notification path. we use to call it bespoke development.

The tool does not need to impress 100 customers. It needs to save your team time and money.

I am not rebuilding your product.
I am rebuilding my workflow.

A small extra nuance that rarely gets mentioned.

Sometimes the “edge case” is not a missing feature. Sometimes it is you.

I have had scenarios where vendors did not want to take me in as a customer because my scale was awkward for them. They did not want to bend their system for one weirdly shaped customer.

So yes, edge cases take effort.

Sometimes the market chooses not to handle your edge case at all.

Risk did not disappear, it changed shape

We used to talk about key person risk.

“If the person who built it leaves, we are stuck.”

That is still real, but the modern toolchain adds a new flavor.

Toolchain risk.

If the LLM you rely on changes availability, pricing, or behavior, your build loop becomes unpredictable.

So is SaaS a safe space. A hard No, if your SaaS vendor gets acquired, changes terms, or quietly dies in the VC ecosystem, you face churn at renewal anyway.

One way or the other, you plan for churn.

The practical difference is that internal slices let you keep the critical asset, which is the working system and its artifacts.

• You can treat the LLM as an assistant to produce deterministic output.
• You can pin models when it makes sense.
• You can keep generated code in version control.
• You can rely on tests so the tool assists the build rather than becoming a runtime dependency.

Survival Guide for Vibe Coding

My browser first bias made this obvious

Building client side tools taught me something I did not fully appreciate when I was only consuming enterprise software.

The technical logic is often the smallest part.

The rest is scaffolding required to sell, scale, and survive as a product company.

When you are not selling it, you can remove huge chunks of complexity.

No multi tenant gymnastics. No pricing plans embedded inside permission logic. No onboarding flows for strangers. No marketplace of integrations you do not want.

Software gets suspiciously small when you stop trying to make it a business.

This is not a moral statement. It is just math.

And it is why “AI clones” feel more credible now. They are often not clones. They are workflow extracts.

Hardening and attack surface reduction

I am biased here, and proudly so.

I am a believer in attack surface reduction. reducetheattacksurface.com

Less surface is better. Less surface means fewer moving parts.

Fewer moving parts means fewer updates, fewer dependencies, fewer forgotten admin panels, and fewer “wait, why is that exposed to the internet” surprises.

Yes, someone still needs to keep a check on hardening and updates. The difference is that when your tool is a narrow slice, the check is smaller.

Also, we should stop pretending that buying a vendor means hardening is solved. Vendors do not do a stellar job by default. Some do, many do not.

A logo on a contract is not a security control.

The real moat is not technical

There is one vendor advantage that still matters a lot.

Delegation of responsibility, and more importantly, liability.

At some point, especially in regulated industries, you are not buying features. You are buying contracts, auditability, and the ability to transfer certain categories of risk out of the org.

If the question becomes “who pays when this goes wrong,” you are no longer in the realm of engineering. You are in the realm of insurance.

That is a durable moat, and it is also why I do not believe vendors are dying.

What is changing is the default.

What I hope vendors learn from this

If I were selling a product in this environment, I would worry less about “AI cloned X” as a headline and more about unbundling as a trend. This is also consistent with the natural flip cycles of computing

Customers are going to ask harder questions:

• Which workflows are we actually paying for
• Which workflows can we replicate with acceptable risk
• Why are we paying for integrations we do not use
• Why does “enterprise grade” feel like “enterprise bloat”

The winning vendors will probably be the ones who embrace this reality instead of fighting it.

Modular pricing.

Clean APIs.

Exportability that does not feel like a hostage negotiation.

A product that earns its cost on workflows customers actually value, not on the fear of migration.

Where I personally landed

I do not think AI assisted workflow replication means the end of vendors.

I do think it means vendors will have to justify their bundles in a way they did not have to before.

And I think a lot of organizations will quietly build internal slices, not because they are rebelling, but because they are budgeting.

If you are thoughtful, you can keep scope small, keep the workflow tight, and keep the value obvious.

Cloning is not the revolution.
Scoping is.

Whether you are looking for specific tools, historical talks, or the journey of specific hackers, the new HAI is faster, cleaner, and now machine-readable.

Here is a deep dive into the new features and changes you will find.

1. Visual Overhaul: Big Data, Big Cards

I wanted the impact of the community to be visible at a glance. I have moved away from dense text lists in favor of a card-based UI.

Status Cards: You will now see large status cards that clearly visualize the numbers for each hacker profile. This gives immediate context to the volume of work contributed by an individual.

Tools & Books: The Tools and Books pages have received a significant visual upgrade. Tools are now displayed in detailed cards rather than simple lines, making it easier to scan for “Datasploit” or other specific utilities.

https://hackingarchivesofindia.com

Tools & Books: The Tools and Books pages have received a significant visual upgrade. Tools are now displayed in detailed cards rather than simple lines.

Mobile Optimization: A huge part of this update was ensuring the archives are accessible on the go. I have significantly improved mobile device handling, ensuring that complex data tables and profile cards render perfectly on your phone.

2. The Evolved Hacker Profile

The core of these archives is the people. I have improved the Hacker Profile pages to provide much more granular detail.

Beyond just a list of talks, you can now see:

• Collaborators: Who has this hacker worked with?
• Tools Built: A direct link to software they have authored.
• Focus Areas: What domains (e.g., IoT, Web Sec) do they specialize in?

Additionally, I have improved the “Social Share” aspect. When you share a hacker’s page on social media, it will now fetch the hacker’s profile picture rather than the generic project logo, thanks to updated SEO tags.

https://hackingarchivesofindia.com/hacker/vivek_ramachandran/

Sister Project: Integration with “Hackers of India”

History isn’t just data; it’s also faces and moments. I am proud to announce a cross-linking integration with a sister project, Hackers of India, launched by Shubham.

While Hacking Archives focuses on the technical contributions (talks, tools, books), Hackers of India focuses on the visual history-capturing candid moments and photos from various events.

The Camera Icon: On hacker profiles in the Archive, you will now see a Camera Icon. Clicking this will take you directly to that hacker’s photo gallery on the Hackers of India website. It connects the work with the person.

3. Better Taxonomy: Focused Areas & Tags

With thousands of talks and data points, categorization is key. I have introduced two major changes to help you browse:

1. Focused Areas: I have introduced ~27 “Focused Areas.” These act as high-level collections of tags providing a grouped view (e.g., Penetration Testing, Cloud Security).
2. Hashtags: Almost every talk I have cataloged now has one or more hashtags associated with it, allowing for precise filtering.

https://hackingarchivesofindia.com/focus/

4. AI-Ready: llms.txt and Markdown Support

Recognizing the changing landscape of how we consume data, I have made the site completely friendly to Large Language Models (LLMs) and developers who prefer raw text.

• llms.txt Support: The site now supports the llms.txt standard, making it easier for AI agents to understand the site’s structure and content.
• Universal Markdown: Every single page on the website now has a corresponding index.md file. If you prefer reading or parsing the content in Markdown format, it is now natively available for every entry.

5. Curatorial Decisions: The Panel Shift

As I catalog history, I have to make decisions on what constitutes primary data. Panel Discussions have become a staple at InfoSec conferences. However, they often don’t directly align with the specific indexing aims of this archive (which focuses heavily on technical presentations and tools).

Consequently, I have moved Panels to secondary items. I will still make a best effort to list them, but they will no longer count toward the primary “Home Page Listing” counts. This ensures the core metrics reflect deep technical contributions.

6. Transparency and Roadmap

I believe in building this archive in the open. I have updated the Roadmap to provide clear details on how I operate, what I am building next, and how the community can get involved.

Explore the Update

I invite you to explore the revamped site. Dig into the history of Indian hacking, discover a new tool, or look up a mentor’s journey.

• Homepage: hackingarchivesofindia.com
• Full Timeline: hackingarchivesofindia.com/timeline/
• Books: hackingarchivesofindia.com/book/
• Awards: hackingarchivesofindia.com/award/

Let me know what you think of the new look!

What is it?

If you use Readwise, you already have a ridiculous amount of reading data sitting there. Highlights from books, articles, tweets, podcasts, PDFs, random rabbit holes at 2 AM. Basically a personal library of “things that made me pause and go hmm.”

But Readwise does not really give you a flashy year-end recap. I wanted that.

So I made Readwise Wrapped.

You paste your Readwise token, select a year, and in a minute or two (depending on how big you are with highlights) you get a set of slides that summarize your reading year:

• Your Numbers: total highlights, books/articles/docs, words consumed, streaks
• Reading DNA: what you actually read (books vs articles vs tweets vs podcasts)
• Monthly Activity: which months were productive and which months were… aspirational
• Reading Rhythm: your peak days and favorite times to read
• Virtual Mentors: authors who show up the most in your highlights
• Top Books: your most highlighted reads
• Best Highlight: the one quote that basically screamed “remember me”
• Next Year Forecast: a small prediction of what you will likely read next, based on your late-year trends

If you enable AI insights, it also adds:

• Reading Personality: a fun label for your reading style
• Your Superpower: what your reading habits suggest you are good at
• Recommendations: books you might actually enjoy, not just “top 10 books everyone must read or else”

Privacy first, because of course

Your Readwise token is used only to fetch the data and then discarded. It is not stored.

Only the final wrapped output is saved, and it gets a unique URL you can share.

Sharing and exports

Each wrapped comes with:

• A shareable link
• A PDF download (multi-page report)
• A share card (1200×630) for Twitter/LinkedIn

Yes, I know. We are all addicted to neat rectangles with stats.

How it works

1. Get your Readwise access token: https://readwise.io/access_token
2. Open: https://readwise-wrapped.apps.anantshri.info/
3. Paste token, pick a year
4. Wait a minute or two
5. Swipe through the slides, then share or download

Tech stack for the people who read README files for fun

• Backend: FastAPI (async)
• Frontend: Vanilla HTML/CSS/JS (no framework bloat, no build pipeline therapy)
• AI: OpenRouter (using free-tier models)
• Database: Supabase
• Hosting: Railway

Screenshots gallery

stats

personality

rhythm

monthly stats

forecast

Credits

• Built with FastAPI and hosted on Railway
• AI insights via OpenRouter
• Data from Readwise

This is a community project. Not affiliated with Readwise.

Support

If you find this useful:

• GitHub Sponsors: https://github.com/sponsors/anantshri
• Buy me a coffee: https://buymeacoffee.com/anantshri

Happy reading. Or happy highlighting. Same thing, just with more optimism.

Corporate platforms have turned “wrapped” into a feature and also a business model. I am on the Fediverse for the opposite reason, but I still wanted the fun part.

So I built Fedi Wrap: a local first tool that generates a year in review report for Mastodon compatible Fediverse servers.

I wanted a year in review, not a JSON endurance test.

Repo: https://github.com/anantshri/fedi-wrap

Why I built it

There are already Mastodon wrapped tools, but many assume your instance exposes posts over the API without authentication.

That breaks the moment you move beyond common Mastodon defaults. I use GoToSocial. It is Mastodon compatible, but it leans harder into privacy and security. Many setups require authentication to access timelines and statuses. Unauthenticated “wrapped” tools simply cannot see your posts.

So the problem was simple.

How do you generate a year in review when your instance is doing the right thing and not handing data to anonymous requests?

Fedi Wrap is my answer: fetch with auth, analyze locally, output a single report.

What it does

Fedi Wrap is a bash script that:

• Fetches posts for a chosen year using toot (so auth is handled by the CLI)
• Runs analysis locally using jq
• Generates a self contained HTML report you can archive and open offline

The report includes:

• Total posts, boosts, replies
• Monthly, weekly, hourly patterns
• Longest posting streak
• A simple engagement score
• Top posts by engagement
• Activity calendar
• Fun labels like posting persona and chronotype

Optional local AI insights

If you want it, Fedi Wrap can use a local LLM via Ollama to generate:

• A narrative summary of your year
• Recurring topics
• Vibe and persona style descriptions

AI is optional. Everything runs on your machine.

I like AI more when it does not eat my data.

To keep results grounded, the AI flow is multi pass: analyze chunks first, then synthesize.

The stack

Core:

• bash
• jq
• toot (for fetching)
• curl

Optional:

• ollama

No Node. No containers. No build pipeline. Boring on purpose.

Screenshots

hero section

ai personnas

ai facts

stats

trends

graphs

Get it here

Live Details : https://anantshri.github.io/fedi-wrap

Source Code : https://github.com/anantshri/fedi-wrap/

Underneath the surface, everything is probabilistic. Atoms jiggle, weather patterns evolve, cosmic rays flip bits. Determinism is not a natural state – it is a carefully manufactured illusion. We build redundancy, consensus, and error correction to give ourselves the comfort of order. Determinism is what lets planes fly and bridges stand. It is what makes society function without all of us collapsing into existential dread.

From a philosophical angle, this is not far from what the second law of thermodynamics tells us: entropy, or disorder, always increases. I am using entropy here as a loose frame of reference, not a precise physics definition. If entropy is chaos, then order is the fragile exception we carve out against the tide of nature. Heroes in stories often strive to preserve order, while villains are agents of chaos. Yet if chaos is the natural flow, then the roles blur. Are heroes fighting nature itself? And are disruptors sometimes just accelerating what would happen anyway? (I reflected more on this in a short note here.)

Determinism is not the natural order, it is the illusion we laboriously construct to keep chaos at bay.

Yet non-determinism is not the villain of this story. Without it, we would have no evolution, no creativity, no discovery. Life itself is one giant probabilistic experiment that happened to work out. Music improvisation thrives on it, so does art, and even scientific discovery often stumbles forward through serendipity.

If anything, our struggle is one of balance. Humans crave the stability of the predictable, but history shows that progress often comes from chance, accident, or surprise. Penicillin was discovered because of mold on a plate, not because of a well-planned experiment. The same random noise that drives mutation in biology fuels the diversity of ideas in human culture. Without randomness, we would have safety but no spark. Without order, we would have sparks but no fire to control.

The problem is not non-determinism itself but where we choose to let it in. Randomness in a jazz performance is delightful. Randomness in open-heart surgery is terrifying. Which brings us back to the hammer: once you learn how to swing it, you are tempted to see nails everywhere. But not every problem is a nail, and not every nail needs a non-deterministic hammer.

The question is never “which is better?” It is always “where does it belong?”

When Non-Determinism is Valuable

• Exploration: Optimization algorithms, evolutionary biology, fuzz testing. Randomness helps escape local traps.
• Resilience: Chaos engineering injects failure at random to prepare systems for the unknown. Netflix’s Chaos Monkey is the classic example: it randomly shuts down production servers to force engineers to design for resilience rather than luck.
• Security & Privacy: Nonces, salts, address randomization, and noise injection keep deterministic systems safer.
• Art & Creativity: Procedural worlds, improvisational music, generative art – all thrive on the unexpected.
• Simulation of complex systems: Weather models, financial markets, or epidemiological spread need non-determinism to approximate reality. Monte Carlo methods, which rely on repeated random sampling, are indispensable in finance and risk modeling because determinism alone cannot capture the richness of uncertainty.

Determinism builds trust. Non-determinism builds discovery.

When Non-Determinism is Wasteful

• Critical infrastructure: A ventilator or airplane cannot decide to “experiment” today.
• Auditable systems: Regulators don’t like surprises in your bank account.
• Basic plumbing: A database that returns different answers for the same query is not creative, it’s broken.
• Excessive randomness in design: Adding noise just for the sake of it creates confusion, not resilience.

If all you have is dice, the world looks like a casino.

A Contemporary Example

Large Language Models are just one modern embodiment of non-determinism. The same prompt might yield slightly different answers each time. To someone raised on deterministic software, this feels odd. Computers were supposed to be machines of certainty, not improvisers. Yet here we are, typing the same input and watching the machine offer alternate phrasings, examples, or directions.

This behavior makes sense once you see them as tools for exploration rather than execution. In areas like brainstorming, research, or creative writing, the unpredictability is an advantage. It breaks you out of local traps of thought, much like a randomized search algorithm. It is the system saying, “Here is another path you might not have walked.”

But the danger lies in misplacing this tool. Just because LLMs work well for generating ideas does not make them fit for deterministic tasks. You don’t want your compliance reports to vary from run to run. You don’t want your accounting ledger to “get creative.” The risk isn’t that the machine is bad : it’s that we are applying it in contexts where discovery is not the goal, and predictability is non-negotiable.

Even when tuned for deterministic outputs, an LLM is not suddenly intelligent. It is simply operating with less freedom of movement. The confidence in its answers does not mean correctness – just as our own brains fill gaps with convincing but sometimes false certainty.

Not every configuration file needs creative reinterpretation. Not every compliance report benefits from variation.

In many ways, LLMs remind us of the larger lesson: non-determinism is a hammer worth swinging only when the problem is truly a nail.

Closing Thought

Non-determinism is not chaos, and determinism is not absolute truth. Both are strategies carved out of a probabilistic universe. The art of building systems, and perhaps of living itself, lies in knowing when to enforce certainty and when to allow surprise. Chaos Monkey and Monte Carlo methods show us that randomness, when directed, can be a powerful teacher. But history also reminds us that unchecked randomness in the wrong domain leads to disaster.

Determinism without flexibility becomes stagnation. Non-determinism without boundaries becomes destruction.

The conclusion is simple but worth repeating: non-determinism is neither a hammer to hit every nail nor a poison to be purged. It is a tool. Like all tools, it finds greatness only in context. Our job is to master that context – to decide when the world needs certainty and when it needs the unexpected gift of surprise.

If you’re curious about a more personal angle on this theme, I’ve written separately about how LLM behavior made me reflect on the way my own brain works. That piece is less about systems and more about cognition, but together they reinforce a simple truth: unpredictability isn’t an error – it’s a lens.

What we usually end up with is people running tools that promise to “think like a hacker” or “stop hackers” while nobody is actually stopping to ask what either of those things mean.

Hacker ≠ Adversary

Hackers, in the original sense, are people who twist a system to do something it was never designed to do. The motivation isn’t always money, fame, or chaos. Often, alot of times it’s plain curiosity.

Adversaries, on the other hand, don’t care about curiosity. They have objectives, budgets, timelines, and reporting managers. They’re not bending systems to explore; they’re bending systems to deliver.

“Hackers twist systems to learn. Adversaries twist systems to win.”

It’s like the difference between me wanting to power my servers with solar energy (hacker mindset) and me figuring out how to redirect solar power in an enemy region to cause a blackout (adversary role). Both involve playing with the system, but the intent is miles apart.

Hacker is a Mindset. Adversary is a Role.

This is the core mistake the industry keeps making. Hacker is not a job title, it’s a way of looking at the world. Adversary is a role someone plays to achieve a mission.

A hacker can put on the adversary hat if they want. But not every adversary has the hacker mindset – many just follow playbooks or orders.

“Following orders is the one thing hackers despise. Following orders is the one thing adversaries depend on.”

This is why red teams sometimes disappoint: you can staff them with highly skilled operators who simulate adversaries, but if they don’t carry the hacker mindset, their attacks never stretch beyond the playbook.

A Personal Note

And let me be clear – I wasn’t throwing the “hacker” word around casually for myself either. For the first few years of my life in infosec, I didn’t feel worthy of the moniker. At one point, I won a CTF at Nullcon and got a jersey with “HACKER” printed across the back. You’d think I’d wear it everywhere, right? Nope. It sat in my closet. I hadn’t proven to myself that I deserved the word.

Because here’s the thing:

“Hacker is not a title you give yourself. It’s something the world eventually recognizes you for – sometimes long before you do.”

The Anonymous Problem

Groups like Anonymous or LulzSec were often labeled as “hacker collectives.” But in truth, most of their operations were adversarial campaigns – planned, targeted, disruptive. The hacker branding made for good marketing, but the Guy Fawkes mask was more cosplay than culture. Misguided people joined thinking they were part of hacker culture, yet in reality they were just extra hands running tools while someone else drove the adversarial playbook.

“Anonymous wasn’t hacker culture. It was adversary culture wearing a hacker mask – literally.”

Tolerance and Hijack

Hacker culture prided itself on openness, decentralization, and tolerance. Anyone could join.

The problem with being endlessly tolerant is you eventually get hijacked by the intolerant. With no central figure, decentralized systems are easy to capture by central-ish entities. We’ve seen it happen repeatedly.

But here’s the irony: this failure is also a shield. The loud imposters burn in the spotlight, while the real hackers remain in the shadows, tinkering away quietly.

“The louder the cosplay, the deeper the shadows for real curiosity.”

Bug Bounties, MITRE, and Reality

Here’s another key distinction:

• Hackers love idiosyncrasies. They stumble onto quirks, weird states, and strange system behaviors.
• Adversaries couldn’t care less about quirks. They’ll phish you, bribe you, or smash their way in if needed. They care about outcomes, not elegance.

That’s why frameworks like MITRE ATT&CK make so much sense for defense. They catalog adversary behaviors, not hacker curiosities. Real-world defenders aren’t dealing with someone who’s tinkering for fun; they’re facing someone with a job to get done.

And it’s also why bug bounties aren’t the same as adversary simulation. Bug bounty programs are valuable, but they are intentionally scoped around the hacker mindset of exploration. They encourage curiosity inside controlled boundaries, which is fine for safety and predictability. Adversarial linkages “chaining bugs into campaigns, mixing technical with social pressure, or stepping outside the target application” are out of scope, and for good reason. No one wants to risk a situation where employees or their families are harmed just so someone can claim a payout.

Bug hunters may apply hacker creativity, but they are not asked to (and should not) simulate the ruthless persistence of a true adversary. That gap explains why organizations sometimes get breached even after generous bounty payouts.

“Hackers get distracted by idiosyncrasies. Adversaries get paid to ignore them.”

What Infosec Really Needs

So what does infosec actually need? Not another poster saying “Think like a hacker.”

What we need is both:

• Hacker mindset for creativity, unpredictability, and system-bending insight.
• Adversary roleplay for realism, persistence, and outcome-driven attack chains.

You need both. One without the other is either too whimsical or too mechanical. And remember, the end goal is simple: make the system more secure against attacks than it was before. If your security bar isn’t raised, the whole effort is little more than a shenanigan.

Closing Reflection

Raising the bar is always a moving target – adversaries adapt, tactics evolve, and the outcome is never perfect security but relative resilience.

The industry keeps confusing hackers and adversaries because they sometimes overlap. But the distinction matters.

Hackers bend rules for curiosity. Adversaries bend rules for outcomes. Sometimes they’re the same person, but not always.

“Security teams that only think like hackers prepare for curiosities. Security teams that only think like adversaries prepare for missions. Security teams that think like both might actually stand a chance.”

And at the end of the day, all of this only matters if the bar for security is raised. Perfect security is a myth, but raising the bar is about resilience – making it harder, costlier, and riskier for the next attacker than it was before. If your systems aren’t harder to break into tomorrow than they were yesterday, then everything else is just theatrics. And remember, an adversary that thinks like a hacker is the proverbial Baba Yaga the nightmare we need to be prepared for.

That’s the balance the industry rarely talks about. Hacker is a mindset. Adversary is a role. If we forget the difference, we end up fighting shadows and missing the real battles happening right in front of us.

That sent me down a rabbit hole. Not about LLMs. About me.

Maybe these models aren’t the future of human intelligence. Maybe they’re a glimpse into its past.

“LLMs feel like early brain prototypes, smooth on the surface, sloppy underneath, and very sure of themselves.”

Hallucinations: The Default Mode

Most people critique LLMs for getting facts wrong. But that assumes facts are the point. The model does not know facts. It predicts the next likely token. What we call hallucination is our label for when that prediction diverges from the world outside the prompt. In that frame, a hallucination is not a bug, it is a natural outcome of training a system to guess the next likely thing, not the next true thing.

That got uncomfortably personal. Because honestly, I sometimes operate that way too. I fill in gaps all the time, with assumptions, with inferences, with memories that feel real but might just be particularly vivid guesses.

So when I see an LLM confidently invent a fact, I do not get mad. I get introspective.

The Brain: Better Window, Better Index

Let’s not get carried away. The brain is miles ahead of anything silicon-powered. But conceptually? It’s kind of doing the same thing, just with more layers of error correction, emotional regulation, and a vastly better sense of what matters right now.

Think of your brain as a fancy LLM with an overclocked context window and an insanely good garbage collection routine. It doesn’t just remember things-it resurfaces them in real-time, adapts them, mutates them based on mood, bias, and lived experience.

A recent EEG-based study compared students writing essays using no tools, traditional search engines, and ChatGPT. The results were striking: those using ChatGPT showed weaker neural connectivity, lower engagement in memory and attention centers, and an overall accumulation of what the researchers called “cognitive debt.” Essentially, the brain downshifted. The more the AI helped, the less the brain worked.

So maybe it’s not just metaphor when we say LLMs are like primitive brains. Maybe it’s a preview of what happens when the real one gets too comfortable. I have written about compute shifts in Flip Cycles of Computing, and this feels like another one, this time inside our heads.

An LLM needs a vector DB and some clever prompt engineering to fake that. Your brain just does it while you’re brushing your teeth.

“The brain is just a large language model with tighter controls, deeper feedback loops, and a much sharper sense of what matters in the moment.”

Intelligence: In the Eye of the Reader

Here’s the bit I’m still chewing on: is what LLMs do intelligence?

When a model prints something that sounds profound, is that because the model is smart? Or because we are? Are we projecting intelligence onto the output, like we do with horoscopes or motivational posters?

It feels like LLMs give us puzzles that we solve by interpreting. Their output gets both intelligence and emotion layered onto it after the fact, by the reader, because we can’t help but anthropomorphize patterns that sound just a bit too human.

Which makes me wonder: how much of my own thinking is just predicted noise that I later decorate with meaning? It is also why I still argue that learning to code matters in the age of AI: not to type faster, but to test assumptions, build small proofs, and keep my own context engine awake. I wrote about that in Why Learning to Code Matters More in the Age of AI.

At times it even makes me wonder if I am a moving model file, born with a base set of weights that get updated by life. Newer generations arrive with a different pretraining corpus, which explains why our slang splits and why each cohort sees the world with fresh shortcuts.

Priming, Echoes, and the Yes Mode

There is also the echo effect. If I go in heated, I often get heat back. Prompt in, tone out. Models are trained to answer, not to sit in silence, so uncertainty still produces fluent guesses. That is the yes mode. It feels helpful, and it often is, but it also explains why hallucinations appear so confidently.

Under the hood the model is not thinking. It is printing the next likely token. Whether that output is good or bad is something we decide after the fact. The same answer can feel profound to a novice and childish to an expert, which says more about the reader’s context than the model’s intent.

There is also a simpler reason the output often feels intelligent. The world is patterned. Most of our days run on scripts. Give a model the right cue at the right time and it will surface the median script for that situation. It reads as intelligence because the world itself is predictable.

“If life runs on templates, a good autocomplete will look wise.”

Garbage in, garbage out is an old line, but it fits here. The balancing act for builders is tricky. To serve the widest audience we optimize for speed, coverage, and low friction. Correctness can take a hit. I do not blame the tool. I blame my own tendency to accept a smooth answer when the rough truth needed work.

Why Am I So Fascinated?

Honestly, this is the part that keeps bothering me. Why do I keep staring at LLMs like they hold the secret to the universe?

Maybe it’s not about them at all. Maybe it’s narcissism in disguise. A weird mirror held up to my own thought process. Watching a system stumble into clarity makes me wonder how often I do the same. But with better grammar and less need for GPU time. I first captured that curiosity in My Thoughts on the New and Emerging World of GPT, AI, LLM.

The Push and the Cycle

One more tension sits in the background. Is AI everywhere because everyone needs it, or because we have already invested so much that it must be everywhere now? I have watched this cycle before, and wrote about it in Flip Cycles of Computing. Games pushed GPUs, then crypto found them, and now AI soaks them up. Tools change, demand shifts, the hardware keeps getting a new purpose.

We’re Still Ahead. For Now.

Let me be clear: the human brain is still winning. LLMs don’t self-reflect. They don’t dream. They don’t wake up at 3am remembering that embarrassing thing from 2008. We have nuance, shame, imagination, and a sense of time. LLMs just have token probability tables. If you want a practical compass for what to build in yourself while using these tools, I laid out a short list in Mastering the Essential Skills for the Digital Age and do read Survival Guide to Vibe Coding with AI

But here’s the twist: they may be crude, but they’re oddly familiar.

“Maybe LLMs are just the prehistoric version of the human brain, stuck in baby mode, pattern-matching their way into what we call thought.”

And maybe, just maybe, watching them fumble around will help us understand ourselves better.

When I argue with a model, I am not debating a mind. I am bouncing off a mirror, polished by millions of voices and reinforced patterns. It does not know me. I see myself in its structured replies. That may not be intelligence, but it is revealing.

Or maybe I’m just hallucinating. Or maybe it’s hubris. I only see what I carry. Right now I carry LLMs, so everything looks a bit LLMish. This is a snapshot, not the final word. If something newer or more fascinating comes along, I will happily rewrite this with a better frame.