Two limits on agentic coding remain stubbornly human: seeing what should be built, and believing it can be.
The search party had reached the southern shore, and the ocean stretched a hundred yojanas to Lanka. (A yojana is an ancient Indian measure of distance, several miles long.)
In Vālmīki’s telling, the vānaras go round one by one, each saying how far he can leap. Ten yojanas, says one. Twenty, says another. Old Jāmbavān says that in his youth he could have managed ninety, but not now. Prince Aṅgada thinks he could reach Lanka but doubts he could come back. The mission, and Sītā’s life, seem to end at the water’s edge.
All this time, Hanumān sits apart, silent.
Then Jāmbavān turns to him. He reminds Hanumān who he is: the son of the wind, the one who as a child leapt for the sun, thinking it a fruit. In the version many of us heard as children, Hanumān had been cursed by sages to forget his strength until someone reminded him. Jāmbavān reminds him. Hanumān rises, grows to the size of a mountain, and crosses the ocean.
The strength was there all along. What was missing was someone who believed in it and said so.
The module nobody touches
Every codebase I have worked with has one. The billing engine written in 2011. The integration layer nobody fully understands. The monolith everyone agrees should be split, and everyone has quietly concluded never will be.
That conclusion was rational when it was formed. A rewrite meant a year of a senior team’s time and real risk. The question is whether it is still rational, and almost nobody is asking.
It is not the agents that are holding back. They will happily attempt the rewrite if asked. It is us. We are sitting on the shore, counting yojanas with the numbers we learned years ago.
The first ceiling: seeing what should be built
There is a real limit on the agent side too, and it is worth being precise about it.
Terence Tao, describing his work formalising mathematics with AI, observed that the tools are good at local improvements and can carry out a large restructuring once he explains it, but they do not spontaneously discover that a restructuring is needed. I see the same in code. An agent will refactor beautifully to a design you describe. It rarely stops and says: this whole module is the wrong shape, here is a better one.
An agent answers the question you asked. It does not tell you that you are asking the wrong question.
So the architect’s job does not disappear. It moves up. Less time choosing variable names and reviewing loops. More time on the questions agents do not raise unprompted: what is the right abstraction, what should not be built, which old assumption is now false. As I wrote in “We Marry the Right One, Not the Perfect One”, the work is fitness, not perfection, and judging fitness is still ours.
The second ceiling: believing it can be done
The deeper limit is belief. Psychologists call it self-efficacy: people who believe they can do something attempt more and achieve more.
The stories are familiar. In 1939, George Dantzig arrived late to a statistics class at Berkeley, copied two problems from the board and solved them as homework. They were unsolved problems; nobody had told him. Roger Bannister ran the first sub-four-minute mile in 1954, and John Landy beat it forty-six days later. This April in London, Sabastian Sawe ran the first marathon under two hours in a record-eligible race, and the runner-up, Yomif Kejelcha, went under two hours as well, in his first marathon.
Our own history has a better example than any of these. In 1913 a clerk at the Madras Port Trust, with no university degree, posted pages of theorems to G. H. Hardy in Cambridge. Hardy could have filed them with the other letters from cranks. Instead he recognised what he was looking at. Srinivasa Ramanujan’s strength had been there all along. Hardy was his Jāmbavān.
Demonstrated feasibility spreads. Once one team on your floor rewrites its untouchable module with agents, three others will try within a quarter. Someone just has to go first, and someone has to say out loud that it is possible.
Being Jāmbavān
If you lead engineers, this is now one of the most valuable things you do. Some mechanisms that work:
- A “previously impossible” backlog. Ask each team for the three things they have written off as infeasible. Put them on a visible list.
- Funded spikes on the untouchable. A spike is a short, time-boxed experiment: here, one or two days with agents on the scariest item. The goal is not to finish. It is to recalibrate what the team believes.
- Share the crossings. When a team does something it thought impossible, make sure everyone hears, with the numbers. Bannister’s real gift was to Landy.
- Permission to fail small. Spikes in throwaway worktrees (separate working copies of the repository that can simply be deleted), not heroic rewrites announced to the board. Linus Torvalds described Linux, at the start, as just a hobby that would not be big or professional. Low stakes made the attempt possible.
And remember that the agent needs a Jāmbavān too. Tell it the hard target is reachable and to keep going past the first obstacle. Just give it the protected oracle and the honest exit from Part 7, so the leap lands in Lanka and not in the sea.
For the Weekend
Ask your team: what three pieces of work have we decided are impossible? Write them down. Pick one. Give two people and an agent two days on it.
Example. Suppose the team’s three write-offs are: retire the 2011 billing engine, add end-to-end tests to the mobile app, and replace a hand-rolled job scheduler with a managed one. They pick the scheduler.
Day 1, morning: map it before touching it.
USER STORYAs the engineer leading the scheduler spike, I want a map of every job thelegacy scheduler runs, so that we port nothing blind.DEFINITION OF READY- Read access to src/legacy_scheduler/ and all its callers.DEFINITION OF DONE- spike/scheduler-map.md listing every job type: its trigger (cron expression, event or manual), its side effects (tables written, messages sent, files produced), and any dependency on another job.- Anything uncertain is flagged, not guessed.- You MUST NOT change any code.DEFINITION OF SUCCESS- The number of jobs in the map equals the number of entries in the scheduler's registry table.
Day 1, afternoon: pin today’s behaviour. Characterisation tests record what the code does now, warts (bugs) and all, so a port can be checked against it. Snapshot testing with syrupy, a pytest plugin, keeps this short:
import pytestfrom legacy_scheduler import JOBS, run_oncepytest.mark.parametrize("job_name", sorted(JOBS))def test_job_characterisation(job_name, frozen_clock, sandbox_db, snapshot): frozen_clock.set("2026-11-02T00:00:00+05:30") result = run_once(job_name, db=sandbox_db) # Records exactly what happened today, including behaviour we think is wrong assert result.side_effects == snapshot
The prompt that produces these:
USER STORYAs the engineer leading the spike, I want today's behaviour of every jobpinned down, so that any port can be proven equivalent.DEFINITION OF READY- spike/scheduler-map.md exists.- The sandbox_db and frozen_clock fixtures work, and syrupy is installed.DEFINITION OF DONE- One characterisation test per job type in tests/characterisation/, using syrupy snapshots generated from the current code.- Behaviour that looks like a bug stays in the snapshot and is listed in spike/suspected-bugs.md.- You MUST NOT fix anything.DEFINITION OF SUCCESS- All characterisation tests pass three runs in a row on unchanged code, so none of them is flaky.
Day 2: port a few and measure the rest.
USER STORYAs the platform team, we want four representative jobs running on themanaged scheduler, so that we can estimate the full port from evidence.DEFINITION OF READY- Characterisation tests pass for all 23 job types.- The managed-scheduler feature flag exists, default off.DEFINITION OF DONE- nightly_invoices, dunning_emails, ledger_close and report_export are ported, each behind the managed-scheduler flag.- For each of the remaining 19 jobs: an estimate in hours, and what makes it harder or easier than the four ported, with the uncertainty stated.- You MUST NOT modify the characterisation snapshots.DEFINITION OF SUCCESS- Each ported job passes its characterisation test with the flag on and with it off.
The flag-guarded registration looks like this:
def register(job_name: str, spec: JobSpec) -> None: if flags.enabled("managed-scheduler", job=job_name): managed.schedule(job_name, cron=spec.cron, handler=spec.handler, idempotency_key=lambda run_date: f"{job_name}:{run_date}") else: legacy.register(job_name, spec)
Day 2, evening: the report that recalibrates the team.
USER STORYAs the engineering manager, I want a short, honest spike report, so thatthe team can decide whether the scheduler port belongs in next quarter.DEFINITION OF READY- The spike branches, test results and spike/suspected-bugs.md are available.DEFINITION OF DONE- spike/REPORT.md, under 400 words: what we tried, what worked, what surprised us, a low and a high estimate for the full port, the three riskiest jobs and why, and the suspected bugs found.DEFINITION OF SUCCESS- Every number in the report links to the test run or file it came from.
In this scenario they do not finish. They do learn that the full port is about six weeks, not the year everyone assumed, and that two of the “scheduler bugs” people had complained about for years are visible in the snapshots. The scheduler moves from impossible to next quarter’s plan. Then someone asks whether the billing engine is really as bad as everyone thinks. That question is Jāmbavān’s real work.
There is a quieter payoff: accurate estimation (the oxymoron). Look again at the shore. Each vānara calling out how far he could leap was a round of planning poker, the estimation game in which every engineer shows a card with a guess and the team discusses the spread. The cards were honest but stale, anchored on what each of them could do years ago. Jāmbavān broke the deadlock with evidence, not encouragement: he knew what Hanumān had already done. A two-day spike does the same for a team. Once four jobs have actually been ported, the estimate for the other nineteen is a measurement scaled up, not a fear priced in. In the next poker round the cards cluster instead of ranging from 3 to 40, and the plan becomes predictable because it rests on something the team has already seen.
You may not reach Lanka. You will learn how far you can actually jump.
