We have to re-learn to walk alone

January 23, 2026

Reading the article about Nexus that Obie has posted I got absolutely struck. Yes, it can be said without a shade of doubt that the modern way of building software, the late-2025-way with Opus 4.5 in the picture, is markedly different from the one we operated in for the last decade (or more).

I haven’t been sitting on my hands either. One of my smaller pursuits, now that I am a proud self-employed raconteur, has been moneymaker - a piece of kit I wanted for all the business aspects of the said raconteurship. Think:

basic accounting
bank statements and balances
invoicing
time tracking
…all of that - across several projects, clients and managing entities

And, out of principle, I’ve decided to take my chances and release the reins - let the models “drive” the application much more than I did in the past 6 months or so. Because it is important to learn, first and foremost - how to care less about code.

And my experience has not been dissimilar from what Obie describes, with a few important differences. But what struck me much stronger is how other humans fit into this.

Let me explain. If you squint, you will notice one element missing from Obie’s story: other team members.

🧭 I am currently available for contract work. Hire me to help make your Rails app better!

In the world of product development that we all got used to from start-ups (and - especially so - scale-ups) of the late 2010s we have retained a number of maxims about product development - and the software engineering craft - that looked immutable.

The team has to be… there has to be a team, basically.
It has to be inclusive and play to everyone’s strengths
Most decisions happen by consensus
If you want a decision touching someone’s professional “turf”, you must route it through that individual (UX, QA, compliance, DBA, infrastructure/platform)

It looked like building a web product was not going to be the creative pursuit it has been from the start of the early Web, but some refined exercise in near-Soviet bureaucracy combined with an incredibly touchy-feely eggshell walks, at every step.

But LLM-assisted development shifts the gears on this, and I am happy it is happening. Because the way it used to work was not sustainable, not tenable - and highly depressing for anyone having the audacity to actually care about what they build.

Here are my thoughts about how to lean into the new era - note that this is my personal opinion, and by no means do you have to do any of that. I do bet though, with a degree of certainty, that top-notch joints who will be able to ride the new process will do either all of those things, or most.

Shift consensus left

While we did gain a lot in inclusivity and kindness in the times of ZIRP, we also grew a big dependence on consensus. Will Jane like this pre-commit hook? Will Bart want to review the button alignment before we ship? Will Leontien from legal not want to first write a policy for this feature?

LLM-assisted development presents an incredible challenge for applying consensus at any given level: practically anywhere a requirement for consensus will mean that both the operator and the model will have to stop to obtain it. The key reason why Obie is describing his incredible velocity with Nexus is not only that he knew, what he wanted - in detail! - but also that the approaches were not questioned!

Imagine the same happening in a high-consensus setting, where the operator is not solo and not in a leadership role - and not autonomous. Imagine Obie and I work together within an engineering team - just pretend, ok? I would have questioned the use of a triplet store and RDF quite vehemently, because this - in my book - is “interesting tech that makes the author feel clever for using it, but brings little value”. Imagine this team was high-consensus, the engineering manager was “more of a people person” and absent, and clear delegation was not defined. I can tell what would have happened: that system would not have been delivered that quick.

And those consensus junctions come up all the time. And the more people are involved - at every level - the more of those points there will be. The more politicised the org is where consensus must be obtained, the more cautious people will be with OK’ing others’ decisions. Is it “safe” promotion-wise to let that peer “ship whatever they want?” Aren’t they too full of themselves? Can you really “just do things”?

If we want to benefit from the LLM product building approach, we must

…reduce the number of consensus junctions
…shift them to earlier and earlier phases, with highest level stakeholders participating - and making decisions at broader levels

Every approval, every discussion, every conflict and competition causes this workflow to get closer and closer to the “previous” model of software development. Yes, the pinnacle of the “new world” is that with every piece of software there is exactly one developer/designer who has 100% control over what gets built, ideally - a solo founder. But this is not attainable nor scalable, and if some products are gigantic already - what will be the expected growth of them with the LLM tools?

So: find where consensus junctions are present, and at least try to shift them left, and delegate the rest. And yes, it does mean “less consensus, more agency”. Are there 3 people responsible for making a decision? Split it into parts: a smaller one requiring consensus of, say, 2 people (but higher up the chart) and the part that can be given to the operator. You do reviews with 2 colleagues? Try doing reviews with 1, if you know that reviews are often not for fault-finding or correcting things - but for bikeshedding.

