Building on Ethereum with agents
Devcon 8 · 3 Nov 2026 · 26:50
BuidlGuidl engineer Shiv Bhonde shares lessons from evaluating how coding agents build on Ethereum. Drawing on work maintaining Scaffold-ETH 2, he examines common mistakes, the value of established standards, and practical ways to help agents make better decisions when building applications and smart contracts.
Speakers
Topics
From Devcon 8, hosted by Ethereum Foundation.
Transcript
[music] Hello. So yeah. Hi, my name is Shiv. Uh I work for build guild as a fullstack developer and um we are the creators of scaffolded 2 and we have been maintaining it from the last 3 years and we have been doing these kind of workshops like building on Ethereum uh for the past couple of years but now the things have really changed and now there is an agent which comes with you always and it has happened like very quickly.
So I hope you guys remember these days like it's not that long ago like it was like four or 5 months ago but yeah like we were crafting the code by hands we are thinking how to write good code then all the assets and everything all the team sitting together but now we have a genie where you can just make it a wish what you really want in plain simple language. age and then it figure out the internals like okay it needs an asset for a game it needs to write or spin up a couple of services and it does the job and you just need to know what you want
what is good and I was trying to uh dig into the facts that whether the people have actually started using the agents and I felt like this is really a good start like If you see in 2025 uh like the whole 2025 there were just 83 million commits on the GitHub but just in September 2026 there are already 7.38 billion commits so it's like 89x um and I mean obviously lot of it is a lot of slop but still I mean people are using it heavily
And all the developer tools which you use are also changing for the agents like earlier uh us uh we built scaffolded 2 in back in 2022 and it was majorly to improve the developer experience for building apps on Ethereum. It had good amount of downloads and we also started thinking about um how our tools are changing for the agents. So if you look like 2022 is when the scaffolded to started giving a quick loop for developers to write code, check the contracts, go on the front end, talk with the contract really
nicely, all this stuff. Then in 2023, we launched extensions. We partnered with Metamas, sign in with Ethereum. So we made a lot more easier like the life of the developers so that they can just plug in the extension. We had to write a lot of code to enable that for the developers. But yeah, but then in 2025, we had this kind of co-pilot beside you, but you were still opening your text editor, but there was this magic of tab autocomp completions. And then we decided, okay, like how do you give a nice context for that copilot and you are still diving driving in your ID?
Uh then we added llm.txt. So giving uh your agent more context people started looking at the docs less and they were just going to chat GPT and asking it the questions and then that's how we evolved like we gave agent llm.txt t so humans don't need to read it but the agent does it for them but at the end of 2025 there was this point and we had claw code to which you can actually give task a big task and let it drip like you can just sit down go on a side and it was really autonomous it was
taking the agency of doing the And yeah and now earlier it was you as a co-pilot but uh no agent as a co-pilot and now it's you as the co-pilot and agent is working for you. So you are just backsitting and saying like okay uh do this do that for me and now you need to make sure that uh agents have really good context of the code and everything. [snorts] So yeah, this was how our extension was looking at like in 2023 like we really tried hard to make developers life easy by giving them extensions so that it's
really easy for them to spin up the apps but yeah like in 2026 we just remove all this bloat uh and just we just give the instruction to agents how to do it. So now it's just a plain English skill file which your agent looks and it knows how to come up with a good code or if you need sponder it can come up with that service easily. So yeah like I would like to just pause here a bit and get one of our main takeaway uh while building with agents is that you need to make sure that the code base is actually good for the
agents like for the past 15 or 20 years we have been maintaining code base for a humor. We have human like we have always thought about how a junior developer can come in and how easy it for it is for him to change. But now you need to make sure that your agent really nicely flies through the code base uh so that it builds better and yeah like you need to be really mindful about the patterns and the taste of how you want your code to look like from overview like again you don't need to go into internals.
Yeah. And now let's look at how the agents are with Ethereum. uh I mean if you look at general agents performance in software development like general software development performance of agents they have been increasing like so these are the evals uh very famous like terminal bench 2.0 to uh software engineering benchmark. So this benchmark basically evaluates how the agents are getting better and these benchmarks are written by really good developers and agents like I mean the good developers are really going out of the task to write to evaluate these agents like the agents are getting
really really good with general software engineering stuff and probably you see like they are doing big germs as well but with Ethereum We are not that good like we have been doing like from past couple of months we have been evaluating like Reinad will be in his next talk talking about that how we are evaluating but um I would like to present some examples where they are not that good. For example, here right like in web 3 like there is this basic flow that uh there are lot of chains and if you want a user to connect and interact with your app you need to make sure that he's on the right chain and if you ask an agent
to do it right now like it will make sure that okay even if the app lives on Ethereum and your wallet is on base you will be able to connect on base and then if you hit deposit then it will ask hey actually you are on different network. Would you like to switch on Ethereum? But like a good UX would be like you hit deposit the wallet ask you to switch to the network and allow you to transact. Um again the ENS like I mean if you ask the agent that hey can you please make sure my uh input allows ENS address like the agent knows how to figure it out.
But if you give it a big task what we normally are doing now with the agents like we are actually giving them the big task and not an arrowed one but during that time it turns out that it has not that good uh it doesn't follow that good pattern of uh all the input should be ENS allowing and then there is this another thing like this was one of the models which we were testing open models and uh for some reason like uh it was not able to find a flag in foundry and then it started generating its own EVM and started making the transaction and started doing
its own work. Whereas if it had a good resource or a pointer like it was just a flag which it needs to add but it just went on this whole journey because now it can't. So yeah, you need to be just mindful about this stuff and yeah, on Ethereum these things actually cost money. So yep. So the takeaway here is like the agent knows Ethereum. They knows the knowledge of it, but they just don't do it unprompted. like you need to still stir it a bit or point it to good resources on how to start with it or sets its trajectory at a good place so
that it takes the good uh pointers and for that we have skills. So the skills are basically the markdown files which uplifts the agent's capability in a certain domain and uh yeah so you can use skills and give it to your agent so that sters the output of the agent a bit and increases the capability and we have a lot of skills as well. So if you go to ethereum.org/developer.tools tools. Uh here you can see the if you search for skills MCP everything uh there is this security audit skill by pass which is really good and eklls is
basically amalgation of all the skills. So if you just give your agent eatsklls.com and ask it to do the stuff it will figure out all these things. It has all the context pointers to all these good resources as well. So yeah, it is a directory of skills I would say and a context pointer to all these good skills as well here. So yep, you need to put all these patterns tools which you want your agents to use u in your codebase.
And yeah like in this third part of the workshop I would like to focus on how to work with agents effectively like u we as a build guild or developers like we have been really close to working with agents and seeing and being very mindful that how humans were using our developer tools and now how agents are using and how we are using as well. and I like to talk some of the workflows and some of the insights uh from my experience. So first one is like you need to get really good at writing the spec or understanding what you really want. uh
because I feel like spec is kind of a new code uh which you hand to your agent and then it figure outs the internal and if you just um let your agent rip like it will come up with something very different which you don't want and you want to rework it again. So this is a kind of a rework graph. So if you don't write no spec at all and just give a very bare prompt to your agent, it doesn't know what it wants and you have to do a lot of rework and if you write a very detailed spec of what you want still you would like to do a rework because you don't know what you want. So
again like at both the points the rework is a lot. you need to find a good balance like your specs should be very light like it shouldn't be very detailed uh and you just work with your agents and you just get like what you really want and I mean yeah like if you are still writing code by hand then probably the rework is very less so uh this is just an example so like uh we were we were working on this project called eals uh and it's a big project like we need to figure out different stuff like there were four people team working on it. So we had first the humans need to align
what they really want before they start adding the agent to the team and u Carlos first wrote this issue with a detailed spec so that us as a human we use the same vocabulary right like okay like what is the vocabulary which we people are going to use while talking what are the things so basically this uh spec helps your agent kind of gives a hazy boundary to work in and it doesn't go completely out of the world and then uh yeah like agents what I've realized is that they really love working or conquering the horizontal
slices of the task but they have that much amount of mind space and everything that they can actually go vertical and have a good slice like they always like they will start by writing the whole cont. I think the colors are not visible but yeah like they loves going horizontal but you want your agents to go vertical because they can build a whole slice of a stack so that they can get a quick feedback. Um and if you ask them to go vertical so they write the contact, they write the pages, they write the hooks and while develop developing the front end they they come and see okay I need an event indexer. So I need to figure out how to
write a event indexer as well. So then it goes and it updates contact. So this is the loop which you want. So you want your agent to go vertically through the slack uh through the stack instead of going horizontally. And this is the next thing like you want the agents to work in smart zone. Uh smart zone is basically this idea came up by Dex Horthy where agents train to their quality of the output of the agent drops around like 40% of the context window. So if you allow your agent to work within the starting 40% of the context window and let it rip in
that thing, it will generate really good output. And if there is a big task, uh what you can do is you can use another agent, consult with another agent and ask it to build in the slices so that each slice lies in the smart zone and you get a really quality output. And this is the last and the most important skill I would say while working with agent is being retrospective about the things that how the agents are working. What is the thing which you don't like about the agent like maybe it's the output which is which it is giving you back how the text it is giving you. So all these
things I think you need to be retrospective and you need to make sure that you have this kind of a good feedback loop for you that you write a spec, you allow the agent to implement, you allow the agent to verify its work, it does code review, it does the shipping, then you have some kind of monitoration uh doing then there is a new task. Along this loop you need to as a human be aware that okay like maybe my agent is spending a lot of time in the verification or there is something which it is getting always wrong. So maybe that is something where you can fix the loop and in this whole loop there are
some things which you can fix. So that is I feel where the human parts comes in is just monitoring the whole loop and just keeping the notes and just allowing the agent to fly nicely. And the only thing u if you want to take from this workshop is that I want you guys if you are complete beginner I don't want you to think anything a lot like just enter this prompt in your agent like scaffold.io/skillmd io/skill.mmd and just enter your idea here and let the agent build so you get your hands dirty as well and this contains all the
things all the skills which I talked about everything and your agent will really nicely fly. >> Yep. And thank you. I like uh do we have time? >> Yep. >> How much uh is it? >> Uh 8 minutes. Okay. Yeah. So what I did was like uh while doing this presentation I kind of tried building a app as well. So if you scan this QR code it's called local rush.mumbai localrush.app app and it's kind of this website which
this is again like what my agent built in the one whole thread and it gives you a burner wallet and it kind of depicts our Mumbai that okay like if you want to get into the local it's really hard like local is really going fast and to get in uh you need to push people really hard and if you don't push people really hard like the train will get missed. So yeah, it says yeah, you need to tell them and then if you do it, it bs you an NFT.
And again, this is gasless like you don't need to don't need your wallet to have gas. It the agent figure out how to add the pay master and everything. And you get this nice local ticket uh on your wallet address which you can transfer to your EOA as later. But yeah, like this is how I started like first uh I gave it a really good speak not that deep like it was just one message and then let it drip like it did all the things in between. I had a bit of question and answer so that we align what we actually want and then again
like just letting it rip and this is what it created. It figured out how to do uh the pay master stuff and it also had a context of my talk as well. So it gave me a nice QR code as well in the chat like I didn't have to go on the website to generate this like agent did everything. Yep. >> All right. Thank you Shiv.
And then over to the questions. uh before you take off your laptop maybe you the question is that what does your personal development environment look like what editor do you have harness what skills MCPS and what model do you use >> so I mean editors I'm not sure [laughter] what editor I'm using right now because I already forgot about that stuff but I use agents like so currently I'm using oh uh my laptop >> can Can we get the screen back?
>> Okay. Maybe you just explain verb. >> So I use T3 code. >> Yeah. So I use this uh T3 code which is basically an agents orchestrator. It's completely open source and it helps you orchestrate all the agents. So here you see on the right side uh I use my Opus 5.5 as a main agent like an orchestrator and then it spins up all the GPT uh agent opus for some research work and uh yeah so T3 code is the one where I do all my work like it has uh editor as not editor but if you want to look at a file pick you can just pick at a file from
here as well and Even it has a nice GitHub uh UI as well in this uh UI. Yeah, it's like a graphical UI on top of cloud code and everything. So yeah, T3 code. >> Is this the vanilla version or do you have some Ethereum specific plugins on top of it? >> Uh no. So uh the thing is like I just use scaffolded.io/skill.mmd. So this link has everything like it has the contest context pointer to all the necessary resources. Yeah.
>> And then you have subscriptions for two. >> Yeah. Code and codex. Yep. >> Right. >> And I mean again like this environment which I talked about T3 code is something which I recently started using and things are moving really fast. So I don't know like maybe next week I'll use some kind of different orchestration. So yeah. >> All right. Then one question is what models do you use and what subject for each one? So you told the models what you use but how do you divide between them?
>> Okay. Again like these models are very deterministic but uh for now like my flow is Opus 5.5 as the main orchestrator because it's really fast. It has good intelligence and I use GPT 6.1 solve as a implementer. So it's really good at implementation stuff uh and fast as well. So yeah like 5.5 as orchestrator and 6.1 solve as uh implement for the code >> and it's probably a good idea to use different models because then they will review each other's code from a different >> yeah that is another thing of >> opus review the code by GPT >> have you found that any specific or
actually this is going to be in the next next talk more about the the models and which is good for what. So, let's let's keep that. But there's one question about what are your thoughts about XDLC for pre-agent era services? And I don't know what XDLC is. >> Yeah. >> Is the Oh, SDLC, I think. I see. I see. Yeah. I think Antropic wrote the article recently. Yeah. I think uh I like that idea a lot. Uh that yep like I think we have gone a bit higher when
it comes to development and now we just need to have a good conceptual integrity along the team and I think specs allows you to do that having a conceptual integrity along the team. So I haven't dived deep into that yet. Yeah. Uh sure. Do you want to have the mic? So that >> so uh what I was saying is uh a lot of developer forums are uh some people don't like this specdriven thing some people are for the specdriven thing and uh the argument that comes is that a lot of uh services that are actually in
production today they uh they do not have the specs and a lot of that code is handwritten and if you write specs for them. Uh the handwritten code might not be accurate to them in a lot of places. So some people argue that yes use specs but let your agent rewrite the service and uh regenerate the service from the specs itself and some people say that no uh let let it build a context and go from there. So uh that is what I wanted. Like for my like my take has been like uh very light spec and let code base be the context for the agent like the code which is there it needs to act like a
context and not a file because that is the thing which I have realized like specs seems to get outdated when the agent change across the team because there might be another team member whose agent is not aware to update the spec. So it's really good that your code base is heavy with context. Um and then of that's why like I think languages like effect.ts or things uh languages like that are getting popular because they are more uh descriptive for the agent rather than writing spec. So yep I think there needs to be balance.
>> All right. All right. Thanks. [music]