Thoughts on CodeGoalie

Agents Calm Down

Mon, 30 Mar 2026 07:21:16 -0400

Agentic coding harnesses are violating the unix philosophy and trying to become the everything app for coding (and work and personal assistant and so on).

Why not build everything?

Many of the articles I’m reading are saying what we’ve been saying all along, “writing the code hasn’t been the bottleneck.” No project was late because engineers didn’t spend enough time sitting at their desks typing code. And now that writing the code is approaching zero, I think it’s more important than ever to carefully, methodically consider every project and initiative.

“This feature is not a good fit for coding agents so we aren’t going to put it into our harness.”

No AI company ever

Non-engineering folks have long enjoyed the luxury of engineering being the bottleneck (not writing code, but review, deploy, integration, etc.) and have been able to change requirements, goals and targets while we were working. When we can take a set of requirements and later that afternoon be dev complete… Just think about what would have happened if we’d implemented verbatim some of those first draft project proposals?

I’m working on a personal project to upgrade my personal daily task list from a plain markdown file to use Remember The Milk (the only task tracking app which gets recurring items right, but I digress). I have a pretty decent idea of what I want. I’ve been working in this flow for over 8 years after all. I’m, of course, having an agent write all the code. But I’m going slow. I’m carefully considering each feature and more precisely how it should work than I ever have ahead of time before. I feel this great responsibility to move intentionally because I have this great power to push a button, fold 5 pieces of clothes, turn back to my laptop and have a working feature.

To me, LLMs and agents and all of it, from the start, has never been about getting faster. It’s about reducing the “manual” effort of willing a (software) thing into existence. As I’ve been gaining experience with agents et al, I keep coming back time and time again to the best practices of the industry: “have a really good and detailed scope doc,” “compare that to the code and form a focused implementation plan,” “break that down into units of work that depend on each other or can be done in parallel.” We always wanted that but it was too time consuming to do and we relied on each other’s existing context. Many tickets don’t have any body description. We just talked about the project scope in the kick off, but didn’t formalize a document. Ironically, the machine is forcing (and enabling) us to do the things that would have been best all along, even for humans.

Do one thing well

Time and again the best software is focused and does one thing really well. That’s the unix philosophy. Composability over batteries included. Make a simple and powerful tool to let those using it combine it with other simple and powerful tools to make something greater than the sum of the tools themselves.

These new releases in the agent harnesses are hard to reason about because many of the new features feel half-baked and not rooted in solving a real problem. I end up feeling obligated to find use for them. It’s FOMO a bit. “Well, if they implemented it and released it, it must be something good. I must be missing something if I can’t find the use case.”

It’s hard to face this down. The company worth tens of billions of dollars is churning out features on the most talked about software of the moment and my gut is telling me to ignore most of it. I got bored and frustrated really quickly babysitting the agent. “Yes” “Approve” over and over. Same prompt. Same slash command. Same skill. Tweak it a bit here and there. Now, I’m automating it and running into some longing for more focus on a simple tool that I can work with not indefinitely inside of.

Do less

I don’t want to leave on a down note so let’s talk solutions. Do less. Make more. Let’s build an ecosystem around this tool. Let’s solve the rest of the SDLC competently. LLMs are a versatile technology and are made even more powerful with agent harnesses. They aren’t a silver bullet either. I love that we’re pushing the envelope of what can these things do. I love that we don’t know yet. It’s exciting to be a part of.

The more I work with agents the more I see how important the “old” best practices are. The more pre-planning matters. The more detailed specs matter. The more nailing down inter-service interacations matter. Start at the boundaries and work inward on both sides. Hand offs. Metrics. Automated end-to-end testing. There’s nothing new here. It’s just compressed and accelerated; and can be exhausting at times. In this age where we can build anything, the taste and discipline to not build something matters. I’d love to see that in the tools themselves.

Happy shipping!

– Chris

Use Your Noodler

Sat, 24 May 2025 06:52:56 -0400

A former coworker of mine over 8 years ago put this image into my head that has never left. He was working as my manager at the time and he had an upcoming large, foundational shifting feature that he wanted to let me know was coming. He said “Don’t do anything right now, but just put this in your noodler and see what comes out.”

He went on to explain that a former boss of his introduced the idea of the noodler to him. Now, I’m not your boss (I can confidently say that because I’m no ones boss as of this writing ;) ), but I’d still like to share this image with you that’s helped me so much and I’ve never been able to shake.

If you haven’t guessed by now, the noodler is the back part of your brain. Back near the subconscious, it’s like a rock tumbler. It’s always spinning and tumbling ideas without conscious effort. You just throw raw stuff into it and in a few days or so, see what pops out. Sometimes it’s just a smoother rock and sometimes it’s a true gem.

I like this metaphor for a few reasons. First, it’s a pretty vivid, concrete concept. I always imagine that red, kid’s science kit version of a rock tumbler that I always wanted. Now I have one and it’s turning half-baked, super hazy concepts into novel, actionable ideas.

Second, it’s an escape hatch. Do this one easy thing, make progress, done for the day. Take something off your plate. You can rest easier knowing that something, somewhere is happening, but you don’t need to spend active energy on it, right now. Wash the dishes and think about the birds outside. Mow the lawn and listen to that podcast. It’s OK. Some other part of you has got this.

Lastly, it works. Not all the time. But more often than not, something comes to me and I can make a small step, or a bigger leap. And if it doesn’t, typically, I’m no worse off.

Happy noodling!!

– Chris

Web Scraping 2.0

Wed, 23 Jun 2021 06:21:51 -0400

With the wide adoption of robust front-end frameworks and CSS-in-JS, traditional methods of targeting xpath or CSS selectors for scraping data from web pages are becoming ineffective. However, this new paradigm of front-end development leaves a key opportunity to improve the web scraping experience.

Having data that’s not readily available in an API is something that I’ve kind of become obsessed with over the past year or so. Even with access to public datasets becoming more and more prevalant, I still wanted access to data from websites or companies that I use but have no interest in separating their data from their platform. So, how do you scrape a React or Angular or other front-end framework app/site? While scraping the data from the HTML may not be feasible or break constantly, you can use their API. The same API the front-end uses. However, often these private APIs are resistant to general use through opaque authentication and authorization mechanisms which make them more work than it’s worth to try and write a traditional API client.

Why not both?

Instead of an either/or approach, a hybrid approach can be used by leveraging browser automation and API requests to quickly and reliably get the data we need. Specifically, executing JS fetch requests using browser automation tools (almost all allow arbitrary JS execution in the current “page”). Parse this request back into the native automation language (typically JSON string returned from JS). Bam! You have a pseudo API!

I’ve been very successful in pulling large amounts of data from an actively scraper resistant environment using this approach. One of the really nice things is that authentication/authorization for the private API requests is handled virtually automatically by the browser through cookies.

Here’s a rough outline of the entire process:

Manually go through the web application performing the actions intended to be automated while watching the network dev tools tab.
Note any requests of interest.
Generalize those requests and reverse engineer a subset of the API.
Begin automation.
Automate authentication, if necessary (Type creds into login form).
Evaluate JS on the page to execute the AJAX/XHR/private API requests.
Parse the returned string into datatypes in your native automation language.
???
Profit!!?

My intuition leads me to believe there are some common patterns here which may be surfaceable in a library, but my experience isn’t quite to the point where I feel confident providing the right abstractions. But, stay tuned and we’ll see how this idea unfolds.

Let me know how your experience scraping data from JS heavy web apps goes! I’d love to know if this works for you or if this ends up being more hassle than it’s worth.

Happy scraping!