Shift micromanagement right

As already mentioned, our work largely consists of making a very large number of decisions. Every decision that needs synchronization with others creates a hiccup: in a highly iterative process those decisions can be made very quickly, provided there is as little approval as possible between an LLM proposing something and a human allowing it to continue or not.

And here comes another twist. The reason why it is possible to work so fast this way is that there is much less rote “coding” and much more “assembly”. You don’t code every function by hand - you either imagine what the outcome should look like, or you let the model give you options. The key is having a vision of what you want in the end. If that vision is strong and detailed - and you are not being micromanaged on every decision - that vision can become a perfect roadmap for the model to execute.

The issue is, rather, that this requires a confluence of 2 factors.

The operator must either have “A-to-Z” vision or be able (and permitted!) to improvise along the way
The operator should not have to stop at every edit and ask someone “is that OK?”

Instead of the operator getting micromanaged by other people (peers, his engineering lead, stakeholders) - he should be focusing on micromanaging the model and the piece of work being shaped. This requires being explicit and directive - what ADDD calls “dictating” rather than asking. You code with the AI, not the other way around.

This button is misaligned, align it
You have created an indirection of 4 methods which are only used in one spot, combine and inline all of them
Examine this change from the point of view of a security consultant, what is broken?

The faster you want to go when code is no longer the bottleneck - the more agency the operator needs, and the less micromanagement should be permeating what is “to the left” of them.

And it is hard. And I mean: hard. I’ve been in situations where the engineering leadership was nearly absent from the “hands on” conversations, and I’ve been in situations where the engineering leadership “wants to play with the rest”. And I undoubtedly prefer the latter. It does have a pitfall, though: for a person with a decent vision of what-is-it-we-are-making-here and sufficient authority it can become unbearable to try and translate their vision to another team memeber. They can hammer that vision into an LLM with a stick and some swearing, spending quite a bit of time - but what do they then have that team member for? Is he worth his salary then?

So the incredibly, incredibly heavy challenge of this new way of working is having sufficient trust to delegate. And it also requires swallowing your pride sometimes, and realizing that the other person will drive the process in a slightly different way than you wanted. You can direct but do it at the right level! The micromanagement of the execution should be with the operator talking to the model and making edits.

But how do we even maintain quality?

A sophisticated stochastic emitter - which is what those models are - is just that, a stochastic emitter. It will produce unexpected results, it will produce garbage - and it is not gifted with telepathy. However, unlike the subjective, touchy-feely humans it can be imperatively instructed and harnessed into conformance - which is exactly how quality can be maintained.

I am not talking about the same level of quality we got used to in the well-cushioned ZIRP years, where choosing between a service object and a command could take 4 people a better part of a few days. This is no longer feasible, simply because the amount of output will increase both factually (very simply: LLMs spit out more code than a human to achieve the same objective) and optically - if the velocity of development is now demonstrably higher, make no mistake: the moving forces of the modern enterprise will also demand more output. For the same compensation, within the same - or drastically shorter - deadlines.

But quite a bit of quality can and should be maintained, even in this wild world of ours. The premise is simple: we need blanket tools, which require minimal configuration, allowing the most bang-for-the-buck impact for safeguarding quality.

Just a few examples. Tests (and types) ensure that the code does what it is supposed to do. Because we are dealing with a piece of software - and not a human - it is perfectly fine to do Befehl-driven-development - a.k.a. committing the cardinal sin of the late 2010-s by telling the executing party to do things exactly as you say. This type of guidance is very blunt, very violent and uncompromising - but it is perfect for providing guardrails. For example:

I need you to write tests for the TransactionIngester first. Make the tests very high-level. Ensure that loading test/mutations_camt.xml produces at least 20 bank transactions, and validate all of their amounts to be correct and have at least 2 decimal places. Ensure the currency is the same across all of them. Once you have the tests written, stop and let me verify.

This sort of thing would be absolutely frowned upon just a year or two ago. How dare you tell which tests have to be written? How dare you specify the exact things to be asserted on, and how dare you specify that the test should be high level?

You know what happened to people giving this kind of direction about 2018? They got dragged to HR, that’s what happened.

