This article is part of a series on agentic systems:
The agents work. The system fails.
That is the pattern showing up across companies that tried to turn AI into a headcount strategy instead of a systems strategy.
Between 2023 and 2026, executives cut teams on the assumption that AI could absorb large parts of the workflow. The reversal came fast. Forbes and Human Resources Director, both drawing on the same rehiring pattern, point to the same outcome: companies tried to remove a workflow and discovered they had only removed the people holding it together. Careerminds survey data cited by HRD reports that two-thirds of companies are already rehiring roles they cut for AI. More than half said the rehiring began within six months.
TechRepublic reports that 55% of companies now regret AI-driven layoffs. Computerworld, summarizing Forrester, adds the missing diagnosis: too often management laid people off based on the future promise of AI, not on proven capability inside a working system.
The industry is not struggling because AI is weak, itâs because systems were removed faster than they could be replaced.
It accelerated the system until the weak parts became impossible to ignore.
Klarna became the clearest public example. Its leadership said AI was handling work equivalent to roughly 700 customer service agents, and the move was framed as evidence that replacement at scale had arrived. But as Digital Appliedâs Klarna analysis summarizes, the routine volume held while customer satisfaction fell on the complex interactions that actually required judgment, escalation, and trust. Klarna then shifted back toward rehiring and a hybrid model.
It was the same system failure in a more visible form.
| Local gain | System failure |
|---|---|
| AI handled routine volume | Quality dropped on edge cases |
| Staffing costs looked lower on paper | Rehiring and correction costs erased savings |
| Output arrived faster | Judgment, escalation, and accountability became the constraint |
The failure is easy to misread because the models did useful work. The diagnosis was wrong.
Companies removed the human layer that interpreted ambiguity, handled exceptions, and preserved continuity across the workflow. Once that layer was gone, the system degraded.
The easy conclusion is that the models still are not capable enough, but that misses the failure mode.
The failure sits in the system the agent operates in.
What broke first was the control layer around the agent: intent definition, handoffs, validation, and exception handling.
The same pattern shows up in engineering teams building agentic systems.
An agent can write a function or scaffold something meaningful, but ask it to help ship a real feature, one that spans research, design, implementation, testing, and rollout, and the surrounding system starts to break down.
That happens because agentic systems today often:
Those failures are connected. When work is passed forward as raw context instead of as a structured handoff, every downstream step has to reinterpret intent, constraints, and success criteria for itself. Local work speeds up, but system throughput does not improve.
This is not a model problem. It is a coordination problem.
As Maximilian Walterskirchenâs essay on piloting agentic engineering argues, autopilot did not simplify aviation. It forced the system around the cockpit to become more explicit.
Pilots were not removed from the loop. Their role shifted toward supervision, intervention, and takeover when automation no longer fit the situation. The new risk appeared at the handoff back to the human.
Automation does not remove the system. It shifts control within it.
The same structural change is happening in software organizations. Agents do more local work, but the surrounding system still has to decide when to delegate, what to pass forward, how to validate results, and where human judgment remains necessary.
The surrounding systems are failing under acceleration.
The 2025 DORA report names the principle directly: âAI is an amplifier, not a fix.â Faster drafting does not repair unclear ownership, brittle reviews, or weak validation. It exposes them.
The recurring debate about smarter models misses the main constraint.
The real question is not:
How do we make agents smarter?
It is:
How do we structure systems so intelligence can scale without losing control?
This series argues that agentic systems are fundamentally a systems engineering problem.
If faster agents still yield brittle systems, the problem is not a lack of intelligence. It is that too much of the work is still being held together by operators compensating in real time.
That makes the fieldâs maturity hard to ignore, because so many systems still depend on craft more than design.
]]>This article is part of a series on agentic systems:
A great demo is not engineering.
Agentic systems can look convincing right up until they meet real operating conditions.
The layoff reversals from Part 1 made the problem visible: companies automated visible tasks before they engineered the workflow around them.
The field can produce impressive one-off results. What it still lacks, in most cases, is the operating discipline that makes those results repeatable.
Early in any field, systems are built through skill, intuition, and iteration.
They rely on:
That is still where agentic systems are.
Success often depends on someone who knows how to phrase prompts, recover from failures, and manually steer execution back on course. That is not yet a robust operating model. It is a skilled operator compensating for missing structure.
Companies that removed humans early ran into exactly that: they mistook operator effort for system design. The hidden coordination work was still there. It only became visible once the system started failing.
You can recognize this stage quickly. The system works, but:
In engineering terms, the system is not repeatable.
Anthropic describes the operational root of this problem directly: context is a finite resource, so systems have to decide what to carry forward and what to compress. If that decision still lives in one operatorâs head, the workflow has not matured.
By 2025 and 2026, the official guidance had already moved away from prompt craft as the main design surface.
The shift is from improvisation to workflow engineering:
Prompt skill should not stand in for the system.
That does not mean every engineering task should be documented like a training manual. The leverage is in making recurring, cross-role, or high-consequence handoffs explicit enough that the work can be resumed, reviewed, and delegated without one operator carrying all the state.
This transition is familiar because every engineering field goes through it.
| Artisanal phase | Engineered phase |
|---|---|
| Operator memory | Explicit artifacts |
| Prompt heroes | Defined roles |
| Manual recovery | Validation and repeatable handoffs |
Agentic systems are still early enough that outcomes often depend more on how the workflow is operated than on how it is designed.
That dependence on operation over design is what immaturity looks like, and maturity only makes the next problem easier to see.
Moving from craft to structure makes a system more repeatable, but it also makes its limits easier to see.
Once work has to move across multiple stages, throughput is set by sequencing, coordination, and the slowest point in the flow.
đ Part 3: Agentic systems are bound by the same fundamental limits
]]>This article is part of a series on agentic systems:
Brittleness explains part of what teams are feeling. It does not remove the deeper limits that govern any workflow once it has to scale.
Every system that scales eventually runs into the same reality: the constraint defines the system.
These are not AI-native limits. Engineering has been running into them for decades.
The default assumption is simple: add more capacity, get more output. Add more agents, get more work done.
Many AI replacement efforts rest on exactly that assumption, which is why those efforts reversed so quickly. Adding more AI capacity did not remove escalation, approval, testing, or exception handling. It only pushed more work toward those stages.
Adding more agents still did not increase throughput in real systems. Local work sped up. The constrained stages did not.
Amdahlâs Law and modern delivery bottlenecks describe the same system from two angles.
| Constraint | What it means | Example |
|---|---|---|
| Serial fraction | Some work must still happen in order | Requirement clarification, approval, deployment |
| Bottleneck stage | One constrained stage sets throughput | Code review, integration, compliance review |
Amdahlâs 1967 paper says the maximum improvement to a system is limited by the fraction that remains serial. Atlassianâs modern explainer makes the team version concrete: if only about 20% of the lifecycle is individual work, even âinstantâ AI on that slice only raises overall throughput to about 1.25x because the other 80% still moves at normal system speed.
Operationally, the same limit shows up as a queue.
If review is slow, faster drafting creates a review queue. If integration is slow, faster implementation creates an integration queue. If approvals are slow, faster planning creates an approval queue. The form changes, but the underlying constraint does not.
Agentic systems often try to scale by increasing what is easiest to increase:
That improves local productivity without automatically improving delivery.
As Atlassian notes, once AI accelerates drafting, the system starts accumulating work at reviews, approvals, and risk checks. The Engineering Leadership Newsletter makes the same point with one concrete example: code review can become the bottleneck even when implementation gets faster.
That is why the layoff-and-rehiring cycle from Part 1 matters so much. The failure was not that AI produced nothing. The failure was that the system still depended on narrow stages where judgment, escalation, and validation lived.
The mistake is optimizing whatever looks most scalable.
Parallel work is usually easy to add. Sequential dependencies and bottlenecks are not.
Effective systems focus on:
Most of the system can get faster without the system moving faster at all.
Once constrained stages define throughput, raw upstream context becomes a liability.
You cannot ask every downstream step to reread everything and still expect the system to move. What crosses the bottleneck has to be smaller, sharper, and easier to verify than the full upstream discussion.
đ Part 4: Artifacts are compression: how systems handle complexity
]]>This article is part of a series on agentic systems:
Once a system has real bottlenecks, handoffs stop being optional paperwork because downstream stages are constrained.
If a downstream stage has to keep rereading and reinterpreting everything upstream, the bottleneck has not gone away. It has simply moved.
As systems grow, the amount of available information grows faster than the ability to process it. Pinecone notes that even long-context models suffer from the lost-in-the-middle problem, where buried information gets missed. Anthropic turns that into an operating rule: context is finite, so systems should pass forward the smallest set of high-signal tokens rather than the whole transcript.
If your system depends on full context, it is already broken.
Complex systems do not pass raw information forward; they compress it into artifacts.
Healthy delivery systems already do this. Atlassianâs PRD guide describes the PRD as a single source of truth for purpose, features, user needs, and success criteria. The same logic applies to specs, designs, test plans, and release evidence.
| Artifact | What it preserves |
|---|---|
| Product requirements document | Purpose, user needs, and success criteria |
| Specification or design doc | Constraints, interfaces, and decisions |
| Test plan | What must be validated before release |
| Diff and release evidence | What changed and how to verify it |
These are not documentation extras. They are the interfaces that keep downstream work from rediscovering upstream intent.
Artifacts move through a recurring pattern: each stage expands the current artifact through research, planning, or execution, then recompresses the result into something the next stage can actually use.
IBMâs traceability guidance shows how that flow stays coherent: requirements, implementation, and test artifacts remain linked so downstream stages can work from the current artifact instead of the entire upstream discussion.
Artifacts only reduce coordination cost if they are designed well.
| Property | Why it matters |
|---|---|
| Lossy but intentional | They preserve what matters for the next step |
| Role-specific | Different stages need different representations |
| Structured | Consistency makes them easy to consume and validate |
| Traceable | Later stages can verify they still satisfy earlier intent |
Without these properties, the handoff degrades back into raw context.
Many agentic systems still rely on large prompts with mixed context, loosely structured outputs, and a single agent spanning multiple roles.
That removes the structure Anthropic recommends: compact context, explicit compaction, and clear boundaries around what each step should receive. It asks each stage to recover intent from a transcript instead of receiving a handoff that already encodes the objective, constraints, and output shape.
The result is predictable: outputs drift, reasoning repeats, and ambiguity moves downstream.
A good artifact reduces ambiguity, but by itself it is only a local act of compression.
It becomes operational only when there is an ordered flow of stages that know when to expand it, when to validate it, and when to pass it on. Without that structure, even good documents stay inert.
]]>This article is part of a series on agentic systems:
Pipelines are easy to mistake for bureaucracy until the work actually has to survive multiple stages.
Artifacts only work because pipelines exist.
Not every exploratory task needs one, but once work becomes multi-stage, interdependent, and high-consequence, staged flow stops being optional.
NASAâs systems engineering handbook and Anthropicâs guide on building effective agents describe different domains, but both converge on the same point: scaled work moves through explicit stages with different responsibilities and outputs.
Pipelines are not a stylistic choice; they are a response to how complex work behaves.
| Force | Why it creates stages |
|---|---|
| Specialization | Different stages need different kinds of reasoning |
| Dependency | Some work cannot begin until earlier decisions exist |
| Risk management | Early stages reduce uncertainty before later stages commit resources |
Those pressures keep reappearing even when the vocabulary changes.
Software delivery moves from planning to design to implementation to testing to deployment. NASA describes comparable lifecycle stages for systems engineering, while Anthropic describes workflow patterns such as chaining, routing, orchestrator-workers, and evaluator loops. The vocabulary changes, but the requirement does not: multi-stage work needs explicit transitions.
While terminology varies, most systems still look broadly like this:
graph LR
Research --> Planning --> Design --> Implementation --> Testing --> Deployment --> Support
Each stage consumes an artifact, transforms it, and emits a new artifact for the next stage.
Pipelines matter because they are not just sequences of tasks. They are coordination mechanisms for turning one usable representation of work into the next.
Many agentic systems still ignore this shape. They rely on:
It can look flexible in a demo, but it scales poorly. Work loops, direction drifts, and validation gets deferred.
Anthropic explicitly recommends simple, composable patterns instead of unnecessary framework complexity for exactly this reason.
Prompt injection makes the security case concrete. OWASP treats indirect prompt injection as a major risk for systems that read external content and recommends least-privilege access plus human approval for high-risk actions.
That principle should already feel familiar from human systems. NIST recommends only giving users, or processes acting on their behalf, the least privilege needed for assigned tasks. In practice, a stage that reads broadly from untrusted sources should produce an artifact, not take broad write actions; review happens there, and only later stages get narrower permissions.
A pipeline explains how work moves. It does not explain why that flow survives change.
Stages can be clear and still remain fragile if their meaning lives in one operator, one model, or one transcript. Durability comes from boundaries that can survive changing tools, teams, and requirements.
]]>This article is part of a series on agentic systems:
Pipelines explain how complex work moves, but modularity explains what lets a system survive change.
Long-lived systems need modularity because tools change, models change, teams change, and workflows still have to keep working.
You cannot modularize what is not already structured.
If the stages, handoffs, and responsibilities are still ambiguous, there is nothing stable to make replaceable.
A pipeline can be clear and still be fragile if planning logic lives in one operatorâs head, approval criteria only exist in one long transcript, or recovery depends on one coordinating agent.
| Without modularity | With modularity |
|---|---|
| Changing one tool destabilizes the whole workflow | Components can change behind stable interfaces |
| Knowledge is trapped in one actor or session | Knowledge is carried in explicit handoffs |
| Failures spread across the system | Blast radius stays local |
Bus-factor problems are really design problems. The risk is not merely that someone leaves. The risk is that the workflow was never encoded in a form the rest of the system could reuse.
Good modularity means small, substitutable parts with a clean separation between interface and implementation.
The key question is not whether the boxes are large or small. It is whether change stays local.
A good boundary lets you replace one part without forcing the rest of the system to rediscover intent, state, or operating rules. A bad boundary only redraws the diagram while the real coupling remains hidden underneath.
That matters even more in a field moving this quickly. Pipelines do take time to build and maintain, but the real cost comes from brittle, tightly coupled workflows that force full rewrites whenever a better tool arrives. If the interfaces are stable and the custom logic stays light, migrations remain local and often get faster too.
Part 1 pointed to the aviation version of this problem, but only in a narrow sense.
Commercial aviation is far more standardized than most software work, so the analogy is not that engineering can be formalized like pilot training. As Maximilian Walterskirchen points out, the useful lesson is narrower: autopilot did not remove pilots from the system. It changed the interface between automation, procedure, and human takeover. Aviation became safer because the system learned to make that handoff explicit.
Long-lived agentic systems need the same discipline. When a model changes, a tool fails, or a task falls outside the expected path, the workflow needs a stable takeover point rather than a hidden dependency on one giant prompt.
| System example | Stable interface |
|---|---|
| GitHub Copilot cloud agent | Plan, branch diff, checks, and pull request are explicit handoff objects 2 |
| Microsoft agent orchestration guidance | Typed payloads, persisted state, evaluator loops, and human approvals keep stages replaceable 4 |
| OpenAIâs agent guidance | Start single-agent, then add specialization only when the task shape actually demands a new boundary 5 |
These systems do not scale by hiding more state inside the model. They scale by making interfaces explicit enough that one stage can evolve without collapsing the others.
Modularity buys three things in practice:
Automation makes modularity more valuable, not less.
Once the boundaries are clear enough to survive change, the remaining problem is organizational.
Who plans, who executes, who checks, and where judgment stays human determines whether modularity becomes a real operating model.
đ Part 7: Designing agentic systems for engineering organizations
]]>This article is part of a series on agentic systems:
The first post in this series opened with layoffs, regret, and rehiring. It also used autopilot as the precedent that matters: automation does not remove the system, it redistributes control inside it. That is the design problem for engineering organizations.
The goal is not to maximize agent count. It is to place automation where it reduces load without erasing the handoffs, validation, and judgment the organization still needs.
At scale, the unit of design is not the model. It is the workflow the model participates in.
OpenAI frames agents as systems that accomplish tasks through tools and guardrails, not isolated prompts. Microsoftâs Azure guidance and Copilot Studioâs multi-agent guidance make the same point operationally: keep orchestration simple, validate typed payloads, persist state across stages, and require human approval for high-impact actions.
The same pattern already shows up in GitHub Copilotâs cloud agent flow5. Research happens first. A plan is formed. Work happens on a branch. Checks run. The diff gets reviewed. Only then does the pull request move forward.
For a feature request that touches API behavior, UI text, tests, and rollout, a workable flow looks like this:
| Stage | Primary actor | Output | Gate |
|---|---|---|---|
| Planning | Human lead or planning agent | Task packet with scope, constraints, and done definition | Scope review |
| Implementation | Coding agent | Branch diff plus changed-files manifest | Tests and linters |
| Evaluation | Evaluator agent plus CI | Eval bundle with results, risks, and policy checks | Quality threshold |
| Approval | Human reviewer | Pull request decision | Merge approval |
| Rollout | Release automation plus human oversight | Deployment state and rollback path | Production gate |
That shape matters because each stage has a clear responsibility, a clear artifact, and a clear point where the next actor can say no.
It also does not mean the human only appears at final approval. In practice, the highest-value human involvement often happens earlier: on scope, design direction, risky changes, and the points where the system needs judgment rather than throughput.
The principles that follow are not abstract best practices. They are the places teams usually lose control once agents move past the demo stage.
If the workflow is ambiguous, undocumented, or negotiated ad hoc in chat, agents will not fix it. They will execute the ambiguity faster. OpenAIâs guidance is blunt that âclear instructions reduce ambiguityâ and improve agent decision-making.
Requirements, specs, design docs, diffs, test plans, and approval records already move work between humans in many organizations, even if they exist unevenly. Where those interfaces already exist, agent stages should plug into them rather than inventing a parallel AI-only process. Where they are still weak, AI increases the payoff of making them just explicit enough to support review and handoff. OpenAI explicitly recommends to âuse existing documentsâ when defining agent routines.
Use sequential flow for linear dependencies, specialization only when roles truly diverge, and maker-checker loops where quality is the main problem. Do not choose a pattern because it sounds advanced. Microsoft says to âuse the lowest level of complexity that reliably meets your requirementsâ.
One actor can sometimes do more than one role, but the responsibilities should still be distinct. GitHubâs cloud agent flow deliberately separates âresearch a repository, create a plan, and make code changes on a branchâ before review. A system that cannot tell the difference between deciding, doing, and checking will drift.
Deterministic checks and approval gates belong at the points where artifacts are produced and irreversible actions become possible. OpenAI argues that high-risk actions should trigger human oversight, and Microsoft goes further by saying to ârequire human approvals for high-impact cross-agent actionsâ.
Those stage boundaries are also security boundaries. They let teams limit capabilities, inspect artifacts before granting more power, and avoid giving a context-exposed agent more write access than it needs.
If review is slow, improve review. If validation is brittle, improve validation. If context transfer is failing, improve the artifact. More agents do not matter if the bottleneck still sits elsewhere. In many engineering teams, that bottleneck is PR review, which means the useful question is not âcan AI replace review?â but âcan better reviewer instructions, tighter diffs, stronger design context, or earlier evaluator feedback raise the signal of review?â Microsoft recommends tracking performance and resource usage metrics for each agent so that you can establish a baseline, find bottlenecks, and optimize.
Aviation absorbed autopilot by redesigning supervision and takeover, not by pretending pilots were obsolete. Walterskirchenâs core warning is that âpilots had been promoted from operators to supervisors of the machineâ. Engineering organizations should do the same with merges, production changes, policy decisions, and exception handling.
Agentic systems donât turn bad systems into good ones. They turn unclear systems into faster chaos. That is the lesson behind the layoffs in Part 1, the throughput limits in Part 3, and the autopilot precedent that runs through the series.
Taken together, the lesson is narrow and unsentimental: agents belong inside engineering organizations as bounded contributors, not as replacements for the organization itself.
They can draft, implement, and evaluate, but they only create durable leverage when handoffs are clear, validation is built in, and humans remain accountable at the irreversible edges.
The systems that scale will not look like autonomous swarms. They will look like disciplined engineering teams with better tools.
The writing process ended up reinforcing the same point.
đ Part 8 is a postmortem on that process, and on why the writing only became good once it was treated as a system too.
]]>This article is part of a series on agentic systems:
This series was mostly written with AI assistance.
I want to say that plainly because pretending otherwise would be silly. What feels more worth saying is that the parts that work did not come from some perfect prompt. They came from turning a messy writing process into something more structured: plans, artifacts, review passes, explicit roles, and a lot of manual correction when the drafts drifted or sounded wrong.
That felt worth writing down. If the series has a useful point, I more or less learned it while writing it: AI was helpful, but only after I gave it a system to work inside.
I did not get here by asking for seven finished essays and polishing the result. The process was much more iterative. Microsoft Research describes LLM-assisted writing as a process where users âactively refine, explore, and co-construct textâ, which feels close to what happened here.
| Phase | Primary tool | Output | What mattered most |
|---|---|---|---|
| Discovery | ChatGPT voice chat | Raw ideas, tensions, candidate directions | Speed and breadth |
| Architecture | ChatGPT plus manual synthesis | High-level plan, narrative spine, article map | Coherence |
| Evidence | ChatGPT deep research plus manual triage | Source list, prior art, examples | Source quality |
| Persistence | Markdown repository | Plans, research notes, article briefs | Stable artifacts |
| Drafting | Copilot | Initial article drafts | Throughput |
| Review | Copilot plus manual critique | Gap analysis, rewrite targets, defect patterns | Judgment |
ChatGPT handled discovery, planning, and source gathering. Copilot handled the file-based drafting and review loops. My part was to keep cutting weak sources, fixing tone, and deciding what survived.
In practice the loop was simple:
That separation mattered more than the specific tools.
What made it work was structure, artifacts, and iteration.
OpenAI argues that customers âtypically achieve greater success with an incremental approachâ. That is a better description of the workflow than any story about fully autonomous generation.
Moving the work out of chat and into plans, briefs, and drafts made it easier to keep the argument stable. Once those artifacts existed, the models had something concrete to work against instead of a fading conversational context.
The useful skill ended up being learning how to inspect output, identify the failure mode, and redirect the next pass without reopening the whole problem.
Most of the quality still came from manual judgment: rejecting obscure sources, removing citation clutter, rewriting robotic transitions, and cutting sections that sounded tidy but dead. That is probably the part people underestimate most when they talk about AI-assisted writing.
The hardest failures were structural rather than grammatical or obviously hallucinatory.
The models were prone to soft argument drift: flattening distinctions, overexplaining points that had already been made, or turning a causal sequence into a list of adjacent observations. That showed up most clearly in endings and transitions, which often sounded like mini summaries instead of the next step in an argument.
They were also too willing to keep weak evidence if it fit the paragraph: obscure sources, repetitive links, or claims that sounded supported until the source was inspected closely.
And then there was the prose itself. It could look polished while still feeling generic. The literature review paper on AI-assisted writing warns that âLLM outputs always appear at first glance to be well written, well informed and thought out, but closer reading reveals gaps, biases and lack of depthâ. That matches my experience almost exactly.
The uncomfortable part is that the workflow depended on me being able to notice those problems. If I could not tell when a source was weak or a section had subtly drifted, the process would have produced something smoother and worse.
The most useful part of the postmortem for me is what I would change next. The series got to a result that I like, but not efficiently.
I would define the thesis, source bar, stylistic anti-patterns, and review rubric much sooner. I would also create a claim map and source map for each article before drafting begins. A lot of the late-stage editing came from discovering those constraints too late.
Too many prompts tried to fix everything at once. Next time I would separate factual review, structural review, prose review, and citation review. I would also track time per article, major rewrite passes, source replacements, and human editing time after the first draft. Without that, it is easy to say AI made the process faster and much harder to say where it actually did.
I kept rediscovering the same roles in ad hoc prompts: series architect, source triage reviewer, article planner, structural critic, style enforcer, citation hygiene reviewer. Next time I would codify some of those into reusable skills or specialized agents with clearer contracts.
OpenAIâs guidance is to âmaximize a single agentâs capabilities firstâ, so I would still start small. But GitHubâs documentation notes that âyou can create specialized custom agents for different tasksâ, and that seems like the right direction for work that keeps repeating the same evaluation patterns.
GitHub also puts this plainly: âThe more Copilot cloud agent knows about the code in your repository, the tools you use, and your coding standards and practices, the more effective it will becomeâ. The writing equivalent is straightforward: the more the system knows about source quality, tone, formatting preferences, and the series spine, the less time gets wasted rediscovering them.
The series argued that agentic systems do not scale because of intelligence alone. They scale when work is decomposed into artifacts, pipelines, interfaces, and validation loops.
The writing process followed the same pattern. Publishable essays came from structured plans, stable artifacts, repeated review loops, and human intervention rather than one-shot generation.
The literature review paper is even harsher on this point, warning that âa press-button strategy leaving AI to do the work is a recipe for disasterâ. That is exactly right. The more autonomous the drafting looked, the more human the editing had to become.
This also speaks about the immaturity of my writing process. I managed to get by because it was only a few articles, but it would definitely not scale to something like a multi-chapter book without the improvements above.
So if there is one lesson I would keep from this process, it is this: AI did not replace the writing system. It made the writing system more necessary.
]]>A similar solution can be used for Doctrine ORM.
Here is an example, removing the uniqueness on emailCanonical of FOSUserBundle:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
<?php
# ClassMetadataListener.php
namespace Acme\UserBundle\EventListener;
use Doctrine\ODM\MongoDB\Event\LoadClassMetadataEventArgs;
/**
* Ran when Mongo metadata is loaded.
*/
class ClassMetadataListener
{
public function loadClassMetadata(LoadClassMetadataEventArgs $eventArgs)
{
$classMetadata = $eventArgs->getClassMetadata();
// Override FOS to not have unique emails
if ($classMetadata->reflClass->name == 'FOS\UserBundle\Model\User') {
foreach ($classMetadata->indexes as $i => $index) {
if (count($index['keys']) === 1 && isset($index['keys']['emailCanonical'])) {
$classMetadata->indexes[$i]['options']['unique'] = false;
break;
}
}
}
}
}
1
2
3
4
5
6
# services.yml
services:
acme.user.metadata_listener:
class: Acme\UserBundle\EventListener\ClassMetadataListener
tags:
- { name: doctrine_mongodb.odm.event_listener, event: loadClassMetadata }
Cache stampede, put simply, is when your process is trying to fetch an expensive cache entry, it is not there, and tries to build it, but a simultaneous process comes and does the same thing. This results in resource waste because of processes all trying to do the same thing, uselessly.
The trick is to put a lock on the cache entry and make the other processes wait. I use the trick of having a TTL for the cache calculation. This way, even if the server crashes or there is an exception, the lock will expire and another process will take over. This estimation is also used to calculate how much time to sleep while waiting.
This example uses Doctrine Cache as a global variable, but this should definitely be refactored (or change to another system).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
<?php
# cacheGetDefault.php
/**
* Get a value from the cache or compute it using a callback
* Includes cache stampede protection
* @link http://en.wikipedia.org/wiki/Cache_stampede
* @link http://blog.lavoie.sl/2014/12/preventing-cache-stampede-using-doctrine-cache
* @global cache Doctrine\Common\Cache\Cache
*
* @param string $key Cache key
* @param Closure $callback Computing function
* @param float $ttl Seconds
* @param float $stampedeTtl Seconds before cache stampede expires
* Should be about 2-3 times the estimated time to build the cache
* @return mixed
*/
function cacheGetDefault($key, Closure $callback, $ttl = 0, $stampedeTtl = null)
{
global $cache;
$data = $cache->fetch($key);
if (false !== $data) {
return $data;
}
if (null !== $stampede) {
$stampede = max((double) $stampede, 0.001); // prevention for infinite ttl
// data is being computed, wait
while ('__STAMPEDE__' === $data) {
// wait 1/20th of the stampede TTL, to give the CPU a chance
sleep($stampede / 20);
$data = $cache->fetch($key);
}
}
if ($data === false) {
if (null !== $stampedeTtl) {
// acquire lock
$cache->save($key, '__STAMPEDE__', $stampedeTtl);
}
// compute the actual data
$data = $callback();
}
$cache->save($key, $data, $ttl);
return $data;
}
1
2
3
4
5
6
7
8
9
<?php
# useCache.php
$cacheTtl = 3600; // an hour
$stampedeTtl = 5; // seconds before releasing lock
cacheGetDefault('recent_tweets', function() {
return file_get_contents('https://api.twitter.com/1.1/search/tweets.json?q=@lavoiesl');
}, $cacheTtl, $stampedeTtl);