DEV Community: Daily Context

Is looping ready to roll? Experts split on the future of coding

Iain Thomson — Fri, 03 Jul 2026 15:07:40 +0000

On the closing day of the AI Engineer World's Fair, industry leaders debated whether loops are ready for mainstream use and whether humans still have a place in coding.

On the loops-now side, Geoff Huntley, founder of Latent Patterns, was understandably bullish. He said that over two years ago he was at Canva and watched engineers prompting repeatedly and realized that this could be done much more efficiently with a software loop.

"It's somewhat inevitable," he said. "It is not a complete silver bullet. This time next year, at the conference we're going to see a whole bunch of talks saying our factories fail, our loops fail. These are things that we are yet to figure out."

He likened the situation to the first deployments of Kubernetes, where it took the industry years to get deployment right. But when they did, it was a revolution.

Dex Horthy, CEO of HumanLayer, was less enthusiastic. Earlier in the week, he gave a keynote in which he described how — as an experiment — he'd taken humans out of the coding loop and let machines do the job. He monitored the results, and they weren't good. He felt it was clear that AI wasn't up to the job yet.

"I think the basic take here is not whether loops are good or bad," he said. "I've seen lots of people try to apply AI to this problem of having to review bots, but it doesn't feel to me like it's working."

The increasing use of loops was inevitable, he said, but too many people are rushing into the space with too little thought. A more measured approach was needed, and some of the most enthusiastic early adopters would get their fingers burned.

The debate, done in the Oxford-style timed format, was closely fought, and the audience was asked to vote on either side. Unfortunately, the stage lights meant the moderator couldn't count votes, but — based on our view of the audience — Horthy's viewpoint won by a narrow margin.

A Third Brain for your Second Brain

Ryan Palo — Fri, 03 Jul 2026 15:02:56 +0000

The concept of the "second brain"/"knowledge base" is one of my absolute favorite nerd snipes of all time. As a writer and blogger, I love everything about the idea of attempting to hoard every single piece of knowledge I accumulate into a structured, tagged, and metadatafied text mound repository. The memory talks today at the AI Engineer World's Fair, along with some of the online track talks, led me to the realization that the human knowledge base and the AI concept of an AutoWiki are a match made in heaven.

Let's start from the beginning so we don't lose anybody: a knowledge base, or a "second brain" if you do it a certain way, is a collection of data in various states from raw, incoming knowledge to processed, synthesized, integrated learnings. Oftentimes these data bits are stored as plain Markdown files (here your AI antennae should be perking up). If you're extra cool, you use an app like Obsidian or Neovim to operate on these files. One popular method is to set up an incoming inbox where you can jot down new information or idea fragments in seconds so that you don't lose anything by thinking, "Oh cool, I'll make a note of that later." Then, when you get some time to process things, you go through your inbox, fill in blanks, do more research, and eventually, you end up with a more processed, more personalized piece of knowledge that is all linked up to lots of other pieces of processed knowledge in your knowledge base. You may also generate even more ideas or thoughts for the inbox during this process. Then, when you go to create or learn something, you already have all of these related, processed knowledge chunks to draw from. If this seems like a cult mindset that interests you, look up the word Zettelkasten.

You know what else processes and synthesizes Markdown files? That's right. AI. It's, like, the main thing it does. Do you know one of the hardest problems to solve in a manually-managed knowledge base? (The more librarian-minded amongst us might also argue that this is one of the most fun problems.) Finding and combining stuff. You have all these linked bits, but then you're forced to a) click through link after link until you're thoroughly lost, b) write up your own summary notes that you then link to the raw notes, growing your web, c) see if you can get lucky with tag or string searches, or d) cry.

One of the online talks, Turn 10,994 Notes into Memory, by Paul Iusztin and Luis-François Bouchard proposes one approach: give your agent access to your notes to answer questions for you. And to answer the question of that being way too much context to consume for each question, they propose giving your agent a little scratch area to set up its own memory wiki. It's possible you don't want it in your main knowledge base updating and editing files unattended. But that doesn't mean it can't have its own knowledge/memory base. And the extra neat thing they propose is a semantic index file so that the agent can know whether to look at its own docs, or dive back into your full knowledge base for more information. You would have to do some work and schedule some staleness/wiki refresh runs before deep AI work sessions, but there is a synergy to these two tools that I hadn't considered before and I will be experimenting with my own knowledge base.

Choosing the Right Tooling Layer for Your Agent

Ryan Palo — Fri, 03 Jul 2026 14:57:01 +0000

Selecting the right abstraction layer is not a new problem in software. It's common to have some experimental restructuring to find the right balance between being abstract enough to consolidate all the duplication that belongs together and going too far, making users jump through hoops to use your overly abstracted MiddlewareManagerAbstractFactoryProvider. There are entire books and undergraduate courses on exactly this problem: what level of abstraction is enough?