In actuality, there are answers to all of those questions. The tests should be high level so that the most of the system gets exercised with the minimum amount of setup having to be done. The tests should do basic assertions because too many assertions which are too specific make tests brittle. The tests should assert the currency is set correctly (and the same) because with that particular standard all of the entries imported from one file must have the same currency. And the assertion should be for the same currency and not for EUR. Why? Because the file may get updated or replaced with another - the assertions have to keep working and they have to make sense.

Telling a junior (or even worse: a medior) developer to “write tests exactly so” would quickly create resentment if the execution is handled by a human, and would take a great amount of skill - also in hiring - to both have it done and not have the person doing the work hang their hat in desperation.

Yet, those super-exacting instructions - and blanket automated QC maxims - are exactly what is needed with LLM-assisted development. Moreover, they become essential because - while you can’t impose a style and a set of tools on a team of humans - you can, and should, impose it on a stochastic sampler. It is not “micromanaging” - it is setting constraints.

This is why Agentic Dictatorship-Driven Development (ADDD) works: LLMs are pattern matchers, not entropy generators. When you give vague instructions, they pattern-match to the most common solutions in their training data - purple gradients, Sarah Chen testimonials, AWS setups, WordPress installations. The only way to escape these common attractors is to explicitly close those paths with constraints. “No TypeScript package in Bun” prevents Node.js cargo culting. “No gradients” prevents the purple-to-pink default. “No AWS” eliminates CloudFormation suggestions. Anti-requirements are just as important as requirements - they tell the model what not to do, which is often more valuable than telling it what to do.

What are those guardrails? Simple, really - and we know all of them:

Forced precompilation and eager loading. App doesn’t build or doesn’t load? Redo.
Forced linting and reformatting. Linter not happy? Format to satisfy linter, redo.
High-level tests with maximum amount of triggered systems. Test not green? Redo.
Automated verifications of output (validators). Generated an invalid JSON? Redo.

While insulting to a developer, for LLMs this is the way to maintain quality. Moreover, those tools should be driven at their default settings for as much as possible, because “introducing a linter” - just like introducing an extra check for “our documentation should build without errors” - should be a no-brainer. It is not going to be there for humans to decipher - it is going to be there for the LLMs to be running them, almost on autopilot. Hundreds of times.

And when I say “default” - I mean it. If adding a guardrail requires a discussion about “which test framework do we pick”, then a discussion about “which set of linter rules do we appply”… the guardrails will not be in place for the moment when the model is let loose on the codebase. And adding (and especially removing!) any of the guardrails will be so high-friction that it will be avoided.

So - the first order of business is adding very high yield, very imperative, caustic guardrails. With spikes and turrets on them.

And it is really key that adding them should be cheap. Why? Well, just as it becomes much easier to try stuff with the code, it becomes much easier to try stuff with configuration. Tell the model to setup a linter. To auto-apply it, then evaluate yourself whether you are ok with the results. If you are not - revert.

Remember - the process is a stochastic sampling endeavour. At the very minimum you should draw the boundaries where the hitting particles will be accepted as valid choices, and where they won’t be.

That is also remarkably difficult with people. It is tough to walk up to a person and say “I see you did X, this is unacceptable because and we will fix it using Z".

Another part is design. The deterministic and robust API surface, combined with… some implementation underneath. No, really: it can be anything. It can be a WASM blob for all I care - if it is concealed behind a decent API and exhibits appropriate behavior - it’s fine. Go ahead and make a mess - it’s not appropriate for all types of software, and not always, but for many.

What is for a junior dev to do?

This doesn’t leave juniors in a great place, unfortunately. I won’t necessarily agree with Kieran that “you are not going to have a great time if you like to write code”. Nor do I agree with Sahil that “taste is cope”. The issue is more nuanced: driving LLMs to produce software does require:

Stern judgment
Readiness to command and coerce, rather than hint and stroke
A good understanding of the subject matter

It is indeed so that embracing LLMs into software creation requires delegation - but not only from the operator to the model. Delegation from the customer (or manager) to the operator is also essential, and you won’t have the necessary basis to delegate without fear if the person you are delegating to is simply… not schooled well.

Moreover, the delegation will falter in situations where the model is producing something sensible, but the instructions are bad. For example, if it is clear that the person is working with a system having specific constraints, but the model misedintifies the constraints. An example: the model may assume that you are writing records one by one and the API you are talking to has rate limits for that - but, in actuality, the rate limits are on a strictly defined amount of write load you are causing. If you don’t know where to look - you won’t find it. To be able to steer the model you have to know what you want, exactly - in fact, your ability to see through and micromanage the model is going to remain a requirement!

