HackerTrans
TopNewTrendsCommentsPastAskShowJobs

anupshinde

no profile record

Submissions

[untitled]

5 points·by anupshinde·2개월 전·0 comments

I put Claude Code in a browser terminal I built in Go

anupshinde.medium.com
1 points·by anupshinde·2개월 전·0 comments

I built godom: Go owns the DOM and the browser is just a rendering surface

anupshinde.com
4 points·by anupshinde·2개월 전·2 comments

Show HN: Godom – a Go framework for local apps using the browser as the UI

github.com
2 points·by anupshinde·4개월 전·0 comments

How I Ported a Python Astronomy Library to Go with AI

anupshinde.com
2 points·by anupshinde·5개월 전·0 comments

Goeph: Go library for planetary positions, inspired by Python's Skyfield

github.com
2 points·by anupshinde·5개월 전·0 comments

ChartTypes

charttypes.com
1 points·by anupshinde·9개월 전·0 comments

comments

anupshinde
·20일 전·discuss
I did not say “humans are just as bad.” That is your assumption. I didn’t even say AI is bad. I use AI quite a lot.
anupshinde
·21일 전·discuss
When I write something heavily edited by AI - I mention that I use AI assistance (not AI led thinking). I will probably remove that because the perception is quite different. Its like applying one applying to an engineering job but write "a pychic, a medium" in a corner of their resume.

It is very common to see that any interesting thought gets immediately tagged like AI slop and the real AI slop wins. Try an A/B test and you shall see that AI actually wins because of the people who hate AI. Most people cannot distinguish between a human and a AI written post and yet those same people want to be judgemental. And the people who are against AI and say "its just the next token generator and I don't use it" and yet use autocomplete on their mobiles are just duplicit. And yes AI is the next-token-generator, we have no proof that most humans were not brainwashed to become the same.
anupshinde
·23일 전·discuss
> Vibe-coded software is simply not good.

That is simply not true. It can be better or it can be worse - depends on who directed it.

I understand where the point comes from, but someone who has coded and architected a lot of applications for many years, does get the good side. But a user who see code as an alien language - they are ultimately going to get the bad side of it.

There was a theory floated around by an youtuber (and a tech geek), on how to vibe code better - and how to let agents run the show. I tried, more than once - it failed badly. Not failed at the output or the UI - failed at writing good and well architected code.

> What happens when things go wrong

- this is the most important question - can the human step in?

For me the answer is a unequivocal yes. I may not be able to fix it in 10 minutes, but I know I will fix it in 10 hours or 100 hours - whatever it takes. But when a user who "can't read code" comes in - and asks me to fix their problem, it is going to cost them a lot more than their total subsidized vibe coding tool cost. They're going to be like - the app cost me 100-200$ to vibe-build, but the dev is going to charge me 5-10x for a 2 line fix.

For some the decision will be like - better buy a new phone than repairing the old one, for others - they can't replace things easily.

What used to take 1.5 years to build 10 years ago, and 6-9 months to build 5 years ago, takes 1.5 months or faster to build today (if it is done with the same rigor).

> The GDPR example

How is it different from having a human dev team hired? The CEOs or founders are responsible - they can't go and say "that dev did the wrong thing, fine them" - will you work for such a person?

> the belief that AI can — and will — displace white-collar jobs is a lie

It already is displacing, unfortunately. It has been taking apart both jobs and businesses - one role at a time - within 6 months of AI coming out. Some are experiencing it now, some have experienced it earlier, some will experience it later.

For example - a good tech guy in finance domain and having good domain knowledge - gets fired. After a while, he will end up competing for jobs in the finance domain - because he needs to survive. The domino effect will be seen. And hope it does not become a race to the bottom.

And new roles are likely to come up and stabilize - but the bar will be high and you will need AI all the time. Otherwise you will be seen like ploughing the farm by hand instead of using a tractor.
anupshinde
·지난달·discuss
Domain knowledge and architectural skills are not gone. I can say even Opus 4.7 and GPT 5.5 get domain-specific stuff wrong. I use both, because when I am not sure I ask both and also check with Gemini. But these days, I ask those even when I am sure - its like I get something confirmed from a peer. And yes, you have to be the gate keeper - the speed breaker in a way - LLMs still lack a lot of context. And even if they get more context, they will end up costing a lot and still have no accountability. In accounting, one wrong entry and the whole system can be seen as "unreliable" - thats why you are needed. The interesting part is "who takes over" - accountants who become coders, or coders who become accountants. And the latter looks more likely, in any profession. And when that happens - the bar will be raised in these other white-collar professions too, just like what happening in tech.

Opus is getting good at architecture - I need lesser "pushbacks" either because I have learnt to say the right thing or it has learnt to do the right thing - I do not know which one.
anupshinde
·3개월 전·discuss
Built/building godom, a framework that lets me build local apps in Go, with the browser serving as a dumb view layer. I don't hate JavaScript or React, but my primary motivation was to eliminate NPM as much as possible. https://github.com/anupshinde/godom I used AI to create the first POC, and once it was proven, it was improved, and AI handled a lot of grunt work where it could. The framework was built primarily to solve my pain points

And building Fractiz.com, a customizable pre-coded backtests platform.
anupshinde
·3개월 전·discuss
Built/building godom, a framework that lets me build local apps in Go, with the browser serving as a dumb view layer. I don't hate JavaScript or React, but my primary motivation was to eliminate NPM as much as possible. https://github.com/anupshinde/godom

I used AI to create the first POC, and once it was proven, it was improved, and AI handled a lot of grunt work where it could. The framework was built primarily to solve my pain points