We now have a similar analog in the space of how we help our AI agents perform tasks. Do we need an MCP for that capability? A skill? Will a simple CLI tool work? The answer depends on a few questions.

Note: For more context, check out Nikita Kothari's AIE World's Fair talk from Thursday, "MCPs, CLIs, and Skills: Choosing the Right Tooling Layer for Agentic Development."

All the MCPs: The Super-Agent Approach

One option would be to load every possible MCP you might ever need access to at startup. This has the benefit of discoverability. If you're not sure what the agent might need to do and you want it to be as unattended as possible, giving access to all of those tool descriptions allows it to be flexible and combine sources and tools as needed. It also allows it to branch out and parallelize, gathering data from multiple sources at the same time.

There's a sneaky trap here, though: MCP server schemas may gobble up your context window. Nikita references example numbers where the MCP schemas for 55 tools from five MCP servers could take up about 16,500 tokens that live in your context constantly.

Skills and CLIs: The Developer's Approach

This is the full opposite end of the spectrum from the previous approach: make your agent aware of any skills that it needs and use those to instruct it on which CLI tools to use and how. Context- and speed-wise, CLI tools have a huge advantage over MCP tools. There's no extra network call to the MCP server, they eat next to no context, and the output of a CLI tool is reasonably predictable. Additionally, if the agent is running locally, you get the benefit of being familiar with its environment and being able to step in and help it along if things get stuck.

The drawback here is security. CLI tools are one of the highest-risk tools for an agent to use because, by definition, if it can access a CLI tool, it can access the shell itself. It's not an unmanageable risk; with careful sandboxing and attention to permissions, the risk can be managed. You also have to be cognizant of what sort of credential issues you may be signing on for. You need to be aware of what credential files the agent has access to, and whether the roles for those credentials are appropriate for its actions.

Why Not Both: The Hybrid Approach

If you have enough MCP servers and tools that it's eating enough of your context to be problematic, you can combine both of the above: bundle your MCP tool usage into skills to avoid the token bloat. Modern clients don't necessarily bundle the entire schema into the context if it's large enough. They do a mixture of caching and compaction/indexing so that they inject just the bare minimum and then load the actual tool schema as needed. If you wrap your process in a skill that describes exactly what tools it needs and how to use them, your client can unpack just the schemas for those tools more fully, saving you context and a bit of load time. This is often the best choice if it warrants the little bit of extra configuration work.

It Depends

So which one should you stick to as the right choice? We started with a storied computer science question, and we're ending with a storied computer science answer: it depends. It depends on what the environment is, what kind of tasks you're trying to accomplish, whether there are CLI tools for the functionality you need, and what your organizational auth/governance requirements are. MCPs are definitely more secure and more governable. CLIs are definitely faster and more reliable. The answer probably lies somewhere in the middle for your use case. The main takeaway here may actually be that the ability to write and maintain really good Skills is a huge advantage.

If you want to do more research into this topic, the Firecrawl blog has a much more comprehensive deep dive into the differences, benefits, and drawbacks of each approach.

The biggest World’s Fair yet powers down for the moment

Iain Thomson — Fri, 03 Jul 2026 14:45:31 +0000

The AI Engineer World’s Fair has ended, and over 7,000 folks are heading back to their homes, states, and foreign countries, and mulling the important lessons learned.

This has been the largest gathering of AI engineers since the conference began in a small way three years ago. Its new home in San Francisco’s Moscone West space oddly mirrors Google’s I/O developer conference, which started as a small gathering in Mountain View and three years later moved into the Moscone due to pressure of numbers.

It has been a novel trip for many. I witnessed three developers from overseas gazing into a parked Waymo with wonder, before the AI-powered car moved off to pick up its next passenger. One, rather sweetly, wished it a “bye bye,” and, based on the system’s popularity, the cars are fast becoming a tourist attraction.

But the conference was all about working and learning. While the keynote speeches garnered huge audiences, it was in the workshops that hardcore coding got done. The show hosted over 100 workshops, ranging from straight product talks to capture-the-flag sessions, roundtable discussions, and coding classes to make models more useful.

AI And The Jobs Dilemma

There was much discussion about the effect of AI on the jobs market, both in public and in private.

If you’re a skilled engineer then there’s no problem – recruiters are beating a path to your door. But for people in more traditional careers the outlook is mixed. Code reviewers should start upgrading their skills, since the increasing efficiency of AI can do their job at a speed and volume is something a human could never match. But there’s no need to switch careers – just move up the development stack and oversee the agent army to make sure it’s doing its job.

