In the not-so-distant future my ideal day working in a software team is jumping on a recorded call for 2-4 hours and discussing everything under the sun: product direction, research spikes, architecture, designs, prototypes, business strategy. Everything. In the call is the whole product team and a few agents which research and prototype for us in the background. We’re sharing screen or video of the whiteboard so it’s recorded as well. At the end of the call, we call it a day. The nightshift will take it from here. Tomorrow morning we’ll individually review what’s built, merge what we like, and throw away what we don’t.

Then we jump right back into the conference call.

This is the idealized end of the spectrum. The reality is this could just as easily turn into a dystopia of “continue” and “accept recommendation” where everyone is managed by Claude. In my work as a fractional individual contributor with multiple small engineering teams I’ve seen this spectrum evolve over the last year. I’m, personally, very excited for my ideal day. Not everybody is.

The Fork

To put it simply, the fork I’m seeing comes down to vision. Does an engineer have a vision of the architecture, a feature, the product, a user journey, or the business? This doesn’t need to be a large vision (think new product lines), but it must be a strong vision. Can you describe it? Can you tell when you’re there? Can you orient others (human and bot) towards that vision? In the AI ethos this is what the word “taste” is being used for. Do you take a stand on an idea?

Those that have vision are flying. For example, a frontend developer friend of mine who works for a small (5-15 engineers) startup has been a recent convert to AI (this spring).

• No frontend error tracking → integrated Sentry during a meeting
• Bug backlogs → Eliminated
• Dependency updates → Trivialized
• Migrations → Achievable
• Personal budget software upcoming subscription charges → Full port as personalized software

The power of AI is: if you know, you know. For seasoned developers who know everything that should be, but never had the time to do it, now is a beautiful time.

The flip side is sobering, though. This engineer is also fighting the negatives of AI:

• Clearly AI-written messages in Slack → who am I really talking to?
• PRs with code smells → do I tell the developer or should I just teach their Claude?
• Management expecting more out of engineering while also showing concern about token spend → use AI, but not too much!

This is not a senior vs junior engineer dichotomy, either. I work with all levels who have adapted better, worse, or not at all over the past two years. I get the privilege of working with and leading multiple teams simultaneously, plus building an immense amount as a solo developer.

I haven’t had this much fun in a long time.

My Development Journey Over the Past Year

I’m a freelance software developer and team lead with a solo practice, Connsulting (the name was too good to pass up). Over the past two years I’ve worked with companies small and smaller:

• A data integration platform company (~70 engineers at the time I was there)
• Enigma Networks, an AI-enabled zero-trust security platform (3 engineers)
• CurieTech, a MuleSoft AI tool turned AI agent development company (4-7 engineers over the past year)
• Other clients on a per-project basis where I’m the only developer

These are small teams at generally pre-product-market fit companies. We’re iterating on product extremely quickly and our software development practices reflect that. I’ve built product and led software engineering practices for all of these companies. For those where I’m all of engineering, I have the benefit of greenfield dev.

The Light Switch Moment

Fifteen months ago (summer of 2025) I was a traditional (though fractional) engineering manager. I had recently helped stabilize the SRE and development teams for a small monitoring company that ended in an exit. I was then working as an API team lead for a data integration platform company where I also took over the QA team. Lots of 1x1s, project planning, personnel challenges, hiring, etc. It’s where my career had taken me and I felt it was high-leverage (growing people can be extremely rewarding), but it was exhausting. I wasn’t growing.

I had tried some of the AI tools and used them for some small use cases. Crawling all of Jira, helping create tickets, rewriting standup notes for posting in Slack. Small things. I tried Cursor here and there, but I wasn’t doing much development so nothing stuck. Auto-complete wasn’t an issue for me at the time.

Soon I got a call from the CEO of the monitoring company that had an exit and he told me about his new project. The company, Enigma Networks, had a small (three engineers) offshore team he and his cofounder needed help managing. I was happy to jump onboard.

We ran into the same problems these teams always have:

