Fast Code Generation Is Easy. Safe System-level Change Is Not.

Two years ago, the question was can agents write code? Today, the question is can your codebase survive them? This talk is about the second question. My name is Bart. I've spent the last 15 years as a software engineer in a variety of roles, and full disclosure, I'm also the guy who built Fellow, the tool I'll mention a couple of times tonight.

For me, the interesting question has moved. Getting an agent to produce a working div is basically solved. The hard part is keeping a large codebase coherent while agents pour code into it faster than we ever did ourselves. Remember when we argued about tabs versus spaces? That feels like a lifetime ago. The speed in which LLMs generate code changes my job. I want to describe user outcomes and spend my time on product behavior. Edge cases and trade-offs.

The conversations that still need a human. And what I don't want is to babysit the agent with the same quality instructions in every prompt. Avoid duplication, clean up unused exports, keep complexity down, write tests that mean something. Those rules should be part of the system, not part of my prompt. So here's the workflow this talk is about. The developer describes intent, the agent changes the code, the local toolchain catches quality drifts, and the human reviews outputs, evidence, and trade-offs. Let's walk through it.

This is the kind of prompt I actually want to write. It's about the user, it's about behavior, it gives acceptance criteria, and it leaves the door open for questions when the product behavior is ambiguous. Notice what's missing. Nothing about how to structure the implementation. No extract the hook, no don't touch the barrel file, no make no mistakes in caps. The agent should inspect the codebase and the checkout flow, in this case, figure out how money formatting already works, make the change and run the checks.

The quality system should catch problems during the agent loop, automatically, every time. That's where deterministic tooling comes in, because agents will usually take the shortest path to working behavior, and that's useful, but in a large repo, it's also how the trouble starts. The agent is trying to satisfy the requests. Honestly, that's what every new hire does, too.

For our savings future, for example, the quickest working implementation might be to write a money format or straight into the checkout component, or to add one more conditional to a component that was already a load bearing if statement, or to import from whatever file has a promising name, even if that file belongs to a local node server and contains server-side secrets. And here's the uncomfortable part. The demo looks great. The users use their savings, the PR is green, everyone claps, but meanwhile, the code base got a little worse, and nobody noticed because each individual change looks perfectly acceptable.

Code quality research has studied smells, complexity, and maintainability for years, and it keeps reaching the same conclusion. These problems breed bugs. Agents generate the same category of maintainability problems. They just generate them a lot more. They just generate them a lot, lot faster. So the feedback loop has to get faster, too. Keep this checkout example in mind. By the way, we're going to see this exact change again later, called red-handed by our tooling. Now, the first answer you might reach for is you should write it in the rules file in the CloudMD or the agents MD, and rules files are genuinely useful.

Now, the first answer you might reach for is you should write it in the rules file in the CloudMD or the agents MD, and rules files are genuinely useful. Every repo should have an agent.md, a Cloud.md, or whatever project memory format your agent supports. That's where the stack lives, the commands, the conventions, the known food guns, the architecture intent, but that is context. A rules file is like the safety briefing on an airplane. It's genuinely important information delivered on every single flight and absolutely no guarantee anyone follows it when things get exciting.

So Cloud's own docs spell out the failure modes. CloudMD content is delivered as a user message. Cloud tries to follow it, and there's no guarantee of strict compliance. The same docs also say that anything which must run at a specific point, like before every commit, should be implemented as a hook because hooks execute at fixed lifecycle events, regardless of what the model decides to do. That's the distinction this whole talk hangs on. Rules files make the agent better informed. Deterministic checks make the workflow enforceable.

If a rule needs to run every time, it doesn't belong in prose. It belongs in a tool, a hook, or a gate. So which checks? I defined four different layers. There's TypeScript, which is for type correctness, but it even has options like no unused locals and no unused parameters. Also useful for code quality, but at a very specific scope. And Linting checks local policy, framework rules, for example, naming conventions, restricted APIs, project conventions, and tests check the behavior we explicitly thought about. But Fellow sits in a different layer. Code-based consistency around the change, unused files and exports, duplicated logic, complexity hotspots, circular dependencies, boundary violations, dependency hygiene.