In effect, I would say that being a junior in today’s market requires a lot of will on the part of the hiring company to teach them. And the “hands off” teaching where you could let a junior drift for months and then “check in” with them every-now-and-then is to be buried. Working in this new reality requires a lot of intensity and focus, and if you want someone to be up to speed quickly - similar intensity in knowledge transfer, as well as transfer of intent, is required. The results you would be getting will be directly (or even exponentially) proportional to how much effort you are ready to put into upskilling a junior, and whether you are ready to outline the actual requirements.

The weight of seniority

And, if I may, there is going to be more of the imperative component (instead of warm and cozy “alignment”) in the work that we do. With manual coding, the assumption was that you “just have to” wait for others to “get it”, or to “approve” something, or to “learn”. With LLMs the tolerance for this waiting becomes significantly smaller, and the waiting itself - very very obvious.

There is the trope of a “micromanaging executive” who goes “heck, I don’t want to negotiate with that engineer - I can just build this myself”. LLMs are extreme enablers in that type of behavior. Pushback becomes very risky, and another side-effect that you can get with teams adopting LLMs will be… teams shrinking. If you do not feel good working with someone, and their skills can be replaced by a machine that can be operated like a tool (and the machine is provided at a tenth of the cost): who will you choose to work with?

That said, if you have a certain number of skilled operators who can expand and detail your vision and drive those agentic flows with vigor, you can build something much more valuable than what was imagined possible.

The new quality calculus

I am aware that following these patterns can be disruptive for some teams. And it - undoubtedly - will be destructive, as well. The quality of “the code” going out the door will change - not necessarily drop, but change in nature. The amount of it will increase, and the amount of features will increase too. Because “trying things” is so easy, there will be even less regard for “how do we shut this down if it doesn’t fly?”, “how does it combine with other features?”. There will be collateral damage, there will be bruised egos - and there undoubtedly will be great software engineers who will emerge from this skirmish strongly jaded.

But here’s something that became possible: you can ask the model “how will it combine with these 7 features once layered”. You can’t ask 7 disparate product managers about the same, because they have conflicting incentives, some of them are clueless and 2 are no longer with the company. You can ask the model, and it will hallucinate you an answer which is, invariably, going to contain some nuggets of truth.

The challenge is that we can’t have our cake and eat it too. We can continue debating Rubocop rules - the problem is that our competitor has built a v2 of their product while we were doing that.

What this means

The shift is not from “high quality” to “low quality” - it’s from “quality through consensus and careful deliberation” to “quality through automated constraints and rapid iteration”. The guardrails I mentioned earlier - linting, tests, validators - these become your quality mechanism. They replace the human review process not because they’re better at catching subtle bugs, but because they can run hundreds of times without complaint, without scheduling meetings, without creating resentment.

Teams will shrink, but they won’t disappear. What you need are fewer people, but each with more agency and more responsibility. The solo founder is the ideal not because collaboration is bad, but because every additional person adds consensus junctions that slow the LLM-assisted workflow to a crawl. The solution isn’t to eliminate teams - it’s to restructure them around clear delegation boundaries and trust that operators will constrain the model appropriately. And those operators deserve maximum agency.

The apparent contradiction between “don’t micromanage humans” and “micromanage the model” resolves when you realize: humans need autonomy and respect. Models need constraints and explicit instructions. The same directive that would make a junior developer feel belittled is exactly what a stochastic emitter requires to produce consistent output. So this isn’t a contradiction at all - it’s recognizing that different systems require different management approaches.

And yes, delegation becomes harder precisely because it becomes more important. When you can build faster, the cost of bad delegation compounds faster too. But the solution isn’t to avoid delegation - it’s to delegate to people who have the judgment to constrain the model effectively, and to invest heavily in teaching that judgment when it’s missing. And to delegate to fewer people.

In that new reality, clarity is more important than alignment - and yes, “clarity” is just a euphemism for “I tell you what to do and how to do it”. But with LLMs, that directive clarity is exactly what enables speed. The question isn’t whether we’ll have more or less clarity - it’s whether we’ll have the courage to be explicit about what we want, and the wisdom to know when to let the operator improvise within those boundaries.

And Obie, please, for the love of all that is good in the world - ditch Medium.