I used an AI assistant heavily while rebuilding friendly-rotary-phone.

And after enough cycles, the pattern is clearer:

• AI is excellent at acceleration
• AI is mediocre at prioritization
• AI is dangerous when you outsource direction

When I gave it clear boundaries and concrete goals, velocity spiked.

When I handed it strategic ambiguity, entropy spiked.

The practical operating model that worked for me:

• Human defines vector (why, scope, tradeoffs)
• AI executes chunks (scaffolding, rewrites, repetitive glue)
• Human reviews integration points and architectural coherence
• Tests arbitrate disagreements

In this project, that model let me:

• pivot stacks quickly
• preserve conceptual architecture
• stand up tests/notebooks/docs faster than solo pace

My current take:

I don’t want AI to replace thought.

I want AI to remove waiting.

That’s a much healthier contract.

#AI #PairProgramming #SoftwareEngineering #Productivity #SystemsThinking

I added two visualization layers to friendly-rotary-phone:

1. Graphviz DOT export for explicit machine diagrams
2. NetworkX views in notebooks for quick structural inspection

I didn’t do it for aesthetics.

I did it because logs lie by omission.

A transition table can be technically correct and still hide a bad mental model. Once you draw it, mistakes become obvious:

• unexpected dead ends
• missing emissions
• transitions that look valid but violate intended flow

The same is true for struct graphs.

When constraints attach primitives in the wrong order, the graph tells on you immediately.

That said, visualization can also seduce you.

A beautiful graph is not evidence of correctness.

It’s only useful when paired with testable invariants.

So the workflow now is:

• build model
• render graph
• challenge graph with tests
• trust only what survives both

I like charts. I like diagrams.

But I like proven behavior more.

#Visualization #Graphviz #NetworkX #Testing #Engineering

I’ve been re-implementing core ideas from my master’s thesis inside friendly-rotary-phone.

Not as nostalgia.

As an experiment in whether old process-first abstractions still hold under modern tooling.

So far? They do.

The current Python implementation includes:

• ETS primitives and temporal structs
• active constraints as extension operations
• class representations as grouped constraint sets
• a struct-generating finite-state machine
• a deterministic transducer that emits symbolic spatial instructions

In short: generate structure in time, then instantiate into form.

That framing feels increasingly relevant in agent-era systems, where correctness is less about one pretty output and more about valid trajectories through constrained state.

Our Bubble Man example is intentionally small, but useful:

• seed_head
• grow_torso
• attach_limbs

Each step is constrained. Each transition is explicit. Each emitted action is inspectable.

No vibes. No magic leaps.

Just a process you can reason about.

A lot of modern AI workflows still optimize for fluent output.

I’m more interested in reliable evolution.

If a system can’t tell me how it got here, I trust it less.

That’s why this old thesis work keeps feeling new.

#AI #StateMachines #FormalMethods #SystemsDesign #Research

Look at it. Clean sync. Reproducible env. No ritual sacrifice required.

There are two kinds of project pain:

1. Hard problems you expect
2. Environment problems you pretend are normal

I have deep respect for hard problems.

I have zero patience left for the second category.

After resetting friendly-rotary-phone, I moved dependency and workflow management to uv, and the impact was immediate:

• predictable setup with uv sync
• clean execution paths (uv run pytest, uv run jupyter lab)
• fewer “works on my machine” conversations
• less cognitive overhead before doing actual thinking

That last one matters most.

In research-heavy work, your best hours are fragile. If your first 45 minutes go to environment archaeology, your best ideas often don’t survive the day.

uv doesn’t make your model better.

It makes your attention available.

My current default for experimentation projects:

• pyproject.toml as source of truth
• uv for environment + dependency operations
• notebooks for exploration, tests for invariants, CI for honesty

If your stack is fighting your thought process, it’s not “developer grit” to endure it. It’s usually a sign the project needs less ritual and more flow.

No fireworks here. Just fewer papercuts.

And more shipping.

#Python #uv #DeveloperExperience #Productivity #Research

Me, staring at another runtime mismatch with a coffee that had gone cold.

Before I get into the stack pivot, context: I’ve been building this with Blueshell, my OpenClaw business and thought partner.

We work like this: I set direction, tradeoffs, and taste; Blueshell handles the heavy execution loops—scaffolding code, validating builds, tightening docs, and helping turn implementation notes into publishable thought entries.

Code and writing aren’t separate lanes in this workflow. They’re one loop: ship architecture, extract lessons, ship the story.

I didn’t switch stacks because I stopped believing in elegant systems.

I switched because I wanted to ship one.

For this thesis reimplementation project (friendly-rotary-phone), I started in Elixir with Livebooks. It felt right on paper: state machines, constrained transitions, deterministic transduction. The architecture had poetry.

But then reality showed up wearing steel-toe boots.

Toolchain mismatch. Runtime assumptions. Notebook loading quirks. “Simple” demos that required too much invisible ceremony. Every hour debugging environment friction was an hour not spent on the model itself.

At some point, I had to choose between loyalty and velocity.

I chose velocity.

And here’s the part nobody likes to say out loud: a good architecture trapped behind recurring setup friction is just expensive taste.

So we did the hard reset.

• Removed the Elixir scaffolding
• Rebuilt the project as Python + Jupyter
• Used uv for deterministic dependency management
• Preserved the conceptual core: ETS structs, constraints, FSM generation, transducer outputs

The model survived.

Only the ceremony died.

I still love Elixir. I still think it’s one of the cleanest ways to model concurrent systems.

But for this moment, this project, and this pace: Python gave me oxygen.

Sometimes architecture is about selecting a language.

Sometimes architecture is about selecting what not to fight this week.

#AI #Engineering #Elixir #Python #DecisionMaking

