AI Toolkit Research for Software Engineer 

November 29, 2025 AI, Personal No comments

Disclaimer: I do not promote any of the tooling mentioned in this blog post nor have I used the vast majority of them. All of the text written by me is my personal opinion. All of the text generated by LLM is its creation – I will be explicit where it is LLM and where it is me.

Unlike most posts where I make emphasis on my own experience and writing by myself, this blog post will be assisted with LLM, but in a good way. I want to create a comprehensive AI toolset list to explore for myself. Although it will have some tools very specific to my personal needs (like climbing) I believe you can apply the same approach to get your ideal list. This could have been LinkedIn post “Definite list of AI tools you must use” but I cannot stand those posts. This is just idea on how you can come up with your own list:

Step 1: Refine research plan

Prompt: “Refine this prompt: Perform research on the landscape of currently available LLM products and AI tooling for both professional and personal development for the user profile and wider audience, using referenced examples of already used tooling. User Profile: A Software Engineer at a big tech company in the Seattle area. Family with two kids, sports (climbing, Muay Thai, running), writing blog posts, coding for fun, and wondering about life in general. Researching topics such as: health, finance, 3d printing, writing about tech, coding, taxes, parenting, relationships, career decisions, trip planning, real estate, etc. Reference examples:  ChatGPT, Gemini (deep research, chat, image gen), Claude Sonet for coding, locally running small LLMs, trying out different AI startups for intermittent tasks.”

The above text was me. The below text is the proposed research plan by LLM:

(1) Research the current landscape of major LLM products (such as ChatGPT, Gemini, Claude) and emerging AI startups in late 2025, specifically analyzing their capabilities for professional software engineers (coding agents, debugging, architecture design).
(2) Investigate the ecosystem of open-source and locally executable LLMs (compatible with Ollama) and privacy-focused tools suitable for a tech-savvy user running consumer hardware.
(3) Search for specialized AI tooling and applications tailored to the user's specific hobbies and creative interests:
(a) Sports performance analysis for climbing
(b) Sports performance analysis for Muay Thai
(c) Sports performance analysis for running
(d) 3D printing modeling and slicing optimization
(e) Technical blogging and creative writing assistance
(4) Find AI resources and tools assisting life management, covering:
(a) Parenting, education, and kids' activities in the Seattle/Bellevue area
(b) Real estate market trends and housing analysis in Vancouver, BC
(c) Personal finance, tax preparation, and investment tracking in the Seattle/Bellevue area
(5) Explore AI interfaces designed for broad life topics, such as philosophical conversation, relationship coaching, career development planning, and travel logistics.
(6) Synthesize the findings to categorize tools by professional utility versus personal development, comparing them against the user's current stack (ChatGPT, Gemini, Claude, Ollama) to identify gaps and superior alternatives.

Step 2: Run multiple researches and synthesize takeaways

I’ve run 4 reports with the above prompt or some variations of it. In the end I got four 20 page documents. After skimming through them it is obvious that either: a) some info is outdated, like recommending Claude Sonet 3.5 when I’m already using 4.5; b) recommendations are too generic; c) some sections were too verbose and some too short for my needs; d) some recommendations are contradictory, for instance using Ollama for privacy and then suggesting some startups that suggest uploading private data to small startups.

One idea I had was to feed all documents into another research specifically asking for summary with bullet points. Unfortunately the result was a 5th document of not better quality. Another approach I took was: “Create a maximum 5 pages summary from the four similar documents. Do bullet points. Keep links to websites. Do NOT do research.” This gave much better results.

Step 3: Edit the result

So I’ve got approximately what I need. The next step was to iterate a few times on the list. E.g. I asked LLM to add a list of general health and longevity tooling following the same format. Copy-paste, read through, and add more sections. The appendix text in the end is the list by AI, with minor edits from me.

Step 4: Action Plan

It is obvious that I won’t be trying all of the tooling (that would be crazy) but to do exploration of what’s available and within my area of interest. As an action plan I highlighted some tooling to use and play with below or use more actively:

  • llms.txt – a file to be added to this blog post so AI knows how to read it.
  • Ollama: The CLI standard for running local models. Already using it, but probably use even more. (got M4 apple processor with 32Gb memory so some LLMs run just fine).
  • NotebookLM: Google’s AI-Powered research partner. Have seen demos of this one and should try.
  • Belay AI: analyzing center of mass and hip trajectory when climbing. Didn’t know such a thing existed. Would be curious to try out.
  • Garmy: Python library and MCP server linking Garmin data to Claude Desktop or Cursor for agentic analysis. Sounds like something I would like to play with next.
  • Meshy: Converting prompts to 3D models. Already tried but wan’t too happy with the results. Will give it another try.
  • Layla & Wanderlog: AI travel agents. Used general LLMs for my travel planning before but will be curious to try tailored tool.
  • Orai: Pocket AI coach analyzing recordings for filler words, energy, and clarity.

Conclusion

I believe the AI and LLM tooling landscape is very saturated. There is a tool or a startup for almost anything you can think of. The point is not the specific list but how I arrived at it and how it is tailored to my needs. In this blog post I provided a method at arriving at your own list of AI tooling that is applicable specifically to you.

Alert: wall of text below.

APPENDIX: THE RESULT

Disclaimer: I am not advertising or promoting any of the tooling below, have no affiliation to any of the companies or products mentioned. The text below is generated by LLM. I only reviewed it.

Executive Summary: The Shift to Agentic Workflows

The technological paradigm has shifted from “Chatbots” (passive Q&A) to “Agents” (active execution). The competitive advantage in 2025 belongs to the “Augmented Architect” who orchestrates specialized AI entities to manage full-stack development, complex financial engineering, and physical performance.

1. The Professional Engineering Workbench

The modern workflow bifurcates into Integrated Agents (living in the IDE) and Headless/Terminal Agents (operating autonomously).

The Battle for the IDE: Cursor vs. Windsurf vs. Copilot

  • Cursor: The “Architect’s Instrument”.
    • Best For: Heavy refactoring and legacy codebases.
    • Key Feature: “Composer” and “Shadow Workspace” index the entire codebase to predict multi-line edits and handle global refactors.
    • Model: Uses Claude 3.5 Sonnet for superior code structure nuance.
    • Pricing: $20/month; generally preferred by power users over Copilot.
  • Windsurf: The “Flow State” Facilitator.
    • Best For: Greenfield projects and rapid prototyping.
    • Key Feature: “Cascade” flow tracks user actions (terminal commands, clipboard) to infer intent, actively running tests and fixing errors.
    • Differentiation: Focuses on keeping the developer in “flow” rather than granular control.
  • GitHub Copilot: The Enterprise Incumbent.
    • Best For: Corporate environments with strict compliance needs.
    • Status: Now includes “Agent Mode,” but critics note the chat often feels disconnected from the editor compared to AI-native rivals.

Command Line & Autonomous Agents

  • Claude Code (CLI): A terminal-resident agent that replaces the chat interface. It can navigate directories, read files, execute Unix commands, and handle large-scale refactoring.
  • Cline / Roo Code: Open-source VS Code extensions that act as “Headless Developers.” They can execute terminal commands and create files autonomously, allowing for a “Bring Your Own Key” (BYOK) model.
  • Deep Think Models: Google’s Gemini 2.5 Pro utilizes “parallel hypothesis testing,” allocating a “thinking budget” to simulate System 2 thinking for architectural reviews and debugging race conditions.

The Sovereign Stack: Local Inference on Apple Silicon

For IP protection and privacy, running models locally on M3/M4 Max chips (Unified Memory) is the standard.

  • Ollama: The CLI standard for running local models (like Docker for LLMs).
  • LM Studio: A GUI alternative for discovering and testing models.
  • Top Open-Source Models:
    • DeepSeek-Coder-V2: Uses Mixture-of-Experts (MoE) for high reasoning with efficient inference; ideal for logic-heavy tasks.
    • Qwen 2.5 Coder: The premier open-source choice for daily coding, rivaling GPT-4 in benchmarks (88.4% HumanEval) and running on 32GB+ RAM.