• Challenges understanding the product and vision
• Sprint planning and estimation (typically dictation by me, to be honest)
• The definition of “done” (work is deployed to prod, no exception)
• Architectural and design challenges

It’s always frustrating to me how communication issues show up in a team once it grows past a single person.

Eventually, we decided to change the team to a European outsourcing company pod: two developers and a part time scrum master. We had asked them how they use AI and they said they saw only modest gains from it. The CEO and I had worked with this company before, so we interviewed the team, made the switch, started the first sprint, and…

Nothing.

We wanted to build a self-signup flow which is not exactly rocket-science. I picked it because it required the least amount of knowledge about the core product. The first sprint turned into the second, and still we hadn’t delivered anything!

I thought I had finally lost touch with development. I felt the rust forming (it had been 3 years since I had done anything other than side projects), so I thought I’d finally become one of those armchair architects. My estimates must be off, I must be missing something.

I had Cursor downloaded so the Saturday of week 4 (two sprints in) I decided to use the $20 plan to see what I could build. It’s just signup (we even used a third party for auth), so let’s see how much progress I could make.

I knocked out the whole sprint that afternoon. I immediately called the cofounders and said “we have a problem.” Over the next few weeks we tried to turn the corner with the new team, but it was clear we had lost faith in them, they weren’t able to deliver anything significant, and we parted ways. I was the entire engineering organization for 6 months until we found two developers we really like.

The shift between engineers diving head-first into AI and those who were not seeing the benefits was already taking place. I wanted to work with teams on the cutting edge, so I dove back in head-first to development.

Solo Development and Experimentation

Fast forward to November of 2025 (the great turning point for many when the models “finally got good”) when I had picked up a solo-development project for a company. It was a greenfield project for a cofounding pair who have very strong product thinking for their niche. I had full creative and architectural control over the product and they had a crystal clear vision of how they wanted to use it.

At that time I was using Composer from Cursor heavily (I had their legacy unlimited plan) and used this solo, greenfield project as an opportunity to stress test two theories:

• How far can AI get in full stack development when given the tools to iterate on its own?
• What deterministic, automated checks (e.g. PR checks, git hooks) can guide the AI down a reasonable path?

Right around this time, agentic development was starting to take shape. My Cursor agent tabs went from function writing to class writing to true agentic development in the month of November. Those productivity improvements never materialized because the framework I chose had too much local development friction. The agent wasn’t able to iterate on its own fast enough.

My main takeaway from this short project was that developer experience (DevEx) is all of a sudden very important because agents are being onboarded onto the platform every single time you open a new chat. This is where I realized streamlining the language, repo setup, and code architecture is extremely important to take advantage of agents.

To delegate larger batches of work to the agent I needed to give the agent the tools and environment to iterate within larger circles of automation. That required restructuring the project’s code architecture.

Hexagonal Architecture

Earlier in my career I was a Java dev and worked with Spring Boot. On that project we used interfaces, abstract classes, and implementation classes to abstract out third party dependencies like Redis. We didn’t want to run Redis during development, so a cache had an interface and two implementations: real (Redis) and local (in this case, an in memory cache). Once we created interfaces for as many third-party dependencies as possible (e.g. Kafka and Elasticsearch) local development became much easier.

Turns out that has a name: hexagonal architecture. Cursor helped me put a label to this practice, so now I could use that language to instruct Cursor to refactor out key, hard-to-run dependencies in my project. This was the key unlock to parallelization.

By implementing a hexagonal architecture I unlocked two things for my agents:

• Severely reduced resource consumption in a worktree because we didn’t have to run every dependency, thus making additional worktrees cheaper to run; and
• Immensely improved testability

Everyone has experienced the truly terrible tests AI writes. They’re often assertTrue(1 + 1 == 2) with slightly more steps. These tests are a false sense of security and they burned me quite often. Unit tests are easy to write and run by agents, so they love them. The key problems with them are: they’re often useless and when a test fails, is the code wrong or the test? Later in this article I’ll discuss this in detail as part of Intent.