So TypeScript protects types, Linting protects local rules, and tests protect expected behavior. And in the end, Fellow attempts to protect the codebase from structural drifts while everything else is technically parsing. Let me classify Fellow properly. It's a deterministic static codebase analyzer and change code quality gate for TypeScript and JavaScript. I describe it as a deterministic codebase intelligence. It's written Rust native, so it's blazing fast, zero config, and no AI inside the analyzer. It's a deterministic static codebase analyzer and no AI inside the analyzer. And that last part is my favorite. And it matters for this talk. The coding agent I'm using and everyone's using is probabilistic. That's fine. That's its charm. But if my quality gate is also vibing, then I don't have a check. I have two opinions. The agent proposes, and something boring and deterministic should verify. Boring is a feature here. You want your quality gate to be boring. The part built for this loop is the audit command. A PR risk gate for human and AI-generated codes. It combines changed file, death code findings with changed file complexity, and duplication findings and emits a verdict. Pass and warn, exit zero, and fail, exit one. And note the scoping. It's changed files only. And that's not an optimization detail. That's survival. If a tool is slow, the agent will route around it. The developer will also route around it. And it ends up running once a night in CI, where nobody reads it. Or worse, on a dashboard somewhere. A check only changes behavior if it's fast enough to live inside the loop.

Now, you might ask, why doesn't the language just do this? And some ecosystems do. Go straight up refuses to compile if you have an unused variable or import. Rust has dead code lints built in. And Zig even makes an unused local a compile error. But TypeScript and JavaScript are gloriously flexible. Which is a big part of why they've always been so productive. And it also means a lot of structure lives outside the compiler. Framework entry points, barrel files, re-export change, table aliases, monorepo boundaries.

TypeScript will not tell you that a public export quietly died in a generated refactor. The ecosystem already has specialized tool. KNIP for unused code, dependency cruiser for dependency rules, JSCPD for duplication. But Fellowes' angle is combining these code-based consistency checks into one fast tool and making the output agent ready. So this is the loop I actually run. The developer starts with product intent. The agent changes code. And the local environment checks the results. While the agent still has the task in his head.

CI still matters. It's the shared confirmation layer for the team. But the repair loop should happen earlier. While the fix costs nothing. There are few things worse than a release blocked by failing CI. And hooks are the mechanism here. Shell commands that execute a fixed life at fixed life cycle points. So certain things always happen instead of relying on the LLM to feel like doing them. Fellowes ships this as a one command setup. What you get is a pre-tool use gate on the agent's bash tool. Think of it as a bouncer standing at the door of git commit. The agent walks up, the bouncer runs fellow audits, verdict fill, the commit is blocked.

The agent walks up, the bouncer runs fellow audits, verdict fill, the commit is blocked. And the bouncer hands the agent a full JSON list of reasons it's not getting in tonight. Straight back into the conversation. And there's the beautiful part, the agent doesn't argue. It doesn't sulk. It just fixes its outfits and comes back two minutes later while the context is still fresh.

And the same installer can also write a plain git pre-commit hook for humans. Same bar, both species. So remember the checkout shortcut from earlier in the presentation? Here it is, caught. The agent wrote its own money formatter into the discount file and left an unused export behind. The feature works, but the audit fails. At the top, a verdict. This one says fail, so the bouncer from the previous slide blocks the commits.

And then there's the attribution, the summary of the whole story. The gate mode is new only, one introduced dead code finding, one introduced duplication group, zero were inherited. The tool separates what this change caused from what was already lying around. Then the findings group per type, symbol and the line. And each finding carries an actions array. The unused export is marked autofixable and the duplication suggests extracting a shared function. And there's even a ready-made suppression command for when a finding turns out to be intentional.