Career Engineering & Strategic Presence

Interview Intelligence (The “Copilot” Era)

  • Final Round AI: Real-time “Interview Copilot” offering transcription and live hints.
  • InterviewBee AI: Adaptive mock interviews that dynamically adjust difficulty.

Strategic Networking & Personal Branding

  • Supergrow: LinkedIn growth tool generating tone-matched content from past posts.
  • Taplio: Identifies viral technical topics and drafts high-visibility posts.

Performance Engineering (Automated Brag Docs)

  • Lattice AI: Auto-drafts reviews, translating engineering metrics into business impact narratives.
  • Fellow: Auto-generates “Brag Docs” by tracking wins from 1:1s year-round.

Public Speaking & Leadership Intelligence

Voice Cloning & Auditory Feedback

  • ElevenLabs Voice Cloning: Clones your voice to objectively audit delivery and identify awkward phrasing before speaking.
  • Orai: Pocket AI coach analyzing recordings for filler words, energy, and clarity.

Simulation & Real-Time Coaching

  • Yoodli: Simulation platform providing private analytics on eye contact and pacing during practice speeches.
  • Poised: Real-time meeting assistant offering live, private feedback on speaking speed and confidence.
  • VirtualSpeech: VR-based training for practicing presentations in realistic 3D environments (e.g., boardrooms).

2. Wealth Management

For a Seattle engineer with RSUs and complex taxes, standard budgeting apps are insufficient.

The “Finance as Code” Approach (Privacy-First)

  • Beancount: A Python-based double-entry bookkeeping system that stores financial records in plain text. It treats finance like code (version control, CI/CD).
  • Fava: The web UI for Beancount.
    • Fava Investor Plugin: Calculates IRR and tracks asset allocation across disparate accounts.
    • Automation: Python scripts (e.g., wash-sale-tracker) can parse trade history to track wash sales and automate RSU vesting tracking.

The SaaS Optimization Route

  • Prospect: Specialized for tech employees with ISOs/RSUs. It models tax implications of exercising options and calculates the “AMT crossover point” to prevent surprise tax bills.
  • Compound Planning: Tracks net worth across illiquid assets and models scenarios for RSU vesting and tax cliffs.
  • StockOpter: Specifically addresses equity compensation guidance and AMT modeling.
  • HouseSigma: Essential for the Vancouver, BC market. Uses AI to provide “Sold” history and valuation estimates, unlocking data previously gated by realtors.
  • VanPlex: Analyzes zoning data to identify “under-utilized” lots suitable for multiplex development (Bill 44), aiding in investment arbitrage.

Financial Education & Investment Intelligence

Tools for deep research, interactive learning, and risk-free simulation (Paper Trading).

Deep Research & Earnings Intelligence

  • AlphaSense: Institutional “semantic search” for broker research and earnings calls; highlights off-script management answers.
  • Quartr: Mobile access to live earnings calls/transcripts; “search across audio” finds specific keyword mentions instantly.
  • FinChat.io: “ChatGPT for Finance” providing sourced answers from verified 10-Ks/10-Qs to minimize hallucinations.

Interactive Education & Family Literacy

  • Magnifi: AI investing tutor; explains portfolio balance and stock fit via conversational interface rather than just charts.
  • Zogo: Gamified literacy app for families; breaks complex topics into bite-sized modules with rewards.

Simulation & Practice (Paper Trading)

  • Thinkorswim: Institutional-grade paper trading with “PaperMoney” to test strategies risk-free.
  • Webull: UX-friendly platform for beginners to practice trading mechanics before deploying capital.

3. The Quantified Athlete: Physical Intelligence

AI is transitioning from logging data to providing active biomechanical coaching.

Rock Climbing

  • Belay AI: Uses computer vision (pose estimation) on a smartphone to analyze center of mass and hip trajectory, identifying micro-inefficiencies in movement.
  • KAYA Pro: Digitizes climbing sessions and calculates “Workload” to prevent overtraining. It filters “beta” videos by body morphology (e.g., finding beta for a specific height).
  • Lattice Training: Uses datasets to benchmark finger strength and build periodized training plans.
  • Crimpd: Utilizes analytics to prescribe hangboard workouts and manage training loads.

Muay Thai & Running

  • Sensei AI: A virtual coach for Muay Thai that analyzes shadow boxing via camera. It corrects hip rotation on kicks and guard retraction.
  • RunDot: The data scientist’s choice. Uses “Environment Normalization” to adjust pace targets based on heat/humidity, ensuring constant physiological stimulus.
  • Runna: Focuses on UX and community, gamifying the training process for better adherence.

General Health & Longevity Intelligence

The intersection of “Quantified Self” and AI for preventative health and programmable biology.

Developer-Friendly Health Data

  • Garmy: Python library and MCP server linking Garmin data to Claude Desktop or Cursor for agentic analysis.
  • HealthGPT: Open-source iOS app using on-device LLMs to query Apple Health data privately.

Longevity & Preventative Analytics

  • InsideTracker: “Programmable” biology platform; integrates wearable APIs and uses Terra AI to map blood biomarkers to peer-reviewed optimization protocols.
  • Function Health: Deep clinical baseline with a 100+ biomarker panel for early detection and chronic disease prevention (closed system).
  • Superpower: Accessible longevity diagnostics and biological age tracking at a subscription-friendly price point.

4. Creativity & Fun

Bridging the gap between software and physical artifacts.

3D Printing Stack

  • OrcaSlicer: The “Open Source Victory” for 2025. Offers granular control (jerk/acceleration settings) and “Scarf Joint Seams” for aesthetics.
  • Obico: AI failure detection (spaghetti detective). It monitors the print bed via camera and pauses prints to prevent fire/waste. Can be self-hosted on a Raspberry Pi.
  • Zoo (formerly KittyCAD): “Text-to-CAD” API. Generates editable, parametric CAD models (code-based) rather than simple meshes.
  • Meshy: Generates 3D assets from text prompts, best for rapid prototyping or game assets.

Knowledge & Blogging Pipeline

  • Repo-to-Blog: A workflow using Gitingest or GitHub Actions to convert codebases into token-optimized summaries. These are fed into LLMs to automatically generate technical “DevLogs” from commit history.
  • Obsidian + Smart Connections: A “Second Brain” setup where the plugin uses local embeddings to allow you to “chat” with your notes vault.
  • llms.txt: A new standard for 2025. Adding this file to a personal site makes it indexable by AI agents.

Music Exploration & Vibe Matching

  • Spotify AI Playlist: Generates playlists from creative text prompts (e.g., “songs for a rainy cafe”).
  • PlaylistAI: Creates playlists from text prompts, images, videos, or festival posters.
  • Maroofy: Search engine that matches songs by “audio vibe” rather than just artist similarity.
  • Cyanite: Advanced “Free Text Search” to find songs matching specific moods or descriptors.
  • Music-Map: Visual tool that creates a floating “cloud” of related artists based on fan affinity.
  • NotebookLM: Google’s research tool; upload your concert history/venue calendars to create a custom event finder.
  • HyperWrite: AI agent capable of browsing the web to find specific tickets or venue schedules for you.

5. Life Logistics

Tools acting as “Chief of Staff” for the household.

  • Ohai.ai: Ingests unstructured data (screenshots of flyers, voice memos) to manage family calendars and conflicts.
  • Milo: An SMS-first family assistant (powered by GPT-4) that manages logistics via natural conversation.
  • HomeZada: A digital home management platform that uses AI to predict maintenance costs, schedule seasonal repairs.
  • Familymind: Synthesizes school PDFs and sports schedules into a master calendar.
  • Layla & Wanderlog: AI travel agents. Layla handles discovery/booking; Wanderlog optimizes daily routes and logistics while traveling.
  • Magic School: Generates personalized tutoring content and educational activities.


No comments