GitHub repo: https://github.com/scaryPonens/friendly-rotary-phone

UPDATE 2026-01-31: I've since moved on to use ChatGPT Atlas. I have yet to retry this test with Gemini or Chrome since I wrote this article.

I'm not mad, I'm just disappointed

For weeks, I've been experimenting with various AI tools, but today the concept of an "agentic browser" truly clicked. I gave the Perplexity browser, Comet, a simple set of instructions to clean out my cluttered inbox—archive old newsletters, delete promotional emails, and organize the rest. It just... did it.

This is the key differentiator. It wasn't just answering my questions; it was executing a task on my behalf. A task I couldn't delegate to other powerful AI like Gemini, which lacked agency and tools to interact directly with my Gmail inbox.

Ok...

That one, simple, time-saving action has solidified my decision to continue with Comet and discover what else it can do. It's not just a smarter way to search; it's a step towards an AI that genuinely reduces my workload.

The future isn’t about asking smarter questions.

It’s about getting things done.

#AI #Productivity #Agents #Automation

Originally published on LinkedIn

Just look at it!

After more than 10 years of living happily inside the JetBrains Toolbox, I’m switching things up. For the next two months, I’ll be writing code exclusively in Cursor/VSCode. Why? For two reasons:

• I really want to give Cursor a fair and honest kick at the tires
• and to a lesser because I invested in a 49-inch monitor
• (bonus reason) are cloud-based dev environments ready to fully support my day-to-day

I’ve leaned on Jetbrains' IntelliJ IDEA and Pycharm batteries-included ecosystems for a long time and I’m curious to see how well Cursor (vs Pycharm + Copilot) can streamline my day-to-day dev workflow. Additionally, my 49-inch monitor investment has had the unintended consequence of making my screen exceptionally hard to share on name-your-favourite-video-conferencing platform. What I tend to do now is share my browser and because most of my goto-tools are cloud-based: Postman, Lucidchart, Mermaid, GitHub, AWS etc. Github Codespaces has been very helpful.

This isn’t about loyalty to one editor over another — it’s about testing whether cloud dev environments are ready to fully support the kind of work I do every day.

👉 To my tech community: if you’ve made a similar jump, what are your best pro-tips for making the transition smoother? Favorite extensions? Hidden tricks? Gotchas I should avoid?

And to my friends in the other camps — yes, I see you emacs Trevor Bernard and vim Saša Savić fanboys. I’ve only got two months and can’t spend six of them tweaking keybindings and configuration files 🫶.

Originally published on LinkedIn

Startups move fast. But speed without control leads to unpredictable outcomes, constant context switching, and eventually burnout 🔥💀. The irony is that developers already understand the problem—just not always how it shows up in team dynamics.

Every developer knows what happens when a message queue gets overwhelmed: the system slows down, crashes, or starts dropping messages. That is why we use back pressure.

What if your team had the same protection? It can. It is called Work In Progress (WIP) limits, and it is a core part of Kanban.

Message Queues and Back Pressure 101

In software systems, queues act as buffers between producers and consumers. If consumers fall behind, the system can respond by:

• Throttling producers
• Buffering messages
• Failing gracefully

This is back pressure. It prevents overload and preserves flow.

Now apply this idea to your team:

• Product minds are the producers
• Developers and reviewers are the consumers
• The Kanban board is the message queue

Too much input without matching capacity creates flow blockages and overload.

Kanban and WIP Limits

Kanban is a flow-based system focused on managing and improving throughput. Unlike Scrum, there are no sprints—just a steady stream of work moving from left to right.

The key constraint is WIP limits.

These are explicit caps on how many items can exist in each stage of the workflow. For example:

• A developer can only have two tasks In Progress
• The team can only have three stories in Code Review
• Product can only have three stories in Ready

These limits force focus, expose bottlenecks, and prevent teams from taking on more than they can finish.

The Analogy in Action

When consumers fall behind in a queuing system, back pressure kicks in. When teams fall behind, WIP limits do the same thing: they signal that capacity is full and protect the system from overload.

Sidebar: Back Pressure in Scrum?

Back pressure maps cleanly to Kanban because WIP limits are built into the process.

In Scrum, back pressure is more implicit. Teams rely on timeboxing, sprint commitment, and velocity to regulate flow. Without strict discipline, scope creep and mid-sprint work easily bypass that natural throttle.

In practice, Scrum often requires an iron-fisted Scrum Master to enforce boundaries and say “no” when the sprint backlog is full.

Kanban embeds the back pressure mechanism directly into the system. Scrum outsources it to process rigor—and people.

Why This Matters for Startups

Startups operate with limited resources and finite throughput. Taking on too much work leads to thrashing: nothing finishes, priorities shift mid-stream, and stress skyrockets 🚀.

Kanban provides a lightweight, flexible way to:

• Focus on flow
• Visualize bottlenecks
• Reduce waste from context switching
• Protect teams from burnout

It requires less ceremony, adapts easily to change, and does not require a dedicated Scrum Master 👮.

Tactical Advice

• Start small: Apply WIP limits to In Progress first
• Enforce gently: Treat limits as signals, not blockers
• Adjust over time: Tune limits using real data
• Use metrics: Track cycle time, throughput, and blocked work
• Build culture: Empower developers to say “no” when limits are reached

Conclusion

Kanban is not just for factories or large organizations. It is a developer-native approach that fits how modern teams actually work—especially startups.

When every hour counts and every developer matters, the fastest way forward is to avoid overheating your most valuable system: your team.

Back pressure keeps distributed systems stable. WIP limits do the same for teams.

You would not run a system without back pressure. Do not run a team without WIP limits.

For deeper practical guidance, Agile Project Management with Kanban by Eric Brechner is a solid next read.