I've been using LLM code agents since the Gemini CLI announcement seven months ago (https://news.ycombinator.com/item?id=44376919). My workflow is centered around Emacs and the terminal, so I skipped Cursor and other GUI-based tools. I'm not sure I would've taken the time to try agents at all if Gemini CLI hadn't been free initially.

While Gemini was a good start, subscribing to Claude Code completely changed how I work.

However, I was surprised to find that the new Codex CLI works incredibly well. It offers a terminal interface that doesn't make my fans spin up or render at single-digit FPS, unlike Claude Code. It also supports other TUIs like OpenCode.

So far, I'm pleasantly surprised, and you may be too.

Comments URL: https://news.ycombinator.com/item?id=46870868

Points: 6

# Comments: 1

The next generation of Calcapp probably won't ship with a built-in LLM agent. Instead, it will expose all functionality via MCP (or whatever protocol replaces it in a few years). My bet is that users will bring their own agents -- agents that already have visibility into all their services and apps.

I hope Calcapp has a bright future. At the same time, we're hedging by turning its formula engine into a developer-focused library and SaaS. I'm now working full-time on this new product and will do a Show HN once we're further along. It's been refreshing to work on something different after many years on an end-user-focused product.

I do think there will still be a place for no-code and low-code tools. As others have noted, guardrails aren't necessarily a bad thing -- they can constrain LLMs in useful ways. I also suspect many "citizen developers" won't be comfortable with LLMs generating code they don't understand. With no-code and low-code, you can usually see and reason about everything the system is doing, and tweak it yourself. At least for now, that's a real advantage.

https://aistudio.google.com/app/prompts?state=%7B%22ids%22:%...

I spent years building a compiler that takes our custom XML format and generates an app for Android or Java Swing. Gemini pulled off the same feat in under a minute, with no explanation of the format. The XML is fairly self-explanatory, but still.

I tried doing the same with Lovable, but the resulting app wouldn't work properly, and I burned through my credits fast while trying to nudge it into a usable state. This was on another level.

I had a big backlog of "nice to have scripts" I wanted to write for years, but couldn't find the time and energy for. A couple of months after I started using Claude Code, most of them exist.

At one point, it generated a verbose formula and mentioned, off-handedly, that it would have been prettier had Calcapp supported LET. "It does!", I replied, "and as an extension, you can use := instead of , to separate names and values!") and it promptly rewrote it using our extended syntax, producing a sleek formula.

These templates were for various verticals, like real estate, financial planning and retail, and I would have been hard-pressed to produce them without Claude's domain knowledge. And I did it in a weekend! Well, "we" did it in a weekend.

So this development doesn't really surprise me. I'm sure that Claude will be right at home in Excel, and I have already thought about how great it would be if Claude Code found a permanent home in our app designer. I'm concerned about the cost, though, so I'm holding off for now. But it does seem unfair that I get to use Claude to write apps with Calcapp, while our customers don't get that privilege.

(I wrote more about integrating Claude Code here: https://news.ycombinator.com/item?id=45662229)

However, it's becoming clear to me that individual apps and websites won't have their own integrated chatbots for long. They'll be siloed, meaning that they can't talk to one another -- and they sure can't access my file system. So we'll have a chatbot first as part of the web browser, and ultimately as part of the operating system, able to access all your stuff and knowing everything about you. (Scary!)

So the future is to make your software scriptable -- not necessarily for human-written scripts, but for LLM integration (using MCP?). Maybe OLE from the nineties was prescient?

Short-term, though, integrating an LLM would probably be good for business, but given that I'm our only engineer and the fact that our bespoke chatbot would likely become obsolete within two years, I don't think it would be worth the investment.

What I'm building is a formula engine that validates, compiles, and evaluates Excel-like formulas. Compared to GoRules, it’s more akin to the ZEN expression language component than to the broader GoRules system.

This is a wheel I see people reinventing all the time, often for use in SaaS applications. The implementations are often underwhelming: function support is limited, documentation is sparse to non-existent and errors are typically only communicated at runtime -- if at all. Formula editors usually lack autocomplete, making them frustrating to use.

I've spent years solving all these problems (with a statically-typed language), and I'd love for others to benefit from the work. I have extracted the formula engine from our app compiler, so the library is nearly complete. The runtime part (evaluating formulas) has been rewritten in TypeScript. Next, I'll build a service around it to validate, compile and evaluate formulas -- which should be fun.

I'm planning to do a Show HN once I have a preview up and running.

I was told that Firefox is no longer supported by a support technician over the phone. A different support technician wrote this to me in an email:

"Regarding the printing option on Firefox, I'm afraid this is no longer within Stripe's support scope."

(I complained that it is not possible to print certain pages of the Dashboard through Firefox, while Chrome works acceptably well.)

Obviously, Firefox's market share isn't what it used to be. However, Stripe has always cultivated an image of being developer-friendly, and Firefox remains popular with developers. Is not supporting Firefox a reasonable position for Stripe (and other sites popular with developers) to take?

Discuss.

Comments URL: https://news.ycombinator.com/item?id=41487862

Points: 65

# Comments: 33

1779900

So back in the day, these were known as Universal Internet Numbers, or UINs. You have to admire the sheer audacity of using that name for the user identifiers of a service you're building. I believe they were renamed to "ICQ#" later.

With my own business, I gain agency. If the product fails, it's because I failed to market it properly, or the product vision was bad and did not resonate with enough customers, or because I failed to execute on that vision. When all the decisions are out of your hands, and you can't even see what prompted them, they can feel capricious and arbitrary.

With my own business, I am in control. I don't have one boss, I have hundreds of them. And as long as I continue to provide them with value, I get to continue doing what I'm doing. I like those terms.

I then rebooted my software project, launched a landing site and started talking to prospects (hundreds of them), before I set out to pivot my existing product to something that might gain traction. (I wound up throwing away 95 percent of the code.) I spent 2014 through 2019 with the product in beta, barely making a living off of a few enterprise support contracts and doing freelance photography (and depleting my savings), but spending at least 80 percent of my time on building the product and getting it to a finished state.

(Some people seem to be able to build a product in a weekend that gets eager customers. I'm not one of those people, choosing to build something that was, in retrospect, much too big of a project for one person. I probably also spent too much time polishing the product before commercializing it, likely due to a fear of failure.)

In 2019, the product was finally commercialized as a SaaS service. I remember thinking that I either wanted it to be a spectacular success, or a spectacular failure (so that I could focus on other things, after close to 20 years).

It was neither, but has been growing steadily ever since. I would have made much more money working for someone else, but the freedom is unparalleled. I get to set my own hours and focus on things I consider important. I enjoy doing everything from support calls and UX work to building a compiler and a type system (that I have mentioned before on HN).

I also have no one I need to answer to, other than our customers. That has been important over the past couple of years, when a series of health emergencies in my family has diverted my attention elsewhere. I have been very fortunate to be able to do so, focusing on what's important, without having to ask permission to cut down on work temporarily.

Overall, I wouldn't trade this for anything. This year, my product will gain a sister product in a more lucrative field (I'm hoping), and I have plans to commercialize my compiler, both as a service and as a traditionally-licensed library. So I'm excited to stay solo and keep working on building the business.

Comments URL: https://news.ycombinator.com/item?id=38199127

Points: 2

# Comments: 0

Also, if this does becomes a problem, we can just stop releasing new versions publicly, at which point the competitor's offering would stagnate, while our offering would continue to improve.