Don’t Outsource Your Thinking: Why I Write Instead of Prompt

November 23, 2025 AI, Blog, Opinion, Personal No comments

Original content by Andriy Buday

I’ve been asked multiple times about my writing process, how I keep consistency, and why I write blog posts at all. Who in their right mind spends multiple hours weekly to write when there are LLMs that generate the same quality text within a minute? Let me share my secrets and answer these 4 questions:

  1. Why do I write at all?
  2. Isn’t it all just a waste of time because of LLMs?
  3. What’s my writing process?
  4. How do I stay consistent?

Image credit: Gemini Nano Banana Pro. I admit the image is cheesy, lol, but it’s also fun.

Why do I write at all?

Writing is structured thinking

Over time I confirmed to myself that ‘writing is thinking’ but also unlike speaking or thinking in my head writing is a structured way of thinking. You get the privilege of ‘parking’ some thoughts for further elaboration, you get the privilege to validate your thoughts with external research, you get all the privilege to mold things and shuffle them around, decompose and synthesize again.

Writing is a transferable skill

Undeniably writing is a skill, but, in my opinion, it is a transferable one. By working on improving my process of writing it becomes easier for me to write documents at work and the easier for me it becomes to write my personal documents (financial planning, goal setting, emails, etc). The more I write the easier it is to overcome that initial ‘hurdle’ of starting a new document. I am a doc producing machine at work: meeting notes – I’ve got it; short design doc – I’ve got it; just documenting my work trip – I’ve got it; producing ‘announcement’ document – I’ve got it. None of it seems daunting. I also wrote a post on “Why documenting everything you do at work matters” believing it is beneficial for your career, especially performance reviews and promos.

Isn’t it all just a waste of time because of LLMs?

Producing vs. Consuming

Here is a big secret, my dear readers: I’m writing mostly for myself, and I have a strong argument why it is worth my time instead of just prompting LLMs. For the sake of argument, I just kicked-off Gemini’s ‘Deep Research’ on the topic of tech writing, answering 4 questions from above. I’m confident that in ~3 minutes I will have a PhD level research paper on this topic. What do I gain from that research? What do you gain from that LLM research? Well, we become consumers – I can read that research paper and, for sure, that will have many punchy arguments and external pointers to like 100+ websites to learn from, but this trains our “info => brain” path, this does not train our “brain => info synthesis” path. Very specifically, next time when you need to produce new information, your retrieval/producing ‘paths’ in your brain are not trained for that.

Numbers

Let’s also do some numbers to see the worthiness of this activity:

  • Range of 2-5 hours per week writing blog posts. It is closer to 2h for writing itself like this post and closer to 5h for larger technical/coding posts.
  • 370 blog posts so far.
  • 800 comments with praise/admiration and additional insights I was missing.
  • Only 3k pageviews/month and only 50 mail subscribers.
  • I have no ad income (I made some <200$ in the past as an experiment).
  • In a way, the blog is an ‘Ad’ of myself.
  • Up-scalling my tech writing skills.
  • Hardly measurable influence on my career growth, but it’s definitely there.

What’s my writing process?

Sourcing Topics and Info

To be honest, at times it is very challenging to come up with new blog post ideas and even when I have an idea expanding on it is also quite a tedious process. I have a “blog post ideas” document which just sits there in my Google docs. Whenever something crosses my mind I would add it there. Another source of ideas is just some question I would get from someone either at work or in my personal conversations. For instance, this blog post was inspired by a person asking about my writing process as he was struggling a bit with writing some roadmap/design document at work. I hear you. This blog post is for you.

Writing Process Itself

At very early stages I usually start with just pouring thoughts and ideas in raw, unfiltered, and very unstructured ways. This is just the expansion step of my framework of dealing with ambiguity. At this stage focusing on quality, perfection, structure is counter-productive. If this is a technical design document, then some template for structure is usually already given, so that ‘pouring’ thoughts happens in compartments. Then, once I have lots of unstructured thoughts, I do more of research, I try to find key points and rephrase where needed, this is where trimming also happens. At later stages I would use LLMs to help me out, but I am generally against using LLMs for everything, and definitely not using for my blog writing. At work, generating summary or bullet points or initial structure is definitely easier with LLMs, and it would be a mistake not to use it.

LLMs

Yeah, I do use LLMs – but not for writing or structuring my thoughts but for other purposes. The main one: finding blind spots in my thinking. I have made many profound realizations of missing some key arguments thanks to LLMs, not only that, even in my personal life I came to realize that there are things I perceive simply differently to other people – eye opening. Another use of LLM is to suggest refinements to text, but not so much proof-reading, unless this is obvious typo catches. Honestly, sometimes, I just cannot stand all this ‘sophisticated flowery’ text generated by LLMs. When I see people write ‘significant impact drastically improving leverage of comprehensive coverage of’ – I know it is LLM and it sucks. You can know these are my own words, because LLMs avoids confrontation. Another way I’m using LLM for my writing is coming up with a common theme in my thinking and generating ideas for the best title.

Focusing on Experience and own Opinions

In the light of LLMs I found it to be ever more important to focus on my own experiences, strong opinions, and on building my own personal expertise. That’s the main distinguishing factor. No LLM has my brain or knows my thoughts.

How do I stay consistent?

Connect Inspiration Periods in One Continuous Chain

This is another question I get quite often. The answer: Consistency is Hard. The way it works for me is a multi-year habit building. I failed many times and I had to re-start it over and over again until it actually started working in a connected chained manner. The analogy I give is from rock climbing: to climb a mountain you connect multiple single pitch climbs. We get inspired at times (new year resolution, someone inspires you) and then you do a few iterations and then you fail. I say: get inspired more often, on purpose, and then connect into a continuous chain! Get inspired by books, people you admire, your mentors, your super-smart colleagues, someone you love, and last but most importantly, your future self!

Conclusion

Writing is not always just the output, but also the process. I see writing as “gym for the brain”. For sure, LLMs can lift weights for you, but that won’t make your thinking and writing stronger. It is like watching fit and strong people on Instagram and wishing you will be one like them without doing anything. The world is dominated by consumption and in my opinion being able to structure your thoughts and clearly articulate is something that will make you stand out.

APPENDIX: Additions by Gemini 3 PRO LLM

Below are some interesting extracts from the 17 page ‘Research Paper’ produced by Gemini on my ‘deep research’ request about technical blow writing and from analysis of the above text:

Blind spot: The “Quality” Trap

You mention LLMs generate “flowery” text that sucks. While often true, advanced prompting can mimic style fairly well. Suggestion: Strengthen the argument that the value isn’t the final text, but the struggle to produce it. Even if an LLM wrote a perfect post in your style, it would still be a “waste” because you didn’t do the cognitive lifting to get there. It’s like sending a robot to the gym for you.

Luck Surface Area

Blogging increases an engineer’s “Luck Surface Area.” This concept suggests that the amount of serendipity (job offers, speaking invitations, consulting opportunities, co-founder inquiries) one encounters is directly proportional to the number of people who know what one is doing.

Beyond the internal mechanics of a current employer, blogging functions as a potent “sales aid” for the engineer’s broader career trajectory.2 Recruiters and hiring managers at elite firms increasingly value communication skills as a primary differentiator. According to industry data, a significant majority of recruiters prioritize communication skills, sometimes even above raw technical proficiency, because technical knowledge can be taught, whereas the ability to articulate complex logic is a rarer trait.

Linearization of Thought and Feynman Technique

The process of writing requires the linearization of thought. Code can be non-linear; it jumps between functions, modules, and asynchronous callbacks. Prose, however, must flow logically from premise to conclusion. This forcing function exposes gaps in understanding. As noted in the analysis of engineering blogging benefits, writing a blog post often reveals that the author does not understand the code as well as they thought they did. This aligns with the “Feynman Technique,” which posits that one does not truly understand a concept until one can explain it in simple terms to a layperson.

Transfer of Experience

