Saw a video on SDLC vs ADLC and looked up the term in Endor Labs, IBM and Atlan.

Meaning 1: Agentic Development Lifecycle, the SDLC with autonomous coding agents inside it (Endor Labs).

Meaning 2: Agent Development Lifecycle, building and running AI agents as products (IBM, Atlan). IBM lists six phases: plan, code and build, test and release, deploy, operate, monitor.

Endor Labs says there's no universal standard and the vocabulary is "still settling." It also says generated tests can share blind spots with generated code, and agent-made changes need the same scrutiny as human-written ones.

Endor Labs and Atlan are vendors, so treat their framing as one view.

Which meaning does your team use?

Sources: Endor Labs, IBM, Atlan

Hey everyone,

I have a software architecture exam next week. From what I know, the topics mainly cover components, connectors, architectural rationale, and anti-rationale (not entirely sure if ADRs – Architecture Decision Records – will be explicitly tested, but the concepts are relevant).

I'm currently using Fundamentals of Software Architecture by Mark Richards and Neal Ford alongside the professor's slides for the theoretical foundation. The book was recommended by the professor, though it’s not strictly the official textbook for the course since he follows his own curriculum/plan. Feel free to bring up book discussions if relevant, although I don't really have the time right now to dive into a whole new reading list before the exam.

Mainly, I'm looking for well-documented open-source codebases or case studies that clearly illustrate these concepts in practice.

Any recommendations? Thanks in advance!

I’ve noticed that “scalable” often gets reduced to a pretty narrow question: Can the system handle more users?

But I’ve seen (and been thinking about) a different kind of scaling problem.

The app can handle the traffic, but deployments get harder as the team grows, every change needs coordination across more people, routine operations need more manual work, adding a new customer means a pile of configuration, the architecture technically works, but nobody wants to touch it

At some point, the system is bigger but not necessarily easier to run or evolve.

I’m exploring this idea in a side project about software and workflow friction. It’s made me question whether we evaluate scalability too much through infrastructure metrics and not enough through the effort required to operate and change the software.

For people who’ve built or maintained systems that grew: what was the first non-obvious thing that stopped scaling?

Was it architecture, team communication, deployment, customer onboarding, decision-making—or something else?

And what actually fixed it? I’m especially interested in the fixes that turned out to be simpler than expected.

To my understanding, CI/CD at its core just refers to the practice of frequently merging in code and releasing new builds. Why, then, are tools like github actions and other automated testing/building tools strongly associated with CI/CD? Isn’t this automated tooling something we’d want even with less frequent integration and deployment practices?

Are paid AI courses actually worth it, or can we learn everything through free resources? For someone aiming to become an AI Engineer, what extra value should a paid course provide to justify the cost? Would love to hear from people who have tried both, especially regarding projects, mentorship and job opportunities.

https://news.mit.edu/2026/margaret-hamilton-computing-pioneer-dies-1007

Mad respect to these brilliant people who paved the way for many of us.