Dan Patrascu-Baba

Reporting progress from the Mindwrinkles front. I've ran 3 arguments through the pipeline that decomposes reasoning and rates it according to formal logica and the most recent science around critical thinking. Fun fact: the worst one comes from a "guru".

Mentoring is not something a true senior engineer would "delegate" to AI

In light of all the debate around "reading the code", here are a few thoughts on why I think most PRs should never happen: danpatrascu.com/blog/why-most-…

@plainionist @unclebobmartin Mentoring is not something a true Senior would delegate.

@unclebobmartin I wonder if there will still be enough seniors willing to make the investment, given how much easier it is to just delegate simple tasks to agents 🤷‍♂️

Serious question: If junior developers skip the struggle because AI does the work, where will the next generation of seniors come from? 🤔

"Just run the tasks in parallel” is one of those pieces of technical advice that sounds straightforward until you have to apply it to a real system. The underlying idea is perfectly valid. When a process is dominated by independent, long-running operations, executing them concurrently can significantly reduce the overall duration. In practice, however, every external system involved introduces its own constraints, and increasing parallelism often means discovering those constraints one after another. We encountered this while optimizing customer onboarding at Atherio. During an onboarding, we ingest around 800,000 behavioural signals. A large part of the process involves retrieving data through Microsoft Graph, followed by calls to OpenAI models through Azure AI Foundry and eventually persisting the resulting data in Azure SQL. The first implementation was relatively serial and, unsurprisingly, took too long. Parallelizing the work was the obvious next step. What followed was a much more interesting exercise than simply increasing the number of concurrent tasks. Microsoft Graph started throttling requests. Azure AI Foundry imposed limits based on both requests per minute and tokens per minute. Once we had adjusted for those, the I/O limits of our S2 Azure SQL database became the next constraint. Each of these required a different approach. For the AI calls, we benchmarked the initial onboardings and established a baseline for the number of tokens consumed by each request type. From there, some fairly basic maths allowed us to calculate how many requests we could safely execute in parallel while remaining within our quota. Microsoft Graph was more complicated because throttling policies differ between resources and endpoints. Mailbox operations, for example, are often limited per mailbox. This meant we could process several mailboxes concurrently, while still keeping operations against each individual mailbox sufficiently controlled. The database introduced another type of limitation. Increasing connection timeouts can make the process more resilient when I/O pressure temporarily increases, but it does not create additional capacity. We therefore also have the option of scaling the database from S2 to S3 during larger onboardings and scaling it down again afterwards. All these constraints now shape the onboarding architecture. Parallelism is still a central part of it, but the final design emerged through benchmarking, calculations and a considerable amount of trial and error. Increasing concurrency without understanding the limits of every dependency would simply have moved the bottleneck from one component to another. This is also the part of engineering that rarely appears in high-level technical content. The advice usually stops at identifying parallelism as the solution, while most of the actual work begins immediately afterwards.

@mjovanovictech I'd be curious. I'm running just on the "Following" tab since my comeback here. The "For You" was unbearable. Would be nice if Linnkedin did something similar.

@danpdc Looks like it shows you more from people you follow

New algo? What's changed?

The biggest problem with technical content is that it stops at identifying potential high-level solutions, while in practice the actual work follows afterwards.

@RaulOnRails That was a great event!

Last week, I hosted Indie TM #12 where Mihai Negrea presented us his indie journey with datadriven.ro during a ~2 hr session. Super inspiring to see the raw side of things and how hard it is to bootstrap a business in this niche. Congrats and let the MRR go brrrrr!! 🚀 You can read the details on indie.md/events/indie-t…

@ImLunaHey It just shows how AI completely distorts the perception of reality. And how much more difficult it is to distinguish real expertise from wannabe engineers.

this site really has a problem with kids pretending to be seasoned software engineers. no your 2 years working on software isnt the same as someone whos been at this for more years than you are old. 🤦‍♀️

I think that's a genuine and important question. Because I've seen plenty of people bad mouthing coding agents and then extaticly cheering some tech influencer hallucinations (plainly wrong information).

I see a lot of tech people being worried about coding agents hallucinating. But how do you guard yourself against the hallucinations of tech influencers?

One of the assumptions we often make in SaaS is that two customers on the same plan are economically similar. Recently, while looking at the operational health of our platform, I found that one customer profile could cost us roughly four times more to serve than another. Both customers were using the same product and paying according to the same commercial model. Their actual usage patterns, however, were very different. The difference only became visible once I stopped looking at total infrastructure costs and started connecting them to the behaviour that created those costs. In our case, the number of licensed users was not enough to explain the variation. The number of people those users managed, combined with how actively they communicated through the platform, was a much better predictor. Pricing is usually treated as a commercial decision, but the architecture still determines what the company is charged for. When the unit you price and the unit that drives your costs begin to diverge, growth can increase revenue while quietly weakening margins. For a CTO, understanding unit economics therefore goes beyond watching the cloud bill. It means understanding which customer behaviours consume resources, how those behaviours vary across accounts and whether the commercial model still reflects the system the company has actually built.

Let's have SQL in UI components. I bet we never tried this as an industry.

We may be creating the next generation of legacy systems before AI-assisted engineering has even properly started. Most teams experimenting with coding agents are gradually building an additional execution layer around them: .md files, skills, rules, hooks, MCP configurations, permission policies, prompt templates and model-specific workarounds. Each of these decisions may be reasonable in isolation. Over time, however, they begin to determine how software is produced across a repository or even across an entire organization. They influence which tools an agent can use, how it interprets architecture, what it is allowed to change, how it validates its own work and when a human needs to step in. The problem is that this layer is rarely treated as architecture. Ownership is often unclear. Rules accumulate, but are seldom removed. Different repositories evolve different conventions. Instructions start to overlap or contradict each other, and there is usually no reliable way to test whether the overall system still produces the intended behavior. A developer can notice that a rule is outdated, question it and ask for clarification. An agent will keep executing it consistently, potentially across dozens of tasks, until someone realizes that the problem was built into the harness itself. As AI-assisted engineering matures, these instruction systems will need the same discipline we already apply to production software: explicit ownership, versioning, testing, observability and a process for retiring constraints that no longer make sense. Otherwise, the most important legacy system in the organization may no longer be the application code. It may be the invisible layer that tells the agents how to write it. Fortunately, Cycle-Driven Engineering has this covered and it provides baked in mechanisms to properly manage all these aspects through its Learning Layer.

@Bolmercl @edandersen Can you provide any type of reasonably documented information about this?

@edandersen @danpdc API prices have over 90% margins.

Entitlement at its peak! So, basically, a company should offer you a service for which you pay 20x less compared to what it costs to offer you the service. How exactly is this supposed to work economically? And it comes from an "advisor"

@edandersen Agreed. That's one reason why I've built the Traverso tool for myself (though I made it available for anyone who wants it) to be able to track in advance my usage and how that usage happens. Helps me to stay informed and plan for the future.

@danpdc The sooner the subscription model ends across the industry the better. It makes it impossible to have a properly informed conversation about the costs and benefits of the technology

The only logical thing to do :))

Starting to use Codex more and more. The first thing I usually do is point it to my Claude code harness and ask it to port the exact harness for itself. Works quite good. Making my Claude project ready for Codex takes 10 minutes