Hexagonal architecture structures code such that third-party dependencies are naturally abstracted away from business logic. Testing the dependencies may still be difficult, but testing the business logic is far easier. This bleeds into the realm of integration testing, which is far more effective (and also more difficult, which is why agents don’t do it). The further up the testing pyramid you go, the closer to reflecting intent the tests get.

November and December of 2025 taught me that to take advantage of AI agents, we have to invest in DevEx. See this article about what separates engineering orgs who are flying with AI vs those that are struggling: it often comes down to their culture pre-AI and if they invested in documentation, clean architectures, and DevEx. I was lucky to have a greenfield project to experiment with to develop this understanding. If your company or project doesn’t have this, try experimenting with a low-risk personal project. The difference in productivity and confidence in what agents produce is tremendous.

Working on Small, Pre-PMF Teams

Throughout the spring of 2026 I started a new project as a DevOps engineer with CurieTech where I was revamping their observability stack, improving the CI/CD process, and reducing AWS costs. Also around that time at Enigma we hired two engineers (one senior and one junior) so I could step back into a more traditional tech lead role. I was working with around 7 engineers who were in the middle of their transition to AI-native engineers. I was continuing to build on individual client projects, but these changes are what I observed and pushed through as an individual who was part of a team.

Across both engineering orgs, I saw a few trends that are no surprise:

• Content overload
• PR load was going up and human review was getting slimmer
• Engineers were at various stages of the grief cycle
• A transition to “builder” mode (which I think swung way too far)
• Engineering is no longer the bottleneck (sort of)

Content Overload

An obvious change was that content generation went through the roof. I like my ticketing systems and keep my Slack and email clean. AI took this to the next level. The first thing that changed was ticketing.

Using AI to create, read, and organize a ticketing system like Linear was my first communication system unlock. At CurieTech we didn’t use ticketing, so I pushed to try to use Linear (I’m allergic to project management chaos) and at a minimum wanted to use it for my own ticket tracking. Using AI to plan, cut tickets, then implement work out of tickets (see The Software Factory below) was a natural fit for me. Back as an engineering manager I used to break down initiatives into epics, then into tasks for engineers to work on.

Quite simply, as an IC with AI I promoted myself. Previously as an IC I was working on tasks. Now I work on epics, break them down into tasks, and assign the tasks to an agent. I’m a team lead again!

Ticket tracking wasn’t just for AI, but now the vast majority of tickets (all the tasks) were exclusively for AI. I wanted to review the epics with team mates, then break down and assign the tasks to AI. This got messy, though. Now parts of Linear were for humans and parts were for agents.

The same thing started to happen with Slack. Most messages are from and to humans, but Claude MCP started to sneak in. Giant content blocks would show in Slack which were clearly AI generated. I’ve tried to combat this by threading messages for agents from my agent under messages from me. “From my Claude to yours” has become a common phrase of mine.

Either way, I see this content problem getting worse, not better. Companies like Clay are starting to structure their own writing manifestos which I agree with and am trying to emulate. Put simply: all written content is suspect now, how do I know the human behind the writing understands what they posted?

Code Reviews

This summer at CurieTech, the engineering team felt like ships passing in the night. Engineers were so focused on getting their work done (planning, building, shipping), that we were no longer reviewing and learning from each other’s work. PRs were flying, but outside of agent reviews (both local and in CI), we weren’t getting deep reviews on anything. Not all PRs are equally impactful (e.g. a CSS change vs a DB migration), so spreading code review time across an increasing number of PRs was not effective.

The team sat down and talked about it: where should we invest our time? We decided that instead of looking at all PRs a little, we’d rather look at some PRs more. I built an Impact Classifier PR check which labeled the PR based on a few criteria:

• High-impact code paths (e.g. billing and DB migrations)
• Complexity (as determined by Claude)
• Change type (e.g. bugfix, improvement, or new feature)

This helped us focus our time on High Impact PRs and let engineers merge lower impact PRs after only their and Claude’s reviews. This was a conscious tradeoff we made given the state of the product and company. Your team’s risk tolerance may be different.