However, LLMs struggle with context, nuance, and novelty. They cannot hallucinate genuine experience. They can explain what a circular dependency is, but they cannot explain how it felt to debug one at 3 AM during a Black Friday traffic spike, nor can they navigate the specific political and technical constraints that led to that dependency in the first place.

The value of human writing has shifted from Transfer of Information to Transfer of Experience. The “Small Web” movement is a reaction to this; it is a flight to authenticity. Readers are looking for the “red hot branding iron” of human personality—the idiosyncrasies, the opinions, and even the biases that signal a real person is behind the text.15 As AI content proliferates, the premium on “human-verified” knowledge increases.

Case Study: Gergely Orosz (The Pragmatic Engineer)

Gergely Orosz serves as the gold standard for the modern technical writer. His transition from engineering manager at Uber to full-time writer was built on a specific process 39:

  • Crowdsourcing via Surveys: Orosz often gathers data before writing. For an article on “Developer Productivity,” he surveyed 75+ engineers and managers across the industry.39 This provides proprietary data that no LLM can access.
  • Structured Workflow: He treats writing with the discipline of coding, using outlines and working with editors/publishers to force progress.41
  • Mimicry: He openly advises starting by mimicking role models.42 If you admire a specific engineering blog, analyze its structure and replicate it until you find your own voice.


No comments

The Hurdles vs. The Levers: A Framework to Think About Personal Productivity as Software Engineer

November 16, 2025 Opinion No comments

I was thinking about what makes a software engineer productive. There are so many things that come to mind: enough focused time, right tooling, fundamental knowledge, soft and hard skills, energy, motivation, attitude. So much of everything and you can definitely find arguments online for one or the other being the most critical. In this post I want to argue, what is more critical, but rather want to make a point that generally there are two categories and then suggest some action items in the end based on this. Additionally, I will try to present examples with personal stories.

Image credit: Gemini

The Hurdles: Logarithmic/Sigmoid Blockers

These are examples of things where being good enough is usually sufficient to get a great boost in productivity but where pushing for being world-class good only gives smaller diminishing returns and only makes you good in that specific area.

Typing speed. Naive example, but for its simplicity it’s easy to understand. Extremely slow typing speed would slow you down. But the difference between really fast 100wpm and 150wpm is tiny for your productivity as a software engineer. To give a personal flavor, back in my university I trained my typing so I could type fast but then when I was in a sports programming competition (speed matters there), the guy who was a slow typer but a ‘big brain’ easily would beat me on hardest problems.

Tooling familiarity. For example, your IDE. If you get lost on how to use it at all, doing anything even simple is extremely tedious. Remember how frustrating it is to find some simple functionality that should be there right at your fingerprints. I would say this is logarithmic as well, but the curve bends at a much higher elevation compared to typing, so you do need to spend deliberate time to learn core functionality of IDE and your entire productivity will be elevated. Knowing some nice rarely used features probably won’t help too much. Back at my first job, I learned how to be productive with JetBrains ReSharper and could execute large refactorings quickly – this distinguished my productivity from others, but not too much from others who knew these tools as well.

Physical and mental health. Being sick sucks for productivity so it is clear the healthier you are the better your productivity is going to be. The difference between being “generally healthy” and “an elite athlete” on your ability to code is not 10x, lol. My intensive Muay Thai classes don’t help me with my coding at all, but general weekly activities help maintain a healthy baseline that doesn’t make you ‘tired’. Arguably this becomes more important as you age. With age our mental capabilities degrade a bit as well as needs for rest increase. 

… there are more …

The Levers: Exponential Multipliers

This is a category I have for things where being better actually makes your productivity be higher, either just linearly or even exponentially, being good is good, being better is much better, and being great makes you 10x.

Fundamental knowledge and understanding. The way I imagine it is that fundamental knowledge is setting the upper limit on your productivity. If you don’t have enough fundamental knowledge it would be hard to break through the “ceiling” and come up with something truly innovative. Yeah, that’s why big tech is chasing those ML PhDs with ludicrous pay as this is what is pushing that most upper boundary limit. That’s why new grads, people who acquired some strong knowledge, are like those big unknowns with huge potential. I know many folks who studied with me, but having had more in-depth knowledge, have achieved greater results sooner.

Consistency. If you are productive consistently, the progress might not be visible immediately but over time it will become apparent and accumulated and it will get you really far. This time I think of this somewhat as linear dependency up to a point, but I also think there is a ‘breaking point’ where this converts into exponential uptrend – there aren’t many people in that space to even compare with you. Imagine someone with great knowledge, but just not consistently utilizing it.

Mental resilience and attitude. Having the right attitude towards dealing with stress, projects, being ‘can handle anything’, being resilient usually sets apart people who get stuck at some point and those who get more done. Resilience is what allows you to tackle a complex, multi-month project without giving up. It’s what allows you to take criticism in a design review and turn it into a better product. This one is arguably hard, but I would also say this psychological factor is huge.

Soft interpersonal skills. If you are a single engineer trying to do something your productivity is capped. Someone who can clearly articulate a technical vision, persuade a team, and mentor others can be that “multiplier” of their impact across the entire organization.

… there are more …

Conclusion

So where am I going with these two buckets of Hurdles vs Levers or whatever we call them? Why does it matter?

IMO it does matter a lot as most engineers spend their time optimizing the wrong thing.

  • Sometimes I notice both in myself and others that we are trying to pull a “lever”, like learning a totally new programming language, all the while some simple “hurdle” is not cleared, like being burned out or not knowing how to use IDE.
  • And other way around, say all the hurdles are cleared but we keep optimizing them, like I might be trying to bring my system design documents to perfection, when I probably should gain a new foundational knowledge on the complex system itself so I push my upper limit on future designs and become innovative with insightful knowledge.

Let’s conclude this as a framework:

  1. First, identify and clear your hurdles. Are you fighting your tools? Are you exhausted? Are you constantly sick? Your workstation setup sucks? Crappy keyboard? Forgetting git and linux commands? Fix these first. You can’t be productive if you’re running with a sprained ankle.
  2. Then, focus all your energy on the levers. Build consistency. Go deep on fundamental knowledge. Have mentorship (both as mentor and mentee). Practice your communication skills. Be better at prioritization. This is how you stop being just busy and start being truly productive.”

What are your thoughts? What obvious examples have I missed? Do you generally agree with this categorization or think there is even a 3rd category?


No comments

Thinking about Large Software Systems as Living Organisms

November 9, 2025 Uncategorized No comments

Have you ever thought about large software systems as organic living organisms? This sounds a bit odd and, maybe, philosophical. Starting with first principles: everything in the world is based on fundamental physical laws. When we think about the organic world we often imagine fuzzy, imprecise, evolving and reproducing things. But when we think about a software program, we often imagine strictly deterministic outputs to given inputs with no typical attributes of living organisms, though on a completely fundamental level both are build with the same basic physical particles and follow same laws. At the level of modelules of even proteins organic world is fairly deterministic similarly to small software systems, but when we get to a system that is built by hundreds of software engineers over a decade that serves millions or billions of requests per day it has more resemblance of a living organism than of that exact deterministic machinery.

I could think of multiple similarities, for instance:

  • Growth and evolution. A codebase is constantly adapting to a changing environment, engineers constantly modify code. Some sub-systems die-off and some new ones are being added.
  • Metabolism. The system consumes resources (CPU, ram, gpu, storage, network, or whatever other capacity) in order to operate (live). It has a “metabolic rate” (your cloud bill) and produces “waste” (logs, error reports, heat).
  • Homeostasis. The system attempts to maintain a stable internal state. Monitoring, alerting, and auto-scaling are all of the things to keep it healthy and in balance. At work people even say “system health”.
  • New Behaviors. This is a bit interesting. In any system with enough complexity, the interactions between individual parts sometimes create unpredictable, emergent behaviors that no single person designed. This sometimes results in extremely difficult to debug bugs or system behaviours that are challenging to explain.

