Tag: engineer

  • The Dark Factory: Engineering Teams That Run With the Lights Off

    A few engineering organisations are already operating a model most companies haven’t begun to consider. While the typical software team debates whether to adopt AI coding assistants, companies like StrongDM are running fully automated development pipelines where agents handle implementation, testing, review, and deployment. Humans set direction and define constraints. The mechanical work happens without them.

    This isn’t speculative. It’s operational. And the gap between companies working this way and those that aren’t is widening fast.

    What “lights off” actually means

    The term comes from manufacturing — factories that run autonomously, with minimal human presence. In software, it describes engineering organisations where AI agents do the bulk of execution work while humans focus on architecture, constraints, and outcomes.

    StrongDM’s approach is instructive: their benchmark is that if you haven’t spent at least $1,000 on tokens per human engineer per day, your software factory has room for improvement. Agents work in parallel on isolated tasks. Code is written, tested, and reviewed without manual intervention. Tasks assigned Friday evening return results Monday morning.

    The ratio of agents to humans is high and growing. But this isn’t about replacing engineers — it’s about fundamentally changing what engineers do.

    The guardrails are the system

    Dark factories aren’t ungoverned. They’re heavily governed in a different way.

    Linters, formatters, comprehensive test suites, design pattern enforcement — these become pre-conditions rather than suggestions. Agents are configured to seek completion only when all guardrails pass. Code review shifts from line-by-line human inspection to AI review with human spot-checks on critical paths.

    The discipline moves from “write good code” to “design good systems for code to be written in.” That’s a different skill. It requires thinking about constraints, validation, and feedback loops rather than syntax and implementation details.

    Anthropic’s experiment building a C compiler with parallel Claude instances demonstrates this principle. Sixteen agents worked simultaneously on a shared codebase, coordinating through git locks and comprehensive test harnesses. The result: a 100,000-line compiler capable of building the Linux kernel, produced over nearly 2,000 sessions across two weeks for just under $20,000. The project worked because the test infrastructure was rigorous enough to guide autonomous agents toward correctness without human review of every change.

    Cursor’s experiments with scaling agents ran into a different problem. They tried flat coordination first — agents self-organising through a shared file, claiming tasks, updating status. It broke down. Agents held locks too long, became risk-averse, made small safe changes, and nobody took responsibility for hard problems. The fix was introducing hierarchy: planners that explore the codebase and create tasks, workers that grind on assigned work until it’s done. No single agent tries to do everything. The system ran for weeks, writing over a million lines of code. One project improved video rendering performance by 25x and shipped to production. Their takeaway: many of the gains came from removing complexity rather than adding it.

    Digital twins as the enabler

    The biggest blocker to agent autonomy has been the fear of breaking production. Digital twins remove that constraint.

    StrongDM built behavioural replicas of third-party services their software depends on — Okta, Jira, Slack, Google Docs, Google Drive, and Google Sheets. These twins replicate APIs, edge cases, and observable behaviours with sufficient fidelity that agents can test against realistic conditions at volume, without rate limits or production risk.

    Simon Willison’s write-up of StrongDM’s approach highlights how this changed what was economically feasible: “Creating a high fidelity clone of a significant SaaS application was always possible, but never economically feasible. Generations of engineers may have wanted a full in-memory replica of their CRM to test against, but self-censored the proposal to build it.”

    What makes this rigorous rather than just better staging is how they handle validation. Test scenarios are stored outside the codebase — separate from where the coding agents can see them — functioning like holdout sets in machine learning. Agents can’t overfit to the tests because they don’t have access to them. The QA team is also agents, running thousands of scenarios per hour without hitting rate limits or accumulating API costs.

    The structural advantage of starting fresh

    Startups and SMBs have a material advantage here. No legacy organisational structure to dismantle. No 500-person engineering floor with stakeholders defending headcount. No 18-month procurement cycles.

    Capital efficiency becomes native. A three-person team with agents can produce output that previously required twenty people. The cost of compute is a fraction of equivalent human labour and falling rapidly.

    This creates an asymmetric advantage. If your competitor ships in days what takes you months, no amount of talent closes that gap. And the competitive pressure isn’t just on speed — it’s on the ability to attract talent that wants to work this way. Senior engineers who’ve experienced agent-driven development don’t want to go back to manual workflows.

    The gap between adopters and laggards

    Companies operating this way are shipping at a fundamentally different pace. The difference isn’t incremental — it’s orders of magnitude in output per person.

    Block’s recent announcement of a near-50% reduction in headcount offers a data point. The company is reducing its organization from over 10,000 people to just under 6,000. Jack Dorsey stated “we’re not making this decision because we’re in trouble. our business is strong” but noted that “the intelligence tools we’re creating and using, paired with smaller and flatter teams, are enabling a new way of working which fundamentally changes what it means to build and run a company.”

    Cursor’s data shows the same pattern. 35% of pull requests merged internally at Cursor are now created by agents operating autonomously in cloud VMs. The developers adopting this approach write almost no code themselves. They spend their time breaking down problems, reviewing artifacts, and giving feedback. They spin up multiple agents simultaneously instead of guiding one to completion.

    The laggards aren’t just slower. They’re increasingly unable to compete for talent, capital, or market position against organisations that have made this transition.

    You don’t need a corporate budget to start

    The dark factory model scales down. A single developer with a Claude Code subscription and well-structured GitHub workflows can run a lightweight version of the same approach.

    Start with one workflow. Pick a repetitive part of your development or business process, establish the guardrails, and let agents handle it. The key investment isn’t in compute — it’s in guardrails and context. Linters, test suites, good documentation, and clear specifications matter more than token budget.

    For SMBs and founders, this is the most asymmetric advantage available. You can operate at a scale that was previously only accessible with significant headcount. The learning curve is steep but short. Within 30 days of serious experimentation, most people develop the intuition for what agents can and can’t handle.

    Projects like OpenClaw — an open-source autonomous agent that executes tasks across messaging platforms and services — demonstrate that the tooling for this approach is increasingly accessible. The software runs locally, integrates with multiple LLM providers, and requires no enterprise licensing. The barrier isn’t access to technology. It’s willingness to change how work gets done.

    What this means beyond software

    Software is where this pattern is playing out first, but the model applies wherever knowledge work is structured and repeatable.

    Audit processes. Compliance checks. Report generation. Data analysis. Document review. These are all candidates for the same approach: clear specifications, comprehensive validation, and autonomous execution within defined guardrails.

    Most traditional industries haven’t started thinking about this. They’re still debating whether to use ChatGPT for email drafts. The firms that figure out how to apply dark factory principles to their domain will have an enormous advantage over those still operating with manual workflows.

    The lights are already off in some factories. The question isn’t whether this approach will spread. It’s how quickly your organisation recognises that the game has changed.

  • Dubai Diaries: Sous Vide or Cooking like an Engineer

    Dubai Diaries: Sous Vide or Cooking like an Engineer

    When I moved to Dubai and got the apartment, the family was still back in Mumbai due to my daughter’s ongoing school session. This meant that I was on my own when it comes to food (getting a cook for just 1 person did not make sense).

    What is Sous Vide?

    Being the engineer (with a management degree like a lot of other fellow Indians), I wanted to use a predictable and low effort cooking method and that’s where I got to know about the sous vide method. It roughly translates to under vacuum, and is basically a low temperature long time technique where you vacuum seal your food and cook it in a temperature controlled water bath. From wikipedia:

    Sous vide (/suː ˈviːd/; French for ‘under vacuum’), also known as low-temperature, long-time (LTLT) cooking, is a method of cooking invented by the French chef Georges Pralus in 1974, in which food is placed in a plastic pouch or a glass jar and cooked in a water bath for longer than usual cooking times (usually one to seven hours, and more than three days in some cases) at a precisely regulated temperature.

    The temperature is much lower than usually used for cooking, typically around 55 to 60 °C (130 to 140 °F) for red meat, 66 to 71 °C (150 to 160 °F) for poultry, and higher for vegetables. The intent is to cook the item evenly, ensuring that the inside is properly cooked without overcooking the outside, and to retain moisture.

    Here’s the video from Sorted Food that inspired me to try out sous vide cooking:

    Why Sous Vide?

    The main reason to go for sous vide cooking is that you need to just set the cooking temperature and not worry much about the cooking time which is quite forgiving. Moreover, you don’t need to be active while the actual cooking is happening and can easily catch a few TV show episodes or a part of a movie while the food cooks. The main active time is for the ingredients prep which can be done while getting the water bath to the required temperature.

    One thing to keep in mind, especially with meats and fish is that while the texture and taste of the food comes out excellent, it may not be as appetizing to look at due to the lack of caramelization or any kind of crust which comes from high temperature cooking like frying or grilling. You could overcome this by finishing it in a pan to get a crust, but make sure it is for a short time as you may end up overcooking the food defeating the sous vide process.

    How to get started?

    Immersion circulators are typically used for sous vide cooking, but I did not want to go for a single purpose device. That’s how I discovered the multi-function Instant Pot pressure cooker with the sous vide feature on Amazon and promptly ordered one. I initially got a bunch of zip lock bags for cooking using the displacement method for sealing, but it was not very secure. I subsequently opted to get a vacuum sealer (Inkbird model) that turned out to be quite handy and reliable.

    There are a bunch of sites with sous vide recipes, of which I found Serious Eats to be quite useful as it gave a very detailed explanation of the differences that varying temperatures and cooking time can have on the end result. I have tried cooking a variety of dishes from prawns, mashed potatoes, fish (salmon & hilsa), chicken, lamb chops to panna cotta and they have come out quite well. This has been endorsed by my better half and daughter as well as the guests to whom we served some of the dishes.

    Here’s a quick reference table for some of the items that I have tried:

    FoodTemperatureTime
    Mashed Potatoes90°C60-90 min
    Salmon or Hilsa (Ilish)43°C (for buttery texture)
    up to 54°C for more flaky texture
    30-45 min
    Chicken breast60-65°C1-4 hours
    Chicken thigh66-74°C1-4 hours
    Prawns60°C (poached texture)30-45 min
    Lamb55-64°C2-4 hours
    Panna cotta90°C60-90 min

    Bonus: Bhapa Ilish alternative via sous vide

    After trying the salmon sous vide, I wanted to give the Bengali favourite hilsa fish (a distant cousin of the salmon after all) a try. Bhapa ilish (steamed hilsa) is a fairly simple dish where you mainly need to season the fish cuts with salt, turmeric, mustard oil & mustard powder (or crushed mustard).

    The typical technique involving a steam bath in a pressure cooker or microwave oven can be a bit hit or miss as the fish texture is very sensitive to temperature. That’s where sous vide comes in and while I didn’t find any online recipes for sous vide ilish, the salmon specs worked out quite excellently.

    Anyway, that’s my journey with the sous vide cooking method. Here are some of the photos of the dishes I cooked over the last couple of years: