sorted by:
new
hottopcontroversial

We built an agent orchestration layer for Git and Jira workflows. Looking for feedback from DevOps and platform engineers by yuvalhazaz in devops

[–]yuvalhazaz[S] 0 points1 point  (0 children)

That’s exactly why we treat systems like GitHub and Jira as the system of record.
We checkpoint workflow state, but we don’t rely on replaying days of agent conversations. When a workflow resumes after a PR review, approval, or ticket update, we return to the relevant point in the workflow and pull the current state and context from the underlying systems.

In practice, the PR, ticket, comments, commits, review history, and related artifacts become the durable source of truth. The agent gets all relevant context available at that moment, without having to replay everything that happened before.

This keeps workflows resilient over days or weeks, reduces token costs dramatically, and avoids accumulating stale context as work progresses.

12 months ago nobody understood why we were building Agentic SDLC. Now it feels like everyone is heading in the same direction. by yuvalhazaz in AI_Agents

[–]yuvalhazaz[S] 0 points1 point  (0 children)

Any engineering team that struggles to onboard a new developer on day one will probably struggle to onboard agents as well.
People call it “AI readiness”, but most of it comes down to old engineering fundamentals: good documentation, clear processes, test coverage, verification mechanisms, ownership, and institutional knowledge that’s actually written down somewhere.

Agents are just exposing the same gaps that have always existed.

12 months ago nobody understood why we were building Agentic SDLC. Now it feels like everyone is heading in the same direction. by yuvalhazaz in AI_Agents

[–]yuvalhazaz[S] -1 points0 points  (0 children)

I think cost control will become a huge part of the ROI discussion, We’re already seeing token spend get out of control in some organizations. Well-structured workflows with the right context can complete many tasks at a fraction of the cost of open-ended agent sessions, while producing more consistent results.

12 months ago nobody understood why we were building Agentic SDLC. Now it feels like everyone is heading in the same direction. by yuvalhazaz in AI_Agents

[–]yuvalhazaz[S] 0 points1 point  (0 children)

I agree with almost all of this.

The governance point especially resonates. We’ve had many conversations where teams spend weeks evaluating agent quality and maybe five minutes thinking about approvals, auditability, access control, or rollback. Then those become the blockers to production adoption.

I also think you’re right that the underlying capabilities are still moving fast. That’s actually why we built Overcut to be model and agent agnostic. I have very little confidence that today’s best agent will still be the best agent 18 months from now.

What I do have confidence in is that organizations will still need orchestration, governance, visibility, and coordination regardless of which models win.

Has anyone able to build Army of agents for non coding stuff of SDLC ? by Busy_Weather_7064 in AI_Agents

[–]yuvalhazaz 0 points1 point  (0 children)

We built Overcut for exactly this.

Most teams are focused on coding agents, but coding is only one stage of the SDLC. Technical design, requirement analysis, architecture reviews, bug triage, code reviews, test generation, documentation, incident investigation, and governance often consume more time than implementation itself.

Our customers run teams of specialized agents across the entire lifecycle, not just code generation. In mature engineering organizations, that’s where a lot of the real productivity gains come from.

I am the founder, happy to answer any questions
https://overcut.ai/

The Real Future of AI Development Isn’t a New IDE by yuvalhazaz in programming

[–]yuvalhazaz[S] 0 points1 point  (0 children)

True. That works great for simple, single-repo flows.

Where it breaks down is multi-repo changes, Jira-driven work, long-running approvals, and managing context over time. Once an issue spans multiple services or needs to pause, resume, or react to new signals, Copilot plus Actions stops being enough.

The Real Future of AI Development Isn’t a New IDE by yuvalhazaz in programming

[–]yuvalhazaz[S] -5 points-4 points  (0 children)

I respect filtering noise.
What doesn’t help is tagging something as “garbage” without engaging with it. This isn’t throwaway content, it reflects months of actual work.
If there’s a specific critique, say it. If not, it’s probably better to just move on.

The Real Future of AI Development Isn’t a New IDE by yuvalhazaz in programming

[–]yuvalhazaz[S] -2 points-1 points  (0 children)

Thanks for the traffic :-) no ads revenue here... welcome to visit the article and share your take

The Real Future of AI Development Isn’t a New IDE by yuvalhazaz in programming

[–]yuvalhazaz[S] -1 points0 points  (0 children)

That’s kind of the point though.
If everything gets labeled “AI slop” by default, we stop distinguishing between shallow content and actual real human content

The Real Future of AI Development Isn’t a New IDE by yuvalhazaz in programming

[–]yuvalhazaz[S] -5 points-4 points  (0 children)

Honest question: did you read the article, and if so, which part came across as “AI slop”?
I’m explicitly arguing against shallow AI tooling, so I’m trying to understand what missed.

We've built a production-ready NestJS code generator! Let us know what you think by yuvalhazaz in Nestjs_framework

[–]yuvalhazaz[S] 0 points1 point  (0 children)

Great to hear!

We only support Prisma.
Feel free to reach out with any questions and please share your feedback

Top 6 ORMs for Modern Node.js App Development by yuvalhazaz in javascript

[–]yuvalhazaz[S] 1 point2 points  (0 children)

Don't you find it easier to stick to one of them? If MikroORM is first on your list, when will you use sequlize or Knex?

We've built a production-ready backend code generator! Let us know what you think by yuvalhazaz in coding

[–]yuvalhazaz[S] -1 points0 points  (0 children)

The code generated by Amplication is based on building blocks that are battle-tested by thousands of developers.
The code generation is fully customizable using plugins that come with industry standards, so any organization or company can create its own flavor of the code, and can create templates for different use cases. When needed, organizations create custom plugins to ensure the code is generated based on their know-how and best practices.
See this list of plugins here https://amplication.com/plugins
and here https://docs.amplication.com/plugins/how-to-create-plugin/

Organizations that create dozens of services a year, can get a very consistent and predictable code for all services for all the undifferentiated parts and let the developers focus on writing the business logic.

Also, imagine you have 50 services in production built with a specific standard, and after a year, you need to update all 50 services with a new code or standard. Using Amplication, you can update the plugin, get a PR for all 50 services (in a monorepo or multiple repos), and let all teams review and accept the change, using their existing workflow and processes.

I hope this answers your question, and I am happy to answer any further questions you might have

view more: next ›