oldnewthing

Not really. Not unless your PM is also an extremely deep technology person. Here is a simple example from our current debate: should we build the resiliency capability that hurts multiple customers and who have asked for it because it reduces their toil or the AI feature that nobody has asked for that our PM wants? The AI "feature" is consuming 6 engineers, is behind schedule and turns out to be significantly more complicated than anticipated and won't hit the end of year timeline. We don't know what uptake is going to be like. The resiliency feature could be shipped in 2 months and cut human interventions >70% of the time. Customers are already lined up waiting for it.

One argument is that the AI "feature" is forward looking and can bring more customers into the platform. Agreed. And then what? They are also stuck on the resiliency feature right?

Somewhat true. Platform teams have to be engineering & product led. I run a platform team and we work very closely with our customers to understand what problems they are facing and identify platform level solutions for those problems. But we are still hampered by the team not using the platform for their everyday work, reducing the empathy they have towards its papercuts. However, being purely product focused can lead you astray of your users. Our PMs invent capabilities that no one really asked for ignoring the rather large backlog of capabilities that they already need. That's also bad.

The problem with every platform team is that, impact is hard to nail down. Does X using your platform Y to generate revenue mean your platform Y has indirect impact same as X? Most companies don't think so and end up destaffing their platform teams. Until, the destaffing ends up in much more inefficiency because everyone is inventing their own crooked wheel, spending time on the same capabilities and detracting from product development.

Not sure what value your comment added. Software engineering is also problem solving. Are you arguing it is not?

Hey, I agree with you. I and my team have the same existential worries. This was one reason why I bought my own subscriptions to Claude and Codex to learn and skill up. I have been using that to intensively do side projects, curating prompts and workflows to see how these new tools fit in my toolbox. I have been bringing back the learnings to my team so that they can upskill as well.

For context, I use Claude and Codex (side projects, Max and Pro plans respectively) and Gemini at work.

The key takeaway I have is: These tools have let me climb up the value chain ladder.

Even with Claude (Max plan, Opus 4.8, High Effort), it makes tons of mistakes, assumes a lot, misses nuance and doesn't really think through every aspect of the problem from every angle. Limited memory, lack of full context and a lack of experience with real world distributed systems means that the initial solutions they offer need a lot of iteration and refinement. Just like any junior engineer would need to do.

So, you might feel that with a LLM, "this should just be an hour" but it usually becomes a 2-week exercise for me.

Which brings me to what I tell my team repeatedly: "the only person with the big picture is you." I ask them to focus on thinking, ideating, refining. Do quick PoCs, talk to customers, discern what they are trying to achive, and what you can do to solve those problems. Work with Gemini (we can only use Gemini at work) to iterate until you are comfortable with the full solution end to end with all the nuances. Then let the agent code.

This moves you up the value chain from being a programmer to a problem solver. That's what software engineering has always been about: solving problems. Don't be discouraged. In fact, I am having more fun, am more energized and loving my craft even more now with LLMs. I am able to write down my thoughts, iterate on them and create a one-pager for ideas fast and get them to my team for them to think about. Sure, probably half of them we discard because it's usually not a "now" problem but we put that in our backlog to dust off when the first customer asks for it.

I also have the following in ~/.bashrc

export CLAUDE_CODE_MAX_OUTPUT_TOKENS=64000 export MAX_THINKING_TOKENS=31999 export DISABLE_AUTOUPDATER=1 export CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1

If this helps, I rolled back to version 2.1.34. Here is the ~/.claude/settings.json blurb I added:

  "effortLevel": "high",
  "autoUpdatesChannel": "stable",
  "minimumVersion": "2.1.34",
  "env": {
      "DISABLE_AUTOUPDATER": 1,
      "CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING": 1
  }

I also had to:

1. Nuke all other versions within /.local/share/claude/versions/ except 2.1.34. 2. Link ~/.local/bin/claude to claude -> ~/.local/share/claude/versions/2.1.34

This seems to have fixed my running out of quota issues quickly problems. I have periods of intense use (nights, weekends) and no use (day job). Before these changes, I was running out of quota rather quickly. I am on the same 100$ plan.

I am not sure adaptive thinking setting is relevant for this version but in the future that will help once they fix all the quota & cache issues. Seriously thinking about switching to Codex though. Gemini is far behind from what I have tried so far.

We were working on the data powering the Xbox console frontend for searches. For example, the metadata that powers a search like "romantic movie". The data was stored in Azure tables. We were all thinking about backup strategies for the data, serialization and deserialization etc. My suggestion was to simply create timestamped copies of the table. That is, if the table was X, the backup would be X_2026-01-18-14-25-00. This required no serialization and deserialization, could run entirely in memory and could shard the processing and was brutally fast. Also, by distributing the copies across multiple regions we could be more reliable. A simple and dumb solution vs a complex one :)

Claude Code is very good; good enough that I upgraded to the Max plan this week. However, it has a long way to go. It's great at one-shotting (with iterations) most ideas. However, it doesn't do as well when the task is complicated in an existing codebase. This weekend I migrated the backend for the SaaS I am building from Python to .NET Core. It did the migration but completely missed the conventions that the frontend was using to call the backend. While the converion itself went OK, every user journey was broken. I am still manually testing every code path and feeding in the errors to get Claude to fix it. My instructions were fairly comprehensive but Claude still missed most of it. My fault that I didn't generate tests first, but after this migration that's my first task.

Created modfin.lyfbits.com. Wrote it to help me model and determine various types of investment scenarios. Continuing to work on it. Not strictly vibe-coded. I use a brainstorm -> write specs with Gemini (requirements, APIs, user journeys, user experiences etc.) -> ask Claude to implement from Specs -> iterate and refine until it is exactly what I want it to be.

I have found that the initial specs only go so far; as I use, "what's missing" becomes clearer.

Workflow is build -> checkin to git -> build container -> deploy to Cloud Run. I have a number of instructions for Claude for logs, frontend, backend, logging etc. based on my past experience. Note that I am mostly a backend developer (AWS, Azure, GCP); I can't code frontend to save my life and on that front, the agents are helping me realize ideas rapidly.

I believe the reason for divesting from the registrar business had to do more with ICANN rules that require Google not both be a registry operator and a registrar. Google does have a large registry business with 60+ TLDs so they could not also be a registrar (even if not for the same TLDs). It wasn’t really a money thing AFAIK.