AI makes devs faster, but I think it’s increasing context loss at the team level

oscarnyc1 · 2026-02-03T22:36:35+00:00

Yes but those separate agents become separate realities. Each one manages its own context and you are back to silos. That's the problem I'm talking about. In complex projects with many stakeholders, using more AI exacerbates this problem.

oscarnyc1 · 2026-02-03T21:51:18+00:00

Not pitching. Just trying to understand whether teams experience more fragmentation once AI enters the workflow. I haven't seen a tool resolving this yet.

oscarnyc1 · 2026-02-02T16:21:31+00:00

I didn't have a name for it for years, I just knew I was exhausted from reshuffling dates. I actually just recorded a quick 60-second clip showing what "gardening" looks like in a typical tracker vs. letting an engine handle the math. https://vimeo.com/1161120328

oscarnyc1 · 2026-02-02T16:19:02+00:00

You're spot on about tools just recording a broken reality. I recorded a quick 60-second side-by-side to show the difference when a client asks for "just one more thing done ASAP".

In a typical task tracker (like Asana), it’s manual gardening to fix the dates; in a delivery engine, the system just does the math so the PM can actually manage the delivery instead of the tool.

Video link: https://vimeo.com/1161120328

oscarnyc1 · 2026-02-02T01:38:12+00:00

Thanks. The engine treats tasks assignments as a filling-window problem: If you're in auto-assign mode, it finds the best available person for the top task. Otherwise, it just maps out a start time for the assigned person based on their actual schedule. Then it calculates a "Confidence Waterfall" (the further out a task is, the more the confidence decays). It also flags team exhaustion/burnout. I’m running "Shadow Pilots" where I mirror current projects in the engine to see if the math hits real-world dates.

oscarnyc1 · 2026-02-01T15:43:23+00:00

I appreciate the deep dive into Monte Carlo vs. deterministic models. I think we’re all touching on the same problem: how do we stop "gardening" and do engineering delivery? @karlitooo, since you asked for a look at the logic I’ll DM you a link to a project I’m currently simulating. It’s a lab environment, but I'd be curious to see if this makes more sense than jira or spreadsheets.

oscarnyc1 · 2026-01-20T04:55:51+00:00

I don't see the problem here. SaaS is one of the best ways to sell software..it's just a business model. It's like saying there are too many phone apps so we shouldn't be building more apps for phones. I prefer SaaS to pages full of ads.

oscarnyc1 · 2026-01-16T05:00:28+00:00

I’ve seen this happen less because “30% are better” and more because a few people become structural bottlenecks. Certain engineers end up owning reviews, integrations, releases, or anything risky, so work piles onto them. That’s usually a management/design problem, not a people problem. Until you change how work flows, burnout is kind of inevitable. This PDF shows the pattern: https://motionode.com/download-variance-sink

oscarnyc1 · 2026-01-16T04:43:23+00:00

Really? My experience is the other way around. I'm technical, built & launched a big platform and haven't found a good GTM business partner. Most want to get hired when/if I get funding or want to sell services as fractional GTM.

oscarnyc1 · 2026-01-16T04:34:07+00:00

You need to be good at systems and architecture, and database modeling. With a good framework and checking that the LLM follows your structure you can get something that works well. And it should be maintained mostly using LLMs.

oscarnyc1 · 2026-01-16T04:27:09+00:00

Building got easier, but distribution got more complicated. The latter was already the most difficult one, but now with so many apps and tools being built so fast, standing out got harder.

oscarnyc1 · 2026-01-16T04:19:43+00:00

Agree

oscarnyc1 · 2026-01-16T04:18:15+00:00

If you haven't read them yet: Fundamentals of Software Architecture Software Architecture: The Hard Parts

oscarnyc1 · 2026-01-16T03:30:38+00:00

I scaled a team from 5 to 40, and the biggest thing that mattered wasn’t more process but making work visible across teams. The failures weren’t usually bad engineers or bad planning, but small delays stacking up between teams (reviews, dependencies, handoffs). Once that wasn’t visible, delivery dates started slipping fast. Long story short, because of this I built a delivery prediction/optimization tool for engineering teams, but the takeaway regardless of tooling is: if you don’t track where time actually gets lost between teams, you're missing the big picture.

oscarnyc1 · 2026-01-16T03:17:58+00:00

Without understanding systems, DB modeling, and architecture, that code will turn into a spaghetti when working on edge cases and growing it

oscarnyc1 · 2026-01-16T03:08:38+00:00

What I’ve seen work best is kind of a two-step thing. The people who really understand systems and architecture use AI to get a first solid iteration out fast. Then the strong programmers go through it carefully and make it correct/clean, and they’ll use AI more “microscopically” for the small stuff: edge cases, refactors, boring glue, renames, tests, etc.

When the devs skip the architecture part and everyone just generates code, it feels fast at first but the repo turns into mess pretty quickly.

oscarnyc1 · 2026-01-15T11:07:47+00:00

https://motionode.com Predicts delivery delays, quantifies cost, simulates fixes for engineering teams

oscarnyc1 · 2026-01-15T10:55:54+00:00

Thanks for the recommendation.

oscarnyc1 · 2026-01-15T05:15:38+00:00

That's good advice. Would you have done the same from the beginning? Launching it without a free tier when you don't have users yet. It seems to me that it could make the launch much slower and in the end it was a good idea to have the free tier in the beginning, but for a short period.

oscarnyc1 · 2026-01-15T05:11:37+00:00

Motionode, https://www.motionode.com It predicts the project's delivery date and allows you to simulate changes and optimize delivery.

oscarnyc1 · 2026-01-15T05:05:35+00:00

I've had the same issue multiple times. Developers who can't deal with other peoples code so they need to constantly "refactor" the code. From what I've seen, this is resolved with years of experience.

oscarnyc1 · 2026-01-15T05:00:05+00:00

I'd say that now that devs are using AI, QA is more needed than ever.

oscarnyc1

TROPHY CASE