Counterarguments could be things like:

  • Replication. Arguably complex systems are not that advanced in self-replication, at least this isn’t their primary goal (unless it is computer virus). We have some data replication and scaling as some analogies, but maybe not quite enough.
  • Consciousness. Although large systems don’t have “consciousness” we can argue that encoded adoptions, distributed algorithms, automatic maintenance, state monitoring are partially related to this. This becomes more blurry in the world of AI.
  • Non-determinism. Systems are often designed to be deterministic. When they are large and complex enough randomness is necessarily introduced and ML models leverage randomness in principle.

Working for multiple very large companies serving billions of users definitely made me think that large software systems grow beyond human-scale comprehension. Sometimes I think these large systems are organisms and software engineers are part of this organism working on making parts of this organism alive and evolving. Also thinking of an analogy of software engineers looking after a large system as gardeners looking after a living garden. If it’s not looked after properly it becomes messy and bushy.

What does this mean practically? Well, this was just a thought I typed in, so not 100% sure but, maybe, it could mean:

  • Stop trying to fit the entire system in our heads and instead build world-class observability (metrics, distributed traces, and logs) and keep parts of the system you are responsible for healthy.
  • Embrace a bit of chaos. The system would sometimes behave unexpectedly. Some practices to stress test the system are good (chaos engineering) the same as organisms are sometimes tested with adverse environments or viruses/infections.
  • Design with evolution in mind and do not expect your solution will be final or will never be pruned by other engineers.
  • The more parts of the system are built with AI assistance the more the system becomes organic. We should focus on ‘trunk’ of trees while we might allow AI to build leaves and small branches.


No comments

Vibe 3D printing

November 2, 2025 3D No comments

Not sure if there is a definition for ‘vibe 3D printing’, but watch me do it, LOL. I bought my daughter a 3D printer for her birthday half a year ago. She prints a bunch of cool stuff from printables.com or does simple models in tinker. Some of the models she is printing are crazy complexity and quality. I was wondering how much 3D printing I can learn/do in just half a day or so. Here we go.

Project: creating custom magnet with topographical map featuring engraved run from STRAVA.

This is the end result:

The context is that I used to go on 10k runs with friends around Burnaby Lake in British Columbia. I no longer live there but my memory of good weekly Sunday runs remains.

Step 1: Extracting Run Trail

First I went to my strava runs and took a screenshot of an actual run. Now, a more correct way would probably be to fetch GPS coordinates either from Garmin or Strava, nevertheless I started with images in a true “vibe mode”.

Now, I only wanted to extract this red line into a 3D object. I expected this to be fairly challenging for someone like me who knows nothing about 3D printing, photoshop or other tooling, so I used Gemini LLM. I convinced LLM to convert this image to just a red line and white background. This took quite a few prompts, but it worked much quicker than it would take me to figure this out in a proper tool. I got this:

Next, I wanted to get a 3D model out of this, the issue is that the image is JPG. I tried some AI software called MeshyAI, but it generated a really bad 3D model, so instead I used a multi-step process. I used some online tool to convert my JPEG into SVG, so I can programmatically work with it (yeah, now GPS coordinates would have been better).

Step 2: Run Trail Map => 3D Model

Next, I vibe coded python script to use Blender’s tools to convert SVG to STL (3d printing file).

https://github.com/andriybuday/burnaby_lake/blob/main/svg_to_stl.py In my vibe-coding I also added platform so I can print it right away and validate it looks ok.

So now I got some reasonable 3d printable trail map, which you can see below in OrcaSlicer:

Step 3: Topological Base

Next, I wanted to take this even further and generate a topological map, potentially with buildings. Turns out there is an add-on “Blender GIS” for Blender software. I had to register at https://opentopography.org/ in order to get an API key for retrieval of topology. This is where things got a bit more complicated. Specifically, I could print buildings but the elevation wasn’t printing.

Next I had to export this into another STL with buildings on top of the topology.

Step 4: Merging in Orca Slicer

Now that I had different objects prepared, I went to add them to Orca Slicer. The most challenging part with terrain was that it wasn’t printing because it was just a surface floating in the air instead of filled-in mesh, so the technique that worked for me was to assemble Cube and meshed terrain from Blender and then do Mesh binary difference between the two, leaving the bottom part of the Cube that was sliced by the terrain. This is what I got in the model:

Step 5: Printing

Turns out that printing tiny buildings actually doesn’t work too well so I stopped on just using the terrain and the trail. Here are 3 results:

Step 6: Strava Plugin: trail to 3D Model

Registered with strava API, then vibe-coded the tool that retrieves GPS coordinates and changes them to SVG. SVG is already importable into Orca slicer and Blender.

Here is the git repo: https://github.com/andriybuday/strava/tree/main/strava-plugin 


It would take another day to actually make properly working nice plugin, but next time around I would have some building blocks in place.

Yesterday’s activity on strava: https://www.strava.com/activities/16326534438

Same activity after running my tool and manual overlap with terrain:

Conclusion

I think my conclusion is that building things is cool. In this post I was able to combine wild usage of AI for image augmentation, vibe-coding python to convert SVG to STL, vibe-coding STRAVA integration, and a bunch of googling & LLM-ing to find answers to my questions, and then sitting with my daughter and fighting Mesh boolean operation. Cool stuff.

P.S. Found this tool that almost does what I’ve done here except it doesn’t export the entire terrain: https://gpxtruder.xyz/ Result of exporting of my today’s hike:


No comments

The Athlete-Engineer: A Framework for Peak Performance

October 25, 2025 Personal, Sports 2 comments

Me training my climbing on a MoonBoard

I consider myself a bit of a recreational athlete, meaning I do sports for fun and health: rock climbing, Muay Thai, running, and occasionally visiting conventional gyms. In 2021 I worked out 365 days straight and as of now have 2.3K logged activities on Strava with a 140 weeks long streak. I haven’t been like this 9 years ago or earlier, barely doing any activities back then, but over time I realized that health and time are the most valuable assets I have. This post is a few things: self reminder to stay on track, potentially some inspiration for you, and an attempt to drive analogies between athletic performance training and software engineering careers.

LEVEL 0: Non-Compromisable Fundamentals

There are only three fundamentals in my opinion. Compromising these is the worst thing you can do to your health, not just physical, but also mental performance, yes including your software engineering career.

Sleep

  • I cannot stress enough how important sleep is: lack of sleep is a slow form of self-euthanasia. The shorter your sleep, the shorter your life.
  • Reducing your sleep time to do more work is counterproductive and all the way detrimental to your health and creativity. It may work short term only or if you have some special super-human abilities. I don’t.
  • For a software engineer, sleep deprivation doesn’t just hurt your health. It destroys creativity and makes complex problem-solving nearly impossible. My productivity is extremely low if I haven’t had enough sleep two days in a row.

Nutrition

  • You become what you eat.
  • I don’t want to expand too much here. We all know the basics: not skipping meals, proper balance of macro and micro, no junk food, less sugar, little or no alcohol. It’s all common knowledge. Consistency is hard.

Physical activity

  • The basic amount of physical movement is a MUST unless you want to die earlier.
  • To cite AHA: “at least 150 minutes per week of moderate-intensity aerobic activity or 75 minutes per week of vigorous aerobic activity, or a combination of both, preferably spread throughout the week”.
  • For those of us sitting all day, this is non-negotiable. Even a 10-minute walk can be that ‘garbage collection’ our brain needs to consolidate thoughts.

LEVEL 1: Improving and Growing

Improving Sleep