And then next steps, my favorite part for agent workflows, runnable read-only evidence commands for when they need them. Here it suggests tracing the export before deleting it. And note what the tool does not do. It never edits your code. It slides the evidence across the table and lets the agent own the fix. And why new only? Well, every real code base has a history. Some of it is from 2019, written by a long gone colleague with a do not touch command above it.

If the gate blocked on all of that on day one, nothing would ever ship. So, all that feels only on findings introduced by the current change sets. Inherited findings still show up as contexts annotated introduced false. And if you're feeling brave, the gate all modes fails on everything in change files. That is what makes the loop practical. Block new drift first, ratchet quality over time. Keep the agent moving without letting it add more decay.

So, why go through all of this? Because of what happens at review time. If the agent generates more code and I review every line with equal intensity, I haven't gained anything. I've just moved the bad bottleneck from writing the code to reviewing it. And funnily enough, for me personally, reviewing is a lot harder than writing. The goal is not to look at less code out of laziness. The goal is to get higher trust through better evidence. I still own the change. I still review the risky parts. But the review starts from a stronger signal.

Does the feature solve the user problem? Did we cover the edge cases that matter? Did the agent quietly make a product decision that should have come back to me? And did it touch a sensitive boundary? It fell out TypeScript and the tests pass. And this is the broader direction of the whole field. Engineering with agents becomes directing systems that produce code. The things that keep their value are ownership, taste, repo-local context, strict guardrails and fast feedback loops.

The typing was never the point. Looking at less code only works when the evidence gets better. That's what the deterministic layer is for. So, let's finish this up. Fast code generation is here. Fibre coding, loop engineering, whichever flavour, and when you have a taste of it, you're not going back to handwriting for loops. The next problem, the actually interesting problem, is keeping codebases coherent while generation speed keeps climbing. As an engineer, I want to prompt at the level of user intent. And architecture trade-offs. I want to think about the hard problems. I want agents handling the implementation details. And I want deterministic systems enforcing the quality rules that should never depend on prompt discipline.

TypeScripts keep checking types, Linting keeps checking local rules, tests keep checking expected behaviour, and for me now, Velo checks consistency across the codebase. Hooks feed failures back to the agent while the fix is still cheap, and CI confirms the final state for the team. And the human reviews the output, the evidence, and the trade-offs that are being made. The agent writes, the local loop verifies. The human decides, and with a bit of luck, git blame will keep pointing to a human for the foreseeable future.

Thank you. Thank you so much, Bart, for your session. It was really interesting to learn about your product, about your approach, how to make our work with AI agents a bit more predictable, I'd say. Of course, it's like super simplification, but still, I think that any chance to have some deterministic part of today's heavily AI agent-infused workflows is always good. At least this is… In my sessions on, for example, token optimization and token cost optimization, I always recommend to inject as many as possible this deterministic guardrails. All type checkers, linters, uniters, everything. That prevents drift at its earliest stage. So we don't go in the totally wrong direction and the price of a mistake is the lowest.

That's a good question. In the beginning, I was really working with the linters. So, I noticed… I think the first time I actually saw the great benefit from it was when Cursor, back in the day, added something that every time you edited a cursor or the LLM edited code, it would immediately run the linter. And it was such a difference in quality to me because now the code generated really fits what I wanted it to look like, how it works. And so, that really taught me the values of those static analysis. And as time went on, I thought, well, I want to see how far I can bring this. How can I bring in more tooling?

