DEV Community: Ahmadreza Samadi

More AI agents do not remove a shared bottleneck

Ahmadreza Samadi — Sun, 01 Nov 2026 18:00:00 +0000

The situation

In a fictional dispatch library, adding more helpers does not shorten the queue: every independent task waits for the same key. The illustration asks where work must be coordinated and where it can proceed independently.

What the source supports

GitHub’s 21 October 2026 engineering article describes adapting its Git infrastructure for agent-scale workloads. It describes changing the scope of write ordering from the whole repository to individual references, so that writes to different references can be in flight at the same time. The post says each write still experiences the cross-region latency. Work on the same reference still requires coordination; independent references need not share every wait.

Practical questions

Our practical question is: what resource do these tasks share? Map the dependency before adding more agents. Separate independent work where the system supports it, retain ordering where writes can conflict, and measure the actual end-to-end result rather than counting assistants.

Limits and disclosure

The library, keys and workers are fictional analogies. GitHub describes its own architecture; this is not a benchmark or a promise that adding agents, parallelism or infrastructure changes will speed up another business. No performance figures or customer outcomes are claimed.

Source and animated example

https://github.blog/engineering/architecture-optimization/the-bridge-to-agent-scale-git-infrastructure/

Watch the fictional animated example. Original animation and music with synthetic English narration; it is not Ahmadreza’s recorded voice.

This companion article was generated and checked with AI tools; no human or native-speaker certification is claimed.

Ahmadreza Samadi · https://a-samadi.com

Structured AI output: correct shape is not truth

Ahmadreza Samadi — Fri, 30 Oct 2026 18:00:00 +0000

The situation

Noor, a fictional business owner, receives a neatly organised extraction from a document. Every field fits the form. One value has no support in the source. A tidy shape and a true statement are different checks.

What the source supports

OpenAI documents Structured Outputs as a feature that makes model responses adhere to a supplied JSON Schema, using a supported subset of JSON Schema. It also states that outputs can still contain mistakes and that refusals or incomplete responses need handling. Support and schema constraints vary.

Practical questions

Our original three gates are format → source → business rule. First check that the response completed in the expected form. Then match each important value to the actual document. Finally check the business requirement separately. Make room for unknown or missing data instead of forcing a guess into a required answer.

Limits and disclosure

Noor pauses the unsupported value for review. This fictional resolution illustrates a control; it is not a tested application or a claim that schema enforcement certifies facts. No actual document, benchmark or accuracy result is represented. This explainer was prepared with machine assistance and source checks.

Source and animated example

https://developers.openai.com/api/docs/guides/structured-outputs

Watch the fictional animated example. Original animation and music with synthetic English narration; it is not Ahmadreza’s recorded voice.

This companion article was generated and checked with AI tools; no human or native-speaker certification is claimed.

Ahmadreza Samadi · https://a-samadi.com

Before combining property records, separate identity from dates

Ahmadreza Samadi — Thu, 29 Oct 2026 05:00:00 +0000

Combining an image with a property record creates a new question before it creates a useful answer: do both sources actually describe the same property?

A model can produce a convincing combined story while leaving that relationship unresolved. I would keep the identity question, each source and its relevant dates visible before presenting the result as a property history.

A fictional pair of records

Every identifier, observation and date below is invented for teaching. These are not customer records or a performed company test.

Field	Image A	Record B
Identifier	P-17	P-17B; relationship not supplied
Evidence date	Captured 5 March 2024	A note describes roof work on 7 April 2025
Update date	Not supplied	Record updated 12 September 2026
Limited claim	A dark area appears on the roof	The record says roof work was completed

Similar identifiers are not proof of a match in this example. Until supporting information establishes their relationship, keep the records separate and mark the proposed match unresolved.

The dark area is an image observation, not a diagnosis of damage. The note is a recorded statement, not independent confirmation that the work happened.

Separate the three clocks

Suppose later evidence confirms that both sources describe the same property. Their dates still answer different questions:

Capture date: when was the image taken?
Event date: when does the note say the work happened?
Update date: when was the record changed?

The September update does not establish that somebody inspected the roof in September. The image predates the work described in the note, so the two sources need not be conflicting accounts of the same moment. Neither establishes the roof's present condition.

For an interface, I would display the relevant date beside its claim rather than collapse all three into one "last updated" badge. This is a design proposal, not a reported product feature.

Preserve the unresolved link in the output

A useful research note could say:

Proposed match: unresolved. Image A is labelled P-17 and was captured on 5 March 2024; a dark area appears on the roof. Record B is labelled P-17B and contains a statement about roof work on 7 April 2025. Its update date is 12 September 2026. Confirm the relationship between the identifiers and inspect the evidence behind the work statement before combining these into one property history.

