stpedgwdgfhgdd

Compact the conversation (CC)

This is the dream, but we are not yet there. For any reasonable complex code base, CC needs guidance, like avoiding duplicate code/use library function. Write more tests. Sometimes there is a much more elegant solution for a problem. Claude will find it, but you need to hint and ask.

If people use Claude without a critical eye, our code bases will grow immensely.

Pro was not sufficient when i started to: Use git worktrees, type every command in plain english in CC.

For example “commit and push”

In my experience using small steps and a lot of automated tests work very well with CC. Don’t go for these huge prompts that have a complete feature in it.

Remember the title “attention is all you need”? Well you need to pay a lot of attention to CC during these small steps and have a solid mental model of what it is building.

In my experience for enterprise software engineering, in this stage we are able to shrink the coding time with ~20%, depending on the kind of code/tests.

However CICD remains tricky. In fact when AI agents start building autonomous, merge trains become a necessity…

Just asked CC to create a work tree and branch. (Space was a typo) What did it do? Just a branch…

You cant trust LLMs for 100%, constant supervision is needed

I asked Chatgpt whether this was a joke. And asked Claude and Le chat for confirmation.

There is a trend to write tools on the spot. Should be easy, right?

So during a big Go refactoring I asked Claude to write a python script to do some renames. I hoped it would be faster, more reliable and save some tokens.

Well that was a rabbit hole. I quickly reverted and let CC do it the old way. Hype vs reality.

Still on my list to experiment with CC and Go’s AST tools to tryout refactorings.

+1. Some refactorings are important but just not urgent enough compared to features. Letting CC do these refactorings makes quite a difference.

At least in the case of lot of automated test coverage and typed language (Go) so it can work independently efficiently.

It definitely takes a lot of experience writing code with a LLM. Like a junior engineer it makes tons of (small) mistakes. It takes years of practice to detect the LLM is introducing small bugs that will reveal themselves only after extensive testing or running in prod.

It will be interesting to see how beginning developers will deal with these bugs as they did not write the code and do not have a mental model of the code. Will quality drop? Perhaps some can be compensated by letting the LLM do extensive testing.

“The goal of software engineering is not to write code faster”

Writing proper code including tests and refactorings takes substantial time.

It is definitely worth it to do this faster, if only to get faster feedback to go back to the first phase; requirements and analysis.

I have experienced this myself, using CC it took me a few hours less to realise i was on the wrong track.

I do something similar, but the problem is that claude.md keeps on growing.

To tackle this, I converted a custom prompt into an application, but there is an interesting trade-off. The application is deterministic. It cannot deal with unknown situations. In contrast to CC, which is way slower, but can try alternative ways of dealing with an unknown situation.

I ended up with adding an instruction to the custom command to run the application and fix the application code (TDD) if there is a problem. Self healing software… who ever thought

Just a matter of time before AI coding becomes commodity and prices drop. 2027

Pro is fine for medium sized projects, stick to 1 terminal.

“We typically making very very detailed plans” - this is writing code in English without tests. Admittedly, since generating code is faster, you get faster feedback. Still, I do not think it as efficient as an incremental, test driven approach. Here you can optimize early on for the feedback loop.

Probably worth it as most people read HN on tablet or phone.

What is potentially a problem is the lack of training material for AI agents to generate games on top of this platform.

I noticed that i hardly look anymore at the generated Go code… I do give a lot of attention to the tests. I let CC write some failing tests, implement. Let it run against some real scenarios. Find bugs, let it write more tests, fix. And iterate.

Writing this I realise, i should more clearly separate the functional tests from the implementation oriented unit tests.

Same experience. One terminal window with Pro is okay. Multiple CC running in parallel not.

We most likely implement a policy that starters in our company can use Pro. Power users need Max.

Use TDD so CC can converge. I see people tuning a prompt, that is fun, not software engineering.

(bit off topic, but I wished someone told me this a few months ago; for regular programming generation, use TDD and a type safe language like Go. (Fast compile times and excellent testing support). Don’t aim for the magical huge waterfall prompt)

I’m programming software development workflows for Claude in plain english (custom commands). The non-deterministic is indeed a (tiny!) bit of a problem, but just tell Claude to improve the command so next time it won’t make the same mistake. One time it added an implementation section to the command. Pretty cool

This is the big game changer: we have a programming environment where the program can improve itself. That is something Fortran couldn’t do.

When using a single terminal Pro is good enough (even with a medium-large code base). When I started working with two terminals at two different issues at the same time, i’m reaching the credit limit.

Another JS implementation…

I do not get it why they don’t pick Go or Rust so i get a binary.

Fwiiw

I noticed that CC’s generated Go code nowadays is very solid. No hallucination recently that i can remember or struck me. I do see youtube videos of people working with js/ts still struggling with this. Which is odd, there is way more training material for the latter. Perhaps the simplicity of Go shines here.

CC might generate Go code for which there are already library functions present. So thorough code reviews are a necessity.

Probably not a popular take on HN; valuable information should not be hidden in commits but in comments. Especially the WHY is crucial to write down in comments.

I’m fine that people squash as long the reasoning is recorded in comments and reflected through automated tests (unit AND system/api).

This is also crucial information for AI coding tools.

The recent developments are impressive. I’m now using my IDE as a diff viewer. Everything goes through the terminal. If there is an error, CC can analyse and fix it.

Still needs a lot of handholding. I do not (yet) think big upfront plans will suddenly start working in the enterprise world. Let it write a failing test first.

Don’t get fully the use-cases this tool solves except for some auto-accept.

You would also expect some eat-your-own-dog-food, why does https://github.com/possibilities/claude-composer/blob/main/s... not use CC with a prompt…

(Ps I left x/twitter a long time)

Bit of topic, but worth sharing;

Yesterday was for me a milestone, i connected Claude Code through MCP with Jira (sse). I asked it to create a plan for a specific Jira issue, ah, excuse me, work item.

CC created the plan based on the item’s description and started coding. It created a branch (wrong naming convention, needs fix), made the code changes and pushed. Since the Jira item had a good description, the plan was solid and the code so far as well.

Disclaimer; this was a simple problem to solve, but the code base is pretty large.

“This is unusual — did your boss ever have to send you a memo demanding that you use a smartphone?”

AI has the promise to optimize worker’s efficiency x-fold. This promise was not the case with smartphones, slack, etc.

And AI will change everyone’s work in years to come, especially for developers.

Suggestion: Integrate with https://kgateway.dev/