And building Fractiz, a customizable pre-coded backtests platform.
anupshinde
·4개월 전·discuss
Just yesterday I had a moment

Claude's code in a conversation said - “Yes. I just looked at tag names and sorted them by gut feeling into buckets. No systematic reasoning behind it.”

It has gut feelings now? I confronted for a minute - but pulled out. I walked away from my desk for an hour to not get pulled into the AInsanity.
anupshinde
·4개월 전·discuss
Glad to see this. I was tired of seeing posts that are on the extremes - "death of software by AI" vs "AI can't do this and that".

I took a break from software, and over the last few years, it just felt repetitive, like I was solving or attempting to solve the same kinds of problems in different ways every 6 months. The feeling of "not a for loop again", "not a tree search again", "not a singleton again". There's an exciting new framework or a language that solves a problem - you learn it - and then there are new problems with the language - and there is a new language to solve that language's problem. And it is necessary, and the engineer in me does understand the why of it, but over time, it just starts to feel insane and like an endless loop. Then you come to an agreement: "Just build something with what I know," but you know so much that you sometimes get stuck in analysis paralysis, and then a shiny new thing catches your engineer or programmer brain. And before you get maintainable traction, I would have spent a lot of time, sometimes quitting even before starting, because it was logistically too much.

Claude Code does make it feel like I am in my early twenties. (I am middle-aged, not in 60s)

I see a lot of comments wondering what is being built -

Think about it like this, and you can try it in a day.

Take an idea of yours, and better if it is yours - not somebody else's - and definitely not AI's. And scope it and ground it first. It should not be like "If I sway my wand, an apple should appear". If you have been in software for long, you would have heard those things. Don't be that vague. You have to have some clarity - "wand sway detection with computer vision", "auto order with X if you want a real apple", etc.. AI is a catalyst and an amplifier, not a cheat code. You can't tell it, "build me code where I have tariffs replacing taxes, and it generates prosperity". You can brainstorm, maybe find solutions, but you can't break math with AI without a rigorous theory. And if you force AI without your own reasoning, it will start throwing BS at you.

There is this idea in your mind, discuss it with ChatGPT, Gemini, or Claude. See the flaws in the idea - discover better ideas. Discuss suggestions for frameworks, accept or argue with AI. In a few minutes, you ask it to provide a Markdown spec. Give it to Claude Code. Start building - not perfect, just start. Focus on the output. Does it look good enough for now? Does it look usable? Does it make sense? Is the output (not code) something you wanted? That is the MVP to yourself. There's a saying - customers don't care about your code, but that doesn't mean you shouldn't. In this case, make yourself the customer first - care about the code later (which in an AI era is like maybe a 30min to an hour later)

And at this point, bring in your engineer brain. Typically, at this point, the initial friction is gone, you have code and something that is working for you in real - not just on a paper or whiteboard. Take a pause. Review, ask it to refactor - make it better or make it align with your way, ask why it made the decisions it made. I always ask AI to write unit tests extensively - most of which I do not even review. The unit tests are there just to keep it predictable when I get involved, or if I ask AI to fix something. Even if you want to remove a file from the project, don't do it yourself - acclimatize to prompting and being vague sometimes. And use git so that you can revert when AI breaks things. From idea to a working thing, within an hour, and maybe 3-4 more hours once you start reviews, refactors, and engineering stuff.

I also use it for iterative trading research. It is just an experiment for now, but it's quite interesting what it can do. I give it a custom backtesting engine to use, and then give it constraints and libraries like technical indicators and custom data indicators it can use (or you could call it skills) - I ask it to program a strategy (not just parameter optimize) - run, test, log, define the next iteration itself, repeat. And I also give it an exact time for when it should stop researching, so it does not eat up all my tokens. It just frees up so much time, where you can just watch the traffic from the window or think about a direction where you want AI to go.

I wanted to incorporate astrological features into some machine learning models. An old idea that I had, but I always got crapped out because of the mythological parts and sometimes mystical parts that didn't make sense. With AI, I could ask it to strip out those unwanted parts, explain them in a physics-first or logic-first way, and get deeper into the "why did they do this calculation", "why they reached this constant", and then AI obviously helps with the code and helps explain how it matches and how it works - helps me pin point the code and the theories. Just a few weeks ago, I implemented/ported an astronomy library in Go (github.com/anupshinde/goeph) to speed up my research - and what do I really know about astronomy! But the outputs are well verified and tested.

But, in my own examples, will I ever let AI unilaterally change the custom backtesting engine code? Never. A single mistake, a single oversight, can cost a lot of real money and wasted time in weeks or months. So the engine code is protected like a fortress. You should be very careful with AI modifying critical parts of your production systems - the bug double-counting in the ledger is not the same as a "notification not shown". I think managers who are blanket-forcing AI on their employees are soon going to realize the importance of the engineering aspect in software

Just like you don't trust just any car manufacturer or just any investment fund, you should not blindly trust the AI-generated code - otherwise, you are setting yourself up to get scammed.
anupshinde
·5개월 전·discuss
If you were forced to choose just one of all the competing players, which is "the one" you will use?

For me, the choice is ChatGPT, not for its Codex or other fancy tooling - just the chat. Not that Claude Code or Cowork is less important. Not that I like Codex over Claude Code.
anupshinde
·5개월 전·discuss
I don't think software engineering is going to die. Coding, as we know it, is going to change a lot. Short-term pain, but in the long term, we are likely to see an explosion of software. Having said that, AGI could change things - but then every profession would be dead.

Check this out: https://www.youtube.com/watch?v=OfMAtaocvJw