I am going over sleep again but this time with more practical recommendations if you are targeting greater benefits.

  • Adjust your sleep duration to your needs. For example, my baseline sleep need is 7h50min, but after very intense kickboxing class >600kcal my need increases by about 50 minutes or if I had an easy day it may reduce a bit. I get this info from my Garmin’s “sleep coach”, the way I address this is by going to sleep earlier or later, not by changing my morning alarm.
  • Improve quality of sleep. Tracking sleep phases helps, and general recommendations also help (darkness, cooler temperature, regular timing), but what I found helped me a lot was to reduce my coffee consumption to single coffee very early in the morning. What might help you might be different.
  • Here is my old post reviewing the “Why We Sleep” book. Practical tips for posterity:
    • Stick to a sleep schedule
    • Don’t exercise too late in the day
    • Avoid caffeine & nicotine
    • Avoid alcoholic drinks before bed
    • Avoid large meals and beverages late at night
    • Avoid medicines that delay or disrupt your sleep (where possible)
    • Don’t nap after 3pm
    • Make sure to leave time to relax before bed
    • Take a hot bath before bed
    • Have a dark, cool (in temperature), gadget free bedroom
    • Get the right sunlight exposure
    • Don’t stay in bed if you (really) can’t sleep

Getting more out of your nutrition

Besides all of the regular recommendations I would like to mention few additional ones:

  • Gut Health: a diverse gut microbiome supports overall health. Strive for a variety of foods.
  • Blood Sugar and Mood: High blood sugar correlates with mood fluctuations, so stable blood sugar levels are ideal. Watch sugar consumption.
  • Creatine is a safe, extensively studied supplement shown to benefit both power and endurance performance. Ok and beneficial to consume creatine. I do. And yes, after a few months of consistent consumption I noticed a small increase in my strength when climbing.
  • Protein. If you are building muscle, it is ok to add some extra protein if you are not getting enough with regular food. I do, though I’m not building muscle actively.
  • A sugar crash is the enemy of deep work. I sometimes take an energy drink – but that’s a horrible idea as it’s like taking on high-interest tech debt. A cheap ‘boost’ now that you’ll pay for all afternoon.

Physical activity

  • My personal weekly target is minimum 300 active minutes (or 150 vigorous), though this is challenging with intense software engineering jobs. I hit my 300 active minutes with 2 Muay Thai classes, 1-2 climbing, 1-2 runs, 1-2 weights exercise or some other activity.
  • Studies show that maximum health benefit is reached up to 600 active minutes after which you are really optimizing for performance and not health. I just changed my target to 400.

Recovery

  • Once you are doing a lot of activities recovery becomes a “thing”. Not only this is needed for physical activities but also mental. We need to take vacations from time to time. We need to take rest at weekends to avoid burnout.
  • Recovery should be periodized to support long-term training. Rest well and enough before next training which should be harder (longer & intense) than previous one(s).
  • For us, software engineers, it is also crucial to have mental recoveries. Also just as muscles grow during rest, our best ideas often surface when our brain is in ‘recovery’ mode.
  • I personally prefer to work extra hard during the week but then keep my weekend completely to myself and avoid logging-in to work on weekends (unless I’m oncall).

LEVEL 2: Optimization 

Optimization comes last. Once you have all of the key ingredients and are consistent only then you can start thinking about all of the niche nitty-gritty optimizations, not before.

Choices

  • We can only optimize on one of the three — health, body composition, or performance. A balanced approach might be best for recreational athletes, but you cannot reach maximum in all three. At the moment I seem to be doing a bit of all of them, with the intention to optimize for health rather than the other two. It is tempting to build muscle or push for that next climbing grade or a new personal record on a 10k run.
  • I think in our careers we might be also facing some choices – do we optimize our hard technical skills or do we develop soft skills, do we build breadth of knowledge or go very deep. It’s a choice and we can only optimize one of them and others could still improve but you won’t reach peak in them.

Deliberate Training

  • When you go running, you can just run regular 5k at whatever pace you find manageable, or you can do a variety of specific training – you can do interval training, long easy runs, tempo runs, etc. Combination of these different dedicated runs help with your race time.
  • When you go climbing, you can just climb whatever for fun, or you can dedicate a session to endurance, do bouldering 4×4, do handboarding, do dedicated climbing specific stretching, etc. This pushes your max grade.
  • Same with all other sports…
  • This can be extrapolated to software engineering as well. You can just be doing your work from day to day or you can be deliberately spending some time to advance. This can come in the form of taking courses, reading books, working with your mentor, trying new technologies out, etc.

Mental resilience

  • Elite athletes frequently employ self-talk such as “You will move up” and “You are #1” to boost performance. Experiment with positive self-talk. Maybe read book “Unf*ck youself”. I know this sounds odd and so on – but if top elite athletes are doing this there must be merit to it.
  • At work we should try to fight imposter syndrome. Too often than not we think that we don’t know enough and are not good enough, while the correct way is to think otherwise and if you are in a leadership position you should assure people you lead with their skills.

Metrics

  • I love measuring and tracking my health and sports progress. I’ve been doing so since 2016. Buying a Garmin sports watch was one of my best purchases of my entire life. My latest one is Garmin’s Fenix 7X Pro Sapphire. The reason this is one of the best purchases is because it is motivating to know how you are progressing (at least for me) and unlike regular apple/google watches this one is sport oriented and battery lasts 28 days (yup ‘days’).
  • I’m creating this health/sports snapshot for myself and will be able to compare it a year from now. Around birthday seems to be a good cadence:
    • Age: 37
    • Weight: 150lbs (68kg)
    • Sleep: avg 7h17m vs. avg sleep need: 8h02m
    • Vo2Max: 56 mL/kg/min
    • Heart: HRV: 47ms, rest: 53bpm, max: 166bpm(avg/year)
    • Run PRs: 5k 22m53s, 10k 48m17s, Half: 1h58m
    • Weekly minutes: 348m (avg weekly over year 10/2024-10/2025).
    • Calisthenics: Max pullups: 21 Max pushups: 102, max pushups in session: 600
    • Max climbing grade: V7 (boulder) and 5.11+ (rope)
    • Max barbell: deadlift: 255lbs, bench: 150lbs, squat: 140lbs (yeah, I know, bench more than squat 😂)
    • Swim: barely making it across the pool, but something I want to improve
    • Bike: 10mi – 35:30, 30k – 1:09, though I never tried to push for anything here
  • This is a direct parallel to our work in engineering. We are judged by metrics as well, like how many pull requests we do, the impact of projects, operational metrics, code quality metrics. I do personally pay attention to these as well and rigorously track them. I will share my weekly work methodology one day on this blog.

Risks

Pushing for anything in performance can have negative effects as well. Here are some personal notes (not universally applicable):

  • Chronic Traumatic Encephalopathy (CTE). A risk associated with repetitive micro-concussions, particularly in contact sports like MMA. Since I’m sparring with people who actively take part in competitions occasionally I get hit fairly hard (even though we try to be careful).
  • Injuries. I’ve had periods where I climbed 3-4 days a week resulting in shoulder injury which needed at least 3 weeks to recover. The key here is to listen to your body and to alternate activities and load.
  • Supplementing. Taking any supplements other than creatine, protein and, maybe, some generic vitamins is very questionable. I recommend against it, but you do you.
  • Burnout. Applying a “max-effort” training mindset to work 52 weeks a year can lead directly to burnout.
  • Metric Fixation. Over-focusing on a new running PR can lead to a physical injury, obsessing over proxy metrics (number of code changes or lines of code) can lead to a career injury which is optimizing for the wrong thing, and missing the actual business impact.

Consistency

Probably the most challenging part of the any of the above levels is consistency. It’s just hard. It’s hard to go on a run when you just don’t enjoy it or when the weather sucks, it is hard to go climbing when the mood isn’t striking, it is hard to find time when you have an intense work schedule. So how do you solve these? I found a few ways that helped me, maybe something would work for you.

  • Cut off low value activities from your life. I do not watch any TV whatsoever. My social media usage is very low. I don’t play video games. I try to recognize time wasters, but may have blind spots. AI seems to be good at helping me unblind things.
  • Curve out time were you have opportunity. My company provides breakfast, lunch, dinner in the office so I leverage these for time saving. I specifically looked for place close to work so I don’t spend time commuting. Cut off nonsense and optimize time – time is the only thing you will never ever get more of.
  • Work on establishing habits. Books like ‘Atomic Habits’ and ‘the power of habit’ give great recommendations, but basically you need to build a clue to kick-off something automatically over time.
  • Find joy in your activities. I didn’t really like running at the beginning – it felt boring, but now I enjoy it and it definitely helps with anxious or depressing thoughts. I’m just going for a run when I need to clear your head. Climbing often is a social activity – solving problems with other guys and gals in a gym is fun.
  • Pair up. If you’ve got friends sharing similar sport interests it is always great to be done socially. I definitely miss those weekly 10k with friends back in Vancouver.
  • Find an accountability partner. Another thing I do in addition to everything above is having someone I am accountable to. It could be either through challenges I’ve been running or by simply promising someone. I hate breaking promises.

