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

Points: 4

# Comments: 2

A few things that come to my mind if I were to build this:

The 'Agent-User' Paradox: To make this work, you'd need the initial agents (the ones responding and testing the goals) to be 'chaotic' enough to explore edge cases, but 'structured' enough to provide meaningful feedback to the 'Architect' agent.

The Schema Contract: How would you ensure that as the backend "writes itself," it doesn't break the contract with the frontend? You’d almost need a JIT Documentation layer that updates in lockstep.

Verification: I wonder if the server should run the 'JIT-ed' code in a sandbox first, using the telemetry to verify the goal was met before promoting the code to the main branch.

It’s a massive shift from Code as an Asset to Code as a Runtime Behavior. Have you thought about how you'd handle state/database migrations in a world where the backend is rewriting itself on the fly? It feels to me that you're almost building a lovable for backend services. I've seen a few OS projects like this (e.g. MotiaDev) But none has executed this perfectly yet.

The hardest mental shift for us was treating Exceptions as Observations. In a standard Python script, a FileNotFoundError is a crash. In Hive, we catch that stack trace, serialize it, and feed it back into the Context Window as a new prompt: "I tried to read the file and failed with this error. Why? And what is the alternative?"

The agent then enters a Reflection Step (e.g., "I might be in the wrong directory, let me run ls first"), generates new code, and retries.

We found this loop alone solved about 70% of the "brittleness" issues we faced in our ERP production environment. The trade-off, of course, is latency and token cost.

I'm curious how others are handling non-deterministic failures in long-running agent pipelines? Are you using simple retries, voting ensembles, or human-in-the-loop?

It'd be great to hear your thoughts.

I’m Vincent from Aden. We spent 4 years building ERP automation for construction (PO/invoice reconciliation). We had real enterprise customers but hit a technical wall: Chatbots aren't for real work. Accountants don't want to chat; they want the ledger reconciled while they sleep. They want services, not tools.

Existing agent frameworks (LangChain, AutoGPT) failed in production - brittle, looping, and unable to handle messy data. General Computer Use (GCU) frameworks were even worse. My reflections:

1. The "Toy App" Ceiling & GCU Trap Most frameworks assume synchronous sessions. If the tab closes, state is lost. You can't fit 2 weeks of asynchronous business state into an ephemeral chat session.

The GCU hype (agents "looking" at screens) is skeuomorphic. It’s slow (screenshots), expensive (tokens), and fragile (UI changes = crash). It mimics human constraints rather than leveraging machine speed. Real automation should be headless.

2. Inversion of Control: OODA > DAGs Traditional DAGs are deterministic; if a step fails, the program crashes. In the AI era, the Goal is the law, not the Code. We use an OODA loop to manage stochastic behavior:

- Observe: Exceptions are observations (FileNotFound = new state), not crashes.

- Orient: Adjust strategy based on Memory and - Traits.

- Decide: Generate new code at runtime.

- Act: Execute.

The topology shouldn't be hardcoded; it should emerge from the task's entropy.

3. Reliability: The "Synthetic" SLA You can't guarantee one inference ($k=1$) is correct, but you can guarantee a System of Inference ($k=n$) converges on correctness. Reliability is now a function of compute budget. By wrapping an 80% accurate model in a "Best-of-3" verification loop, we mathematically force the error rate down—trading Latency/Tokens for Certainty.

4. Biology & Psychology in Code "Hard Logic" can't solve "Soft Problems." We map cognition to architectural primitives: Homeostasis: Solving "Perseveration" (infinite loops) via a "Stress" metric. If an action fails 3x, "neuroplasticity" drops, forcing a strategy shift. Traits: Personality as a constraint. "High Conscientiousness" increases verification; "High Risk" executes DROP TABLE without asking.

For the industry, we need engineers interested in the intersection of biology, psychology, and distributed systems to help us move beyond brittle scripts. It'd be great to have you roasting my codes and sharing feedback.