Despite talks of job losses, more than one CEO we spoke to is bullish – he’s hiring as many engineers as he can since AI is making them so productive they more than pay their way. He’s looking at AI as a way of expanding his number of employees as a win-win.

On the other hand, for ordinary workers, the outlook is mixed. One attendee said a client of theirs was hiring bank salespeople for eight months and mining their pitches to build an AI pitching agent, then letting them go. His comments brought to mind the long practice of hiring cheap H-1B workers and getting established engineers to train staff in the jobs they would shortly lose.

For hardcore coders the situation is looking less rosy for those who have coasted in their careers. During the show, the U.S. government relaxed its prohibition on Anthropic’s Fable 5 and Mythos 5. While the latter is more important for security engineers, Fable could be a serious threat to those who don’t know how to use it.

Getting Loopy

A key theme of the conference was loop coding in AI systems, and the debate has been constant and occasionally vociferous.

There has been much debate about loop coding – whether it saves money and tokens, if the loop can truly move from codebase to practical apps, if it will lead to more efficient working or if there are hidden problems under the surface, and if it is just an inevitable move for the industry.

That loops are coming doesn’t seem to be in doubt. Last month Microsoft's CEO Satya Nadella was quite clear that this is the next big thing, as was OpenClaw’s founder Peter Steinberger. But it remains to be seen if this is going to be an immediate thing, or a slow burner like Kubernetes or cloud computing.

It has been a fractious debate at times throughout the week. The key question seems to be how efficient looping will be and the cost involved. On the security side there is the fear that loops will be deluging security staff with AI slop – filing huge numbers of flaw reports that repeat common flaws and cause staff to miss more serious problems.

On the cost side the question is will loops save companies token costs, and the jury is still out on that. On one level users can own their own loop systems, which could be a cheaper option than going to the hyperscale vendors. However, if companies aren't prepared to commit to that, then loops could be a money pit.

The Importance Of Lobbycon

Meeting folks in the lobbies of the hall isn’t in the schedule but its value cannot be overstated.

The second floor of the center was abuzz with people catching up with old friends, making new ones, and sharing chat and code that built new relationships. There was even a talk on the topic – possibly the one that mentioned AI the fewest times during the whole show – but was important in building friendships.

Lunch was a key part of this. While the Moscone does sell food, large groups of people headed out to the many restaurants and watering holes in the vicinity to have in-depth conversations. One suspects that more than a few business plans were forged over the last week that will lead to startups shortly.

There’s also the fun side. With the World Cup in town there were more than a few football shirts in evidence – happy USA fans after their win, but the one chap in a Tartan Army shirt was visibly upset after Scotland’s finest failed to live up to the hype. Parties abounded in local venues, with people having fun and building contacts.

As delegates head out of the cool, grey city of love they’ll be carrying important knowledge, useful experiences, and the knowledge that San Francisco isn’t the hellhole it’s portrayed as in certain parts of the media.

The Conspiracy Big Software Engineering Doesn't Want You to Know

Ryan Palo — Fri, 03 Jul 2026 14:38:37 +0000

Buckle up, gang — it's conspiracy theory time.

I've had this theory percolating in the back of my head for a while now. It was seeded as I started learning more about agents and skills, and throughout this whole conference, it has grown to be fully formed. Let me walk you through it in a bit of a scenario:

One of the quickest and most approachable ways to start customizing how you work with AI is learning how to write Skills. When you're writing your skills, it's critical that you explain when it should be used in very concrete terms. It's also important that the skill itself is clear, concise, and accurate, showing step-by-step how to do the process that it is describing. It should contain links to relevant context, and it should be updated semiregularly as processes change.

"But wait," you say, a little confusedly. "Isn't that just good process documentation? Like, aren't we already supposed to be doing that to help our teammates, new hires, and interns?"

"Ha ha ha!" I laugh agentically. "No, no, no, my sweet, little spring plum. We don't need software engineering anymore — that's what the agents are for."

A few weeks after this conversation, somebody at work cites an article shared at the AI Engineer World's Fair. It reported research that there are a multitude of benefits to agent performance if your codebase is well structured and well architected. If you have a practical, descriptive test suite, up-to-date documentation, a clear dev environment setup, production metrics and observability, and a functional CI/CD pipeline, agents generate correct code more often. They create security vulnerabilities less often. They waste less money, and they can be trusted to not break everything as often.

I see your eyes narrow suspiciously. You say, "OK, hang on a darn minute here. Those are definitely just good software engineering practices."

"Ohoho," I chortle into my AI-rtisanal, vibe-crafted, probiotic high-protein custom kombucha blend. "Absolutely not! Look at the date of the study. April of 2026! This is some high-octane, bleeding-edge research you're looking at here, not some decrepit industry standard." I levitate away as you stand there looking frustrated.

