I’m Panji Gautama. I write about engineering leadership, product, and how I work.
Bikes of Bentang Jawa: testing my AI workflow on something I wanted to use
I wanted somewhere to compare the bikes people rode at Bentang Jawa, so I used it to test my AI workflow. This post follows the setup behind the project: Claude Code paired with Codex, shared memory, MCP, skills, and remote agents. Two or three prompts remains the target; the preparation, reviews, and limits of the experiment matter too.
On testing a cheap LLM gateway
I tested whether a cheaper LLM gateway could replace OpenRouter in a forecasting workflow. It was faster and appeared substantially cheaper, but forecasts shifted, one verdict changed, and questions about billing and prompt logging remained. Here's how I compared the routes, what the results could and couldn't establish, and what I would check before switching.
AI, Hype, and Real-World Value: My Takeaways from Indonesia Product Conference 2025
At Indonesia Product Conference 2025, the useful AI conversations were about practical applications and customer value. I came away thinking about augmenting human expertise, choosing initiatives carefully, and understanding why people use a product. One GrabExpress story was a reminder that usage data can show a pattern, but talking to customers explains what is behind it.
Software Estimation
Software estimation affects business decisions, coordination, and risk, yet it is easy to confuse an estimate with a deadline. I outline common pitfalls and distinguish rough, budgetary, and definitive estimates according to how much is known. The post connects clearer requirements and shared checklists with better confidence, and points toward tracking estimation accuracy to improve over time.
On Growing in Software Industry: Domain Knowledge
A product can meet its acceptance criteria and still miss the business problem. I explain why software engineers benefit from understanding their company's revenue, customers, industry, and competitors, then bringing that context into product discussions. Domain knowledge helps us choose appropriate solutions, suggest useful improvements, and draw clearer boundaries when designing the systems behind a product.
On Growing in Software Industry: System Design
System design is a skill worth practicing at every level of an engineering career. I share starting points for understanding the discipline, learning frameworks such as RESHADED and PEDALS, and getting practice or feedback through mentors. The aim is to strengthen problem-solving and discover gaps in your knowledge by working through different kinds of design problems.
On Knowledge Management Method: BASB a.k.a. Building a Second Brain
As my responsibilities and information sources grew, a collection of linked notes became harder to manage. I describe how Building a Second Brain and PARA helped me organize knowledge in Notion around projects, areas, resources, and archives. These are personal implementation notes about keeping information manageable, capturing it in smaller pieces, and retaining useful links between ideas.
On Capturing Notes
My note-taking became easier when I reduced the friction of capturing information and the number of tools involved. I describe the setup I arrived at using PARA, Notion, a newsletter reader, and Kindle, along with ways to collect highlights and references. The important habit is to capture useful things and put them somewhere you can work with later.
Redis use-cases aside from Cache
Redis has uses beyond caching. I collect six examples, including persistent application state, bitmaps, geospatial queries, distributed locks, approximate analytics, and messaging through streams or pub/sub. This is a short reference to possible building blocks and their commands, inspired by ByteByteGo, for engineers who want a broader picture of the problems Redis might help them address.
On Evolutionary Architecture Book
My notes on Building Evolutionary Architectures focus on fitness functions: explicit characteristics that help teams judge whether a system is evolving in the right direction. I connect that idea to change, coupling, and domain boundaries. A well-structured monolith can evolve too; the useful question is which architectural qualities matter to the company and how to keep checking them.