So I found out about KNIP, which does a really good job at detecting the dead code parts. And I also noticed that it was duplicating code left and right. So I added JS CPD, which does the duplication part. And that all really surfaced how all these tools were helping the agent to write better code. But I noticed that when it was all in those different tools and at the time, those tools were a little bit slower. So I thought, well, maybe I can build something that does the same thing that these tools do, but in a faster way so that I can put it inside the loop and I can get faster feedback. So that's how I started. And now I'm just thinking about, okay, how can I make this tool do even more stuff that linters can't really do because they're looking at single files. So, yeah. That's really good. I mean, the deaf community needs more stories like that, right? Some real-world problem, a bit of curiosity and huge potential to build tools these days, right? I checked your repository. I see that you actively use artificial intelligence to build this, right? There's lots of skills, custom agents, everything, right? Yeah. Yeah. Because I think that's how you would develop these days to really use it. And, yeah. Absolutely.

This is a Rust code base, and Rust offers more capabilities than Fallow. Enhancing a programming language to align with Rust's community standards is a compelling motivation for language development. Addressing false positive findings involves strategies like suppression, category-based disabling, and reporting potential bugs in Fallow on GitHub. False positives in Fallow can sometimes stem from internal framework configurations, especially in less commonly used frameworks.

Fallow is an open-source project, welcoming contributions through pull requests. In comparison to Sonar, which is broader and covers a wide range of languages, Fallow focuses more on being a dashboard tool. Sonar is known for its extensive coverage across various languages, while Fallow is more tailored towards specific functionalities and frameworks, providing a different user experience.

To work with false positives, there's basically two ways. One is you can suppress findings. So, if you're actually using it somewhere, there's just like ESLint. There's ESLint Disable. There's Fallow Disable. Or it can be that a certain category of findings is something that you would want to disable together. So, there's an option to do that, as well. It's possible that it's an actual bug in Fallow. So, if that's the case, just shoot an issue on GitHub. And, yeah. In some cases, because the way Fallow works, it tries to detect the framework you're using. And some of the false positives are due to internal framework configuration stuff. So, most of the larger frameworks, like React, Angular, Vue, those are all covered. But if you use something a little less, something a little less wide used, it can be because of things frameworks do that they display false positives. Yeah, and, yeah, folks. This is an open source project. Feel free to send a pull request. Maybe it's even a better option today.

So the next question is, first, personally, I'm not a big fan of one-to-one comparison of the products. But, anyway, how does this compare to Sonar, if you use this one? Yeah, yeah. I have worked at companies that use Sonar, and I think Sonar is a great tool that does a lot of similar stuff. Sonar is a lot bigger, broader, just every language out there. But I think the main difference is that Sonar is more geared to be a dashboard. So it's something that you look at after you have created your pull requests. It reports findings on your PR, and you can look at the dashboard. But for TypeScript, JavaScript specifically, my experience was that the tooling to run it locally is not that great. That was a while ago that I last used it. So it might have improved. But the only real way to see all those findings is to afterwards look at the dashboard. And I wanted to create something and use something that immediately answers these kind of questions and can immediately pipe their results back to the agent so it can fix itself.

Yeah, I think that's practical advice for folks who use Sonar. Just give it a try to follow. Maybe you combine these products, maybe you take a different technical decision. I think that's an absolutely good idea to experiment with different products. A bit of a technical question from Brad. What process do you like to use to flesh out plans and intent before you send the implementation to an agent? Yeah, that's a good question. I don't think this is really related to Fellow itself because I try to keep, like I showed, the intent about the actual feature you want and not so specifically about how it should implement it. But as far as my process goes, I try to put a lot of effort into writing the plans. So there's, I think he's called Pocock, Matt Pocock, who has a repository out there with a lot of different skills related to working with AI. And I think my setup somewhat resembles what he has, which is a lot of effort into getting the plans properly. I try to get all the guessing from the agent out of the way so it has a plan that's really specific into the feature you actually want. So this is both for building Fellow and for building the other work that I do. So that once the agent sets off, the plan is really well defined and as much as I want it to be. Yeah, I I think what you shared is a very modern, up-to-date general recommendation split into multiple steps, research, plan, and then implement. Sometimes you can skip research, but plan and implement, yeah, they should be kind of separated. Yeah, one little thing is that I also have something which I call the review panel, which are a couple of different agents that have a persona, which I model around users of the tool. So I can spin that up once I have my plan ready. And they often give me feedback about how real people would react to certain changes. So it helps me do something solo with a group of people who are actually not there, but in spirit. Exactly, exactly. And again, I'm always curious how different developers use AI tools differently in case of open-source repositories. So yeah, everyone, folks, you can go and check what kind of skills, what kind of custom agents Bart is using in this particular project. Always insightful, I'd say. Definitely, I will find something for myself. The question about portability, so this is specifically a PipeScript thing, JavaScript thing, right? Can we apply some techniques, maybe high-level, low-level to other programming language and architectures? Yeah, there are two sides to this, I think, or at least two sides. One side is something that Fellow calls health, which reasons about what well-maintainable codes. And those principles are from people who are a lot smarter than I am, which have PhDs, et cetera. And those, I think, you can apply to any language. But there is also, recently, there was someone who created an issue feature request about a certain metric that he thought was a good idea to add to Fellow, which I really researched and tried to get to fit. But it was, I think it was Elcom 4, for people who know about that stuff.

