Comment by steve_adams_86 | Hacker News Reader

Comment by steve_adams_86 | Hacker News Reader

Watching the examples and other people's demos, I get the sense that this product completely ignores what makes good software. It has no "big picture" plan or contextual awareness required to make those nuanced yet critical decisions in the far ends of applications. Those cases where you badly need domain expertise, understanding of how the user interfaces with the product, awareness of existing technical debt, and so on.

The scope it can assist in is too limited. It is exactly the kind of thing I'd use to generate self-destructing spaghetti. The thing is, people with less experience will eat this up because it can do some tasks with ease which might not be familiar to them yet. Over time, the code they produce will be a mine field of incongruent patterns and solutions.

It appears to support the hypothesis that these tools may actually create more work, but I worry that the work will be much like that created by outsourced developers shipping duct-taped nonsense back to North America throughout the last 20 years or so.

And, on top of that, the first few fixes will actually work! They will look good to PMs and to the business! Look at the velocity!

The velocity is good enough to scale back the size of the team, it's good enough to mandate a pace that is only possible with AI doing automated submission and review of PRs, it's good enough to not have any kind of formal design work. Just ship.

After several months of this, any additional bug fix by the AI is just adding to the existing morass of tech debt created by the AI. Slowly but surely, the AI will stop being able to submit a PR that doesn't result in a regression. The people who actually care about software quality aren't on new projects; those are run by juniors and copilot. Nope, they're going to be stuck on maintenance of this garbage.

And meanwhile, that new team working on new feature X is moving so quickly... better give them a raise!

The people who suffer here are, of course, the non-marginal user, who will have to contend with every new feature breaking every other existing feature that they like in the software.

That hasn't been our experience using it in-house! It's not perfect, but not every software engineering task is some galaxy-brain architectural shit. Sometimes, you have to lay down some bricks. And sometimes, to lay down bricks, you need to touch more than one tiny patch of code.

Having something round up the likely areas of the codebase that needs touching feels magical. It doesn't always succeed! But it feels pretty magical to get that boost when you're new to some part of a codebase (which, real talk, code I wrote > 1 month ago, I must page back into memory).

Making it easy for me to progressively add context for the model is an accurate analogue for how I think as a developer when tackling a task. I have to build a mental model of how things work. And then a plan for how I'm going to change it.

Maybe for the kinds of tasks you usually tackle, it won't have value. But the amount of context it's attempting to bring to bear on whatever task you give it is categorically more — and better — than any other tool I've seen. I have seen (and been the author of) spaghetti. Could I make CW generate spaghetti? Surely. That's why it's a tool for developers, not a substitute for developers.

A part of building great products is allowing your engineers to focus on things that really matter. But sometimes you need to change copy, add small features, from my experience with some of these tools, it is incredible. A PM can just create a repo issue, and the bots will go away with high accuracy and quality (if your codebase is setup well), and submit a PR.

This level of velocity for teams cannot be understated.

A lot of software doesn't need to be good. I could see using this to prototype internal tools fast.

Also, it doesn't need to be good yet - whoever has the best tooling infrastructure when the models get better will win.

Reply on news.ycombinator.com