About Me: Pre-AI era Software Product Engineer with a proven track record of delivering high-quality software. I am adept at LLM tools and frameworks. I love Claude Code. I am quick to onboard, fast to learn new tech, and I value transparency, maintainable code and open communication.
~$250 in 3 weeks at work. Its not steady, equal token distribution per day. There are days when it is $40 and there are days when it is < $10. Mostly due to bottlenecks like waiting on reviews, figma designs, story refinement, etc.
(Sidebar: There is a prediction that the traditional roles of Designer, Product Owner and Programmer are disappearing and converging into one single specialized role. (Claude Code has a blog about this) and I feel there is truth in this.)
So, my runrate right now is ~$4,200 per year, but I won't be surprised if it goes up. It depends on several factors.
> If you've recently used AI tools for professional coding work, tell us about it.
POCC (Plain Old Claude Code). Since the 4.5 models, It does 90% of the work. I do a final tinkering and polishing for the PR because by this point it is easy for me to fix the code than asking the model to fix it for me.
The work: Fairly straightward UI + backend work on a website. We have designers producing Figma and we use Figma MCP to convert that to web pages.
POCC reduces the time taken to complete the work by at least 50%. The last mile problem exist. Its not a one-shot story to PR prompt. There are a few back & forths with the model, some direct IDE edits, offline tests, etc. I can see how having subagents/skills/hooks/memory can reduce the manual effort further.
Challenges:
1) AI first documentation: Stories have to be written with greater detail and acceptance criteria.
2) Code reviews: copilot reviews on Github are surprisingly insightful, but waiting on human reviews is still a bottleneck.
3) AI first thinking: Some of the lead devs are still hung up on certain best practices that are not relevant in a world where the machine generates most of the code. There is a friction in the code LLM is good at and the standards expected from an experienced developer. This creates busy work at best, frustration at worst.
4) Anti-AI sentiment: There is a vocal minority who oppose AI for reasons from craftsmanship to capitalism to global environment crisis. It is a bit political and slack channels are getting interesting.
5) Prompt Engineering: Im in EU, when the team is multi-lingual and English is adopted as the language of communication, some members struggle more than others.
6) Losing the will to code. I can't seem to make up my mind if the tech is like the invention of calculator or the creation of social media. We don't know its long term impact on producing developers who can code for a living.
Personally, I love it. I mourn for the loss of the 10x engineer, but those 10x guys have already onboarded the LLM ship.
I feel there is a set of codebases in which LLMs aren't showing the 2-10x lift in productivity.
There is also a set of codebases in which LLMs are one-shotting the most correct code and even finding edgecases that would've been hard to find in human reviews.
At a surface level, it seems obvious that legacy codebases tend to fall in the first category and more greenfield work falls in the second category.
Perhaps, this signals an area of study where we make codebases more LLM-friendly. It needs more research and a catchy name.
Also, certain things that we worry about as software artisans like abstractions, reducing repeated code, naming conventions, argument ordering,... is not a concern for LLMs. As long as LLMs are consistent in how they write code.
For e.g. One was taught that it is bad to have multiple "foo()" implementations. In LLM world, it isn't _that_ bad. You can instruct the LLM to "add feature x and fix all the affected tests" (or even better "add feature x to all foo()") and if feature x relies on "foo()", it fixes every foo() method. This is a big deal.
I mean, can you expect a vibecoding company to do stuff with 0 downtime? They brought the models down and are now panicking at HQ since there's no one to bring them back up
This made me laugh only because I imagine there could possibly be some truth to it. This is the world we are in. Maybe they all loaded codex to fix their deploy? ;)
Coming from a Gsuite + Atlassian + AWS world to an all-inclusive Microsoft world was an experience. It should be in the bucket list for every developer to try once in their life.
WSL is a far better developer environment in Windows even for dotnet based development. I use it at work. It is fine.
Windows OS on the other hand is a mess. There are dedicated keyboard shortcut (win + c), keyboard buttons, buttons on desktop for copilot. Copilot is almost on every Microsoft software. I'm not getting the appeal of copilot at all.
Also, I have a personal gripe with a non-standard way of placing the Fn key - first of all, why keep it close to Ctrl, why? and on top of that, Lenovo & Microsoft and every other manufacturer have them in different positions on the keyboard.
FWIW; Every Lenovo I've used in recent history had a setting in the BIOS to remap Fn/Ctrl.
On my assigned machine, I have it swapped so Ctrl is in the lower left spot because otherwise I'd lose my mind trying to figure it out between all the machines I swap through. (Emacs users will have to use something else to put Ctrl where they want ....)
- Launch my own hand-rolled paper trading solution by mid to late 2026. I want to focus on strategies that prevents heavy losses, rather than actively looking for profits. If I succeed, go live in 2027.
- I hope to complete 3 semesters with a B or above in the ongoing Online Masters Degree program I've enrolled for.
- Do more coding with AI.
- Be prepared for job interviews - even though I have no plans to change jobs. This year my rustiness and lack of interview readiness has cost me "dream jobs" (from my POV)
Non-technical skills:
- The usual. Lose weight, eat mindfully, gain strength, learn the language of my country.
I am not and I don't actively plan on becoming one (if it "happens", then so be it).
1. I'm full time remote employee now and I am not fully onboard with it. I don't plan to retire as a remote worker. I want to work in office again - in some form.
2. WLB is a valid factor. It is a sad reality that we need to talk about this in 2022.
3. I guess here you meant to say that the company won't go under before you retire, which makes sense.
4. Avoiding interviews is one of the weaker excuses to stick to one company. It puts you at risk if stuff hits the fan. Always be looking. This is not a critique of the interivew process, but you need to play the game.
5. Job market is another weak example. If you plan to be a lifer, you _want_ a strong job market, otherwise your job will be at risk.
6. Ageism. Surely ageism is going to be a big topic very soon if not already?
The tech-boom went mainstream in mid to late 2000s. Those who benefited from that wave are already in their mid-30s now and by mid 2020s they will fit the criteria for ageism. I am hoping this gets talked about more by then at least.
7. I heard somewhere that "the top company in X years time hasn't been established yet." I believe there will be new opportunities.
Other reasons that might influence becoming a Lifer:
1. Arcane knowledge of internal systems.
2. Specialization: Too old/reluctant/afraid to specialize in ML/AI/web3/...
3. You're a superstar coder/10X Engineer/Charismatic Leader/...
I have around 25 years of career left (with retirement age in mid 60s). It feels too risky to say I would stick to one company for life, even if it is _insert-your-dream-company_.
Remote: Yes
Willing to relocate: Yes (EU & US)
Technologies: Python, TypeScript, Java, GCP, Ruby, Node.js, SQL, Cassandra
CV: https://docs.google.com/document/d/1GKI7JDAdrAUpGpsmnMdzJWso...
Email: damodaran.balaji [at] gmail [dot] com
About Me: Pre-AI era Software Product Engineer with a proven track record of delivering high-quality software. I am adept at LLM tools and frameworks. I love Claude Code. I am quick to onboard, fast to learn new tech, and I value transparency, maintainable code and open communication.
reply