jmvldz

The explore step with Codex-5.3-Spark and Opus 4.6 Fast both feel incredible.

I don’t have much in the way of tests right now but I am building with Typescript and Rust so that catches many basic bugs.

I don’t find the issue to be breaking other parts of the app, more-so that new features don’t work as advertised by Claude.

One of my takeaways here is that I should give Claude an integration test harness and tell it that it must finish running that successfully before committing any code.

Interesting. I had not thought about a code review sub agent. I will give that a shot.

Haha fair enough. Fixed!

I'm trying to prototype extremely quickly and I'm working on my project alone so yes, often I accept PRs without looking too closely at the code if my local testing succeeds.

I'm using Typescript and Rust and I think it's critical to use strict typing with LLMs to catch simple bugs.

I've worked at Uber as an infra engineer and at Gem as an engineering manager so I do consider myself an "actual professional developer". The critical bit is the context of the project I'm working on. If I were at a tech company building software, I'd be much more reticent to ship AI generated PRs whole cloth.

I don't have a ton of tests. From what I've seen, Claude will often just update the tests to no-op so tests passing isn't trustworthy.

My workflow is often to plan with ChatGPT and what I was getting at here is ChatGPT can often hallucinate features of 3rd party libraries. I usually dump the plan from ChatGPT straight into Claude Code and only look at the details when I'm testing.

That said, I've become more careful in auditing the plans so I don't run in to issues like this.

Ooh, that's a good title for another post! And yes, I agree with you.

Initially I would barely read any of the code generated and as my project has grown in size, I have approached the limits of that approach.

Often because Claude Code makes very poor architectural choices.

100% yes. QA'ing a bunch of LLM generated code feels like a mental flood. Losing that mental rest is a great way to put it.

"It isn't like programming. It is its own thing."

You articulated what I was wrestling with in the post perfectly.

Ah interesting. I wonder if it's similar with Devin users.

I agree the branching sounds super cool!

Coding agents are the future and it's anyone's game right now.

The main reason I think there is such a proliferation is it's not clear what the best interface to coding agents will be. Is it in Slack and Linear? Is it on the CLI? Is it a web interface with a code editor? Is it VS Code or Zed?

Just like everyone has their favored IDE, in a few years time, I think everyone will have their favored interaction pattern for coding agents.

Product managers might like Devin because they don't need to setup an environment. Software engineers might still prefer Cursor because they want to edit the code and run tests on their own.

Cursor has a concept of a shadow workspace and I think we're going to see this across all coding agents. You kick off an async task in whatever IDE you use and it presents the results of the agent in an easy to review way a bit later.

As for Void, I think being open source is valuable on it's own. My understanding is Microsoft could enforce license restrictions at some point down the road to make Cursor difficult to use with certain extensions.

Another YC backed open source VS Code is Continue: https://www.continue.dev/

(Caveat: I am a YC founder building in this space: https://www.engines.dev/)

This is cool! I like that you have a visual element for the agent working on multiple tickets at a time.

Very cool! Love the demo.

have you looked at Browser Use? https://browser-use.com/

I see what you mean. So do you think a pure tutorial would have been better?

This is our first HN post so I was trying to strike a good balance between talking about what we think the future will look like and briefly mentioning what we're up to.

I could definitely have kept it to a tutorial, though, and saved the plug for what we're building for a later Show HN or Launch HN.

Ooh, fair point. Did it feel less compelling because we didn't mention that at the top?

Wow, the inference is insanely fast. This is amazing.

I think a much clearer argument would be: 'Developers want great tools. JavaScript has too many tools which induces the paradox of choice. A better tool might replace JavaScript in the future because of this.'

I personally am developing applications with minimal JavaScript a la Pinboard.

You can do much of this with Fabric, specifying remote and local hosts. Cool piece of code though.

I’ve spent the last 3 1/2 years working on a computer science degree from Stanford. In the past year, I cannot think of a time my understanding of the concepts mentioned in the article provided me a particular advantage in my programming work. That time includes a research position, an internship at VMware, an internship at Nicira (bought by VMWare), a self-initiated Unix course, a TAship in networking and a few quarters teaching introductory computer science in the CS 198 program.

I found this article intentionally contrarian for no useful purpose. Gayle, the founder of Career Cup cited at the end, runs a business grooming programmers to work at large companies (see her book 'The Google Resume'). Google and other large software companies are notorious for asking puzzle questions. Jeff Atwood, founder of Stack Overflow, has repeatedly expressed a hate for these questions. I've bought one of Gayle's books. It was well-written and helpful. However, I assume most programmers starting with Codeschool, Lynda and others are just dipping their feet into the world of software not shooting for working at Google tomorrow.

Mastery of computer science concepts is important in the long term. But as a 'long-term' programmer (~2 years of serious programming), I have yet to implement my own complex data structures in production use beyond simple JSON objects. Libraries simply abstract most of these problems efficiently enough for most work.

I read a comment recently stating 'the best programmers don't need frameworks'. Of course! The best produce frameworks themselves! And more importantly, the best produce frameworks, languages, and tools to educate the next generation of programmers in best practices. (See zachgalant's comment above.)

For those of us in software, let us not challenge ourselves to achieve personal mastery and also to enable mastery and education for others.

My cofounder spent an entire year with this exact problem. He worked with one developer who dropped off the face of the earth, payed a designer for work, and otherwise busted his ass for an entire year after graduating undergrad. He worked at a pool while his peers went to work for the likes of McKinsey and Goldman.

Now, I and another technical cofounder are working with him. We also have designers and a potential new technical employee.

You are still in school. You have time.