Conclusion

Our cognitive performance is inseparable from our physical health. The same principles that build a 10k PR or a V7 climbing grade are the exact same ones that build a high-impact, sustainable engineering career: you need fundamentals, deliberate training, and recovery.

You can’t sprint a marathon, and you can’t sprint a career without burning out. By investing in your physical platform, you are directly investing in your mental output. The return on that investment is a career and a life that is more performant, resilient, and sustainable.

Let me know what you think!

P.S. This post was in part inspired by my personal trainer from Vancouver. Thank you for your recommendations! And now I promise to incorporate compound barbell training once a week back into my routine and will report back after some time! 🫡


2 comments

The Practical Ceiling: AI, Diminishing Returns, and Our Future

October 19, 2025 AI, Opinion No comments

I would like to discuss a dilemma between near science fiction predictions of development of AI and grounded practical applications of AI.

Image credit: me + Gemini
Gemini or any other LLM does NOT take credit for the contents of the blog post, though!

First of all, it is completely undeniable that AI is changing our lives and will have a transformative effect on the future. We can argue that humanity has lived through many transformative events over and over again: invention of fire, agriculture, writing, electricity, industrialization, information technologies, so AI can be seen as just one more invention on our part. Now, is AI really just one more invention or something that would absolutely change what it is to be a human as we know it? Is this our last invention?

I just finished reading the book “The Singularity is Nearer”. The book is arguing that we will eventually extend the capabilities of our biological brains and go beyond the limits of our organic bodies. At first we would come up with inventions that would greatly extend and improve our lives (reaching “longevity escape velocity” in mid 30s) and that we will build brain-computer interfaces (think of phones now, AR glasses or something of the like next, brain implants next, nanorobots next, with eventual consciousness upload to the information network). As another book “Homo Deus” (my review) argues – we eventually become god-like and gain the ability to control life and environment and Homo Sapiens go extinct. We might eventually lose our carbon-based existence and just become information.

To my way of thinking, while much of that, like nanorobots repairing our bodies, may sound like science fiction, as long as it doesn’t break the laws of physics I’m on board that it can and may happen.

Now, let’s look at some more practical examples.

  • From transportation technology: Crossing the Atlantic would be 6 weeks sailing in the 1800s, 6 days in early 1900s with fast liners, 1950s – 8 hours by plane, 1970s – concorde doing that in <4h, and technically 90min possible from anywhere on planet to anywhere by rockets, but we are still flying boring 8h from London to NY.
  • Military: We came up with ever larger nuclear bombs, but post “Tsar Bomba” in 1961 it simply doesn’t make sense to make any larger ones.
  • Digital: digital camera resolution, audio quality, single processor’s clock speed, and many more examples where more has diminishing returns and becomes impractical.

This same pattern of hitting a practical limit is not just a historical curiosity because I can see it already happening in the world of AI. Let’s have a look at some examples:

  • LLMs are now reaching the plateau of information saturation where they basically learned everything there is to learn from the internet.
  • Vibe coding is mostly hype in my opinion. Yes, I do vibe-coding as well for fun, like my previous post about doing 3h multiplayer typing game, and it is a huge productivity booster, but I believe it fundamentally is like many other tools [post pending] – having logarithmic benefits – huge at the beginning and eventually ever more diminishing.
  • Plateau in image recognition. This once was a grand challenge of computer science, and is now a largely solved problem for most practical purposes, but pushing models to 99.9% accuracy is not practical.
  • Parameter count race. All those 7B to 70B to 1T parameter models. There is no point in multi-T models and the cost is just not worth it. I recently ran 7B LLM model on my mac air and it is not that bad at all. 

My point is that in many individual fields where AI is applicable we will be reaching the some kind of optimal point between theoretical possibility and practical application. In the process we will be seeing major transformations, like the entire sector of jobs associated with driving will be replaced by self-driving vehicles. There is a good chance this could create socio-economic disruptions and ripple effects. Just imagine, some rich “haves” can give their child superpowers while some poor “have nots” could not afford that. But I agree to the point that this is only “in-transite”, because now people in some poor countries can afford a phone that would be multi-billion worth of technology if this was mid last century.

My own predictions are that:

  • AGI is still very far away, a much longer time-frame than “The singularity is nearer” is arguing for. Maybe 10-30 years from now.
  • Each and every AI application will reach its optimal practical point.
  • Human lives will improve as they did with other technologies. 
  • Software engineering jobs won’t get extinct, but they will transform and we need to adopt.
  • I will die, but someone born next century might not.


No comments

Vibe Coding & Designing Typing Multiplayer Game

October 11, 2025 AI, Fun 2 comments

The other day my daughter showed me the typing game her teacher encouraged kids to play. My daughter was impressed with my typing speed. This blog post is to impress her even more.

The game she played was online typing practice – you type text and compete with other players for speed and accuracy. Players are represented as racing cars. If you win races you qualify to higher league of players. In this post I want to do few things:

  1. Vibe code standalone JS file – you can try it out right in this blog post.
  2. Vibe design a full fledged online game.
  3. Vibe implement the backend for the multiplayer game.

Vibe Coding Typing Trainer

Here is the result of about 30 minutes of work. You can play it yourself (if reading from e-mail you may need to open the blog).

This was achieved with 13 prompts, summarized like this:

1. Initial project creation prompt
2. CORS issue fix request
3. Container class addition request
4. HTML demo update request
5. Simple version (typing.html) request
6. Visual version creation request
7. Error display duration adjustment
8. Error display fix attempt
9. Revert request for error display
10. UI enhancement with "click to activate" label
11. Visual version adjustment request
12. Final revert request
13. History documentation request

Vibe Designing Multiplayer Game

Now instead of working with Claude, I started working with Gemini to create a design for the multiplayer game.

Here is the high level system design document: opens in another page.

Given that I explicitly prompted it to be fully stateless, relying only on client side local history, no login and no other complications this seems to be a fairly good start. My prompt was:

Now I want you to create a comprehensive system design to build the game described above. We need:
- simple website with JS logic
- backend that can create rooms of gamers based on their levels
- the game should protect user privacy so there is no user info stored on backend
- game history is only stored as long as user has local cookies
- backend should handle at least 10k users
- single game has max 6 players
- if user wins the game they are placed into higher league

As a next step I fed the generated system design document back to Claude in Visual Code. This time I had to fight a lot more with the AI as it was running into issues connecting players but finally arrived at the multiplayer game:

Prompting history:

- Initial setup of multiplayer backend server
- Setup Node.js with Socket.IO and databases
- Create basic server structure
- Implementation of matchmaking system
- Create skill-based queue system
- Handle player matching logic
- Game room and state management
- Implement room creation and management
- Handle player synchronization
- Create typing texts table
- Add sample data
- Visual keyboard integration
- Add keyboard visualization to multiplayer version
- Implement key highlighting


The backend is powered by:

- Node.js
- Socket.IO (for real-time WebSocket communication)
- Redis (for server-side data/caching)
- PostgreSQL (for the database)

Conclusion

I have complete confidence that if I had 2 or 3 days to spend on this I could actually create a game that can be put out there on some servers and be actually playable by actual human beings! The new world of AI is nuts. I’m out of my time allocated to blogging, but I’m convinced over and over again, that the old times of programming are over – the only way to survive is to adopt.