But it just didn't really fit into PipeScript because it was punishing classes that had certain methods. But in the way that we use PipeScript for the web, we have Angular and NestJS, for example, who add a lot of methods to a class which were not created by the framework. So, yeah, it didn't really work, but stuff that's in there, I think, is portable to other languages. And I think the same for the architecture stuff, which Fellow tries to maintain. The defaults that are in here are specific to how PipeScript projects for the web are currently set up. But all the models like MVC, etc, you are able to model those with certain Fellow settings.

And as on the other side, porting it to other languages as a tool itself, that was a little bit harder because a lot of the work that Fellow does is built around building a graph of your code base. And to be able to do that, it needs to know a lot about entry points. So where does your application start? And those entry points are based a lot on framework stuff. So for React, NestJS, Angular, those all have specific files, locations. So Fellow knows, this is the NestJS app. We have pages. Those are entry points, and we can follow the graph along that path. And yeah, other languages do those things differently. And building the graph itself is built on the Oxium Rust packages, crates, I need to say. And those only work for PipeScript. So the general principles are portable to other languages. But the tool itself, at the moment, not.

Yeah, fair enough. I think that's a great opportunity for people who watch us now, maybe if you want to have something like that for your favorite programming language, just adopt these high-level ideas, kind of meta-Fellow, right? But land it, ground it on your programming language of your choice. So it's a challenge for everyone, folks, who watch us today.

And the last question of today's event, I specifically want to have this one from Alejandro, our today's most active participant in Q&A session. Great job, Alejandro. And it's about this always-choice, continue existing session or start a new one. So what's your take on, is it better to add input of the fix into the same context, or is it better to spin up a new session to avoid context fraud, maybe also not to inflate costs, etc.? So what's your take on that? Yeah, I think this is a really hard question, Alejandro. And I don't really know what the best answer for this is.

Back in the day, and I think, I don't know how it started, but everyone sort of was like, if you have 50% left in your context window, you can ask another question. If you have less, you need to start a new session. But at the moment that Opus and Tropic went to a million token window, I kind of stopped watching that. So now I always finish the session in the current context window with the idea that the agent made a certain decision based on an assumption. And if the agent still knows why it did something, which could have been something that you asked him to do, it can also better know when to stop and ask you if this is really what you want, instead of when you're in a fresh session, all that context is of course lost, which is on one side, the reason that you made the decision to start a new session, to get it in a fresh state of mind. So yeah, I think it's mostly better to keep it in the current context, unless there's... In general, the answer is, it depends.

I didn't want to say it depends. It could be the third most complex problem in software engineering, like naming, cache validation, and start or not start a new session. Thank you so much, Bart. Everyone, find Bart on LinkedIn, find myself on LinkedIn, let's stay connected. Thank you so much. It was a great pleasure to watch your session and have a conversation with you. Thank you. Thank you.