unhappy path

The most dangerous thing about vibe coding

Thu, 23 Jul 2026 00:00:00 GMT

The most dangerous thing about vibe coding (especially from non-domain engineers) is not AI writing bad code, it’s people building things that should never have been built in the first place. Tactical solutions where the problem space is misunderstood or not well shaped. Solving automation issues which shouldn’t exist if the workflow could be re-imagined or redesigned properly. Cool & shiny new tools and services to solve non-problems but serve as novelty. Re-inventing wheels at a scale never before seen. And it’s not (only) about the cost of maintenance - it’s the whole human structure around the code and tools, that will now bend to people not thinking deeply enough about what they built. The fact it now can easily be done, doesn’t mean it 𝘴𝘩𝘰𝘶𝘭𝘥.

Originally posted on LinkedIn (opens in a new tab), July 2026.

It always takes longer to do it wrong

Fri, 03 Jul 2026 00:00:00 GMT

A short weekend note on the cost of shortcuts — or “micro-laziness”, depending how you look at it. Also a podcast recommendation, and an anecdote about toilet paper.

Friday morning, listening to Huberman with Andy Stumpf. Interesting man, interesting life (Navy SEAL vet), a lot of stories. I’ll take just one small one from there — on why it pays to do things right, and why shortcuts always take longer.

He talks about his kids finishing toilet-paper rolls and, instead of throwing the cardboard away, stacking the empty roll on the new one. Slowly they build a tower of empties next to the toilet. Roll done? Park it on the holder, or on the floor. Then another. Until there’s a cute little tower. Not very stable.

Eventually the tower falls on someone. Nobody dies. It just tends to happen when it’s inconvenient. Everyone knows this tower. Of course they do.

Andy, no matter what he tries, cannot get the kids to stop. His line on it:

It always takes longer to do it wrong.

End of toilet-paper stories.

This is true of almost everything. It is extremely familiar in software engineering. The famous “technical debt” applies to more than code — toilet paper, cleaning, laundry, dishes. You name it. Same pattern we know too well:

Approve a half-architecture because “we need to show progress”.
Push a new process without understanding the real consequences. We ship fast.
Leave broken pieces in the system because “nobody is complaining right now” and “we’re focused on the critical things” (always).
Build on old code with no plan for how you get off it.

Sound familiar?

Every one of those decisions looks reasonable in the moment. We are not actually solving it. We are just putting another roll on the tower. And another.

Until one day it falls. You never know who it falls on. Sometimes they just happened to be walking past. It does not stay with the person who deferred it in the first place. It becomes a problem for everyone who has to work with what was built.

So: enforce technical discipline. Find the people who will lead that work and actually connect to it. Allocate people and tasks to lowering entropy. Not only at the team or code level — at the system and architecture level too. AI only makes this more necessary than it already was.

Adapted from a LinkedIn post (opens in a new tab) (Hebrew original), July 2026.

Staff archetypes in the age of agentic engineering

Fri, 19 Jun 2026 00:00:00 GMT

The dominant AI narratives in engineering right now are depressingly predictable: seniors are finally 10x, juniors have no future, and companies keep cutting headcount. What gets less attention is how agentic engineering is changing the landscape for senior-plus engineers - tipping the scale toward some shapes of work and away from others, including ones the industry still needs.

AI can be an expensive footgun. What’s happening is interesting at least, and might be a bad omen.

I’ve been using Will Larson’s staff archetypes (opens in a new tab) for years - Tech Lead, Architect, Solver, and Right Hand. It’s a gross generalization, but the categories are useful and have always felt natural. Here’s how they look under current incentives.

Tech Leads are getting squeezed

Coordination, vision, and unblocking - the parts that used to define their impact - are being eaten by prompts and agents. Some Tech Leads are adapting. Some are watching their leverage shrink. Focus drifts toward shipping speed and away from the quality and standards work that was their wheelhouse.

Architects are getting sidelined

Hard. Companies believe they can ship fast without deep architectural thinking, so Solvers and small teams cut Architects out of the loop. Some of that is on Architects too: adapting long-term coherence to vibe-coding velocity is genuinely hard. Either way, they’re undervalued right now, and it’s dangerous.

Solvers are thriving

Management loves people who can take ambiguous problems, lean on agents, and ship aggressively. They’re also the ones cleaning up the 2am messes when the magic breaks. The growing costs for them are overload and a fuzzy long-term future inside the company. Constant fire-fighting and project-hopping make it harder to build real domain expertise.

Right Hands remain rare

Especially in the startup scene I know. My guess is they’ll be the ones driving the technical side of AI transformations alongside management - embedding practices and tools across the org while trying to keep systems and culture from breaking. Hard to see that working without first spending real time as Solvers, then (hopefully) switching back.

The incentive trap

We’re currently optimizing engineering orgs around Solvers too heavily. The other three archetypes are still needed, but relatively starved. Today’s incentives also shape the Staff-engineer mix five to ten years out - and I see huge gravitation toward Solvers.

I shouldn’t be surprised. Still annoying to watch.

Adapted from a LinkedIn post (opens in a new tab), June 2026.

The real achievement is a machine that does not need you

Wed, 01 Apr 2026 00:00:00 GMT

I’m back to work — well, for a day, kinda — from about a month of active reserve service, trying to catch up on what’s been happening. Checking in on the team and the projects in flight. And you know what the best part is?

They carried on just fine without me.

Developers, architects, data engineers, data-ops. Cloud infra stayed stable. Production is fine. Pipelines are flowing. Releases are happening. Data is being annotated. Things are shipping. Wartime and all.

It’s not as if there are zero issues. It’s a hectic startup with all the uncertainty that comes with that. Still: no drama, no frantic pings. Things are not on fire.

Solid work from people who know their stuff, and how to keep the spice flowing.

The real achievement in management or leadership was always building a machine that doesn’t need you to babysit it. For now it’s nice to check in every few days, see that everyone is safe.

Sarcasm levels were getting dangerously low out there. So there’s that.

Adapted from a LinkedIn post (opens in a new tab), April 2026.