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.

Hi folks, Stjepan from Manning here. The mods gave us permission to share this.

A feature can be well-designed, tested, and delivered on schedule, and still leave the user’s problem untouched. What interests me is how engineers recognize that before the team has spent three months building it.

Take a request for a dashboard. That’s already a proposed solution. The underlying problem might be “I can’t tell which jobs have failed” or “I spend Friday afternoon assembling a report.” Those are different problems, with potentially very different engineering costs.

Asking which one we’re solving sounds straightforward. Doing it when the roadmap is committed, and everyone wants an estimate, is harder.

That’s why I wanted to bring Jon Bennallick’s Product Thinking for Engineers here. It’s now in Manning’s Early Access Program (MEAP), and it focuses on the judgment engineers bring to decisions about what gets built.

The part I find especially relevant is pushing back with evidence. “This feature seems pointless” doesn’t give a team much to work with. “What evidence would tell us this is worth building, and could we test that before committing to the full implementation?” opens a more useful conversation.

Of course, engineers don’t always have access to users or authority over priorities. Better questions won’t magically fix that. But making assumptions and costs explicit can help a team distinguish a technical disagreement from a disagreement about what users actually need.

The book covers turning user feedback into actionable decisions, spotting low-value work early, and discussing cost and commercial value. Jon uses actual projects from agencies, scale-ups, and smaller businesses, including his own mistakes. There’s no code or framework tutorial; the focus is contributing to product decisions without having to become a product manager.

Book and available MEAP chapters:
https://www.manning.com/books/product-thinking-for-engineers

MEAP means you can read chapters as they’re written, with the finished ebook included when it’s ready.

We’re giving away 5 ebook copies to the 5 people whose comments contribute most thoughtfully to this discussion. We’ll choose based on the substance of the contribution, not upvotes or whether you agree with the book’s premise. A useful counterexample absolutely counts.

Manning is also offering the community 50% off the book with code MLBENNALLICK50RE.

Here’s the question I’d love to hear your experience with: when did your team build exactly what was asked for, but miss the underlying need? What would have helped you catch it earlier—and did you actually have room to challenge the request?

A thoughtful account of what didn’t work is just as welcome as a success story.

Thanks for having us.

Cheers,

Stjepan

University of Maryland Computer Science Professor Mihai Pop and Postdoctoral Associate Marcus Fedarko are answering questions about their bioinformatics and computational biology research tomorrow! Mihai's lab has developed software tools widely used in the field of metagenomics. Submit a question: https://redd.it/1wmp6cs

I’m a software developer and I’ve been thinking a lot about where AI coding agents are taking software development.

It seems like we’re moving beyond AI simply helping developers write code. Agents can increasingly take a ticket, understand a codebase, implement changes, write tests, debug issues, create PRs, and potentially handle parts of deployment and maintenance.

So I’m wondering: do you think the traditional SDLC will eventually be largely replaced by an agent-driven development process?

If so, how soon do you think most companies will actually adopt something like this? Are we talking 2–3 years, 5 years, 10+ years, or do you think we'll never get to fully agent-driven development?

I’m also curious about the other side of this:

• What types of companies won’t adopt AI agents aggressively?
• Will large enterprises actually trust agents with production systems?
• Could the current AI boom turn out to be an AI bubble, where companies eventually cut back because the cost, reliability, security, or productivity gains don't justify the hype?

There are already examples of companies pushing heavily toward AI-driven development.

I'm less interested in AI hype or predictions from CEOs/VCs and more interested in what developers are actually seeing inside their companies, is this irreversible?

If you're a developer, architect, tech lead, or engineering manager:

How much of your actual SDLC is being automated by AI agents today, and where do you think this goes over the next 5–10 years?

I've been working with actor systems in Go for several years and keep noticing the same thing... as systems grow, teams gradually reinvent state ownership, supervision, runtime inspection etc (usually as a pile of separate libs, queues and conventions).

Actor systems have had most of this as a coherent model for decades.

I maintain Ergo, an OTP inspired actor framework for Go, so I'm obviously biased but I'm genuinely curious - why did actors stay niche while microservices became mainstream?

Is the actor model actually too complex?

P.S. The current AI-agent wave makes this even more obvious to me. Everyone is building agents and inventing orchestration pipelines, while actor systems already have a native model for long-lived workers, messaging, supervision and coordination.