Learn Agile Practices

Unlock Your Potential with Learn Agile Practices: Enter a Learning Ecosystem & Achieve Technical Excellence

[David Cramer @zeeg]

Everyone is slowly coming to this realization, and I assure you, no one is running multitudes of agents overnight. No one that is doing anything of substance at least.

There _are_ people pretending to be scientists, or fully caught up in their drug infused AI overdose, that think their slop machines are changing the world. They're not tho, and they're just wasting a bunch of money and compute to create a lot of LoC that will just get thrown away.

The state of the art is still "can we even one shot a production quality patch that we wont regret later", and its rarer than you'd expect based on discourse.

[Learn Agile Practices @learnagilep]

@ExtinguishedEng @benjamincrozat Exactly. Additionally, domain knowledge is fundamental. Are we sure it’s a good idea to give it up so easily? 😅

[Learn Agile Practices @learnagilep]

@themoontography @ZssBecker Considering that one of the biggest problem in software history is having too much code and too much features… doesn’t look much good to me.

[Learn Agile Practices @learnagilep]

@paoloanzn Actually, replacing saas with custom generated app is a very bad idea. No matter how many engineers you have

[Learn Agile Practices @learnagilep]

As always: writing code is just 10% of the work

[Manthan Gupta @manthanguptaa]

LLMs have made code cheap.

So now people are spinning up 10 agents working on 10 features in parallel. Sounds productive.

But the tradeoff is obvious: the code quality is often spaghetti + over-engineered.

LLMs behave like over-eager interns. They will do more than asked, add abstractions you didn’t need, and optimize for "completeness" over simplicity.
Which means you end up babysitting anyway.
For anything non-trivial, I have found you still need to spend 1–3 hours upfront:
• defining scope
• writing clear specs
• thinking through system boundaries
• setting constraints

Otherwise, the system drifts.
And even after that, you have to review the code.
They still hallucinate patterns, introduce unnecessary layers, or miss edge cases, even with detailed instructions.
A lot of people advocate "just let agents cook."
In practice, you're often getting 60-70% unnecessary code that increases:
• cognitive load
• onboarding time
• surface area for bugs
• long-term maintenance cost
For side projects, this is fine.

But for real systems with shared codebases, multiple engineers, and production traffic, this compounds fast.

We are already seeing:
• unstable tools
• memory leaks
• constant crashes
• frequent rewrites
This isn't just "early days", it’s a direct result of speed > discipline.

Spinning up 10 agents feels like productivity.
But you are often just pulling forward the cost into refactoring hell.
I would rather:
build slower → keep systems simple → refactor less frequently

Good engineering is still about what you choose not to build.

[Learn Agile Practices @learnagilep]

@PropzSaladaz @twannl We are pretty far from delegating domain knowledge, imho

[Learn Agile Practices @learnagilep]

@PropzSaladaz @twannl There were a lot of waiting times even before AI helped us coding… yes multitasking has always been a bad idea.

[Learn Agile Practices @learnagilep]

@pipe_dev Write tests first!

[Gergely Orosz @GergelyOrosz]

Cannot wait for teams that build their custom JIRA/Workday replacement/custom CRM to one day turn around and ask:

“Why do we have so much internal software that is buggy / has poor UX + we need to maitain?”

Seen this movie well before AI, when Uber built uChat (custom Slack)

[Learn Agile Practices @learnagilep]

@leodev Such as?

[Learn Agile Practices @learnagilep]

@oliverbrocato You are. That’s it. If you care about why, then we can discuss 😉

[Learn Agile Practices @learnagilep]

@nateliason Your expectation of AI handling all of your code on its own is pretty delusional at the moment. Therefore, people will still change it manually. Therefore, it must easy to read and change for a human.

[Learn Agile Practices @learnagilep]

@thdxr Let LLM write the tests is a bad idea for the same reasons TDD is a great one.

[Learn Agile Practices @learnagilep]

@svpino @The_X_Architect Product is a never ending journey. There is no such thing as 90% done.

[Learn Agile Practices @learnagilep]

@GergelyOrosz It doesn’t make sense. It doesn’t matter. Any piece of code added to the codebase should be treated the same way

[Learn Agile Practices @learnagilep]

@TheAlphaThought If you can’t pay your employees… do not open a business 😉

[Learn Agile Practices @learnagilep]

@SumitM_X Multiple microservices query the same database? Mmm. Microservices should be indipendent, even from data perspective. That’s the real issue 😉

[Learn Agile Practices @learnagilep]

@Hasen_Judi That’s not the problem that docker tries to solve. The problem is ensuring the environment is the same everywhere, basically removing the “it works on my machine” sentence.

[Learn Agile Practices @learnagilep]

@fidexcode CRUD is just one way to expose data. Better approaches are domain driven (see DDD and Hexagonal architecture). Backend is knowing all of those, and everything else about scalability, data management, ecc - and picking the best option for the current situation

[Learn Agile Practices @learnagilep]

@brankopetric00 @rob_ferney That’s exactly where agile/xp/lean can help. They are heat friend of devops - which is not infrastructure, btw. Same as agile is not scrum or sprints. 😉