Repo: https://github.com/adenhq/hive

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

Points: 107

# Comments: 35

I grew up helping my dad run his factory so I'm very familiar with ERP systems for manufacturing. A few years ago, when I decided to build a startup and I indentified the biggest problems with ERP is the fact they all just serve as data integration and system of records now - there're not enough processes automation. Therefore, I thought it'd be very meaningful to leverage AI to automate business processes such as PO, Price Requisition, and invoices, etc.

3 years in, I realized that every customer in our space (construction and contracting) want process automation, however, AI is simply not good enough - it's too slow, unpredictable, inconsistent, and overall hard to count on. For example, automating a quote by asking AI to insert dynamic variables from a relational database is hit or miss. Asking voice AI to provide training does not capture full breadth of the offline activities. Asking AI to fill out a work order creates a ton of errors.

Later, we decided that though LLM and the foundation models were progressing fast, the dev tools were lacking way behind, particular behind all the hypes and promises these AI applications claimed. The agents are not reliable, consistent, intelligent, evolving, and chances are the market would demand more apps to keep the party going.

Therefore, we went full open-source. The mission we have in mind is really to "generate reliable agents that can run business processes autonomously". We see all this hype about general computer use (GCUs) and can't help but making an opposing argument - that the AI agents need guardrails, more defined paths, and most importantly consistent results just like a human would need

- Proactive Reasoning (anticipating future needs or consequences)

- Memory & Experience (events affecting himself/herself)

- Judgment (based on experience)

- Tools & Skills (capabilities to execute)

- Reactive Adaptiveness (handling immediate roadblocks)

- Contextual Communication (articulating intent and collaborating with others)

- Character & Traits (consistent behavioral biases: Risk profile, Integrity, Persistence)

The project seems to have gained a bit of a traction so far and I hope that you can fork it and tell the community what's missing and what we should be working on. I deeply thank you because the it's truly painful to build and deploy these one-off agents that don't get utilized. (https://github.com/adenhq/hive).

- I see a lot error propagation with CUAs

- A GUI is very flakey and it produces a lot action latency

- There're hidden states behind each screen that CUAs simply can't capture

- Token consumption is absurd (but I guess this will alleviate as LLMs get cheaper)

What do you guys think? Any good ideas what'd be a good counter to this?

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

Points: 1

# Comments: 0

This is Vincent, Chen and Sam here from Acho https://acho.io/. We've built a data warehouse for you to access big data with no code.

As a former financial analyst, I used to spend a lot of time building spreadsheets but always wanted to step up my game and gain more understanding in big data. Then I was faced with a slew of "big data" tools such as Hadoop, Hive, Redshift, Kafka etc. They all seemed useful but I could not possibly learn them all since I'm not a full stack SDE or data scientist. This frustration led me conceiving this idea about building a data warehouse for non-programmer like me. Luckily I met Chen, who's been building big data pipelines for big corporates for years.

This new data warehouse I'd imagined should integrate with data seamlessly, transform/clean data like an Excel, update data maintenance-free, and send data with permission controls all without me having to understand distributed computing, database architecture, schema design, ETL, or SQL on a deep level.

Then we built Acho. Here's how Acho works. First, you can set up an integration with a production system (eg. .CSV, MySQL, Salesforce etc.). Then you can load them into an Acho project. On each project, you can transform, update, and share your tables all without coding. Lastly, you can export data to a reporting UI, or BI tool.

Currently, Acho monetizes through monthly subscription on usage. We keep a free tier so you can test Acho out. When you process data on Acho, all data is encrypted in a batched file accessible to no one but you. We disclose detailed security practices, compliances and policies to our users.

Building a data warehouse for everyone is not easy, but we're constantly adding more services to the product. From additional integrations, transformation widgets, built-in BI tools, to pipeline management, we love to know what you might need and we'll get it built as soon as you need it.

Vincent, Chen, Sam

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

Points: 2

# Comments: 0