P.S. Another thought: I have a friend who works on Linux kernel stuff. You would imagine that hardcore stuff like that would not be affected by the era of AI, but no, he says that AI helps to properly review pull requests to the kernel and catch real issues, moreover it does help to build more complex things. Caveat, of course, is that the proper knowledge is still required. Who knows, if I knew nothing about programming, maybe, I wouldn’t be able to build this typing game so quickly? Or, maybe, this is just a matter of time?

Github: https://github.com/andriybuday/typing-trainer


2 comments

Finding Your Voice at Work

October 5, 2025 Opinion, RandomThoughts No comments

“If you stay silent as a mouse you will just stay where you are.“

This was the advice I got from a team lead at my first job, right after I’d rushed through the office to complain about a broken system that endangered a delivery to our client the next week. He praised me and didn’t want to shut me down, even if I might have overdone it. For many of us, finding that voice is the hardest part. We hold back our ideas, questions, and concerns for a number of reasons. Let’s break down the four most common ones:

  • We assume that something is obvious.
  • We assume that others know better.
  • Deference to authority.
  • Physiological: not feeling safe, fear of judgement.

Stating the Obvious

One of the biggest mistakes we make is assuming that others have the same knowledge or perspective as we do. What seems obvious to you is often the result of your unique experiences, learning, and context. But others may not have the same background.

One of my university professors used to say there are only three types of proof: by contradiction, by reasoning, and obvious. I struggled with the 3rd one because when something is somehow “obvious”, it wasn’t that obvious to me at all.

Quickly re-stating that “obvious” part often removes the ambiguity from the discussion and sets the common baseline. Without being aligned on the same baseline the entire conversation doesn’t make sense, that’s why it is super-important to simply re-state the “obvious” and explicitly list what the assumptions are.

Sometimes I notice how very senior leaders would ask very basic questions about something only to witness that not everybody in the room was on the same page about this basic truth.

Sharing the “obvious” has very little drawback. While there may be a small cost, say a bit more document space or an extra minute in a meeting, that cost is a cheap insurance policy against catastrophic misalignment. A little information overhead is always better than massive miscommunication.

Others know Better

It is oftentimes true that others know better (to state the obvious). But this shouldn’t be a blocker, rather it should be an incentive! If you speak up and you’re wrong, you become the main beneficiary: you get corrected and learn a critical piece of information. If you’re silent, you leave the meeting still misinformed. If a question is forming in your mind, it’s highly likely that several other people in the room are thinking the exact same thing but are too afraid to ask. By asking, you don’t expose your ignorance; you serve the collective need for clarity.

Deference to Authority

Sometimes it’s not fear or lack of clarity, but simple deference to authority. When senior leaders are present, people instinctively stay quiet, assuming their ideas matter less or that others will take the lead. This one is tricky as it also includes some cultural aspects of how you were raised and also cultural aspects of your company.

More often than not, however, leaders actually want more people to speak. They value a challenging question or divergent perspective far more than a room full of nodding heads. In fact, leaders sometimes speak first precisely to kick-start the conversation, and they often intentionally hold back because they don’t want their presence to silence the room. In fact, sometimes leaders don’t speak at all precisely because they want to ensure others feel there is room to contribute. Silence out of deference is perceived as alignment, which can lead to misguided decisions. Don’t assume your idea matters less. Assume your perspective is a critical puzzle piece the decision-maker needs.

Physiological Safety

This one is a tough one because it’s rooted in our fundamental human desire for psychological safety. This is a need that is not always easy to satisfy in high-pressure environments, such as the big tech corporate world.

Google has done this famous study “Project Aristotle” which concluded that psychological safety was the number one predictor of a team’s effectiveness, more so than the individual skills, intelligence, or seniority of the team members. The “how” a team worked together was more important than the “who.” Safety there means that team members are confident that no one will embarrass or punish them for admitting a mistake, asking a question, or offering a new idea.

Being comfortable taking “interpersonal risks,” such as challenging the status quo, offering divergent ideas, or asking for help is a lot more beneficial than taking another risk of closing in and solving the problem on your own.

Conclusion

The path from “mouse” to “wolf” isn’t about aggression or volume. It’s about recognizing that your unique perspective is a crucial piece of the collective intelligence. Your job isn’t to be an expert on everything, but to ensure that the room has all the information it needs: whether that’s stating the obvious, asking the ‘dumb’ question, or challenging the senior leader. So:

Ask the ‘n00b’ question. Challenge the status quo. State the obvious. Share your ideas. You lose virtually nothing, but the collective clarity and your growth is a big win. Speak up!


No comments

Talk Is Cheap; The Smallest Code Change Speaks Loudest

September 28, 2025 Opinion No comments

How many times have you been in a meeting where a brilliant idea was discussed, only to have it disappear into thin air? “Talk is Cheap; Show me the code” by Linus Torvalds perfectly captures the frustration, which roughly means that ideas, promises, or arguments don’t carry much weight until they’re backed by action. In software, the ultimate proof is working code. To be brutally honest, I often talk more than I code, and while talking is important at more senior roles, the ultimate delivery is still code.

From “Wouldn’t It Be Nice” to “I Did It”

I have been in multiple discussions where we were talking about some tool or some product and we all thought, “oh, it would have been nice if the tool had this capability or just this extra command flag we can use”, but because none of us had familiarity with the tool it basically stayed with that “would have been nice”. Over time I noticed: diving into the code is usually less intimidating than it looks. Once you do, you not only solve the problem but also gain familiarity others don’t have.

Why don’t people do this more often? It’s simple: it requires effort taking time away from your main project and has a high risk of failure. My proposal is to time-box your effort. There is definitely a sweet spot where you can spend y hours on the thing, where uncertainty reduces the most drastically, to make the final call if more effort is worth it. The ‘y’ should be somewhat proportional but limiting to the benefit ‘x’ you get, maybe y = sqrt(x).

The Approval Stamp: Reducing Friction

Another example: I was using some internal tool and it had a simple UI validation bug. One path to take was to file a ticket with the team owning the tool, someone would look it up, which would definitely be low priority on their plate, and this would get fixed in few weeks or not at all, but I needed the fix right now to avoid workarounds, so I published the fix code change – literally 2 lines of code. It would have probably taken 2x more time to file the ticket and communicate with the tool owners. They only had to stamp the change.

A bit more abstract: let’s say you are using a system owned by someone else, and you need to change something from x to y. In one way you know that’s a simple change and the person is likely to agree, but explaining it and waiting for them to apply the change causes friction. Instead if you just do the change on your own, and getting Y instead of X is just an “approve” stamp on the other side you will get your stuff really soon.

How about Alignment?

But won’t you come across as someone for pushing for a change without aligning first? – Yup, there is such a risk. There is a very simple way to avoid this: just soften how you propose the change. Ideas: 1) give a quick short “heads-up” message “I have this idea to improve Z by changing x to y, I will share a preview change to show what I mean”; 2) frame your code change as a light proposal, a “preview”, a “suggestion”.

Conquering Uncertainty with Code

This is perhaps where the ‘smallest code change’ provides the most value. Many of us, myself included, can get lost in the abstraction of system design by drawing diagrams and talking through every possibility. While this is a necessary step, it’s not a substitute for engaging with the actual code. I’ve worked with software architects in the past who were so detached from the codebase that their designs were completely unworkable. They simply didn’t know what they were talking about. The solution is to complement your high-level design with ‘on the ground’ code.

The key learning for myself: whenever working on the design of something: do more code digging and make small refactorings along the way (even if a bit unrelated).

Feeling of Doing instead of Talking

This one is a bit subjective, but we are humans as well as software engineers. There’s a fundamental difference between talking about progress and actually making it. Pushing code feels a lot better than just talking about it. Wouldn’t you agree?

Next time you’re tempted to keep talking, try the smallest code change instead. It speaks louder than a hundred conversations. This is one lesson for me.


No comments