That note records a next check instead of substituting an explanation for the missing evidence. It is a suggested format, not an evaluated matching algorithm.

Make the next action explicit

For this fictional workflow, the next task is to resolve identity and inspect support for the recorded statement. It is not to publish a condition diagnosis or conclude that a property is an investment opportunity.

Adding more fields can help organize a review, but field count is not an accuracy measure. A reviewer should be able to follow a claim back to its source, see what time it describes and identify what is still unknown.

The full property data enrichment guide develops the fictional example. For the broader workflow, Start with the decision connects the intended action with the evidence it needs.

AI assisted this adaptation. Fictional records and proposed checks are teaching material; no customer outcome, current property assessment or performed company evaluation is claimed.

Which Dubai property source should your AI answer use?

Ahmadreza Samadi — Mon, 26 Oct 2026 05:00:00 +0000

A fluent AI answer can still use the wrong kind of property evidence. Before asking a model to summarize a Dubai property source, define the question: are you describing a sales-price series, comparing a rental benchmark, or asking about one particular property?

Those outputs are different. Putting them into the same dashboard does not make their meanings interchangeable.

Keep the measure attached to the claim

Dubai Land Department's Residential Sales Price Index page separates property segments and reporting periods. Its historical reference periods should stay historical: the date a website was updated is not necessarily the period the observations describe.

The linked 2020 methodology explains why the mix of properties sold matters and describes a hedonic approach using recorded characteristics. This is a description of that published methodology, not a claim that every present-day index uses an unchanged model.

The same index page includes restrictions on commercial use, including pricing, investment decisions and performance measurement. I am linking to the explanation and notice here, not reproducing its series or deriving a property's price from it. Public visibility alone does not establish permission to redistribute data or build a commercial feature around it.

A rental benchmark is another input

The Smart Rental Index FAQ describes building-related characteristics and registered rental contracts among its inputs, and specifies coverage limits, including an exclusion for DIFC.

A rental benchmark does not, by itself, supply an acquisition price, operating costs, financing or realized occupancy for a particular property. My conclusion is limited: that source alone cannot establish the property's investment return. This is not a determination of anyone's permitted rent increase.

DLD also has a separate Property Valuation service, with an application, supporting documents and review before a valuation certificate is issued. A model-generated paragraph linking to the service is not such a certificate.

Give the summarizer an evidence card

This is my proposed record format, not an official DLD form:

{
  "question": "What claim am I trying to support?",
  "source_and_purpose": "Which document or service addresses it?",
  "observation_period": null,
  "coverage_and_exclusions": null,
  "measure_and_units": null,
  "method_and_use_limits": null,
  "access_date": "2026-10-17",
  "unresolved": []
}

The nulls are intentional. Missing fields should remain missing until evidence fills them. An instruction to produce a confident summary should not turn an unknown period into a current observation or a market segment into an inspected apartment.

For a product, the useful first output may be a source-selection note with the gaps visible. That gives the next reviewer something to inspect before a number becomes a recommendation.

The full source-selection guide includes the distinctions, limits and proposed evidence card. Source review: 17 October 2026. This educational article is not a current market report, property valuation, rent-dispute decision or investment recommendation.

AI assisted drafting and source comparison. No personal transaction, customer outcome or tested company system is claimed.

AI cost per accepted result: beyond token prices

Ahmadreza Samadi — Thu, 22 Oct 2026 05:00:00 +0000

The price of a model call matters. The cost of getting a useful result through a complete workflow matters more.

At a glance

Divide the full workflow cost, including model calls, tools, retries and human review, by the number of results that pass a defined review standard. Cheaper requests do not automatically mean cheaper accepted results. The property-research example below is a proposed test, not a reported company result.

When an AI provider lowers its price, a team can afford to test more ideas. But a cheaper call does not automatically make a product cheaper to operate. The workflow may still need repeated calls, other tools, and a person to check the output.

How do you calculate cost per accepted result?

I would start with a simple measure:

Cost per accepted result = total workflow cost ÷ results that pass review.

The numerator includes model input and output, cached context, tool calls, retries, failed runs, and human review time. The denominator counts outputs that meet a defined standard for the task. A low price per request can still produce an expensive result when many requests fail or need extensive correction.

If no output passes review, report the experiment’s total spend and zero accepted outputs separately. Cost per accepted result is undefined for that run; do not report it as zero or infinity.

Compare workflows only for the same defined task and acceptance criterion, and include the relevant cost categories consistently. Read cost per accepted result alongside precision, recall and time to a decision; a lower cost figure alone does not show that the workflow is more useful.

