In my experience at the begining of the full agentic coding loop in our company we were more hands on with the codebase and had better judgement over the plans. Now it is quite often that the inital plan after executed needs more refinement and that made the plan review somewhat obsolete for us.

Same is for things like asembly there are still people who need to edit that, but most of us are working with the higher-level programming languages.

If it was otherwise outsourcing companies would've dominated the market for a long time, but it is with the exp from clients and many users that you get to build a great product.

It takes a lot of time to understand what is the pain of the user, in many cases we know what the problem is but we have not time to think of a good solution to it.

I think a lot of product development happens in the itearations after the intial prototype/MVP and so on. It is not only the technical aspect to it, you need to spend time on a problem deeply understand what are the root causes of pains and address them in your product, both from UX and also from technical perspective.

People were able to "prompt" a product even before to an outsourcing company, but they'd rather pay the fee to a product company because of the expertese they have gained through out the years and all the users they've spoken to.

Otherwise what I have found is that the LLM will add a new if statement which will handle the newly discovered issue and you start stacking them ifs. As the article mentions LLM's unlike humans aren't lazy, they will copy, paste add patches for every issue, why bother think and understand root cause :d.

So as part of our review we have a rule against that as well.

At least give me the article ffs.

Wanted to dive and see what ClaudeCode is all about, so visualized it. You can run it locally from our fork: https://github.com/CodeBoarding/claude-code

We are open-core: https://github.com/CodeBoarding/CodeBoarding

Interested to hear what is something you didn't expect, for my 2 minute check I saw there are Computer-Use capabilities baked into it, however I've never observed that behavior in my usage. Probably not enabled by default.

Really like the article I think it is awesome, and I strongly believe AI for coding will stay, but I also beleive that we need to still have a strong understanding of why we are building things and what they look like.

Curious to hear what other think about that - should you leave people focus only on their strong sides, or they should still help out with e2e things.

This is why we've been building CodeBoarding - visualizing your codebase with a diagram so you can quickly understand and navigate the codebase. Now you can just copy a component and paste it as context for your agent so it knows where to work. The analysis agent for the diagram creation is open-source you can find it here: https://github.com/CodeBoarding/CodeBoarding

I would love to hear your opinion on vibe coding for larger projects, how do you navigate the context selection? Further what kind of guardlines are you using, we are thinking of adding guardrail which makes most of the files readonly so your agent (cursor, claude code, etc.) cannot delete/edit them.

Looking forward to chatting with you all, Ivan

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

Points: 2

# Comments: 0

Our project is technology specific so we share only with the relevant communities, started with python. Now we added support for TypeScript and so posted at few subreddits relevant to type-script. We got a lot of up-votes there, currently the hottest post on vuejs, however no stars on github.

I was wondering does this mean that people actually don't care, as it seems they up-vote but don't really check the project. A question for all open-source people, how do you measure these different sources of traction as I also got nice discussions under the posts. Is it that the profile of people who star repositories is very different from those who are just kind of interested but do not really about the open-source aspect?

I also thought it could be as the repo is written in Python and TypeScript people don't like that. This is our project, maybe also we don't put enough effort in the readme: https://github.com/CodeBoarding/CodeBoarding

Looking forward to hear what you would suggest and your general opinion on the topic!

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

Points: 1

# Comments: 2

But comparing the control-flow-graph probably makes more sense for a big refactor commits, as it might blow the context. However so far we haven't seen this be an issue.

Curious to hear what was your approach when building diagram represnetation!

Alex and I are devs, and we've noticed that recently we've been super productive at writing code (prompting :D). But when it comes to understanding big systems, prompting doesn't work that well — for that, diagrams are best imo. Most tools out there don't scale to big projects (e.g. PyTorch), so we're building CodeBoarding — a recursive visualizer for codebases. It starts from the highest level of abstractions and lets you dive deeper. We use static analysis and LLM agents. The control-flow graph is our starting point, and we validate the LLM's analysis against the static analysis output. LLMs alone often hallucinate or apply familiar architectural patterns that don't actually exist in the code.

Since this is a concise representation of a codebase, we also added an MCP-server to provide our docs for the libs your project depends on — reducing hallucinations and avoiding blowing up the context window. The vision: With agents writing more and more code, we think we also need a concise representation for it — diagrams. But for that to work, the diagrams have to be accurate, and that's why static analysis has to take part in the fun ;d.

Would love to hear what you think about diagram representations for code, what problems you've run into with hallucinations while vibe-coding (even with tools like gitingest/context7), and any general feedback :)

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

Points: 6

# Comments: 2

I’m Ivan, and I’ve developed ToolFuzz – an Agent Tool Fuzzing framework as part of my thesis (with the help of my advisors). I really wanted ToolFuzz to be a tool for people to use and so it is available as an open-source library for everyone to use. The repository can be found on github - https://github.com/eth-sri/ToolFuzz

What ToolFuzz does? ToolFuzz detects two types of errors in agent tools:

1. Runtime failures – Using taint analysis and fuzzing, ToolFuzz generates problematic arguments that trigger exceptions. Using those args then we use LLMs to generate prompts which might lead to problematic tool invocations.

2. Correctness failures – Generating synonymous prompts and validating consistency in the tool return values and the agent's responses. If results are inconsistent, that’s a strong signal of a correctness issue.

Would love to hear your feedback on this!

My Background:

Hey all, I am a master student studying Machine Intelligence in ETH Zurich. I have always been super interested in software testing/programming languages/software engineering and for the last two years AI/ML/AI Agents. When it came time to do my thesis I wanted to do something related to testing and AI agents as they are the hype at the moment (I am also super hyped about agentic systems in general). This said I found a super cool topic - testing agent tools. You see at the moment there are a bunch of benchmarks, but no real testing framework as this is more of a software engineering topic (my guess), which made it perfect for me. I wanted to do something which is more applied and can be useful for people who build actual software and less of a pure research. So this is why and how ToolFuzz was made.

I hope you’ll try it out and share your feedback! My goal is for this to be more than a scientific paper/thesis, but a tool that’s genuinely useful to people. All feedback is greatly appreciated – this is my first time releasing something for others to use, and I’m really excited to interact with everyone!

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

Points: 1

# Comments: 0