At Enigma we took a different approach. With a team of three (including myself), we still reviewed all PRs manually. The senior engineer and I often had more feedback on the junior developer’s PRs, much of which was architectural or around development best practices (e.g. database design, how much logic to put in the frontend vs backend). The junior learned fast, there’s just a lot of ground to cover in full-stack SaaS development.

I decided to produce a skill for the junior called /pre-pr-review. I had Claude crawl all of the PRs in all repos, collect up all the feedback we’d provided, and condense that into a skill for local review before a branch ever hit PR. The junior engineer said the review comments even sounded like me! We still reviewed the PRs once they hit GitHub, but the easy comments are all cleaned up. It’s like reviewing a PR for the second or third time instead of the first. We update this skill every once in a while to incorporate new feedback.

AI-Native Juniors

The junior engineer at Enigma is an interesting case: he’s never done software development without AI. He’s truly AI-native. It’s been fascinating to understand how he works and thinks about development. Below is what I’ve found is radically different vs the same with him compared to myself and other devs making this transition.

The same:

• Being organized is just as (if not more) important
• Possible vs correct (e.g. where to put business logic, what a good DB schema looks like) still requires years of experience getting burned
• Why something is a good or bad solution is often not technical, but instead judgement and experience

Different:

• No fear of languages (they’re all new)
• Fullstack development is clearly the new baseline
• Learning is everything
• Product sense is a natural requirement because the coding is not (and never was for them) a significant part of the job

By working with this engineer, I’m learning where my value as an architect and experienced developer really comes from: it’s the understanding of systems, product sense, and war stories. I knew this was valuable, but I’m realizing now that this is the value of my experience. All the scar tissue I have accumulated is far more valuable than any of the language or coding expertise. This experience is what the AI agents can’t help make judgement calls on or present options to juniors who don’t know the magnitude of the question they’re being asked.

This is the experience I want to pass on to juniors and is why the destruction of middle management by big tech is so disappointing.

Transitioning (Back) to Management

The other engineer at Enigma has over a decade of software engineering experience and has been in team lead positions before. The most interesting part of working with him has been working through the grieving process! Only after my discussions with him “letting go” of the code an increasing amount did I reflect on my transition from IC to engineering manager.

My first year as a team lead I reviewed every single PR from my team in detail. I knew the code, I owned the services, I wanted to ensure code was up to my standards. This did not go well for me. Others did not build how I built, and this created tension in the team. I also was not able to do my core job (see Well Qualified vs Uniquely Qualified) of planning and leading because I was spending too much time in the code. It took me a year to stop doing this and another year before I stopped feeling bitter about it.

Unfortunately, many engineers (like the senior at Enigma) are not being given that time or that choice. This engineer has been in lead positions before, so he at least has some tolerance for it, but other engineers (like some at CurieTech) do not want this and are not prepared for it. Not everyone wants to be a manager! This is a very difficult transition and as Molly describes, many in the industry are grieving.

This is why empathetic management and team leads are more important now than ever, yet much of the industry is pushing full-throttle into “builder” mode. Long term, this is a mistake.

Working Across Product and Engineering

Alongside all ICs being managers of agents now, another team lead responsibility has been thrust upon them: driving the product forward.

All of a sudden, engineers are being asked to understand and push forward the product and business. I’ve believed for a long time that this was always a requirement for engineers (after all, an engineer’s core job is to deliver business value through code), but many got away with it because coding was such a bottleneck. An engineer could be valuable as a translator: translate requirements into code. No more! Agents have taken that job. So what’s left for us?

My experience is primarily with these small teams and working solo. I love Granola because it gives my agents access to my calls. As a product-minded solo developer on some projects, I’ve changed how I speak on calls. Each client requirements meeting becomes a conversation about intent, expected behavior, architectural tradeoffs, and future directions. I can enumerate action items as a summary to help out the agent I know will read this afterwards. The beauty of this requirements gathering is right after the call I ask Claude to read the transcript, cross-reference the features and bugs with code, spike development approaches, and recommend the Linear tickets. My core value becomes the interview process once I’ve set up the development engine (see The Software Factory below)!