This is a measurement framework, not a universal benchmark. Teams need to define what “accepted” means for their own workflow and record the assumptions behind any cost comparison.

How does this connect to my work?

At Appraiva, I work on connecting property imagery analysis with property identity, data enrichment and search. The property-research test in this article is a proposed experiment, not a description of an Appraiva feature or a reported company result.

How would you test a property-research workflow?

Imagine testing a tool that flags property records for further investigation. Start with a human-labeled set of records. Ask the system to surface candidates with supporting evidence. Have a reviewer accept or reject each suggestion, then measure precision, recall, total cost, and time to a decision.

That is a proposed experiment, not a description of an Appraiva feature or a reported company result. It illustrates why a model that is cheaper to call might still cost more per accepted candidate if it sends too many false leads to a reviewer.

What would I test first?

Choose one repetitive task and write down the current human process.
Define a clear acceptance rule before running the AI test.
Track model, tool, retry and review costs for every attempt.
Compare accepted results and time to decision against the current process.

The useful question is whether the workflow helps someone reach a reliable decision at a cost that makes sense. Lower model prices make that test easier to run; they do not answer it by themselves.

This is an evergreen excerpt of my published article. The dated provider-price announcement is omitted. AI prepared this syndication from the published text; no new company result or measured experiment is claimed.

Measure cost per accepted result

Divide all recorded workflow costs by the number of distinct results accepted under a rule fixed before the test. Include retries and rejected attempts in cost; do not count repeated attempts as new accepted results.

All attempt costs → Acceptance rule → Cost per accepted result

Total recorded cost ÷ distinct accepted results. With none accepted, unit cost is undefined.

This guide uses “accepted result” for an output that passes the recorded review rule. “Verified result” in the historical URL and earlier title refers to that same rule; neither term establishes independent certification. Keep unknown costs separate from explicit zero. Compare the same intended result batch and currency, and report acceptance counts alongside unit cost. A lower unit cost with a weaker acceptance rule is not a like-for-like improvement.

Decision checklist

Freeze the task, intended result IDs and acceptance rule.
Record model, tool, labor and other costs consistently for all attempts.
Retain rejected attempts and retries in the numerator.
Count each accepted result once; report unknown cost inputs as unknown.
If no result is accepted, report total spend and zero accepted results, with unit cost undefined.

Full guide · Signature ideas · Related tool

Why dividing metro rent by home value does not give property yield

Ahmadreza Samadi — Mon, 19 Oct 2026 05:00:00 +0000

A ratio can be arithmetically correct and answer the wrong question.

Take a monthly rent estimate, multiply it by twelve, and divide it by a median home value. The result looks like a useful annual percentage. But before naming it “yield,” check whether the rent and value describe comparable properties, places and periods.

The 2026 metro study keeps that limitation visible. It combines HUD FY2027 two-bedroom gross rents with ACS2024 owner-stock values to explore hypothetical cash budgets. It does not observe the rent and purchase price of the same investment property.

Start with the data contract

For each input, write down its population, geography, unit and vintage before joining rows.

HUD describes FMRs as estimates of gross rents at the 40th percentile for standard-quality units. HUD also explains that some rent areas are subdivisions of OMB metropolitan areas. A metro identifier is therefore a starting point for a geography check, not proof that every input has identical boundaries.

The study's ACS B25077 value describes owner-occupied housing stock, not the acquisition price of a matching two-bedroom rental. Its original source files and notes are retained in the versioned repository.

Even a perfect identifier join cannot turn those two housing populations into one matched property sample. Calling the resulting ratio an observed investment yield would give the output more meaning than the inputs support.

A fictional example makes the problem visible

Assume a gross monthly rent input of $2,000 and a value proxy of $300,000. These numbers are invented for teaching; they are not a city result or a property offer.

The simple ratio is:

2,000 × 12 / 300,000 = 8%

Now choose a $200 monthly utility deduction and eleven occupied months. Assume management takes 8% of receipts, an annual fixed cash budget is $7,000, and annual principal-and-interest payments are $12,000.

Receipts = (2,000 − 200) × 11 = 19,800
Management = 19,800 × 0.08 = 1,584
Annual cash surplus = 19,800 − 1,584 − 7,000 − 12,000
                    = −784

The 8% ratio and the $784 shortfall are not contradictory. They describe different calculations. Neither establishes this property's actual return, because this example has no actual property and the assumptions are hypothetical.

Keep cash and profit separate in the code

The cash calculation includes the whole principal-and-interest payment. Principal repayment reduces debt; it is not interchangeable with interest expense. The CFPB explains that distinction.

