DEV Community: Will Green

My Experience with AI, One Month In

Will Green — Thu, 05 Feb 2026 23:32:32 +0000

I’ve been pretty skeptical about AI for software development. I recently started a new job at Netwrix, and I’ve been encouraged to really give it a go. So, I’ve taken this first month to try it out in earnest. We’re using Claude Code. Here’s what I’ve found:

It’s really helpful to get a high-level overview of existing code bases. I can clone repositories and ask Claude to summarize the project. I get a 10,000-foot overview of the architecture, capabilities, and dependencies. I can ask it to focus in on areas of interest and ask deeper questions. As a new employee in a high-level engineering IC role, this capability is invaluable in getting a lay of the land.

I’ve also found it useful, when combined with the Superpowers plugin and skills, for designing, planning, and executing features. I start with the “brainstorming” skill. I describe at a high level what I want to do, like “add backend for frontend handling for OIDC” or “set up CI with artifact publishing on merges to main, and optional publication of preview artifacts on pull requests”. It will then get to work, searching the web as needed, and ask me some clarifying questions. I’ll go back and forth with it, and when it thinks it has a design, it presents me with a design markdown document. It goes through it with me section by section, and we review it, perhaps asking questions on things that are unclear to me or just don’t seem right. Claude will work some more, often presenting me with options. From there, I’ll ask about the trade-offs and sometimes ask about an option I know about that it didn’t consider. This back and forth will continue until I’m satisfied with the design. I can then take this design to the team, product security, and stakeholders as needed to make sure we agree. If necessary, we can fire up Claude again and tell it we want to revise the design. The important thing here is that there is still a human (or multiple humans) in the loop throughout the design process.

Once we have a design that we like, I’ll use the “write plan” skill, again from Superpowers. I’ll do this in a new session with a fresh context window. Claude will load up the design document, examine the code base, and start breaking it down into workable tasks, organized in phases if there are a lot of them. Claude may again ask some clarifying questions and present me with an implementation plan, again in the form of a markdown document, for review. I use the tool to make any revisions necessary before moving on to implementation. Again, there’s a human in the loop, supervising and making decisions. I find here that if there’s more than a dozen or so tasks, it’s a sign that what I’m looking to do is probably too big to be reasonably implemented in a single PR. I haven’t yet settled on the best strategy to deal with this. One option I’m considering is doing one section of work per worktree and PR that. I know that what I don’t want to do is dump a 10k line PR and ask my team or Claude to review it.

When I’m ready to start implementation, I’ll again clear the context and use the “implement plan” skill to start a new worktree. This skill uses the implementation plan from the previous session to start working on the tasks in chunks. It has been given the directive to make commits after every task. As with the previous steps, I remain in the loop, reviewing the code Claude generates before allowing it to commit. If I’m not happy with what I see, I’ll check with the implementation plan to make sure that my concern isn’t going to be addressed in a future task. Otherwise, I’ll tell Claude not to commit and address the issues. Once I’m happy with that, I’ll allow Claude to commit. One of the nice things that this skill does when it crafts commits is that it includes the Co-Authored-By: trailer. This is a clear indicator to others that Claude assisted with this, and it shows as much in GitHub. Another nice thing of the Superpowers plugin is that it includes a subagent that is tasked with reviewing the last commit, checking it against the plan as well as best practices. If it finds issues, it will send it back to the implementation agent to correct. Pretty neat!

Once the tasks are complete, Claude prompts me to open a pull request. When I agree to, it crafts a detailed description of the change so that others can understand better the intent of the change. In some cases, it will include a checklist of actions that remain to be taken for verification. I’ve found pretty good success having Claude, after clearing the context, ready the PR description and assist me with performing those tasks.

My overall takeaways:

I’m impressed with Claude’s capabilities, especially when coupled with the Superpowers plugin. I find it imperative to keep myself in the loop at all phases, to help keep things on track. I also find that the Superpowers workflows model the ways in which I would (or should) work in the absence of an AI assistant. In fact, I feel like it is helping me to be more disciplined in that regard, and more work for me when I try to take on too much at once.

Now that Anthropic has released Opus 4.6, it will be interesting to see how the frequency with which I have to manage context changes.

Apollo Server(less), REST APIs, DynamoDB, and Caching

Will Green — Wed, 24 Jul 2019 04:10:01 +0000

My team ran into an interesting issue today with our configuration of Apollo Server, data sources, and our caching layer. It stems from our architecture decisions, and how seemingly sensible defaults can lead to failures. Fortunately, it has a happy ending with a fix in less than a dozen lines of code.