The very next day, I'm wheeling my Onewheel through our open-plan office blasting a podcast from a shoulder boombox, and you catch the AI podcast host talking about "in this new era of AI development, the real winners are using prompt caching and routing to manage cost. If you're not working to get the most out of every dollar you spend on AI, you're already behind."

"THAT'S. IT!" We all turn to see you standing on top of your adjustable sit-stand desk (currently in stand mode for extra elevation). "THE NEW HOT THING IS TO TRY TO OPTIMIZE COSTS AND CACHE YOUR API CALLS IN EFFICIENT WAYS?!?" The top of your head catches fire. You don't seem to notice. You look around wildly at the ceiling and walls. "I SEE YOUR GAME! I KNOW YOUR TRICKS! YOU CAN'T HIDE FROM ME!!!" An intern wheels your desk with you on it out into the hall and asks Claude to "hire another staff engineer. Make no mistakes." Another engineer walks through the door moments later, and your People Ops team gives each other high-fives. The head of People Ops updates a metric with a sigh: "Lost another one to the Conspiracy."

And scene.

There's a secret cabal of veteran software engineers pulling the strings behind the curtain to trick us into doing good software practices by telling us they're cool, new AI skills that we need to adopt or get left behind. I'll take no further questions at this point. Thank you.

(Content note: This is a tongue-in-cheek way of poking fun at the hype-ier parts of the industry, but I'm legitimately really excited about how much of this conference was focused on buckling down and using our new shiny tools with a good, solid, grounded engineering base beneath it.)

Let Us Be Free

John McBride — Thu, 02 Jul 2026 15:55:55 +0000

Nearly half a century ago, the free software movement made a demand that was both technical and moral: Users should have the freedom to understand, run, modify, and share the software on which they depended.

It was a demand born from practical life with machines. A printer that couldn't be fixed. A program that couldn't be studied. A system that asked its users to accept dependence as the price of progress.

That belief shaped modern computing and gave us the tools and norms that made the internet, open infrastructure, and collaborative software development possible.

Today, that belief faces its hardest test.

The technology has changed, but the warning signs are familiar. In 1980, at the MIT AI Laboratory in Cambridge, Massachusetts, a new Xerox 9700 printer was installed. The previous printer had come with source code that could be modified, inspected, recompiled, and reinstalled. Richard Stallman had changed that software to message users when their print job was done or when there was a jam, a small but meaningful feature since the printer sat several floors away.

The new printer arrived with software preloaded and installed, no source code available, no way to modify it. If you needed help or new features, you hoped and prayed Xerox would listen.

That loss of agency, alongside other anti-consumer shifts in early software, helped push him toward GNU and the free software movement: the belief that software should be free as in freedom, free to inspect, run, study, modify, understand, and redistribute.

AI and inference services today are not too dissimilar. Closed frontier intelligence can make entire companies, governments, developers, and communities dependent on systems they cannot inspect, reproduce, modify, or meaningfully contest.

At the dawn of this AI moment, we were promised unfettered intelligence across our products, companies, and codebases. We were told we'd be free to build whatever we wanted. At first, with tab completions. Then whole function blocks. Then files. Then apps. And now, entire long-running horizon tasks and services.

But we've traded true freedom for cloud inference and models we can't run ourselves, inspect, reproduce, modify, or own. Inference providers have gotten us hooked on /v1/chat/completions APIs when, just three years ago, nearly everything in a typical engineer's stack was free and open software. Now, the token squeeze has begun, and what was originally a pretty good deal will start to get more expensive, restrictive, gated, and guarded.

This is a freedom problem.

What about open weight models? I can download Qwen or GLM or Kimi or MiniMax and run it locally with ease. Good. That matters. Open weights are a meaningful step toward a freer future, and they should be defended.

But open weight is not open source.

Weights are not source code in the way a compiler, kernel, or editor has source code. They are the trained result of a process we often cannot inspect, reproduce, or meaningfully understand. I cannot inspect or modify the weights, at least not without expensive specialized fine-tuning. I cannot reproduce the output.

A half-freedom is no freedom at all.

The free and open software movement has never faced such an existential crisis. We risk trading our freedom and dignity for access to new frontier models, granted only to a curated list of companies and governments.

As agentic workloads move off "localhost" and into cloud compute boxes, we will soon be expected to trade our sovereign ability to run agent software ourselves for rented vCPU black-sandboxes we can never understand.

We must demand that AI labs open source their models, datasets, and training workflows. We must demand that frontier intelligence be made available for all. We must demand that local inference, agents, and workflows be open and free. We must preserve the right to build with intelligence without asking permission.

If I am not for myself, who will be for me? If I am only for myself, what am I? If not now, when?

If I am not free now, when?

18 Hot Takes On Where AI is Headed Next

dev.to staff — Thu, 02 Jul 2026 15:53:07 +0000

by Peter Yang, Behind the Craft

Today, I want to share 18 hot takes on where I think the AI market is headed.

AI is in a weird place right now. The government is restricting access to frontier models, enterprises are becoming conscious of token costs, and everyone’s trying to rebuild their product for agents first instead of humans.

I’ve interviewed dozens of AI leaders and spent far too much time following these topics on X/Twitter. Here are 18 hot takes on where I think AI is headed next:

The frontier-only AI stack is collapsing
The AI super app era is here
Traditional software risks becoming a dumb pipe for agents
Cloud agents and collaboration are the next wave

The Frontier-Only AI Stack Is Collapsing

Tokenmaxxing at frontier API prices makes no sense. Uber burned through its entire 2026 AI budget in 4 months, Microsoft moved engineers off Claude Code due to cost, and companies are realizing that running everything on frontier models can get expensive fast. Tokenmaxxing makes sense when you’re on a subsidized $200/month plan but is unsustainable at API rates.
Companies will rely on a portfolio of models. Coinbase recently cut its AI spend nearly in half by switching engineers to Chinese open-source models like GLM and Kimi. Airbnb and Pinterest have done the same with Alibaba’s Qwen models. I believe that this will be the default path forward — using frontier for high-stakes work and cheaper models for everything else.
China’s open-source strategy is working. Chinese models are taking market share from frontier models at US companies. China is also building the full AI stack — from energy (e.g., solar, nuclear) to data centers to domestic chips. The Chinese government is planning a $295B investment in AI data centers with at least 80% of the chips built domestically.
Frontier labs are in a catch-22 situation. If they release great open-source models, they might undercut their own frontier API revenue. If they gate the best models behind a trusted list, companies will just lean on open alternatives more. The last major US open-source model was OpenAI’s gpt-oss series back in August 2025, which already feels like decades ago in the AI space.
The US needs to think about its AI strategy holistically. I believe that restricting access to frontier models will only hurt American innovation. Banning US companies from Chinese models won’t work either. Just look at how China took over the global electric vehicle market. To compete, we need the best closed and open models while scaling our energy grid and data centers much faster.

The AI Super App Era Is Here

Anthropic and OpenAI want to transform all knowledge work. Both labs want to remake how white-collar work gets done with agents. What started with coding has expanded to design, finance, legal, science, and more. Knowledge workers are now adopting Codex three times faster than developers.
The race to build the best AI super app is on. Whoever wins it will take massive market share away from pre-AI knowledge work tools. The main players are Codex, Claude, Cursor, and a few others. With browser and computer use, I can already get Codex to handle almost everything I want to do on my computer.
OpenAI is well positioned to win the super app race. ChatGPT has 800M+ weekly active users and Codex is arguably the best AI super app right now. OpenAI has a clear opportunity to merge ChatGPT and Codex into one app and push agents into the mainstream. I think this is imminent.
Anthropic leads enterprise but has a fragmented product suite. Long term, I don’t think it makes sense for Claude, Cowork, Claude Code, and Claude Design to all exist as separate products. Working with Claude needs to feel more like working with a single capable coworker instead of a product suite. Claude Tag, Anthropic’s new agent for Slack, is a step in the right direction.

Software Risks Becoming A Dumb Pipe For Agents

Agents are becoming the default user. Most products are still designed for humans clicking buttons, but agents will very soon read, write, buy, and do a lot more on our behalf. Cloudflare’s data shows that bot traffic to websites already exceeds human traffic. This matches my personal experience — I rely on agents like Hermes and Codex to browse websites and steer traditional apps.
If your product isn’t built for agents, it might as well not exist. Without clear APIs, documentation, and CLIs or MCPs, agents simply won’t discover your product, and neither will the humans who now lean on agents to find things. That’s why the best AI builders I’ve interviewed are all building for agents first.
Existing knowledge work products risk becoming dumb pipes. There’s a dark side to building everything for agents first. Take Google Workspace, for example. If I can just use Codex to edit Google Docs for me, I might never touch the Google Docs interface. Today’s apps risk becoming tomorrow’s dumb pipes for agents, the same way cable became the dumb pipe for internet apps.
Adding an AI chatbot to your product isn’t going to save you. A chatbot trapped inside a single app, with only that app’s context, can’t compete with an agent like Hermes or Codex that carries my personal context and gets work done across many apps. For example, I get a daily morning brief from Hermes that pulls info from my calendar, unread emails, and Slack.
Pure-play SaaS is losing to services with SaaS bolted on. Companies don’t want another SaaS tool to onboard to and maintain. Instead, they want an outcome delivered to them. Pure-play SaaS will struggle to compete with AI skills that users and teams can build and personalize inside their favorite AI super app.

Cloud Agents And Collaboration Are The Next Wave

Startups can compete with AI labs by going deep and using a portfolio of models. For example, coding startups like Devin and Factory are doing well because their harnesses route across multiple models to help customers save on cost without giving up performance. They’re also focused on a few specific use cases instead of trying to be everything to everyone.
Always-on cloud agents will be accessible from any device. Running agents with your laptop half-open will feel silly soon. Instead, many builders are already launching cloud agents using Cursor, Devin, and others. Codex and Claude Code are no doubt working on the same experience, and this will be the default soon.
Collaboration between agents and teams has yet to be figured out. The default agent harness with a list of threads on the left is still very much a single-player experience. The multiplayer experience is still being defined — whether that’s Claude Tag in Slack, agents in Linear, or something else.
“The future isn’t 20 terminal tabs. It’s better loops.” I watched Peter Steinberger share this in his keynote at yesterday’s AI Engineer conference. He no longer watches the agents code. Instead, he defines the requirements, and let agents plan, execute, and validate by themselves. I’m a bit wary of loops since they can lead to AI slop, but I’m sure better planning and models will make them more mainstream.

The AI Market Is About To Get A Lot More Interesting

Here are my 18 takes summarized in four bullets:

The frontier-only AI stack is collapsing. Companies will use a portfolio of models to save costs, with everyday tasks defaulting to low-cost open models from China.
The AI super app era is here. Codex, Claude, Cursor, and others are competing to disrupt knowledge work by using agents for everything you can do on a computer.
Traditional software risks becoming a dumb pipe. Agents will become the default user. They’ll use APIs and browser use to access your website and app without humans ever seeing them.
Cloud agents and collaboration are the next wave. The future is agents living in the cloud, accessible from any device, and collaborating closely with both you and your team. This will happen very soon.

Let me know what you think about these takes in the comments!

How Docusign is Bringing Contract Table Extraction to Production with NVIDIA Nemotron Parse

dev.to staff — Thu, 02 Jul 2026 15:34:59 +0000

By Hiral Shah, Senior Director, Product Management, Docusign

A major recurring theme among the engineering teams at this week’s AI Engineer World’s Fair in San Francisco is the push to move specialized AI models out of research and directly into high-volume production.

At Docusign, that optimization challenge happens at massive scale: we handle millions of transactions daily and have nearly 1.9 million customers in over 180 countries. Organizations have historically lost significant value every year to the friction, delays, and missed obligations that come from treating these agreements as static documents rather than live sources of business data.

Much of that trapped value sits inside tables: the pricing schedules, SLA obligations, and contractor rate cards that define enterprise relationships but are often the hardest part of a contract to extract accurately.

To solve this, we integrated NVIDIA Nemotron Parse, a vision-language model purpose-built for document understanding, directly into our document processing pipeline.

Docusign and NVIDIA took the AI Engineer World’s Fair stage this week to give attendees a look at how the architecture works under the hood. Here’s what that looks like:

Why Contract Tables Break General-Purpose AI

Contracts routinely contain merged cells, multi-page structures, mixed formatting, and nested layouts that general-purpose vision language models (VLMs) and broad AI models weren't designed to handle. The result is inaccurate extractions that require manual correction, slowing down the workflows they are intended to accelerate.

Our teams watch this operational friction play out across real enterprise scenarios every day:

System Downtime: When a critical system goes down, operations teams need to know immediately which SLA notification requirements apply and to whom.
Resource Tracking: When business stakeholders ask legal what hourly rate was agreed to in a contractor engagement, the answer is often buried deep inside a rate card table.
Vendor Renewals: When procurement teams manage a complex vendor renewal, pricing structures scattered across multiple exhibits require significant manual review to piece together.

The Production Pipeline: From Layout To Structured Data

Docusign's document understanding pipeline processes agreements at scale, handling layout detection and Optical Character Recognition (OCR) across millions of documents. Adding reliable table extraction required a dedicated model layer that can handle the structural complexity those earlier stages couldn't fully resolve.

At the core of this integration is NVIDIA Nemotron Parse, a compact vision-language model that combines layout detection, OCR, and document semantics to interpret and reconstruct complex tables accurately.

For production deployment, the model infrastructure centers on two core requirements:

Serving with vLLM: Nemotron Parse is served via vLLM and integrated directly into Docusign's existing layout and OCR pipeline.
Data Governance & Locality: Sensitive agreement data stays entirely within Docusign's secure environment. Keeping documents local is a hard requirement when handling confidential business terms, while giving our engineering teams the flexibility to run and optimize the model for our specific use case.

Moving Beyond Synthetic Benchmarks

To properly validate this integration, we skipped clean, synthetic benchmarks, which fail to capture the formatting variations, inconsistent structures, and mixed-language content that enterprise contracts actually contain. Instead, we tested the architecture against real, complex enterprise contracts.

The accuracy and reliability of this production deployment gave NVIDIA the confidence to deploy Docusign IAM to manage its own enterprise agreements.

What’s Next On The Roadmap

The work doesn't stop here. Our engineering teams are continuing to improve model accuracy on more complex and varied table structures. We are also actively exploring deeper integrations with agentic workflows through the NVIDIA Agent Toolkit, and a public API for direct integration with downstream developer systems is coming soon.

Table extraction powered by Nemotron Parse is currently accepting beta customers for extractions in Agreement Manager, with full general availability on the horizon.

If you're building document intelligence pipelines or moving VLMs into production, how are your teams tackling structural layout variations? Let's swap notes in the comments!

Your Agents Should Be Multiplayer

dev.to staff — Thu, 02 Jul 2026 15:32:03 +0000

by Sergey Karayev, cofounder @ Superconductor

Recently, my wife and I sat down to plan an upcoming trip. Naturally, we each asked an AI. Trouble was, I had my chat and she had hers, and they knew nothing about each other. So we served as couriers between chatbots: her idea pasted into my chat, my hotel booking screenshotted into hers, the itinerary reconciled by hand in a Google Doc.

I bring this up because your team probably works the same unfortunate way: each person in their own chat or coding agent session, with precious little shared.

I've been building software with the same set of people for over a decade. In the past year, we all got a superpower: coding agents that can do extremely impressive things. But each one (Claude Code, Codex, Cursor, etc.) was built for a single player. That's fine and dandy if you're vibe-coding your own little app. It's just you and Claude, and it's absolutely magical.

But put that same agent on a team and the magic fades quite a bit. The model is no longer the bottleneck. Coordination is. You don't know who's working on what. You can't see that an agent already tried the approach you're about to attempt, and abandoned it. You spend an hour re-deriving context that a teammate has, because it's trapped in their private chat.

Now let me tell you of a better way. On the Superconductor team, every coding agent session is in the cloud, open to anyone else on the team to join. What this enabled was transformative.

Code review improved first. My teammate reviews my work by joining the session I built it in. The session holds the full history of decisions, including the dead ends. Instead of Slacking me "why'd you name it this way?" she asks the agent. She gets her answer, and I never waste time answering. She also doesn't have to check out the branch locally — the live app preview in the cloud sandbox does the job.

Handoffs became easy. If I have to pass a feature to a teammate, he picks it up with full context: what's done, what's left, what the agent already tried. Nothing is trapped on my laptop, and the ball keeps rolling. And since agents don't sleep, a team spread across time zones can push forward around the clock. The old "shift" model of work might be making sense again.

Perhaps most importantly, we are continually learning best practices from each other. Every knowledge worker is facing the same question right now ("what's the best way to use these things?") and mostly figuring it out alone. Your teammates are quickly going to teach you more than any blog post.

And the utility of multiplayer AI goes beyond code. We now have an agent sitting in all of our team and customer meetings, reading the live transcript and taking actions while we talk. Another agent regularly checks on our progress against our stated goals and messages people as needed for clarifications.

My bet is that the agentic company of the future runs on shared cloud sessions. More like Slack threads, less like terminal sessions. The teams that pull ahead will place their agents where everyone can collaborate with them, instead of handing each person a genie with a lamp to hide it in.

My co-founder Arjun expands on the theme in his talk on "multiplayer agentic engineering: how to have your whole team and your best agents work together." Come by today (Thursday, July 2) at 1:55 p.m., Room 2020 — we'd love to hear what you think.

Letting the DEV Community Weigh in on the Topics of AIE

Ben Halpern — Thu, 02 Jul 2026 15:24:12 +0000

I’m at the AI Engineer World’s Fair in San Francisco, where the vibes are enthusiastic. However, enthusiasm does not mean hype. The content has largely been grounded in pragmatic problem-solving. My sense is that the industry is finally homing in on the "jobs to be done" conversation over model hype — though I could still do without the “maxxing” suffix applied to everything.

To mirror the tone of the conference itself — where raw hype isn't quite as cool as it used to be — the global DEV Community has been providing excellent commentary on the reporting we’ve been publishing. The Daily Context newspaper has been distributed every day at the conference to help attendees stay caught up on broader themes, but it’s also gone out on DEV for thousands of remote developers to read and weigh in on.

To close the feedback loop and elevate the conversation, here are a few standout quotes and themes from the community that caught my eye.

Infinite Code and Shifting Constraints

We talk a lot about AI enabling us to ship infinite code, but our community quickly pointed out that raw volume is a vanity metric. Raju Dandigam cut straight to the core of the issue, noting that:

"Choke points govern value, not code volume. The teams who win won't be the ones generating the most, they'll be the ones who made the choke points cheap to clear."

When code generation becomes free, our bottlenecks move downstream to architectural cohesion, verification, and code review. As Nazar Boyko added, a development command center only helps if it surfaces the current constraint; otherwise, you've just built a faster way to watch the wrong thing.

Blame Shifting and the Frontier Default

Another fascinating debate unfolded around why developers stubbornly default to expensive frontier models for trivial tasks. While it's easy to preach about "tokenomics," kingai offered a brutally honest psychological perspective. The frontier default isn’t always a capability hedge — it’s a blame-shifting hedge. If a fast model fails, it's your fault; if a massive frontier model fails, you get to blame the model.

To break this habit, Pon argued against making users choose between models upfront via complex dropdowns. Instead, software should default to fast, cheap models out of the gate, gating escalation on a deterministic check of the output structure rather than the model's own self-reported confidence.

Agent Architecture: Claims vs. Evidence

The structural shift toward treating an AI agent as an append-only event log generated some of our sharpest technical pushback. While the log-as-state model ensures exceptional reliability, Alice dropped a brilliant warning: The log faithfully resumes claims, not objective truth. If an agent records a confident status event saying a file is empty without an underlying tool confirmation, the log simply hardcodes a durable hallucination.

Mateo Ruiz proposed an elegant architectural split modeled after double-entry bookkeeping: Maintain a claim ledger for state resumption, but use an independent evidence ledger (file diffs, exit codes) to handle real-world verification.

The Hidden Tax of Autonomous Decisions

Finally, we have to look closely at dependency selection. When you ask an agent to build a feature, it implicitly chooses your library stack for you. FrancisTRᴅᴇᴠ highlighted the profound security edge here, warning that a model's authoritative delivery easily disarms human checkers, leaving the door wide open for typosquatted packages or supply-chain attacks.

Practicality Wins the Cycle

The DEV community isn't getting swept up in the sci-fi dream of fully unsupervised autopilot. The developers winning this cycle are applying basic, defensive engineering principles — making inputs predictable, creating strict code harnesses, and testing outputs rigorously.

Frankly, I think that mirrors the tone of the conference, and this is the feedback loop our industry is in right now. Everyone sees a form of progress, but nobody wants their AI-pilled manager to come back from the market having been sold magic beans.

Without Structure

Ryan Palo — Thu, 02 Jul 2026 15:18:45 +0000

“Without structure, AI makes code worse.” - Tereza Tížková

AI is a supercharger, not a magic wand. It doesn't magically fix all your problems and make your code better. It just amplifies what's already there. If your codebase is an unstructured, sloppy, brittle mess, adding agents will just help make more of that. Additionally, and hopefully unsurprisingly, how you implement AI coding practices on your teams affects the outcome powerfully. Much like an actual supercharger, it works much better if you incorporate AI coding practices in a structured, measured, and deliberate way, versus just bolting it on and firing up the engine.

Luckily, there's a rubric for ensuring your codebase is agent-ready. Here are the pillars the Factory team enumerated as indicators of a well-structured codebase: style and validation, a build system, testing, documentation, a dev environment, observability, security, and task discovery. If you're feeling comfortable with how your codebase scores in all these areas, then it might be ready for some agents to work within it.

Luckily, this is a net win no matter what: As it turns out, all of those things on that agent-readiness list are also the things that make for a really solid, maintainable, scalable, and stable software product for humans to work on, too. Making improvements in these areas ends up being zero-cost versus if you weren't planning on adopting some agents. This has been a theme so far at the World's Fair: It seems like we're working our way out of the initial hype cycle. It's no longer good enough to burn tokens and ship the product as fast as possible. We're engineers. We're learning to use these tools like we've learned to use all of our other tools: to build good things well.

Check out Tereza's talk on the AI Engineer World's Fair 2026 livestream for much more detail and references.

Some Robots Just Can’t Handle The Expo

Iain Thomson — Thu, 02 Jul 2026 15:05:23 +0000

As you'd expect, there were robots aplenty at the AI Engineer World's Fair Expo, although with mixed results.

Many companies had little four-wheeled box robots, such as those used to deliver shopping in some cities. One would dispense small swag gifts in exchange for a QR code, while others just jerked around the floor, stopping and starting to avoid running people over.

Those that garnered the most attention were the humanoid bipeds, but this proved to be a mixed blessing. While they were attracting a lot of attention, it wasn't always the best kind. We observed numerous delegates having great fun trying to push them over.

This seems a tad rude and, judging from the picture, at least one was left broken in a tangle of limbs. Its compadre was all right, however, and was in the traditional kneeling pose while it recharged, or "praying to the great power socket," as one wag put it.