Tax, insurance and other budget items must also have explicit owners in the calculation. If the fixed budget already includes taxes and insurance, adding an escrow-inclusive payment can count those amounts twice. The CFPB's payment-component explanation helps distinguish principal and interest from the total monthly payment.

This study therefore labels its result cash surplus. It does not rename it accounting profit, net operating income or total return. Its maintenance reserve is a chosen cash allocation, not a claim about realized repairs.

Missing inputs should remain missing

A zero cost means the scenario explicitly assumes no cost in that field. An unavailable cost means the scenario is incomplete. Converting both to zero makes an incomplete budget look reassuringly precise.

The same distinction matters at the boundary. With zero occupied months, there is no finite break-even rent under this model. Returning zero would suggest an answer that the equation does not support. The model returns an undefined threshold while preserving the cash-budget result.

For the fictional example, the break-even gross monthly rent is:

200 + (7,000 + 12,000) / (11 × (1 − 0.08))
≈ 2,077.47

That is a scenario threshold, not a forecast that a tenant will pay it.

Make the next decision smaller

The useful next step is to replace a proxy with a property-specific observation: a verified price, a comparable rent, an actual cost or a financing quote. Then rerun the cash budget and inspect which assumption changes the answer.

You can change the study's assumptions, inspect its methodology and reproduce the source version. The point is to make uncertainty inspectable before a percentage becomes a recommendation.

AI generated this methodology adaptation from the published study and checked the fictional arithmetic. No customer outcome, firsthand investment result or independent review is claimed.

Why can AI lose track of something you already said?

Ahmadreza Samadi — Wed, 14 Oct 2026 23:56:23 +0000

You told an AI assistant the budget was $600, then it proposed a $900 trip. This fictional example makes one distinction clear: what you can scroll back to see is not necessarily everything used for the next reply.

Originally published on a-samadi.com on 10 October 2026. Primary references reopened and checked on 15 October 2026 for this edition. The examples and diagrams are illustrative, not observations of a particular product.

At a glance

Context: information available for this reply.
Memory: selected saved information, if the app supports it.
Training: how the model learned its underlying patterns.

What input does an AI use for each reply?

Context is the input available when a model produces a response. It can include your question, instructions, earlier messages and relevant files or tool results. The context window is a limited amount of working space. Its size depends on the model; text, images and the new answer can all consume it.

Source: Anthropic: Context windows.

A long chat may be managed by the app

A chat application can summarize earlier turns, leave some material out or retrieve past information when needed. Different products handle this differently. A visible transcript and the current input therefore need not be identical. A working desk is a useful analogy, not a literal description of storage.

Sources: Anthropic: Context windows, Effective context engineering for AI agents, Claude: Chat search and memory.

A summary can drop a detail

A shorter summary may preserve the main goal but omit an exact limit, date or decision. In the fictional example, “plan a trip” survives while “budget $600” is missing. Summarization can help a conversation continue, but the selection of what to keep matters.

Source: Anthropic: Effective context engineering.

Available does not mean correctly used

A model can overlook or misuse a detail that is still in its input. Larger context is not a guarantee of better recall or a correct answer. Losing access to a constraint and failing to follow an available constraint are different failure modes.

Sources: Anthropic: Context windows, Effective context engineering.

How does saved memory differ from current context?

Some applications save selected information across conversations or retrieve relevant earlier chats. These features depend on the product, settings and access. They are not the same as including every old message in every reply. Review important saved notes rather than assuming a complete permanent transcript is active.

Source: Claude: Chat search and memory.

A message is not an instant training step

Training adjusts a model to learn patterns. Ordinary answering, called inference, uses a trained model on current input. Sending a chat message does not itself instantly retrain the model. A service may have separate policies for later use of chat data; check its settings and terms.

Source: IBM: What is AI inference?.

Keep a short current brief

For a long task, restate the goal, hard limits and latest decisions together. Ask the assistant to list those constraints before answering, then compare the result with them. A fresh brief helps provide useful input; it cannot guarantee correctness. Check important names, dates and numbers in the final output.

Sources: Anthropic: Context windows, Effective context engineering.

The original explanation and ten-slide carousel show the mechanism visually. For an applied decision framework, explore Before You Build the AI.

About the author

Ahmadreza Samadi is a Dubai-based technology entrepreneur, Co-Founder & Technical Lead at Appraiva (Cleveland, Ohio; remote), and Co-Founder & CEO at Royal Abraj Group (Dubai).

AI assisted this adaptation and source review. No firsthand product test or measured improvement is claimed. For the weekly AI and property brief, see Start with the Decision.