For small teams (particularly pre-PMF), driving the product forward and building with product is the entirety of engineering’s value. I’d go as far as to say that many pre-PMF companies may not even need execution-only engineers at this point. Engineers who only execute have had their value commoditized by agents. We have to deliver something more.

One issue I’ve encountered with Enigma is it’s so easy to build new features that there’s a risk of going overboard. I call this product dilution. Pre-PMF, why not have every feature under the sun? This was never a good idea, but didn’t happen often due to the cost of development. Now, you can have any feature you want by lunch. The core issues with this are:

• Unclear value proposition for users
• Immense tech debt due to product sprawl
• Dilution of product vision
• Accidental expansion of competition by moving into their markets

At Enigma we’ve experienced this, so after we hit a threshold of features, we’ve spent far more time rapidly iterating on the user experience and journeys than additional features.

As team lead at Enigma, I’ve also side-stepped feature sprawl by spiking what it would take to build a feature. I can deliver an estimate for how long it would take to build a feature (greatly reduced these days), so product has confidence that if a prospect decides to buy, we could build it. There’s no reason to commit to it now if that doesn’t materialize, though. This is just-in-time feature development!

The Intent Gap

The final concept I’ve been seeing when working on these teams is the gap between what is and what should be: the intent gap. Intent is a set of requirements, both functional and technical, that must be translated into code. Human language is messy and non-deterministic, but code is not. Translation from one to the other is always lossy.

Imagine a set of Linear tickets. If you squint, these are git commits in human language (changes) to an established product behavior. Later tickets may conflict with or overwrite earlier tickets (merge conflicts) and must be reconciled. The issue is that translation of tickets into code is lossy. Best case scenario is you’ve linked the tickets into git commits, but often agents have no understanding of why something is the way that it is. They just know what is (the code).

This is what causes test thrashing (see Hexagonal Architecture). Is the code right or are the tests right? It entirely depends on what the intent was when building those tickets. Closing this intent gap is exactly where engineers must step in. What should be is continually evolving and we cannot relinquish that power to the agents. Otherwise, they’re driving the product direction. If engineers do not understand intent, then unfortunately they do not provide much value above what agents can provide at a much lower price point.

The thought experiment above is essentially a re-derivation of Spec-Driven Development (SDD). I’ve tried this with the CurieTech team with mixed results. Either the specs become so dense and structured that they’re effectively code (which is now duplicated as actual code) or vague enough that the generated code doesn’t do what you want. Ultimately, English is messy. Words mean different things. English is non-deterministic.

I believe there will always be a gap between what is and what should be which humans must close. The level at which these gaps exist, though, will change.

The Evolution of Software Development

This shift is far from over. The mass extinction of software engineers didn’t happen, nor do I think it will. The job, however, will continue to change rapidly. Below I have a few concepts I’ve found have stood the test of time (“time” being at least two months, which is an eon for AI) which help me orient my value as an engineer. Each concept describes a spectrum where my work is on one side and agents are on the other. The spectrum is constant, but the line between what I do vs the agent is constantly changing (in favor of the agent) as the models and application harnesses improve.

The Judgement Pyramid

Product development requires an immense amount of decision making. These decisions span from trivial (variable naming) to consequential (core user journeys). There are far more trivial decisions than consequential decisions, which results in a judgement pyramid.

Engineers have already offloaded many decisions. Any time you use a high-level coding language or development framework, you’ve offloaded decision making to a set of defaults. This is the tradeoff we make: convenience for flexibility. Nothing has changed here, but now we can delegate nearly everything to an agent which has opinions of its own. So where do you draw the line? Your threshold depends on your experience, your company culture, your project, and your product’s maturity. You may have a different threshold for personal and professional projects.

For a given context, I want to pick a threshold then make every decision above and zero decisions below. The cost cuts both ways if you don’t draw a clean line across. Trivial decisions turn into human approvals that unnecessarily break the agent’s and your flow (for example, watching a set of terminals only to hit “Approve” every minute). Missed human decisions on important topics delegate to the agent an authority it should not have.