Let's start from the outside and work our in...

Outermost Layer: Apollo Server

My team decided, for various reasons that I'm happy to elaborate on in a another post, went with an entirely serverless architecture on AWS for our application. That means all our code is deployed in Lambda functions. We love it, but it comes with tradeoffs. At the time of this writing, the biggest of these has to do with interacting with certain other AWS services that can only be deployed within a VPC (Virtual Private Cloud). Services such as RDS (Relational Database Service), and importantly for this story, ElastiCache (managed Redis & Memcache).

By default, when you deploy a Lambda function, it is not deployed into A VPC. The API calls to invoke the function are open to the Internet, but protected by IAM Authorization. You do have the option to specify a VPC to attach the function to. However, here's where the tradeoffs come in. First of all, you need to configure the VPC to have multiple IP subnets large enough to accommodate the maximum concurrency (how many instances of your function can execute at the same time) across all the functions that you want to attach to this VPC. Second, you need to configure Security Groups that allow your functions in the Lambda subnets to talk to the resources, such as Redis, in the other subnets. Third, you need to set up VPC Endpoints for any services that you use that aren't natively resident inside a VPC, such as S3 and DynamoDB. Finally, if you access any APIs out on the Internet, you'll also need to set up a NAT Gateway. That's a lot of networking setup, and a lot of things to misconfigure!

Even if you set up your VPC correctly, you'll soon discover that the cold-start (first time an instance of your function is run) time is atrocious, on the order of 10-20 seconds before your code can start executing. That's because of the mechanics of attaching Lambda to a VPC requires setting up an ENI (Elastic Network Interface) for each instance of your function. ENIs were not designed to for quick setup and teardown. This reason alone makes attaching a function to a VPC a non-starter for an API that services a web app.

For that reason, we opted to forgo anything that required a VPC and deploy our Apollo Server Lambda unattached. That means that Redis and Memcache are out of the question for caching.

Caching

When I talk about caching here, I'm speaking about DataSource caching, and specifically how it interacts with RESTDataSource. RESTDataSource allows you to create an abstraction for calling REST APIs in your resolver functions. Its interface allows the Apollo GraphQL engine to insert a cache into the process, such that repeated requests will only hit the network once, and duplicate requests will use the cache. By default, this is an in-memory cache, but if you're running with a concurrency greater than 1, which you almost certainly will with Lambda, you're going to want to use an external cache service, such as Redis. However, Redis needs to be deployed inside a VPC, and as previously discussed, this is a non-starter for our architecture.

Enter apollo-server-cache-dynamodb, a Node module that I wrote to use DyanmoDB as a Key Value cache, with automatic key expiration. You configure this and plug it in to the Apollo Server configuration, and it takes care of injecting it into your Data Sources. All your Data Source GET requests will be cached in DynamoDB, using the request url as the key.

Cache Key

If your Spidey-sense tingled at the thought of using the request url as the cache key, you'd be right. This, in fact, turned out to be the source of our problems. The way we are querying an API results in a very long query string. So long, in fact, that it breached the DynamoDB limit of 2048 bytes for a partition key. When the RESTDataSource class went to cache the response for one of these very long urls in DynamoDB, it would raise an error and cause the entire GraphQL request to fail.

Fortunately for us, RESTDataSource provides a number of ways to hook into interesting request and response events. For example, there's willSendRequest, which allows you to set an Authorization header for every request. There's also cacheKeyFor, which allows you to calculate your own cache key for the request. This is the hook we needed in order to generate a cache key suitable for use as a DynamoDB partition key.

Cache Key Calculation

We decided that we'd use a hashing function to calculate a unique identifier for the request url. We quickly realized that we would make our cache ineffective if we didn't take care to sort the query string parameters using a stable sort algorithm. As it turns out, the WHAT-WG URLSearchParams interface provides a sort method:

The URLSearchParams.sort() method sorts all key/value pairs contained in this object in place and returns undefined. The sort order is according to unicode code points of the keys. This method uses a stable sorting algorithm (i.e. the relative order between key/value pairs with equal keys will be preserved).

Bazinga! Once we had a way to stably sort the query params, generating an identifier for the request was very straight forward. Initially, we went with a straight sha1 hex digest, but ultimately we opted to go with a UUID v5.

Here's what our cacheKeyFor implementation looks like, using the uuid package:

cacheKeyFor(request){
  const requestUrl = new URL(request.url);
  requestUrl.queryParams.sort();
  return uuidv5(requestUrl.toString(), uuidv5.URL);
}