Start with the decision, then build the AI

Ahmadreza Samadi — Wed, 14 Oct 2026 22:13:33 +0000

An AI product earns its place when it helps someone make a useful decision and act on it.

By Ahmadreza Samadi · 13 September 2026

Updated 10 October 2026

At a glance

Define the user’s decision first. Work backward to the evidence and its limits, design the next action and any human review, then evaluate the whole workflow—including incomplete information, review effort and delivery cost. Start with one decision the product can support well. The property-research example below is hypothetical.

When I assess an AI product idea, I start with a business question: what decision is difficult today, and what would make it easier?

That question provides a practical starting point for both product strategy and engineering. It identifies who needs the result, what information matters, and what the system must do beyond producing an answer.

Which decision should this AI product help someone make?

Consider a hypothetical property research tool. “Analyze properties with AI” leaves many product choices unresolved. “Help an investor decide which properties deserve further investigation” is more specific. It identifies an action and a point in a workflow where better information could help.

The distinction matters because a useful research tool may need to show supporting evidence, make comparisons easy, and identify missing information. A single score would only cover part of that job.

Work backward to the evidence

Once the decision is clear, ask what evidence a person would need to make it responsibly. In this example, that might include imagery, its capture date, relevant property attributes, and the limits of what can be inferred.

Then ask whether the necessary data is available, sufficiently current, and appropriate for the use case. These questions belong early in product development because the answers can change what the product should promise.

Design the action after the answer

An output becomes useful when it fits the next step. Does the customer shortlist an opportunity, request additional information, or send a case for human review?

That action shapes the interface and the architecture. It determines which information must be retained, which integrations matter, and where a person needs to be able to question or correct the system.

How would I evaluate the whole workflow?

For this hypothetical tool, I would evaluate several questions together:

Does it surface information that is relevant to the research decision?
Can a user understand the evidence and its limitations?
How much review is needed before taking the next step?
What happens when information is incomplete or the system is wrong?
Is the value of that assistance worth the cost of delivering it?

A model metric can inform those questions, but it cannot answer all of them. Product evaluation also needs to examine the experience of the person using the result.

Choose the smallest useful commitment

I would rather define an initial product around one decision we can support well than make a broad promise that is difficult to evaluate. A focused scope gives the team a clearer way to learn from customers and decide what to build next.

My approach is to connect the customer’s decision, the supporting evidence, the product workflow, and the engineering effort. That connection is where technical capability becomes a business proposition.

Put the method to work

Before You Build the AI turns these questions into an interactive decision brief. Explore a worked example, adapt it to a product idea, and export a first experiment.

If you prefer a text editor, the editable decision-first kit includes a blank copy, a separate fictional example and reading notes. Extract the ZIP, save a private working copy and fill the ten fields. This is another format for the same proposed planning aid, not a performed experiment or a validated assessment.

For the professional context behind my interest in property research workflows, see my work on AI real estate intelligence at Appraiva. The example in this essay remains hypothetical.

About the author

Ahmadreza Samadi

Technology Entrepreneur based in Dubai. Co-Founder & Technical Lead at Appraiva; Co-Founder & CEO at Royal Abraj Group.

DEV Community: Ahmadreza Samadi

More AI agents do not remove a shared bottleneck

The situation

What the source supports

Practical questions

Limits and disclosure

Source and animated example

Structured AI output: correct shape is not truth

The situation

What the source supports

Practical questions

Limits and disclosure

Source and animated example

Before combining property records, separate identity from dates

A fictional pair of records

Separate the three clocks

Preserve the unresolved link in the output

Make the next action explicit

Which Dubai property source should your AI answer use?

Keep the measure attached to the claim

A rental benchmark is another input

Give the summarizer an evidence card

AI cost per accepted result: beyond token prices

At a glance

How do you calculate cost per accepted result?

How does this connect to my work?

How would you test a property-research workflow?

What would I test first?

Measure cost per accepted result

Decision checklist

Further reading

Why dividing metro rent by home value does not give property yield

Start with the data contract

A fictional example makes the problem visible

Keep cash and profit separate in the code

Missing inputs should remain missing

Make the next decision smaller

Why can AI lose track of something you already said?

At a glance

What input does an AI use for each reply?

A long chat may be managed by the app

A summary can drop a detail

Available does not mean correctly used

How does saved memory differ from current context?

A message is not an instant training step

Keep a short current brief

About the author

Start with the decision, then build the AI

At a glance

Which decision should this AI product help someone make?

Work backward to the evidence

Design the action after the answer

How would I evaluate the whole workflow?

Choose the smallest useful commitment

Put the method to work

About the author