Every time a new model comes out I try to push the envelope of how high I can make that threshold and still have good results. The higher the level, the more leverage engineers have to do more. Only if it can perform reliably, though.

Destinations, Not Directions

At CurieTech we’re working on a major Dark Factory and agent development platform named Curie. Throughout development the team and I have split up features to work on. Given we’re pre-PMF on this project, we’ve been working fast. My velocity on the project tends to be faster than the rest of the team’s (having architected the platform helps), but through many conversations with the team I struggled to put my finger on how I was achieving larger batches of work without the agent going off the rails. It turned out I was prompting differently.

An engineer at CurieTech helped me realize this difference when we discussed the type of questions he was having to answer with Claude. I’m not ceding all judgement to Claude (that’s one way to get lots of work done), but I’m also rarely surprised by what it did. How was I keeping it in check, yet letting it have enough autonomy to do meaningful work?

The answer is twofold:

1. Provide the agent with the tools and context it needs to get the job done (e.g. MCP servers, local file access, design docs, tool access) → This alone can be dangerous (there is always risk associated with it)
2. Provide the agent with a destination (a “goal” in other contexts) and recommended steps or landmarks

Imagine you are asking the agent to go from one destination to another. One option is to give turn-by-turn directions (these are individual steps or tasks). If the agent misses a step, runs into a detour, or you gave a bad direction, it’s stuck. Even if an agent tells you it’s stuck, you must context switch back, understand where it is, figure out how to get to the destination from this new location, and point it there. This is extremely costly context switching. Worst case is the agent trudges on and breaks something!

The alternative is telling the agent the destination and landmarks along the way. Now the agent can reorient along the way (like Google Maps rerouting) and use your landmarks to know it’s on the right track. The added benefit is I have confidence the agent is bounded to a tighter set of paths between here and there, so risk of it going rogue is reduced. Finally, once it gets to the destination, I can check the artifact or results, not check every decision it had to make along the way.

Let’s look at a few examples around trying to save money on your AWS bill.

Directions, Not a Destination

Pull down my AWS Cost and Usage report, sort the costs by highest to lowest, aggregate them, filter down to those greater than $500 a month, and send me those categories.

These are turn-by-turn directions. Often, this level of detail is not required because agents are good at this work already. Are we accounting for different regions? Do the tags matter? What are we doing with this data? How many of these resources are really necessary? The agent doesn’t know, so it can’t help you.

Destination with no Guardrails

Reduce my AWS bill.

The agent is going to delete your AWS account. This is a Monkey’s Paw situation. I’m fairly sure the models are smart enough to ask you before doing this, but this is a risk.

Destination with Landmarks

We’re trying to reduce our AWS bill. Find the highest-cost areas, cross-reference those resources’ utilization in CloudWatch, and recommend the lowest-risk, highest ROI actions to take to reduce the bill.

This is not a long prompt, but is asking the agent to do a lot of work! Note the goal right up front and the deliverable (recommendations) at the end. I ask for cross-referencing between tools (the agent needs access to these to get the job done) and it can figure out how to sort, group, and filter as needed to achieve what I want.

Subtle changes to your prompts can go a long way in improving the autonomy and alignment of your agents.

Planning is the Work

The natural result of setting destinations, not directions, is now I need to set the destination for a lot of agents. If agents can reliably get to where you direct them, the job becomes directing.

Whoops, that’s management!

We have to know where we’re going if we have any chance of directing the agents. This is the key difference I see between engineers managing agents vs being managed by the agents: do you have a vision of where we’re going?

I’ve approached this collaboratively with agents using a skill called Epic Forge. It’s my take on Matt Pocock’s Grill Me skill. The skill does the following:

1. I describe as clearly as I can what we’re trying to build
2. The agent grills me on functional requirements
3. In parallel, the agent spikes architecture and blockers to flesh out the technical requirements
4. We bring it all together for a final epic and set of tickets containing all requirements