Apollo Client fetchPolicies, React, and Pre-Rendering

Will Green — Thu, 18 Jul 2019 16:09:57 +0000

Background

My team at FireEye built the FireEye Market as a React app with a GraphQL (Apollo Server Lambda) backend. It's a marketplace to "Discover apps, extensions, and add-ons that integrate with and extend your FireEye experience." One of the things we discovered early on was that we needed to work to improve the Time to First Meaning Paint (TTFMP). We couldn't really reduce our bundle size further, and we already do code splitting. So we looked instead to generate static HTML, with the Apollo Client cache data serialized into the markup. This allows the client to quickly download a fully rendered HTML page, to begin interacting with immediately, while the React app scripts are downloaded and evaluated by the browser. When the React app hydrates, it has been configured to read the serialized data into the Apollo Client cache, which then makes the data instantly available to the React app to update the component tree. However, there is a catch...

Enter `fetchPolicy`

Apollo Client, and the corresponding React components (Query, Mutation, Subscription, and graphql HOC that encapsulates them) that consume the client, have an option called fetchPolicy. What this does is control how the components interact with the Apollo Client cache. This is very powerful, but the documentation for it is spread out in a couple places in the Apollo docs. My aim here is to consolidate that information, and hopefully, clarify it a bit.

The valid values for cachePolicy are:

`cache-first`

This is the default if you don't explicitly specify an option. What this means is that the client will look in its cache, and if it finds all of the data it needs to fulfill the query, it will use that and not make a network request for the data. Each of the queries you make, along with the arguments, are stored in the cache. If the query is cached, then it will use the data from this query. I believe that the selection set of the query is also considered, so if that differs, a network request will be made.

I'm admittedly unsure on this last point. The FireEye Market app has a known set of queries that the client executes, which differ only in the parameters passed at runtime.

`cache-and-network`

This policy will look in the cache first, and use that data if available. It will always make a network request, updating the cache and returning the fresh data when available. This may result in an additional update to your components when the fresh data comes in. This policy optimizes for getting cached data to the client quickly, while also ensuring that fresh data is always fetched.

This is the policy that we have found to work best for most cases when dealing with pre-rendering.

`network-only`

This policy skips reading from the cache altogether and goes straight to the network for data. Queries using this option will never read from the cache. It will, however, write the results to the cache. This is for the situation where you always want to go to the backend for data, and are willing to pay for it in response time.

`cache-only`

This policy exclusively reads from the cache, and will never go to network. If the data doesn't exist in the cache, then an error is thrown. This is useful for scenarios where you want the client to operate in offline mode only, where the entirety of the data exists on the client.

I've never used this policy myself, so take that assertion with a giant grain of salt.

`no-cache`

This policy will never read data from, nor write data to, the cache.

Configuration

Armed with this knowledge of fetchPolicy, how do you configure it? There's two places: in the client config, and in the request config.

Client Configuration

When you configure the Apollo Client instance, you can provide it with a defaultOptions key, which specifies the policy each type of query should use unless specifically provided by the request.

const defaultOptions = {
  watchQuery: {
    fetchPolicy: 'cache-and-network',
    errorPolicy: 'ignore',
  },
  query: {
    fetchPolicy: 'network-only',
    errorPolicy: 'all',
  },
  mutate: {
    errorPolicy: 'all'
  }
}

From the docs:

Note: The React Apollo <Query /> component uses Apollo Client's watchQuery functionality, so if you would like to set defaultOptions when using <Query />, be sure to set them under the defaultOptions.watchQuery property.

Also note that the graphql HOC, which given a document that is a query, ends up wrapping an instance of the <Query /> component.

Request Configuration

You can also specify the fetchPolicy per request. One of the props that you can provide to the <Query /> component is fetchPolicy. This will override whatever is configured in the client for this query only.

<Query query={QUERY_DOCUMENT} fetchPolicy="network-only">
  {(data) => { /* render prop! */ }}
</Query>

Similarly for the graphql HOC, you can specify a fetchPolicy in the config object:

const listAppsForNotificatonSettings = graphql(APPS_FOR_NOTIFICATION_SETTINGS_QUERY, {
  options: {
    fetchPolicy: 'cache-first' 
  }
});

Conclusion

As I mentioned, we found that this cache-and-network policy ended up being the best option for providing the best experience for our customers when serving up pre-rendered pages for various entry points into the application. In a few cases, we found that using cache-first was a better option, but this are few. As always, this is what worked for my team. Your mileage may vary.