These are the questions everyone seems to be ignoring and saying “only LLMs can make projects quickly” but ignoring everything those LLMs are built on (your llmis probably calling a code gen tool).
For the at work side, I personally haven’t experienced any disadvantages or missed any project deadlines because I didn’t use an LLM, so what does velocity get me? Thumb twiddling time?
High quality ensued. Usually ;)
Yes, very much so. Our team was fast with those tools and created many of our own before this LLM AI (we used other AIs though to go faster), however it still took weeks to months from idea to launch; the same complexity now takes days, including everything. We already had rigorous processes and those really help now moving at speed. No way anyone can beat this except better AI.
I was thinking the other day how much better Drupal is. Want a online store? A few commands and bam, online store. Want a newspaper? A few commands and bam, newspaper with publishing workflows, user management, and caching.
Using coding agents isn't much different. There are several things the models are trained to do very well and a few commands will get something. If the developer wants to move the project beyond that, it requires domain knowledge and a lot of hacking.
I wonder if the coding agents will move towards the Drupal model where they create interchangeable components with common interfaces. Like Drupal the coding agents never provide anything truly inovative that hasn't been done before.
I work as a DevOps engineer and have been using agents exclusively to code since the beginning of the year. Agents are really nice to quickly craft utilities to speed up planning. For instance I had it create a small cli for me that'll pull my cards from azure DevOps, load them as json, markdown and csv, and push updates once I'm done. Then I'll load into context transcripts of meetings and other written requirements, cross with current state of repos, to have meaningfully conrextualized work items without me having to implement these myself. I'll just have a long chat with the agent exploring these cards and defining the necessary refinements for description and acceptance criteria than I jusr push them all at once. Anything you can think of you just ask for the agent, so for me I don't trust code, so I'll have all my clis be no-op by default, so they will first print all they'll do and if I think the changes make sense I approve them and let the script commit to the canonical board.
Working with cloud consoles like Aws in general is a huge hassle, so crafting quick inventory utilities and tools for correlating data is a breeze.
Now the work itself is mainly ci pipelines, terraform files and automation. For these I'll base the agents on the specified work items and enrich them with my own understanding of the problem. I then launch the agents and read the agent output attentively. This is very important. You can't just prompt and leave, you need to be present all the time so you can steer the agent into solving the right problems. At the very least you need to review all the changes after an implementation session is done when you came back from making coffee. Many times it tries to create meaningless abstractions or very complicated solutions that I know can be done better. Or I have a different idea of how to organize the project so I do many follow-up sessions to refactor code.
In my personal projects I do a lot of small utilities. I spent some weeks designing and polishing a replacement for zurg and debridmediamanager the way I like it to be, simple and to the point, also tightly integrating them with jellyfin https://gitlab.com/gabriel.chamon/buzz
I have my own micro desktop environment on top of hyprland called Archie which recently I've been redesigning and improving a lot with agents https://gitlab.com/gabriel.chamon/archie
I have my own agile based methodology for creating and managing work items with tight integration with gitlab https://gitlab.com/gabriel.chamon/orisun
I have been improving my fork if gamma-launcher so that installing and managing the game on bazzite is simpler and more automated than relying on workarounds for workflows intended for windows https://gitlab.com/gabriel.chamon/gamma-launcher
Now for how I approach developing with agents. I think it's really important to get your constraints sorted out as soon as possible, so have your agent create a CI pipeline for code quality testing, like with ruff, pyright and pytest, to control style, code consistency and cyclomatic complexity. Put in the AGENTS.md explicit instructions that the agent must run these tools at the end of every coding session. If adopting a new project, use the agent to explore the code and see which refactoring points are worth tackling. Agents really thrive on good codebases, so this first code quality improvement pass is a must.
To sum it up, with agents you give up writing code manually for reading lots of code, exploring the domain with the help of the agent and architecting the solution at a strategic level. You trust the agent but you also verify. And lots and lots of manual testing. My personal take is that I'm infinitely productive now, only constrained by how much code and agent terminal output I can read, and also by the rate limits of the model providers and mental fatigue.
Either you would get chastised for wasting time with prototypes, or worse, your prototype would end up in production
I think the software industry really needs a cultural reset to embrace slower and deliberate development to build quality, but unfortunately AI has us racing recklessly in the wrong direction
I am so tired of it. Are there any companies out there that actually give devs time to build quality software anymore? I'm so burned out of the "move fast and break everything" grind
What did the time savings gain you? A quicker release date? How can you prove that? “This would have taken weeks” is the old problem of project time estimation. How can I take any engineer seriously that they think they know it saved weeks?
Reminds me a bit of this blog post[0].
I remember doing a Drupal project around that time and being astonished at how powerful it was.
I also remember feeling more like a technician connecting various components than like a software engineer, writing code.
I totally saw the value for the client but I really disliked my experience, so I avoided it afterwards.
0: https://www.rickmanelius.com/p/the-website-rfp-and-the-impos...
Has this (for me, normal) process really been that arduous in your past jobs? It's a slam dunk to leadership, as we do this to corral time wasted.
Imagine if instead of f AI generated code, we all just started copying and pasting code from open source repos.
Imagine my velocity! I cloned the Linux kernel in seconds!
Instead we're basically doing exactly that, except through an AI remixer.
It leaves a very sour taste in my mouth
So you do no validation of the code that’s generated? Just asking because you didn’t state that as a step in your process. You’re prototyping to running then you’re missing a big step that will most likely cost you later.
Why does it matter how much time I spent writing code for a project I’m most likely either not sharing or if I am sharing it can be obtained for free? Which market am I rushing to? Bluntness doesnt seem to be an advantage other than bragging.
The Speed of Prototyping in the Age of AI
Sunday 31st May, 2026 · 7 minutes
Note: These are personal reflections on how my workflow has shifted over the past year, not a pitch for any tool. Your mileage will (and probably should) vary.
A few years back I wrote about my love of throwaway prototypes; those little proof-of-concepts that exist purely to get an idea out of your head and into something tangible. At the time, my biggest bottleneck was me; the time it took to scaffold a project, wire up the boring bits, and get to a place where the interesting parts could actually be tested. Fast forward to now, and that bottleneck has all but vanished.
I've been a little hesitant to write about this. I've already shared some cautious thoughts on AI and where it fits into my workflow, and I stand by all of it. I still think the industry is figuring things out in real time, and I still think it pays to be careful. But cautious doesn't mean blind, and the honest truth is that AI has changed how quickly I can go from "I wonder if…" to "oh, it works".
If you've looked at my recently, you'll have noticed a stream of new repos showing up. Sakoa, a progressive systems language I've been designing from scratch, complete with an effect system, three memory modes, and a MIR with multiple backends. Kato, a notation language meant to sit somewhere between JSON, TOML, and YAML, but explicitly designed to be friendly to both humans and agents. Seal, a tiny CLI that quietly kills the .env file by stashing secrets in OS-native credential stores. Karabiner, an iOS-first agent-native messaging app. Plim, a Notion-inspired, embeddable block editor for the web with a framework-agnostic core and React bindings. And a few more knocking around that aren't ready for the spotlight yet.
A few years ago, that list would have been three repos with READMEs, two abandoned branches, and one working prototype I'd be quietly proud of. Now? The prototypes exist. They run. Some of them have tests. A couple are starting to look like real projects. And while not all of them will turn into anything serious (and that's kind of the point), there is something really satisfying about being able to actually try an idea, rather than just talk about it.
The thing nobody really warned me about is how much AI changes the shape of engineering work, not just the speed of it. When I'm not the one typing every line, I'm forced to think differently. I'm thinking about boundaries, contracts, and how the pieces fit together. I'm writing prompts and specs that describe the system holistically, before the system exists.
That shift sounds small but it's been quietly transformative. I'm planning at a more abstracted level, framing problems before I solve them, and I've gotten noticeably better at delegating; both to agents and to people. Turns out that the skill of "describing exactly what success looks like, in a way that a junior engineer (or a model) can act on without you in the room" is the same skill in both directions. Sharing vision, breaking work down, anticipating where things might go wrong; these are muscles I've been forced to exercise much more deliberately, and I'm better for it.
I've been tracking this loosely for a while, mostly out of curiosity. Based on my own day-to-day engineering tasks (measured roughly by time-to-PR for typical pieces of work), I'm averaging about 4x faster than I was before agents became a meaningful part of my workflow. Some days it's more, some days it's less, and some days the agent does something delightfully strange that costs me an hour to undo (which I'll happily count against the average).
But that number understates the more interesting effect: the kind of work I can take on has changed. Things I would have previously parked under "nice idea, no time" now slot into an afternoon. Refactors I would have winced at are doable. The cost of trying something has dropped enough that I'll just try things I'd otherwise have argued about in a doc.
It's not all upside. The same velocity that makes me productive also means I'm typing less code than I used to, and I've noticed I have to be deliberate about keeping my own technical dexterity sharp. If I let it, the tools will happily do all of it; and that's not really a deal I want to make. I still want to know how the things I work on actually work.
So I've started carving out time for the manual bits on purpose. Implementing something end-to-end by hand. Reading source code instead of asking for a summary. Sitting with a debugger instead of pasting a stack trace into a chat. It's slower, sometimes frustrating, and probably necessary; both for my own sanity, and because the moments where AI isn't enough still call for an engineer who actually knows what they're doing.
The flip side of this is much more enjoyable: with the new velocity, it's surprisingly easy to carve out time for exploration, learning, and prototyping. The hours I used to spend on the unavoidable middle bits of a project are now freed up to play with new ideas, dig into things I don't fully understand, or just build something weird for the sake of it. That's a trade I'm happy to make.
This new pace has shown up in my day job too. Without going into too much detail (I'll save the proper write-ups for once I've got the appropriate sign-off), the velocity boost has let me make impact in a few different areas of my role that I wouldn't have had the bandwidth to touch otherwise:
Both of those are the kind of thing I probably would have had ideas about a couple of years ago but wouldn't have had the headroom to actually deliver alongside my core work. The change in velocity doesn't just speed up the things I was already doing; it expands the surface area of what I can do at all.
A few other engineers in the field have been writing about similar shifts, and it's been reassuring (and helpful) to read along. Two I'd particularly recommend:
I'd also nod at for a broader look at what coding agents are actually capable of in the wild; well worth a read if you haven't.
I still don't think AI is magic, and I'm still cautious about the broader picture; the environmental, financial, and social questions haven't gone anywhere. But for me, right now, the day-to-day reality is that I can move faster, think bigger, and ship more than I could before. And that's been genuinely fun.
I don't have a neat conclusion to wrap this up with. I'm just going to keep prototyping, keep getting my hands dirty when I need to, and keep paying attention to what changes and what doesn't. More thoughts as things continue to shift.
Until next time… ✌🏽