I care about the technical and architectural requirements. Often in my description I provide the constraints I care about, but I need to decide all of them (see The Judgement Pyramid). I also don’t want theory. Tokens are (relatively) cheap. Try it, test it, spike it. Let’s not leave it to chance. This is throwaway code, doesn’t have tests, contains hacks, etc. I just need to know if what we’re suggesting can work. This is all de-risking.

The whole skill might take 2 hours, most of it not requiring my attention. This is often an entire sprint’s worth of work! I’m driving the vision and the destination. The agent is helping me figure out how to get there. The end result is an epic with the feature’s vision and a set of incremental tickets with clear acceptance criteria.

So how do we build it?

The Software Factory

Software factories, particularly dark software factories (those with no human involvement), are a hot topic. Steve Yegge’s Gas Town was the premier example of this until he shut it down. There’s a thin line between what agents can execute and what they cannot. On my podcast Manager/Builder, we discuss in the episode Dark Factories that the line is judgement.

In the section above, using the Epic Forge skill we designed the entirety of the feature. All functional requirements are locked. During implementation we may run into unexpected complexities (though we already de-risked using spikes) which the agent must address, but it has a destination in mind. The factory is the culmination of all the sections above: dark software factories are for execution.

Enterprise AI costs are spiraling out of control, so companies are investing in routers and putting a cap on developer spend. Orgs are struggling to scale AI high performers’ skills, and software quality and consistency is degrading because everyone has their custom setups. Not to mention parallel development isn’t scaling on laptops.

So let’s put it all together. In 2025 individuals in orgs experiment with AI, but orgs see little company-wide productivity improvement. Then orgs try to share knowledge internally with plugins which are picked up by the leaders, but not the laggards. So orgs force AI usage which leads to tokenmaxxing. Soon orgs are forced to curb rampant AI spend, leading to a router craze. The natural progression of this is centralization of execution backed by internal routers based on real engineering task data.

We’re already seeing the seeds of this. Companies like Databricks are building immense, centralized datasets of real developer workloads driving real cost efficiencies for their internal routers. The software execution factory solves two additional problems: offload work from developers’ laptops and execution becomes extremely consistent due to centralized implementation.

This is many birds with one stone:

• Give high-powered models to developers for local planning, experimentation, and spiking
• Load up tasks into a central execution bucket which takes in tickets and spits out PRs
• Linting, coding best practices, test coverage rules, etc all become centrally managed by architects and team leads which naturally improves quality across the board
• The DevEx team (or whoever owns the factory) gathers an incredible amount of data and telemetry about how much features cost (a head of engineering’s dream!)
• Immense feature implementation parallelization
• 24/7 execution in the factory

The list goes on. The key here is we are not expecting the factory to make judgement calls. That is for humans. At CurieTech we’re building Curie to be this factory and are at the dogfooding step where Curie is building Curie. Our goal is to empower our engineers to spend their time thinking, planning, and verifying in a shared way (skills and plugins), then executing work in a consistent way through the factory. The more we can expand the commoditized section on the right of the spectrum below, the higher leverage we have as engineers.

This is just Cloud 2.0! We’re progressing through the same infra, application layer, commoditization, and centralization that we did with the cloud. Now IT/DevEx teams need to manage their internal routers and factories the same way they manage their company’s cloud infrastructure.

The Future I’m Excited For

Returning to my utopia from the introduction, maybe now you see how close we really are to it. Moving dev off machine to a software execution factory, planning offline with assistance of an agent, and spending the majority of our time discussing intent is all possible now. I see glimmers of all of these in the teams I’m working with and in my own solo work. The friction has more to do with how our organizations and teams operate than the tooling available. It takes time for organizations to adapt, much like how factories did not achieve productivity gains for 40 years after the introduction of electricity.

I’m personally and professionally excited for where we’re going. I’ve never been more convinced that software engineering is here to stay. I’m having the most fun I’ve had in a long time and I can’t wait to see how my job will change next week, month, and year.

---

Thanks to Dima and Jenny for reading early drafts and telling me where it wasn’t working.