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

Points: 2

# Comments: 0

But everything your harness looks at could be this. So the skills in your code base, the commands that you've added, the memories that were auto created, they all work towards improving or completely destroying your productivity.

And most of it is hidden. You hear people talk about this all the time where they'll be like, Oh, I use GSD or I use Superpowers and my results have gotten worse.

Your results might have gotten worse precisely because you use them (along with your memories and other skills).

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

Points: 2

# Comments: 0

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

Points: 2

# Comments: 0

I actually think that the harnesses which do end up building products, the harness will be the product.

As an example, I have a harness which I have my entire team use consistently. The harness is designed for one thing: to get the results I get with less nuanced understanding of why I get it.

Mind you, most of my team members are non-technical, or at least would be considered non-technical, two years ago.

These days, I spend most of my time fine-tuning the harness. What that gives me is a team which is producing at 5x their capacity from three months ago, and I get easier to review, more robust pull requests that I have more confidence in merging.

It's still a far cry from automating the entire process. I still think humans need to give the outcomes to even the harnesses to produce the results.

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

Points: 2

# Comments: 0

I originally put this in a plugin to share it with co-workers, friends, and family so that they could achieve similar results to what I was achieving without having to learn all the different whack-a-mole strategies to keep Claude in check.

This was especially helpful over the last week where making some surgical changes allowed me to maintain quality.

Interestingly, with Opus 4.7, I am seeing some degradation in the initial quality of code that the main agent produces, but by the time it goes through the process which has been defined in this structure, it does result in a shape which I've come to expect.

It does especially well with the review cycles and the quality of writing that it can produce.

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

Points: 1

# Comments: 0

One of the hard rules in my harness is that it has to provide a summary Before performing a specific action. There is zero ambiguity in that rule. It is terse, and it is specific.

In the last 4 sessions (of 4 total), it has tried skipping that step, and every time it was pointed out, it gave something like the following.

> You're right — I skipped the summary. Here it is.

It is not following instructions literally. I wish it was. It is objectively worse.

I have a pretty robust setup in place to ensure that Claude, with its degradations, ensures good quality. And even the lobotomized 4.6 from the last few days was doing better than 4.7 is doing right now at xhigh.

It's over-engineering. It is producing more code than it needs to. It is trying to be more defensible, but its definition of defensible seems to be shaky because it's landing up creating more edge cases. I think they just found a way to make it more expensive because I'm just gonna have to burn more tokens to keep it in check.

Ask claude code to give you all the memories it has about you in the codebase and prune them. There is a very high chance that you have memories in there which are contradicting each other and causing bad behavior. Auto-saved memories are a big source of pollution and need to be pruned regularly. I almost don't let it create any memories at all if I can help it.

Disclaimer: I'm also burning through usage very quickly now - though for different reasons. Less than 48 hours to exhaust an account, where it used to take me 5-6 days with the same workload.

Good design is not always logical. Color theory, if followed, results in pretty bad experiences. And interestingly, good design can't always be explained in a natural language.

Main thing is, it's very hard to get AI to have taste, because taste is not always statistically explainable.

The best I've gotten to is have it use something like ShadCN (or another well document package that's part of it's training) and make sure that it does two things, only runs the commands to create components, and does not change any stock components or introduce any Tailwind classes for colors and such. Also make it ensure that it maintains the global CSS.

This doesn't make the design look much better than what it is out of the box, but it doesn't turn it into something terrible. If left unprompted on these things, it lands up with mixing fonts that it has absolutely no idea if they look good or not, bringing serif fonts into body text, mixing and matching colors which would have looked really, really good in 2005. But just don't work any more.

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

Points: 2

# Comments: 0

Engineers are still important. They're important in building the harness to ensure that anything which is being built/shipped is of sufficient quality.

In my opinion, testing/QA/etc is now the core product.

But the best code that you'll get is literally connecting to the pain point the customer was saying to the agentic workflow that is building your product.

Bad customer communication in my experience is the result of every person who handled the convo pre-engineers posturing the message trying to make sure the next person is motivated to get it to the next gatekeeper.

This is all very biased based on my own workflow though.

Entire job descriptions and functions were built to guard the engineer's time. Product owners, product managers, customer success, etc., all shielded the engineers who produced code because that was the scarcest resource.

With that scarcity gone, we really need to be thinking about the entire structure differently. I'm definitely in the we still need people camp. The roles are wildly different, though. We can't continue doing the same job that we did with a slight twist.

[0] https://dheer.co/gatekeeping-on-a-different-stage/

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

Points: 2

# Comments: 0

And as always, my first shot was how hard could it be to try and build a codec which could be that efficient.

I've personally been on a drive to improve my ability to one-shot complex features, products, or make even surgical changes. It's been a few months since I've been doing that, and honestly, results have been great for both work and work/life balance.

This was a fun experiment. It burned through tokens, but it helped me identify some more improvements I could make to my one-shot agent teams/swarms, notably in the area of brevity and creating a testing rubric when dealing with domains I don't have prior knowledge in.

Ultimately, I did not achieve the compression that I hoped I would, but it was fun seeing the swarm discuss it amongst themselves.

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

Points: 9

# Comments: 3

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

Points: 2

# Comments: 0

Something I've been doing in my own organization, but also trying to help other organizations with, is getting engineers closer to the customers now that building and the time it takes to build is no longer the resource, which is scarce.

Docs written by agents almost always produce mediocre results.

[0] https://news.ycombinator.com/item?id=47579977

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

Points: 19

# Comments: 11